Читать книгу Мастерство Программирования - - Страница 7

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

Представьте: вам нужно забить гвоздь. Что возьмет Мастер? Скорее всего, молоток. А что может взять неопытный, но очень амбициозный программист? Он может начать проектировать лазерную установку с ИИ-наведением, которая будет анализировать плотность древесины, рассчитывать оптимальный угол и скорость удара, а затем с точностью до микрона забивать гвоздь. Да, это круто. Да, это "высокие технологии". Но вы потратите годы, горы ресурсов, и в итоге, возможно, сломаете всю стену.

Почему мы так делаем?

1. Синдром отличника: Желание показать себя с лучшей стороны, написать "идеальное"решение.

2. Страх будущего: "А вдруг завтра понадобится, чтобы пицца могла летать на Марс?"– и мы начинаем закладывать функционал, который, скорее всего, никогда не пригодится (это очень часто нарушает принцип YAGNI – You Ain't Gonna Need It, "Тебе это не понадобится").

3. Увлеченность технологиями: Новая модная библиотека или архитектурный паттерн кажется настолько крутым, что хочется применить его везде, даже там, где это совершенно избыточно.

В чем проблема "космического корабля":

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

• Увеличение сложности: Чем сложнее система, тем больше мест, где могут возникнуть ошибки. Тем труднее ее отлаживать, тестировать и поддерживать.

• Замедление разработки: Проект ползет вперед, как улитка, потому что каждая новая "фича"требует перенастройки сложной, ненужной инфраструктуры.

• Высокий "порог входа": Новым членам команды будет очень трудно понять, как все это работает, и они потратят месяцы, чтобы разобраться.

Мастер не боится простоты. Он понимает, что краткость – сестра таланта. Его код – это скорее швейцарский нож: острый, функциональный, многоцелевой, но при этом компактный и интуитивно понятный. Он делает ровно то, что нужно, и делает это хорошо.

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

Меньше кода означает:

• Меньше мест для ошибок.

• Легче читать и понимать.

• Быстрее отлаживать.

• Проще изменять.

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