Успешный программный продукт обычно проходит за свою жизнь через руки множества разработчиков. Вы — лишь одно из звеньев в цепочке опекунов вашего проекта, и каждая строчка кода, которую Вы написали — это оставленный Вами артефакт, который когда-нибудь будет изучаться Будущим Разработчиком. Также, как Вы унаследовали решения разработчиков, которые были до Вас, другие разработчики унаследуют решения, которые Вы делаете сегодня. Они получат от нас в наследство все наши недоразумения, срезанные нами углы, примененные нами недопонятые паттерны и техники, наше невнимание к деталям, нашу лень, наши изменения, сделанные на скорую руку, наших скелетов в шкафах, наше грязное белье. И гораздо реже — выгоду от нашей дисциплинированности, наших обсуждений и подготовок.
Рубрика «Проектирование и рефакторинг» - 72
Работая в интересах Будущих Разработчиков
2012-11-20 в 15:09, admin, рубрики: cooperations, rails, ruby on rails, документация, командная работа, культура кода, паттерны, проектирование, Проектирование и рефакторинг, рефакторинг, Совершенный код
Опыт разработки плагина для Yasca
2012-11-11 в 17:10, admin, рубрики: c++, Code Style, java, php, Проектирование и рефакторинг, метки: c++, Code Style, java В этой статье я хочу поделиться опытом использования одной полезной утилиты, позволяющей автоматизировать сборку и анализ качества кода. Речь пойдет о Yasca — свободно распространяемом ПО, представляющем собой небольшой PHP движок и набор утилит для выполнения анализа Java, С++ или PHP кода, включающего в себя PMD, JLint и RATS. Сама интеграция выполнения этих утилит осуществляется путем разработки небольших плагинов, на языке PHP. О процессе разработки такого плагина и пойдет речь далее.
Читать полностью »
Progressive Enhancement или всё-таки Graceful Degradation
2012-11-02 в 8:47, admin, рубрики: graceful degradation, Progressive enhancement, serenity, Веб-разработка, принципы проектирования, Проектирование и рефакторинг, проектирование сайтов, разработка, метки: graceful degradation, Progressive enhancement, serenity, принципы проектирования, проектирование сайтов 
Нельзя просто так взять и рассказать про progressive enhancement, не упомянув о graceful degradation. В чем же разница между этими понятиями? Как уже говорилось в более ранней статье, graceful degradation можно перевести, как отказоустойчивость. Это очень широкое понятие, но в контексте веба его можно понимать как отказоустойчивость клиентских веб-интерфейсов, серверной части сайтов и так далее. В этой статье graceful degradation будет пониматься как отказоустойчивость клиентских веб-интерфейсов.
Graceful degradation может выражаться в возможности работы при отключенном JavaScript, в достаточно аккуратном отображении интерфейса в браузере, не поддерживающем новые свойства CSS3, в адекватном отображении сайта при отключенных изображениях. В каждом из этих случаев работа пользователя с интерфейсом будет в принципе возможна, хотя и не так удобна.
Читать полностью »
Простая поддержка окружений в Spring 3.1+
2012-10-30 в 13:25, admin, рубрики: java, spring, Программирование, Проектирование и рефакторинг, метки: springМногие знают что для подстановки значений в конфигурационные файлы Spring можно использовать context:property-placeholder.
<context:property-placeholder location="classpath*:/prop/*.properties"/> <!-- здесь будут искаться property файлы -->
<bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">
<constructor-arg ref="mongo"/>
<constructor-arg name="databaseName" value="${mongo.db}"/> <!-- здесь будет подставлено значение из найденных property -->
</bean>
Но, при данном подходе, можно лишь подставить различные значения параметров, но не изменить логику развертывания контекста. А ведь, в некоторых случаях, нам необходимо развернуть огромную систему, интегрированную с внешними системами, а в некоторых — просто одну маленькую заглушку.
Когда передо мной встала задача, в зависимости от окружения (dev, prod, load-test), изменить логику развертывания — я искренне попытался использовать старый проверенный способ через property.
Читать полностью »
Разработчики при написании кода визуализируют то, что пишут. По сути имитируют работу компьютера в голове. Но почему бы компьютеру самому не делать то, что разработчики имитируют?
Разработка через страдание
2012-10-24 в 12:20, admin, рубрики: DRY, KISS, Storm, suffering oriented programming, архитектура, Программирование, Проектирование и рефакторинг, разработка, разработка через страдание, рефакторинг От переводчика:
Немало копий сломано в спорах о том, когда уместнее KISS, а когда DRY, когда лучше как можно быстрее и проще решить задачу любыми средствами, а когда стоит создавать красивые и универсальные абстракции. Натан Марц, автор популярного фреймворка Storm, используемого в Твиттере, предлагает свой вариант. Чтобы не создавать тонны бесполезного кода ради абстрактной универсальности и в то же время не позволять системе превращаться в кашу из костылей, он использует «разработку через страдание» (suffering oriented programming).
Однажды меня спросили: «Как ты решился пойти на такой страшный риск — писать Storm одновременно с запуском стартапа?» (Storm — фреймворк для распределённых вычислений в реальном времени). Да, пожалуй, со стороны создание такого крупного проекта для стартапа кажется крайне рискованным. Тем не менее, с моей точки зрения это вообще не было рискованным делом. Трудным, но не рискованным.
Я использую стиль разработки, который сильно уменьшает степень риска таких больших проектов, как Storm. Я называю этот стиль «разработкой через страдание». В двух словах: не занимайтесь реализацией технологий, от отсутствия которых вы не испытываете страданий. Этот совет применим как к большим, архитектурным решениям, так и к маленьким повседневным задачам. Разработка через страдание существенно уменьшает риск, гарантируя, что вы всегда работаете над чем-то важным, и что вы хорошо разобрались в предметной области, прежде чем вложить в решение много сил.
Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».
Читать полностью »
Манифест эволюции программы
2012-10-19 в 16:13, admin, рубрики: IT-стандарты, информационные технологии, правила, Программирование, Проектирование и рефакторинг, разработка, метки: информационные технологии, правила, Программирование, разработкаДолгие годы меня удручает то, что я вижу в индустрии программирования — каждая последующая версия большинства программ или сервисов работает медленнее, жрет больше ресурсов и требует более мощного железа.
Это произошло с моим Macbook-ом, это произошло с моим iPhone-ом, это происходит с каждым апдейтом Windows, Visual Studio, Office, и т.д.
Программы работают медленней, веб-сайты тормозят, телефоны умножают мощность процессора при незаметных на глаз улучшениях производительности.
Читать полностью »
Манифест эволюции программ
2012-10-19 в 16:13, admin, рубрики: IT-стандарты, информационные технологии, правила, Программирование, Проектирование и рефакторинг, разработка, метки: информационные технологии, правила, Программирование, разработкаДолгие годы меня удручает то, что я вижу в индустрии программирования — каждая последующая версия большинства программ или сервисов работает медленнее, жрет больше ресурсов и требует более мощного железа.
Это произошло с моим Macbook-ом, это произошло с моим iPhone-ом, это происходит с каждым апдейтом Windows, Visual Studio, Office, и т.д.
Программы работают медленней, веб-сайты тормозят, телефоны умножают мощность процессора при незаметных на глаз улучшениях производительности.
Читать полностью »
Динамическая интерпретация метамоделей
2012-10-15 в 18:18, admin, рубрики: Анализ и проектирование систем, метамодель, метапрограммирование, моделирование, предметная область, Программирование, Проектирование и рефакторинг, метки: model, метамодель, метапрограммирование, моделирование, предметная область 
Продолжая серию статей по метапрограммированию, подготовил выжимку из достаточно объемной своей работы о повышении уровня абстракций в информационных системах. Хабр конечно любит практические решения, и их таки есть у меня, но материала много и я вынужден разделить его на несколько статей. А для иллюстрации эффективности подхода, могу сказать, что внедрение его во множестве живых проектов позволило повысить эффективность разработки в десятки раз, например, создавать приложения баз данных со структурой в несколько сотен таблиц за неделю и портировать решения между платформами за считанные часы. Эта статья носит характер теоретический и наполнена специфической терминологией, без которой, к сожалению, она была бы значительно объемнее.
Читать полностью »
Функциональное программирование в ООП
2012-10-08 в 14:08, admin, рубрики: clean code, ооп, Проектирование и рефакторинг, Совершенный код, функциональное программирование, метки: clean code, ооп, функциональное программированиеДумаю, никто не станет спорить, что хороший код — код, который не только исполняет, но и максимально описывает свою задачу (это, конечно, относится в первую очередь к бизнес-логике). Причем описывает ее не деталями алгоритма, а своей сигнатурой (названием, параметрами и возвращаемым типом), сигнатурой вызываемых методов, переменными, которые он использует. В таком случае тело метода можно прочитать сверху вниз, не удерживая в памяти какой-то дополнительный контекст.Читать полностью »