Проектирование и рефакторинг *

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

Ниже представлен «проект NULL», тот самый костяк, с которого обычно все и начинается. У меня.

Данный пост скорее всего не будет интересен тем кто уже матерый и тем кто на прямую не связан с разработкой на С++, т.к. ниже представленные материл несет одну единственную цель — дать готовый фундамент для начала.

Если вы работаете в большой команде разработчиков над одним и тем же проектом, то рефакторинг становится очень сложной задачей. Приведем пример: мы хотим переименовать функцию do_something() в do_something_with_blackjack(). Мы переименовали все вхождения этой функции в своей ветке и отправили задачу на тестирование. В тот же момент кто-то другой добавил ещё один вызов функции, но со старым названием, тоже в своей ветке. По отдельности наборы изменений будут работать, а вот после слияния получится ошибка.

В статье будет рассмотрен приём, который можно назвать «автоматизированный рефакторинг» — использование самописных скриптов, которые делают нужную работу за вас, позволяя провести рефакторинг после слияния всех веток и перед непосредственной выкладкой на staging/production.

На примере phpBB будет показано, как можно «отрефакторить» вызовы SQL-запросов, чтобы они использовали автоматическое экранирование входных данных (и таким образом помочь в решении проблемы SQL-инъекций).

Слабая связанность (low coupling) часто является признаком хорошо структурированной компьютерной системы и признаком хорошего дизайна. Wikipedia

Dependency Injection (DI) — это набор паттернов и принципов разработки програмного обеспечения, которые позволяют писать слабосвязный код. По мнению М.Фаулера, DI является разновидностью более глобального принципа инверсии управления (IoC), также известного как “Hollywood Principle”. Между тем, границы принципов внедрения зависимости достаточно размыты. Невозможно провести действительно четкую границу между этим и другими принципами написания качественного объектно-ориентированного кода. Например, принцип Dependency Inversion из SOLID, который часто путают с Dependency Injection, как бы подразумевает внедрение зависимостей, но им не ограничивается.

Как для любых паттернов и принципов, для DI существуют анти-паттерны. Ниже я их перечислю (с несколько вольным переводом англоязычных названий на русский язык).

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

В предыдущей статье рассматривалась теория и практика прогрессивного улучшения (progressive enhancement). В этой статье мы от идеологии перейдем к аксиологии и рассмотрим финансово-экономическую обоснованность применения прогрессивного улучшения.

В некоторых комментариях к предыдущей статье выражалось мнение, что использовать прогрессивное улучшение в реальной разработке не стоит. Причины сводились к излишней дороговизне: «На то, чтобы создать сайт в соответствии с этим подходом, нужно потратить слишком много времени, а это слишком дорого и не нужно ни заказчику (за такие деньги), ни исполнителю».

Прочитав недавний топик "Использование try — catch для отладки" решил все таки в качестве дополнения поделиться и своим опытом.

В этой статье предлагаю рассмотреть получение callstack’а места, где было брошено исключение в случае работы со
структурными исключениями (MS Windows). В детали работы исключений вдаваться не будем, т.к. это тянет на отдельный цикл статей (для интересующихся рекомендую Рихтера, MSDN и wasm.ru). Конечно, есть много уже готовых проектов для генерации minidump’ов (например CrashRpt или google-breakpad), так что эта статья носит больше образовательный характер.

Что делать с полученным стеком вызовов — решать вам. Можно смотреть отладчиком, можно записать в файл и смотреть сторонней программой (для этого не забудьте записать список загруженных модулей с их адресами, а так же вам понадобятся отладочные символы).

Один из разработчиков Microsoft объяснил, почему замечательную игру Pinball не включили в состав Windows Vista. Ходили слухи, что это было сделано по юридическим причинам. Но нет, причины сугубо технические. Оказывается, Pinball просто не смогли портировать 64-битную платформу.

Прошло почти три года с тех пор как я впервые написал о своём отказе от такой абстракции как репозиторий (Repository). С тех пор я практически не использовал никаких концепций репозитория в системах, которые мы разрабатываем. Я не убирал из проектов уже существующие репозитории, но теперь я просто не нахожу в них никакой ценности в качестве абстракций.

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

Но давайте посмотрим на проблему с другой стороны. Что мы делаем, когда разбираемся с чьим-то кодом? Как происходит сам процесс изучения кода? Мы листаем функции, ищем определения переменных, классов, переходим от функции к функции, от файла к файлу.

