Рубрика «Проектирование и рефакторинг» - 72

О компонентах и интерфейсах

2012-11-29 в 13:07, admin, рубрики: Анализ и проектирование систем, Программирование, Проектирование и рефакторинг, метки: Программирование

Вступление

В последнее время очень часто сталкиваюсь с ситуацией, когда приходится иметь дело с непониманием разработчиками необходимости дробления систем на компоненты. А если это понимание есть, то обнаруживается непонимание сокрытия реализации компонента. А уж об удобстве интерфейсов и говорить не приходится.

Здесь и далее имеются в виду компоненты в смысле частей одного одного процесса. Компоненты, являющиеся отдельными процессами или сервисами, работа с которыми идет через RPC или еще как-то, здесь не рассматриваются. Хотя в большой мере все нижесказанное относится и к ним.

Пример первый:
Мне нужен компонент, давно разработанный и протестированный в другом отделе. Подхожу к разработчику. Завязывается диалог:
— Вот мне нужна вот эта штука. Как мне ее использовать в своем проекте?
— Да, вот нужно залить проект из CVS вот по этой метке. Скомпилить. Получится либа, и вот с ней нужно линковаться.
— Ок, спасибо.
Выкачиваешь проект. Компилишь. Вылезает куча ошибок, не хватает каких-то инклудов. Начинаешь выяснять. Оказывается для сборки проекта надо выкачать из CVS еще кучу проектов, их тоже собрать. Некоторые собираются стандартно студией, некоторые с бубном, вроде autoconf, make и иже с ними. Все. Собралось. Начинаются проблемы с линковкой. Не линкуется одно, второе, третье. Сторонних библиотек не хватает. В итоге — куча потерянного времени на непроизводительный труд и вникание в использованные библиотеки, сторонние компоненты и технологии.
Читать полностью »

Код CSS «с душком»

2012-11-25 в 20:12, admin, рубрики: css, Веб-разработка, код с душком, Проектирование и рефакторинг, стиль кодирования

Недавно Крис Койер отвечал на вопросы читателей Smashing Magazine. Один из вопросов был о том, как распознать код CSS с «душком»:

Как можно определить, что ваш CSS пованивает? Какие признаки указывают на то, что код неоптимален или что разработчик писал его спустя рукава? На что вы смотрите в первую очередь, чтобы определить, плох или хорош код?

Я подумал, что могу расширить и дополнить ответ Криса исходя из собственного опыта.

Я работаю в BSkyB. Я делаю большие сайты — над последним из них я тружусь уже больше года. Плохой код CSS доставляет мне очень много проблем. Когда занимаешься одним сайтом месяцами, ты просто не можешь себе позволить плохой код, и его обязательно надо исправлять.

Я хочу поделиться несколькими вещами, на которые я обращаю внимание прежде всего, чтобы составить впечатление о качестве, сопровождаемости и чистоте кода CSS.
Читать полностью »

Работая в интересах Будущих Разработчиков

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, принципы проектирования, проектирование сайтов

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-29 в 13:04, admin, рубрики: Проектирование и рефакторинг

Разработчики при написании кода визуализируют то, что пишут. По сути имитируют работу компьютера в голове. Но почему бы компьютеру самому не делать то, что разработчики имитируют?

Читать полностью »

Разработка через страдание

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, и т.д.

Программы работают медленней, веб-сайты тормозят, телефоны умножают мощность процессора при незаметных на глаз улучшениях производительности.
Читать полностью »

Информация

Комментарии

Рекомендуем