Недавно в нашей новостной ленте появились два Героя, программисты-пекари – Борис и Маркус. Борис – хороший человек и перфекционист, а Маркус – очень скромный и серый программист, не желающий выделяться. Оба стремятся к лучшему и хотят быть полезными. Но кажется, что Маркус не очень старался.
Это новая ветка – продолжение. Сегодня сюжетная линия коснется только Маркуса. Он – главный герой.
Итак, история под катом.
Читать полностью »
Рубрика «Проектирование и рефакторинг» - 73
Хлеб Маркуса и YAGNI
2012-10-06 в 15:00, admin, рубрики: .net, Программирование, Проектирование и рефакторинг, рефакторинг, метки: c++, Программирование, рефакторингДвигаем элементы в прототипе Axure
2012-09-26 в 0:20, admin, рубрики: axure, Веб-разработка, интерфейсы, Проектирование и рефакторинг, прототипирование, метки: axure, прототипированиеСегодня я столкнулся с проблемой, решением которой хотел бы поделиться. Эта заметка будет полезна тем, кто старается делать свои прототипы Axure максимально интерактивными.
Итак, задача. Визуализировать на прототипе добавление какого-либо объекта со сдвигом других объектов. Для примера возьмем добавление вопроса в сервисе онлайн-консультации.
Необходимо сделать так, чтобы при нажатии кнопки «Отправить» новый вопрос появлялся над старыми, а старые, в свою очередь, сдвигались вниз. Читать полностью »
Завяжите шнурки и подтяните свои штаны!
2012-09-08 в 23:51, admin, рубрики: архитектура по, никто не читает теги, проектирование, Проектирование и рефакторинг, разработка, рефакторинг, старпатИтак, что же замедляет разработку программного обеспечения?
Задумайтесь об этом вопросе на секунду. Как так выходит, что чем дольше Вы что-либо разрабатываете, тем сложнее и неприятнее добавлять в Ваше приложение новые фичи, попиливать архитектуру?
И почему раньше задачи решались так просто, а теперь выглядят запутанными и сложнореализуемыми?
Казалось бы, положение должно улучшаться, ведь Вы уже давно в проекте, разве нет? Почему всё происходит наоборот?
Читать полностью »
Главный принцип хорошего кода
2012-09-04 в 19:03, admin, рубрики: Программирование, программирование как искусство, Проектирование и рефакторинг, разработка, философия программирования, философия разработки, метки: программирование как искусство, философия программирования, философия разработкиЗа двадцать лет разнообразного программирования я сформулировал, убежден, главнейший принцип хорошего кода. Опираясь на него, мне и моим коллегам удавалось приводить в порядок самый страшный код, объединять в команде малосовместимых программистов и годами поддерживать системы без лишнего нытья.
Прочтение этой статьи: 15 минут
Осмысление методики: 10 минут
Ощутимые результаты: 30 минут
Протоколирование: рекомендации по трассировке
2012-08-30 в 20:24, admin, рубрики: Блог компании Инфопульс Украина, Программирование, Проектирование и рефакторинг 
В данной статье я хочу поделиться своими мыслями/наблюдениями/рекомендациями относительно реализации такой важной задачи при разработке ПО как протоколирование. В Интернете существует множество статей описывающих инструменты для протоколирования, но очень мало информации о том, какие именно события, и какую информацию, нужно записывать в протокол работы программы.
Читать полностью »
Практика рефакторинга в больших проектах
2012-08-22 в 11:25, admin, рубрики: Программирование, Проектирование и рефакторинг, рефакторинг, тестирование, метки: Программирование, рефакторинг, тестированиеНекоторое время назад я попал в геймдев, где столкнулся с проектами по 2 млн. строк кода, которые пишут десятки программистов. При таких масштабах кодобазы возникают проблемы неведомого мне ранее характера. Об одной и них я хочу вам сейчас рассказать.
Итак, представьте себе следующую ситуацию. Так уж случилось, что вам надо отрефакторить очень большой кусок кода, целую подсистему. Строк, эдак, на 200К. Причем рефакторинг явно выглядит очень крупным, затрагивающим базовые концепции, по которым построена ваша подсистема. Фактически надо переписать всю архитектуру, сохранив бизнес логику. Такое бывает, если, например, вы сделали один проект и у вас впереди новый, и вы хотите в нём исправить все ошибки прошлого. Допустим, по первым прикидкам, на рефакторинг надо месяца 2, не меньше. В процессе рефакторинга всё должно работать, в том числе нельзя мешать другим программистам добавлять новые фичи и чинить баги в подсистеме. Часто такой рефакторинг бывает насколько сложен, что совершенно невозможно замерджить старый код в новый, а также невозможно выкатить результат по частям. Фактически вам надо заменить двигатель самолёта на лету.
Примеры из практики, как моей, так и моих коллег:
- Переделать всю работу с базой данных с чистого JDBC на Hibernate.
- Переделать архитектуру сервиса с отсылки-приёмки сообщений на удалённый вызов процедур (RPC).
- Полностью переписать подсистему трансляции XML файлов в рантайм объекты.
Что делать? С какой стороны подойти к проблеме? Ниже представлен набор советов и практик, которые нам помогают справиться с этой проблемой. Сначала более общие слова, а потом конкретные методики. В общем-то ничего сверхъествественного, но кому-то может помочь.
Читать полностью »
Введение в CQRS + Event Sourcing: Часть 2
2012-08-12 в 15:09, admin, рубрики: .net, cqrs, DDD, event-driven, Веб-разработка, Проектирование и рефакторинг, метки: cqrs, DDD, event sourcing, event-drivenВ прошлой статье я начал с основ CQRS + Event Sourcing. В этот раз я предлагаю продолжить и более подробно посмотреть на ES.
В примере который я выкладывал с моей прошлой статьей магия Event Sourcing’а была скрыта за абстракцией IRepository и двумя методами IRepository.Save() и IRepository.GetById<>().
Для того чтобы поподробнее разобраться что происходит я решил рассказать о процессе сохранения и загрузки агрегата из Event Store на примере проекта Lokad IDDD Sample от Рината Абдулина. У него в аппликейшен сервисах идет прямое обращение к Event Store, без дополнительных абстракций, поэтому все выглядит очень наглядно. Application Service — это аналог CommandHandler, но который обрабатывает все комманды одного агрегата. Такоей подход очень удобный и мы тоже на него в одном проекте перешли.
Читать полностью »
«Впереди планеты всей», и как мы докатились до этого. Или краткое описание автоматизации рабочего процесса
2012-08-01 в 14:08, admin, рубрики: Delphi, Программирование, проектирование, Проектирование и рефакторинг, рефакторинг, метки: Delphi, Программирование, проектирование, рефакторинг 
Не хочу начинать сей рассказ с того, что это мой первый пост, какой я бедный-несчастный, не ругайте меня сильно и тд. и тп., а перейду непосредственно к делу.
Но для начала небольшое лирическое отступление. А вы чего хотели?
Работаю я в Обнинской/Калужской региональной редакции газеты «Из рук в руки», и должность моя — «сервис-менеджер». Но, по сути, я исполняю обязанности не только сервис-менеджера, но и быдлокодера Delphi и 1С (назвать себя программистом, пока что, язык не поворачивается). На эту работу я устроился примерно полгода назад, когда еще учился в техникуме. И так получилось, что я пришел туда в такой период, когда у руководства уже были идеи по улучшению рабочего процесса, но еще не было рук, которые бы этим занялись. Для начала мне дали задание написать конвертер для газетных объявлений, который бы менял их формат так, чтобы их можно было загружать на сайт, а то операторам не улыбается вручную парсить мегатонны строк в блокноте. Задание было успешно выполнено, после чего меня оформили, и выделили деньги для покупки Delphi XE2 Professional мне на новое рабочее место (да, у нас директор и сисадмин в одном лице, поэтому они быстро друг с другом договариваются, когда появляется необходимость закупить софт или хард). И когда я уже был в штате, мне доверили заняться инновацией — программой для составления объявлений. А тут начинается самое интересное…
Кому интересно, прошу под кат.
PS. присутствуют ссылки и картинки, но не для пиара/рекламы, а для более подробного описания.
Почему компьютерное зрение очень мало используется на практике
2012-07-30 в 13:00, admin, рубрики: Алгоритмы, Компьютерное зрение, машинное зрение, Песочница, Программирование, проектирование, Проектирование и рефакторинг, метки: Алгоритмы, Компьютерное зрение, машинное зрение, Программирование, проектированиеНа самом деле правильнее было бы назвать «машинное зрение», но так я думаю понятнее будет, если кто не знает то это не охранное видеонаблюдение, а распознавание или измерение чего либо c помощью камер. Существует много задач и областей, где компьютерное зрение было бы очень востребовано и могло бы использоваться повсеместно, но на практике оно используется очень редко.
Я реализовал несколько проектов в этой области для решения разных задач, конкретно это вычисление и подсчет площадей, контроль качества продукции, причем разной и в разных отраслях таких как: фигурная порезка и раскрой листов ДСП, ДВП, МДФ, измерение площадей шкурок животных на производства изделий из кожи и др.
Задача вычисления площади может показаться довольно сложной. Если подходить строго математически, то да, например, посчитать площадь квадрата или прямоугольника очень просто умножаем длину на ширину и готово, если треугольника чуть сложнее, а вот других криволинейных фигур может быть очень сложно.
Мой алгоритм подсчета площади настолько прост, что его можно реализовать без всяких библиотек и т.п. буквально в десять строк кода, по сути это простейший детектор движения только с калибровкой камеры. Камера жестко фиксируется над местом, куда подается продукция, делается снимок фона (без продукции), например, белый стол, цвета пикселей загоняются в массив. Далее на стол подается или ложится образец, например какая-то коробка. Далее делается второй снимок с коробкой, цвета второго кадра пишутся в другой массив и затем сравниваются значения цветов, количество отличающихся пикселей суммируется. Затем этот образец измеряется рулеткой, вводится в программу его площадь и вычисляется площадь одного пикселя, т.е. площадь делится на число пикселей. Вот и вся калибровка. Далее достаточно подавать любую продукцию, любого размера и формы, определятся число изменившихся пикселей, и умножается на площадь одного пикселя, найденного при калибровке, надеюсь все понятно. Причем продукция может двигаться, например, на конвейере, площадь будет измеряться правильно, нужно только захват Читать полностью »
О дизайне. Часть 2. Практические примеры
2012-07-28 в 10:37, admin, рубрики: .net, ood, Проектирование и рефакторинг, метки: ood, оопКак мы обсудили в прошлый раз, дизайн штука не простая; постоянно приходится держать в голове кучу всяких вариантов и стараться найти компромисс среди множества разных требований, раздирающих ваше элегантное решение на части. С одной стороны, хочется, чтобы решение было простым в сопровождении, хорошо расширяемым, с высокой производительностью, при этом оно должно быть понятным не только его автору, но еще как минимум одному человеку; хочется, чтобы решение ело мало памяти и не нарушало ни одного из 100 500 принципов ООП, ну и, самое главное, мы хотим его закончить хотя бы в этом году, хотя менеджер постоянно твердит, что оно должно было быть готово еще месяц назад.
Многие из названных критериев являются не очень совместимыми друг с другом, поэтому рано или поздно мы приходим к выводу, что хороший дизайн – он как уж, который старается протиснуться между десятков противоречивых требований, и найти разумный компромисс, максимально удовлетворяющий наиболее весомым требованиям, не забывая, что вес этих требований может еще и меняться с течением времени.
Читать полностью »