Соглашаемся на некачественный код

В предверьях семинара http://profyclub.ru/projects/seminars/2588/ я изложил свои мысли в виде статьи. Предлагаю ознакомиться и покомментировать :)

Соглашаемся на некачественный код
Денис Миллер

Что скрывается за качеством кода? Минимально количество ошибок? Правильно оформленные названия полей и методов? Жесткое распределение файлов проекта по папочкам? С точки зрения Стива Макконнела [2] качество системы снижает расходы на её разработку. Чем меньше мы усилий тратим на понимание своего же кода, тем легче мы добавляем новый функционал. Продолжая эту мысль – чем меньше мы допускаем запутанности кода, тем лучше качество. Часто разработчики говорят, чтобы в будущем было легче разобраться в коде, нужно выработать «Соглашение о наименовании». Ниже я покажу , что такое соглашение имеет смысл, но с качеством кода связанно косвенно.

В начале разработки сложных приложений ведущие разработчики и менеджеры проектов ставят перед командой вопрос о принятии «Соглашения о наименовании» (Coding & Naming Convention, сокращённо CNC). Фактически дав разрешение на религиозную войну. Соглашение есть способ документирования опыта, предпочтений и привычек одного из разработчиков. Преимущественно документируется (навязывается) опыт ведущего разработчика. Если бы было не так, то в команде в 7 человек, должно появиться как минимум 7 соглашений. Многие команды, чтобы избежать разногласий выбирают соглашение рекомендуемое авторитетным источником (Java [5], .Net [6]). Другой вариант, когда команда принимает соглашения уровня корпоративного стандарта.

Если посмотреть со стороны на процесс принятия соглашения. То можно заметить, что происходит парадоксальная ситуация. Команда забывает, что суть соглашения не в наименовании, не в авторитете, а в том, чтобы поддержка разработанного кода была легче и самое главное будет легко передан смысл кода. Когда любой разработчик сможет обратиться к написанному мною участку кода и этот участок будет понятен. Проведём аналогию с русским языком. Грамматика и орфография является неким соглашением. Но если так, ТО Сей4ас Я наPушИЛ соГлашеНИЕ По НАИМеноВанИЮ. Но смысл понятен и я легко могу внести изменения.

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

Важнее определить не соглашение. А принципы, из которых должны исходить разработчики, чтобы код был легок в поддержке, сопровождении и дальнейшем развитии. А таких принципов три[3]:
1. Коммуникация
2. Простота
3. Гибкость

Код пишется не для компьютера, а для человека. Первый принцип говорит, что разрабатывая код подумайте: сможет ли его прочитать другой человек? сможет понять его смысл? Второй принцип подсказывает, что требуется выбирать наиболее простое решение. А любую сложную функциональность (например, метод больше 10 строк [1]) декомпозировать на несколько простых. Гибкость – самый сложный принцип, за его реализаций предлагаю обратиться к шаблонам проектирования (design patterns)[7].

Исходя из указанных принципов можно строить уже не стилистическое соглашение CNC, а смысловое. Косвенно о таком соглашении идёт речь в книге «Совершенный код» Стива Макконнела[2] и ещё больше рассказывает о реализации трёх принципов Кент Бек [3].
В семинаре выбран другой, но не менее важный подход. Подход известный в математике «от обратного». Определив соглашение в виде положительных утверждений, мы не определяем случаи злоупотребления теми или иными конструкциями. Которые не несут ярко выраженного отрицательного эффекта для разработчика и даже соответствуют «соглашениям». Такие случаи только потенциально могут привести к сложности кода. Их называют - smells. Так если каждый программист будет допускать их появление, то они будут накапливаться словно снежный ком. И через буквально 1-2 месяца разработки корректный с точки зрения «соглашений» код будет совершенно нечитаемый с точки зрения смысла.

Семинар предлагает командам принять новое соглашение, которые должно сформироваться на основе каталога smells. "Code smells" сигнализирует о потенциальных сложностях кода. Правильная интерпретация этих сигналов позволит вам выявлять некачественный код, затрудняющий разработку и приводящий к удорожанию решений, а также трудности модификации существующего кода. Предлагаемая практика полезна как малым командам, так и крупным предприятиям, вовлеченным в промышленную разработку. На семинаре мы рассмотрим общий каталог Smells, включающий различные уровни: кодирование, базы данных и архитектуру. Особое внимание мы уделим каталогу некачественного кода и способа устранения smell’ов – рефакторинг. Один из первых авторов, кто поднял тему рефакторинга и работы со smell’ами является Мартин Фаулер [1].

Внедрение нового подхода в кодировании требует определённые усилия. Во-первых, нужно изменить порядок принятия соглашения. Заменить принятие правил как цельного документа на постепенное (итерационное освоение, см. принцип итерационного подхода в Agile-методологиях). Так предлагается построить приоритетный список некачественных решений по степени появления. После одобрения всей командой в течении одной итерации осмысленно и целенаправленно избегать пять самых приоритетных smell’ов и проводить рефакторинг над ними. Здесь можно использовать техники парного программирования, code review различного уровня. В завершение итерации добавить встречу для обсуждения (Smell Meeting). Во-вторых , требуется изменения режима разработки. Заменить устоявшуюся цепочку задача-модификация-тестирование на задача-рефакторинг-модификация-рефакторинг-тестирование. А в дальнейшем посмотреть на популярный на западе подход к самоорганизующимся и самообучаемым командам на основе Agile-подхода[7, 8] в разработке.

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

Дополнительно:
1. Мартин Фаулер. Рефакторинг. Улучшение существующего кода
2. Стив Макконнелл. Совершенный код. Практическое руководство по разработке программного обеспечения
3. Kent Beck. Implementation Patterns
4. Э.Гамма «Приемы объектно-ориентированного проектирования. Паттерны проектирования».
5. Code Conventions for the JavaTM Programming Language. http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
6. .NET Framework Developer's Guide Guidelines for Names.
http://msdn2.microsoft.com/en-us/library/ms229002.aspx
7. Российское Agile сообщество.
http://agilerussia.ru
8. Рассылка «Инженерные практики Agile».
http://subscribe.ru/catalog/comp.soft.prog.agile