Чистота нам только снится
Однажды код будет прекрасным, возможно сегодня
Нет программиста, который не думал о том, как бы написать код еще лучше.
Нет разработчика, который на code review не думал, что код коллеги непонятен и может быть написан лучше.
Нет руководителя, который не думал о важности качества кода и решений, принимаемых нанятыми им людьми.
Истоки
Желание сделать лучше, которое проходит красной нитью по нашему труду, также переносится и на нашу внутреннюю кухню, где за историю разработки программного обеспечения оно породило множество языков и фреймворков, практик, а также материала по качеству кода и грамотным архитектурным решениям.
Подходя к практике, с любым языком программирования и любой задачей, человек, без наличия опыта о том, как сделать лучше, все равно задает себе вопросы и, каждый по-своему, приоритизирует их для себя.
- Как сделать, чтобы работало?
- Как написать, чтобы другие поняли?
- Решал ли другой эту задачу ранее?
- Можно ли использовать готовое решение для отдельных шагов?
- Как написать, чтобы в следующий раз быстрее сделать аналогичную задачу?
Ответы на эти и аналогичные вопросы включают в себя известные практики:
- ООП и шаблоны проектирования
- Принципы и рекомендации чистого кода
- Известные принципы разработки и дизайна ПО (SOLID, GRASP и пр.)
- Практики процессов разработки (TDD, ATDD и пр.) и пр.
Программист же, отвечая на эти вопросы, путем самостоятельных проб написания кода, общения и изучения существующего материала рано или поздно, но открывает для себя ту или иную практику и интегрирует в свои решения.
Открытия
В попытке проанализировать и улучшить ситуацию на отдельном проекте люди приходят к количественным методам и стандартам, таким как:
- Статический анализ кода
- Юнит-тестирование
- Check-style проверки
- Различные верификации состава дистрибутива.
Скорость работы программы также можно проверить автоматизированными средствами, попробовав различные решения.
И лишь только code review позволяет проверить код на осмысленность, рациональность или привнести рекомендации по архитектуре и дизайну. Автоматизированные способы проверки никогда не помогут:
- Выделить общие компоненты
- Подсказать шаблон проектирования
- Выделить избыточность
- Проверить концептуальное дублирование
- Проверить прозрачность кода и удобочитаемость.
Ведь именно повторное использование, читаемость и масштабируемость кода имеет вес для будущего проекта и его поддержки.
Именно это влияет на стоимость доработки, а соответственно, становится критериями стоимости изменения.
- Разработчик быстрее погрузится в проект, если не только есть документация, а сам код состоит из небольших компонентов с понятными наименованиями
- По качественным тестам можно быстро понять входящие и исходящее данные из программы и ее модуля
- Если в ходе написания кода разработчик старался написать более абстрактный код как часть своего решения, то однажды его получится вынести в библиотеку и переиспользовать в другом месте
- По качественному файлу сборки у читателя кода не возникнет вопросов: зачем это зависимость? зачем эта таска сборки? куда релизится артефакт?
- Новые изменения тем проще внести, чем код чище, сильнее связность и слабее зацепление компонентов.
Со временем каждый автор кода, который ценит свой труд, станет таким разработчиком.
Компромисс
На этом пути разработчик идет на множество компромиссов, один из важнейших — компромисс поддержки и скорости.
Результатом принятия этих компромиссов становится то, что для множества проектов нельзя уверенно сказать, является ли код чистым и используется ли полностью та или иная практика.
И к чему в итоге приходит средний проект? Code review приносит новые компромиссы, попытки сделать код чище идут какое-то время,
пока у разработчиков хватает энтузиазма поддерживать качество, погружаясь в код коллег.
Но в итоге компромиссы постепенно превращаются в технический долг, вопросы на подумать, а новый функционал отправляется на продакшен, ведь работает — не трогай.
Рефакторинг
Со временем, для упрощения поддержки проекта разработчики начинают думать о рефакторинге, который теперь нужно сделать,
не сломав текущий функционал. Если юнит-тесты ранее не были написаны, придется начать с полного покрытия ими кода. Или принять риски и провести полный функциональный регресс.
Конечно, не забыв поговорить с бизнесом и объяснить ему важность этого.
Но:
- Регресс некоторым проектам может стоить очень дорого
- Бизнесу обосновать выгоду рефакторинга может быть крайне сложно
- Инициативных разработчиков, которые могут провести качественный рефакторинг крайне мало (раз уж их проекты уже страдают по качеству кода, да и что запрещает таким разработчикам, которые умеют применять лучшие практики, применять их сразу, вероятно это их лучшая версия кода).
В коллективе проекта, которому явно требуется улучшение качества, как раз из-за множества рисков идея рефакторинга звучит бессмысленно или по крайней мере слишком сложно.
Так и получается — фактически люди редко не доходят до рефакторинга, оправдываясь уже знакомой фразой: “Ну вроде же работает, зачем менять”.
Глобальным спасением качеству кода может быть только увеличение фактического опыта по улучшению качества кода у каждого программиста.
Общая рекомендация
Из множества рекомендаций, как сделать лучше сейчас, и получить таким образом этот опыт, хочу выделить правило бойскаута:
Оставь место стоянки чище, чем оно было до твоего прихода
Очевидно и его применение для нового проекта, где мы создаем место, в которое захотят приходить.
Это крайне простое правило, которое не требует от человека прочитать весь интернет, понять абстракции и лучшие архитектурные принципы.
Я выделяю именно его, потому что писать чище можно начать лишь постепенно, а именно во времени программист чаще всего находит оправдание, когда оставляет плохое решение.
Итоги
Подводя итоги, хочу еще раз напомнить о качестве кода и архитектуры. Какие бы аргументы и оправдания не приходили вам в голову, спешу сказать, что вы всегда будете в выигрыше, если будете думать о качестве и поддержке сразу. Это даст вам рост, как специалисту, а проекту упростит поддержку.
В дальнейших статьях я хочу на примерах кода близкого к промышленному показать как действительно начать использовать лучше практики по качественному коду на Java, но без революционного рефакторинга, лишь планомерно улучшая проект.
Ведь то, что многие знают какие-либо принципы, не улучшает проекты.
То, что разработчики на собеседовании спрашивают лучшие практики по качеству кода, не говорит, о том, что обе стороны знают, зачем они нужны, и применяют ли их.
То, что вы проводите code review, не дает вам кода, который удобно поддерживать.
Надеюсь, моя статья вдохновила вас на новые изменения в сторону качества. Жду вас в своем твиттер и в clean code канале здесь с интересными статьями.
