Java Clean Code: как сделать код читаемым и красивым

Зураб Белый
Руководитель практики Java

Первую программку написал в 14 лет, тогда и связал свою жизнь с IT. В коммерческой разработке более 15 лет. Прошел путь от джуна до руководителя отдела Java-разработки.

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

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

• KISS (Keep It Simple, Stupid)
• DRY (Don’t Repeat Yourself)
• YAGNI (You Aren’t Gonna Need It)
• APO (Avoid Premature Optimization)
• BDUF (Big Design Up Front)

• большинство паттернов и принципов было сформулировано давно;
• и не всегда четко;
• и не всегда для разработки ПО;
• за десятилетия понятия размывались и/или растягивались.

• Kiss был разработан ВМС США в 1960 году
• Простые системы будут работать лучше и надежнее
• Не придумывайте к задаче более сложного решения, чем ей требуется
• Иногда самое разумное решение оказывается и самым простым

• Порой наиболее правильное решение – это наиболее простая реализация задачи, в которой нет ничего лишнего
• Простейшее объяснение какого-либо явления с большей вероятностью будет точным, чем более сложные объяснения
• Согласно KISS следует программировать и писать, как можно более упрощенно

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

• Все что не нужно в системе и не прописано в требованиях – не следует и реализовывать
• Программист не сжигает напрасно бюджет, не тратит время и другие ресурсы, а просто делает то, что действительно от него хотят

• Разработка – это про деньги
• Никому не нужны программы, которые стоят больше, чем бизнес может себе позволить
• Оптимизировать программы по любому параметру стоит только после того, как станет понятно, нужна ли эта оптимизация
• Прежде чем вы погрузитесь в детали реализации, убедитесь, что эти оптимизации действительно полезны
• Преждевременная оптимизация – зло
• Преждевременная оптимизация может привести к задержкам при написании кода и, следовательно, увеличит затраты времени на вывод функций на рынок

• Снижать сложность воспринимаемых за раз компонентов
• Делать маленькими классы и методы в них
• Соблюдать принцип единственной ответственности
• Снижать количество зависимостей в классах
• Уменьшать сложность методов

• Не пренебрегать дизайном системы
• Интерфейсы, разделение по слоям и архитектурные паттерны может быть сложно применить в будущем
• Лучше применять YAGNI к разработке частей кода, которые не потребуются в ближайшем будущем

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

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

• Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы
• Изменение единственного элемента системы не должно требовать внесения изменений в другие, логически не связанные элементы