Это расширенная версия статьи, изначально появившейся в SD Times. Он также появился на xMatters.com.
Мне посчастливилось познакомиться с лучшими практиками программирования в самом начале своей карьеры. Один из моих наставников организовал практические занятия, на которых мы экспериментировали с разработкой через тестирование и рефакторингом запутанного кода. Я был членом (и руководил) книжными клубами, которые читали и обсуждали мастерство разработки программного обеспечения и шаблоны проектирования.
Мне всегда нравилась идея User Experience (UX) - смотреть на программное обеспечение с точки зрения пользователей и стремиться сделать его максимально интуитивно понятным в использовании. Итак, совершенно не связанный с разработкой программного обеспечения (по крайней мере, я так думал в то время), я записался на программу графического дизайна, чтобы изучать визуальные и интерактивные аспекты программных продуктов.
Как и следовало ожидать, с годами рассмотрение программного обеспечения с точки зрения пользователей помогло мне принимать более обоснованные решения при разработке. Но одним из самых важных выводов, которые я извлек из этой программы графического дизайна, было рассмотрение того, как другие разработчики использовали мой код - в конце концов, они являются «пользователями» моего кода.
К тебе, Стив ...
В своей классической книге по юзабилити Не заставляйте меня думать Стив Круг излагает три своих закона юзабилити для создания и представления контента веб-сайтов:
1. Не заставляйте меня думать.
2. Неважно, сколько раз мне нужно щелкнуть, главное, чтобы каждый щелчок был бессмысленным и однозначным выбором.
3. Избавьтесь от половины слов на каждой странице, затем избавьтесь от половины того, что осталось.
Я быстро понял, что цель законов Круга применима к другим способам публикации, включая исходный код. Фактически, большинство лучших практик программирования можно извлечь из трех рекомендаций Круга по юзабилити с некоторыми простыми настройками:
- Не заставляй меня думать.
- Разбираться в коде должно быть тривиально и однозначно.
- Всегда ищите способы уменьшить сложность кодовой базы.
Основываясь на этих принципах, давайте посмотрим, как хороший «UX кода» влияет на ремонтопригодность приложений и продуктивность команды.
Не заставляй меня думать
«Программы должны быть прочитаны людьми».
Разработчикам часто приходится изменять код, не имея полного представления о самой программе. Кодовые базы могут меняться очень быстро, особенно когда их активно разрабатывают несколько инженерных групп. Быть в курсе всех изменений, когда они происходят, при этом оставаться продуктивным зачастую невозможно.
Учитывая эту реальность, код должен быть сделан так, чтобы его назначение и использование были самоочевидными… очевидными… самоочевидными¹ - насколько это возможно. по-человечески возможно, во всяком случае. Короче говоря, разработчик без какого-либо опыта работы с приложением (даже младший разработчик) должен иметь возможность бегло просматривать файл и иметь довольно хорошее представление о том, что он делает.
Каждый вопрос, который возникает при чтении кода, увеличивает нашу когнитивную нагрузку, отвлекая внимание от текущей задачи². Это ключевое обоснование передовых практик, шаблонов проектирования и соглашений о кодировании, которые, как было доказано, упрощают разработку. Дополнительные практики, такие как следование твердым принципам и выбор значимых имен для пространств имен, классов, методов и переменных, имеют большое значение для того, чтобы сделать код более выразительным.
Этот подход согласуется с сохранением краткости классов и методов для облегчения чтения. Представьте, что вы читаете статью, состоящую из одного огромного абзаца. Без адекватного разделения - Круг сказал бы пробел - становится трудно следить за тем, что происходит. То же самое и с кодом, который требует двойного и тройного чтения для понимания.
Документация в коде - это еще один инструмент, который мы должны постоянно использовать, чтобы давать указания следующему человеку, читающему наш код. Современные IDE отображают комментарий заголовков классов и методов, поскольку мы используем их в различных частях нашего программного обеспечения. Когда они хорошо написаны, эти комментарии могут помочь другим избежать необходимости переходить к разным частям приложения, чтобы узнать, что происходит.
Обходить код
Тщательно подобранные соглашения об именах и комментарии в коде не только помогают разработчикам понять назначение кода, но и действуют как указатели. Они аналогичны выбору значимых заголовков и названий глав в книгах. Когда книга хорошо структурирована, беглого просмотра оглавления книги обычно бывает достаточно, чтобы точно определить тему. Мы должны иметь возможность делать то же самое с пространствами имен, классами и именами методов.
Удаление повторов в коде - еще один метод, который мы можем использовать, чтобы сделать код более удобным для навигации. В частности, мы должны стремиться применять правило SPOT, чтобы иметь единое, недвусмысленное и авторитетное представление ³ различных частей знаний в нашем приложении. Такой подход устраняет вопросы о том, когда и где используются разные представления, и снижает вероятность появления ошибок из-за того, что вы забыли синхронизировать все представления.
Следование правилу SPOT и принципам SOLID вместе помогает устранить побочные эффекты между различными компонентами системы; они делают код более предсказуемым и изолируют логику между задачами. Хорошее разделение задач должно предотвратить необходимость вносить изменения во всей системе при внесении изменений в модуль.
Снижение сложности
Мы знаем, что сложность программного обеспечения увеличивается с каждой строкой кода, которую мы добавляем к нему. В свою очередь, эта сложность увеличивает нашу когнитивную нагрузку, поэтому рекомендуется минимизировать сложность программного обеспечения.
В своей статье о YAGNI Мартин Фаулер предостерегает нас от слишком раннего внедрения функций в систему. Может возникнуть соблазн сделать это в ожидании появления новой функции, запланированной на будущее. Однако это часто усложняет наши системы - сложность, которую необходимо поддерживать до тех пор, пока функция не будет полностью разработана и выпущена. И, учитывая постоянно меняющиеся требования к программному обеспечению, весьма вероятно, что будущая функция будет оставлена или изменится в объеме, так что то, что было изначально реализовано, потребует существенных модификаций.
Собираем все вместе
Предположим, что относительные усилия по пониманию и использованию неорганизованного кода примерно такие же, как и при написании кода, который легко понять. Последнее приносит больше удовольствия, потому что время, затрачиваемое на написание хорошо структурированного кода, выполняется один раз, тогда как время, необходимое для понимания беспорядочного кода, тратится каждый раз, когда программист работает над этим программным обеспечением. Это дорогостоящий и утомительный способ разработки программного обеспечения, которого относительно легко избежать, «не заставляя их думать», чтобы вместо этого они могли думать о том, что имеет значение: о качественном коде.
Ссылки
¹ ² Не заставляйте меня думать - Стив Круг
³ Прагматичный программист - Эндрю Хант и Дэвид Томас
