Команда Spring АйО подготовила перевод статьи Джеффа Атвуда о том, почему попытки «спроектировать всё заранее» только мешают реальной разработке. Атвуд утверждает: без живого прототипа любые архитектурные решения превращаются в гадание на диаграммах. Хотите делать осознанный дизайн — поднимайте зад с кресла и пишите код.

Комментарий от Михаила Поливахи, эксперта сообщества Spring АйО:

Если честно, статья перекликается просто до слёз. Наверное, самый главный совет в разработке ПО да и по жизни в целом:

Что бы Вы ни сделали, какое бы решение в жизни, при дизайне софта или чего либо Вы бы не приняли - Вы всё равно пожалеете. Со временем придёт понимание, что можно было сделать лучше, что решение было не оптимальное и т.д. И это нормально. Так будет всегда. Поэтому, главный совет - просто действуйте. Вопреки. Даже зная, что Вы ошибетесь.

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

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

Я пытался найти эту цитату и, как и Уэс, помню, что читал её, но не могу вспомнить, где именно:

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

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

• Я забыл что-то действительно важное

• Я нашёл другой, более простой подход

• То, что я делаю, просто не имеет смысла

• Я изобретаю велосипед и должен был бы поискать готовое решение

• Да мне это вообще не нужно!

В реальном мире между реализацией и дизайном идёт плотная обратная связь. Когда вы используете Photoshop как инструмент проектирования, возможно буквально всё. Visual Studio, увы, такой снисходительности не проявляет.

Я не продвигаю подход «кодить до упаду». Я лишь замечаю, что, по моему опыту, писать код без плана столь же бесполезно, как и писать код при избыточном планировании. Разработка ПО — это злая задачка: нельзя принимать решения по планированию, не имея какого-то прототипа кода, который позволит принимать решения осознанно. Если вы планируете слишком далеко вперёд относительно кода, гарантирую — вы делаете работу, которую придётся выкинуть или перекраивать до неузнаваемости.

Самый разрушительный симптом сверхпланирования — ошибочная мысль о том, что быть Software Architect™ — значит нарисовать кучу UML-диаграмм и передать их команде разработчиков в Бангалоре. UML прекрасен, если вы не хотите делать работу: вы просто рисуете картинки того, как бы выглядел результат, будь он действительно сделан. Это не просто пограничная лень — это прямой путь к катастрофе. Невозможно спроектировать реальное приложение на белой доске. Нужно сделать прототип в коде, чтобы собрать данные о производительности и последствиях выбранных решений для дизайна. Иначе вы вообще не понимаете, создаёте ли что-то осмысленное — или это хотя бы возможно! Как отмечает Роберт Гласс в книге Facts and Fallacies of Software Engineering, в дизайне ПО нельзя быть отстранённым:

Далеко не будучи предсказуемым, структурируемым, рутинным процессом, проектирование — согласно данным Кёртиса и Соловея (1987) — это запутанная работа наугад, методом проб и ошибок. И помните: эти выводы сделаны на основе наблюдений за работой лучших дизайнеров. Можно представить, насколько более хаотичен процесс у тех, кто далёк от вершины мастерства. Вероятно, худший возможный подход и, тем не менее, очень соблазнительный для новичков — «сначала простое». Хотя с него действительно легко начать, он слишком часто приводит к локальным решениям, которые не складываются в общую систему. В результате эти локальные решения приходится выбрасывать.

Из всего этого легко понять, что дизайн — процесс сложный и итеративный (эта мысль прямо выражена у Виегерса [1996]). Более того, это, вероятно, самая интеллектуально насыщенная часть разработки ПО. И также очевидно, что первоначальное проектное решение почти наверняка будет неверным. А оптимальное? Ну, первоначальные решения редко бывают оптимальными. Но само это слово поднимает другой любопытный вопрос — существует ли вообще оптимальное проектное решение?

Как разработчики — и особенно если мы воображаем себя так называемыми «архитекторами» — мы всегда должны принимать решения, опираясь на опыт и данные. И нравится нам это или нет, но это означает одно: поднять зад с кресла и писать код.

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.