Библиотека сайта rus-linux.net
ITK
Глава 9 из книги "Архитектура приложений с открытым исходным кодом", том 2.Оригинал: ITK
Авторы: Luis Ibanez, Brad King
Перевод: А.Панин
Невидимая рука
Программное обеспечение должно выглядеть так, как будто оно было разработано одним человеком. Лучшими являются разработчики, создающие код, который может развиваться любым другим разработчиком, если основного разработчика собьет автобус, упоминаемый в известной фразе. Мы достигли осознания того, что любой признак "индивидуального стиля разработчика" является указателем на дефект программного обеспечения.
- KWStyle используется для автоматической проверки соответствия кода определенному стилю оформления. Этот инструмент является упрощенной системой разбора кода на языке C++, проверяющей его соответствие стилю оформления и сообщающей о любых несоответствиях этому стилю.
- Germit используется для регулярных обзоров кода. Этот набор инструментов может использоваться для двух целей: с одной стороны он преграждает путь в кодовую базу для недостаточно проработанного кода, выявляя содержащиеся в нем ошибки, неточности и дефекты в ходе итерационных циклов проверки, в рамках которых другие разработчики улучшают рассматриваемый код. С другой стороны он позволяет создать виртуальный тренировочный лагерь, в котором новые разработчики будут учиться у опытных разработчиков (термин "опытные" следует понимать как совершившие все ошибки и знающие обо всех секретах...) методам повышения качества кода и обхода известных проблем, которые были выявлены в ходе циклов поддержки программного обеспечения.
- Точки вызова программ Git, позволяющие использовать инструменты KWStyle и Germit, а также позволяющие выполнить некоторые внутренние проверки. Например, проект ITK использует точки вызова программ Git, с помощью которых предотвращается добавление в репозиторий кода с символами табуляции или с завершающими строку пробелами.
- Команда разработчиков также исследовала возможность использования инструмента Uncrustify для приведение кода к единому стилю.
Следует подчеркнуть, что единый стиль кода не просто улучшает его эстетическую привлекательность, а на самом деле оказывает влияние на экономические показатели проекта. Исследование совокупной стоимости владения (Total Cost of Ownership (TCO)) программными проектами установило, что в течение цикла жизни проекта стоимость его поддержки будет составлять около 75% от TCO и, учитывая то, что стоимость обслуживания регулярно повышается, она обычно превышает затраты на полную разработку проекта за пять первых лет цикла жизни программного проекта. (Обратитесь к книге "Software Development Cost Estimating Handbook", Volume I, Naval Center for Cost Analysis, Air Force Cost Analysis Agency, 2008.) Затраты на сопровождение проекта оцениваются в 80% от той работы, которую на самом деле выполняют разработчики программного обеспечения и при осуществлении этой деятельности большая часть времени разработчиков отводится на чтение кода, созданного другим человеком и выяснение того, для выполнения каких действий этот код предназначен. (обратитесь к книге "Clean Code, A Handbook of Agile Software Craftsmanship", Robert C. Martin, Prentice Hall, 2009). Единый стиль кода чудесным образом сокращает время, затрачиваемое разработчиками на погружение в код из нового файла проекта и понимание этого кода до того, как они смогут как-либо модифицировать его. К тому же, сокращается вероятность того, что разработчики неправильно поймут код и модифицируют его, создав новые ошибки в ходе добросовестной попытки исправления старых (The Art of Readable Code, Dustin Boswell, Trevor Foucher, O'Reilly, 2012).
- Доступность для всех разработчиков, из-за чего мы предпочитаем инструменты с открытым исходным кодом.
- Использование на регулярной основе. В случае проекта ITK эти инструменты были интегрированы в систему ночных и последовательных сборок, формируемых с помощью системы CDash.
- Использование как можно ближе к тому месту, где был разработан новый код для немедленного исправления отклонений от стиля оформления, таким образом разработчики будут быстро узнавать о том, какие методы разработки нарушают стиль оформления кода.
Продолжение статьи: Рефакторинг