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

Под внутренним качеством подразумевается не качество самого приложения (внешнее качество), то есть отсутствие ошибок, соответствие требованиям, простоту использования и т.д., а качество кода этого самого приложения.

Свойства качественного кода

Какими же свойствами обладает качественный код:

• расширяемость, гибкость (extensibility, agility)
• сопровождаемость (maintainability)
• простота (simplicity)
• читабельность, понятность (readability, clarity)
• тестируемость (testability)

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

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

Итак, теперь мы лучше понимаем, что означают абстрактные слова "хороший код", "правильный код" и т.д. Это код, который обладает полезными внутренними качествами (ценностями).

Как же достичь хорошего кода?

Существует довольно много способов, и их можно условно разделить на внешние и внутренние. Внешние способы - это различные программистские практики, например, парное программирование, статический анализ кода, code review и т.д. В какой-то степени сюда можно отнести и модульное тестирование с TDD/BDD, так как они улучшают качество кода: написать модульные тесты на существующий плохой код довольно сложно, поэтому его приходится рефакторить, а при использовании TDD/BDD написать плохой код с самого начала довольно сложно, хотя и вполне реально.

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

Внешние способы достаточно результативны, однако они всегда являются лишь дополнением внутренних. Если программист не обладает навыками правильного написания кода и проектирования, парное программирование с более сильным товарищем или code review ему поможет. Но что делать, если они оба не обладают этими навыками? Поэтому для каждого программиста, кроме знания инструмента (языка программирования, технологий) важно также и умение ими пользоваться (я уже когда-то об этом писал). Это 2 разных, ортогональных друг другу направления развития.

Итак, рассмотрим один из внутренних навыков, а именно навык проектирования (design).

Зачем каждому программисту иметь навыки проектирования

Многие программисты думают, что проектирование - это какая-то специальная фаза при разработке ПО, считают ее сложной и не всегда нужной. Строят там какие-то заумные дяди какие-то UML-диаграмки и прочую чушь. Все равно ведь когда будем писать код - будем половину менять и переписывать. Но ведь на самом деле, проектирование - это не только формальная фаза процесса создания ПО (практически любого), а очень важный (я бы сказал даже необходимый) шаг в программировании. А если выкинуть название "проектирование", то это необходимый шаг в любой человеческой активности. Сейчас объясню на примере, почему. Представим себе, что перед нами стоит какая-то задача. Что мы должны сделать перед тем, как начать ее выполнять? По идее, сначала мы должны понять что нам нужно сделать. Вторым шагом нужно разобраться, как мы будем это делать. И только потом - уже собственно делать! Так и в создании ПО. Сначала мы пытаемся понять, что нужно сделать (анализируем требования, или иногда даже анализируем желания клиента и создаем требования по ним). Затем мы пытаемся разобраться как мы будем это делать (по сути, проектируем, как будет выглядеть результат, чтобы не переделывать десять раз). И только потом берем клавиатуру в зубы и идем программировать. Однако здесь важно понимать одну очень важную деталь: результат проектирования (проект) не обязательно необязательно должен быть вырезан в камне диаграммах UML и документах, а вполне может быть сделан на доске, куске бумажки или даже просто в голове, если этого достаточно. Так что отсутствие конкретной формальной фазы еще не значит, что программисты не занимаются проектированием какого-то куска кода, базы данных, UI прототипов или даже микро-архитектуры. Занимаются. Это и есть проектирование, просто менее формальное.

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

Технический долг

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

Также эта метафора объясняет, почему иногда приходится писать код быстро, не тратя времени на правильное проектирование. Как и с точки зрения финансов мы берем деньги в кредит/долг для более быстрого достижения поставленной цели, здесь мы это также делаем для более быстрого получения результата. Однако мораль сей басни такова, что не нужно забывать, что за подобные действия мы будем расплачиваться в дальнейшем.
Более подробно о техническом долге можно почитать у Фаулера и Jeff Atwood.

Рецепты правильного проектирования

Хорошо, теперь мы знаем, что есть свойства хорошего кода (ценности), и что проектирование может нам помочь достичь их. Но как это сделать? Какие есть рецепты?

Индустрия создания программного обеспечения очень молода. Создание ПО часто сравнивают со строительством, архитектурой, мол, там все четко и понятно - есть требования к зданию, по ним делается дизайн, проект, потом этот проект просчитывается, конструируется, подбираются материалы, все планируется и лишь только затем начинается постройка. Кроме того, на данный момент существует уже куча стандартных подходов для строительства различных типичных зданий, существуют различные инженерные решения, позволяющий построить как гигантский небоскреб, так и тоннель под Ла-Маншем или какой-нибудь супер-мост. Однако, почти все забывают одно существенное различие: архитектуре уже как минимум 10,000 лет и человечество накопило очень много знаний и опыта за это время, а вот индустрии создания ПО - меньше века. И если в сфере языков программирования и технологий наша индустрия проделала очень внушительный путь, то по проектированию накопленных знаний не так и много. Многие подходы еще только нарабатываются и внедряются, поэтому и готовых рецептов-то не так уж и много.

Из того, что связано непосредственно с проектированием, можно назвать паттерны и принципы проектирования.

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

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

Мне кажется, что ценности, принципы и паттерны можно выразить следующей иерархией (с удовольствием жду комментариев по ее улучшению):

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

Однако данная пирамидка совсем не обозначает, что нельзя достичь вершины, не зная те же паттерны или принципы. Очень даже можно, вот только не факт, что в полученном результате их не будет :) Да и зачем изобретать велосипед, если можно использовать наработки таких умных и известных инженеров, как Бек, Гамма, Фаулер, Лисков, и множество других. Понимание и разумное использование принципов и паттернов помогает достигнуть вершины быстрее и с меньшими трудозатратами.

Мне кажется, что информации по паттернам проектирования уже очень много, а вот с принципами все не так просто. Поэтому в следующих частях я постараюсь осветить принципы проектирования, и не останавливаться только на SOLID.

Это кросс-пост с основного блога, расположенного по адресу www.merle-amber.blogspot.com.