Главная

Чистота нам только снится.

Однажды код будет прекрасным, возможно сегодня

 

13+

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

Истоки

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

  • Как сделать, чтобы работало?
  • Как написать, чтобы другие поняли?
  • Решал ли другой эту задачу ранее?
  • Можно ли использовать готовое решение для отдельных шагов?
  • Как написать, чтобы в следующий раз быстрее сделать аналогичную задачу?

Ответы на эти и аналогичные вопросы включают в себя известные практики:

  • ООП и шаблоны проектирования
  • Принципы и рекомендации чистого кода
  • Известные принципы разработки и дизайна ПО (SOLID, GRASP и пр.)
  • Практики процессов разработки (TDD, ATDD и пр.) и пр.

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

Открытия

В попытке проанализировать и улучшить ситуацию на отдельном проекте люди приходят к количественным методам и стандартам, таким как:

  • Статический анализ кода
  • Юнит-тестирование
  • Check-style проверки
  • Различные верификации состава дистрибутива.

Скорость работы программы также можно проверить автоматизированными средствами, попробовав различные решения.

И лишь только code review позволяет проверить код на осмысленность, рациональность или привнести рекомендации по архитектуре и дизайну. Автоматизированные способы проверки никогда не помогут:

  • Выделить общие компоненты
  • Подсказать шаблон проектирования
  • Выделить избыточность
  • Проверить концептуальное дублирование
  • Проверить прозрачность кода и удобочитаемость.

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

  • Разработчик быстрее погрузится в проект, если не только есть документация, а сам код состоит из небольших компонентов с понятными наименованиями
  • По качественным тестам можно быстро понять входящие и исходящее данные из программы и ее модуля
  • Если в ходе написания кода разработчик старался написать более абстрактный код как часть своего решения, то однажды его получится вынести в библиотеку и переиспользовать в другом месте
  • По качественному файлу сборки у читателя кода не возникнет вопросов: зачем это зависимость? зачем эта таска сборки? куда релизится артефакт?
  • Новые изменения тем проще внести, чем код чище, сильнее связность и слабее зацепление компонентов.

Со временем каждый автор кода, который ценит свой труд, станет таким разработчиком.

Компромисс

На этом пути разработчик идет на множество компромиссов, один из важнейших — компромисс поддержки и скорости.

Результатом принятия этих компромиссов становится то, что для множества проектов нельзя уверенно сказать, является ли код чистым и используется ли полностью та или иная практика.

И к чему в итоге приходит средний проект? Code review приносит новые компромиссы, попытки сделать код чище идут какое-то время,
пока у разработчиков хватает энтузиазма поддерживать качество, погружаясь в код коллег.

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

Рефакторинг

Со временем, для упрощения поддержки проекта разработчики начинают думать о рефакторинге, который теперь нужно сделать,
не сломав текущий функционал. Если юнит-тесты ранее не были написаны, придется начать с полного покрытия ими кода. Или принять риски и провести полный функциональный регресс.
Конечно, не забыв поговорить с бизнесом и объяснить ему важность этого.

Но:

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

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

Глобальным спасением качеству кода может быть только увеличение фактического опыта по улучшению качества кода у каждого программиста.

Общая рекомендация

Из множества рекомендаций, как сделать лучше сейчас, и получить таким образом этот опыт, хочу выделить правило бойскаута:

Оставь место стоянки чище, чем оно было до твоего прихода

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

Итоги

Подводя итоги, хочу еще раз напомнить о качестве кода и архитектуры. Какие бы аргументы и оправдания не приходили вам в голову, спешу сказать, что вы всегда будете в выигрыше, если будете думать о качестве и поддержке сразу. Это даст вам рост, как специалисту, а проекту упростит поддержку.

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

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

Надеюсь, моя статья вдохновила вас на новые изменения в сторону качества. Спасибо за внимание!

13+