Вступление

В предыдущей статье я написал о разных способах оформления интерфейсов к компонентам и сокрытия их реализации в C++.
В этой статье расскажу вкратце, как в Java отделить интерфейс от реализации, а реализацию скрыть.
Я не буду рассматривать компоненты разных там Java EE, я рассмотрю самые обычные jar-ники-библиотеки.
Итак.

Вступление

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

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

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

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

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

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

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

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

Успешный программный продукт обычно проходит за свою жизнь через руки множества разработчиков. Вы — лишь одно из звеньев в цепочке опекунов вашего проекта, и каждая строчка кода, которую Вы написали — это оставленный Вами артефакт, который когда-нибудь будет изучаться Будущим Разработчиком. Также, как Вы унаследовали решения разработчиков, которые были до Вас, другие разработчики унаследуют решения, которые Вы приняли сегодня. Они получают от нас в наследство все наши недоразумения, срезанные нами углы, примененные нами недопонятые паттерны и техники, наше невнимание к деталям, нашу лень, наши изменения, сделанные на скорую руку, наших скелетов в шкафах, наше грязное белье. И гораздо реже — выгоду от нашей дисциплинированности, наших обсуждений и подготовок.

В этой статье я хочу поделиться опытом использования одной полезной утилиты, позволяющей автоматизировать сборку и анализ качества кода. Речь пойдет о Yasca — свободно распространяемом ПО, представляющем собой небольшой PHP движок и набор утилит для выполнения анализа Java, С++ или PHP кода, включающего в себя PMD, JLint и RATS. Сама интеграция выполнения этих утилит осуществляется путем разработки небольших плагинов, на языке PHP. О процессе разработки такого плагина и пойдет речь далее.

Нельзя просто так взять и рассказать про progressive enhancement, не упомянув о graceful degradation. В чем же разница между этими понятиями? Как уже говорилось в более ранней статье, graceful degradation можно перевести, как отказоустойчивость. Это очень широкое понятие, но в контексте веба его можно понимать как отказоустойчивость клиентских веб-интерфейсов, серверной части сайтов и так далее. В этой статье graceful degradation будет пониматься как отказоустойчивость клиентских веб-интерфейсов.

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

Многие знают что для подстановки значений в конфигурационные файлы 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.

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

От переводчика:
Немало копий сломано в спорах о том, когда уместнее KISS, а когда DRY, когда лучше как можно быстрее и проще решить задачу любыми средствами, а когда стоит создавать красивые и универсальные абстракции. Натан Марц, автор популярного фреймворка Storm, используемого в Твиттере, предлагает свой вариант. Чтобы не создавать тонны бесполезного кода ради абстрактной универсальности и в то же время не позволять системе превращаться в кашу из костылей, он использует «разработку через страдание» (suffering oriented programming).

---

Однажды меня спросили: «Как ты решился пойти на такой страшный риск — писать Storm одновременно с запуском стартапа?» (Storm — фреймворк для распределённых вычислений в реальном времени). Да, пожалуй, со стороны создание такого крупного проекта для стартапа кажется крайне рискованным. Тем не менее, с моей точки зрения это вообще не было рискованным делом. Трудным, но не рискованным.

Я использую стиль разработки, который сильно уменьшает степень риска таких больших проектов, как Storm. Я называю этот стиль «разработкой через страдание». В двух словах: не занимайтесь реализацией технологий, от отсутствия которых вы не испытываете страданий. Этот совет применим как к большим, архитектурным решениям, так и к маленьким повседневным задачам. Разработка через страдание существенно уменьшает риск, гарантируя, что вы всегда работаете над чем-то важным, и что вы хорошо разобрались в предметной области, прежде чем вложить в решение много сил.

Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».

Наверное, у каждого программиста возникала ситуация, когда совершенно не знакомые с IT люди просили его объяснить, в чём же состоит суть его профессии. Так уж сложилось, что у большинства людей понятие «программист» ассоциируется либо с замкнутым гиком в очках и свитере, либо с неким гениальным красноглазым подростком-хакером — но при этом никто не знает, чем именно он занимается.

Как рассказать им об этом, не пугая страшными терминами и фрагментами кода?
Под катом я воспроизведу такой рассказ, а также развенчаю несколько мифов о программировании.

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