Принцип YAGNI в программировании - ожидание и реальность

Эта иллюстрация, как нетрудно догадаться, сгенерирована с помощью нейросети.

Увлечение принципом Ягни(YAGNI) (в переводе «Вам это не понадобится») в каком-нибудь бизнесовом проекте, и не только, может привести к совершенно непредсказуемым последствиям. Хотя, если вы работали в похожих условиях, как будет описано далее, он вполне предсказуем. Похожие ситуации опираются не только на принцип Ягни, кто-то может назвать это просто бездумным подходом, когда следование любому принципу программирования, несмотря на обстоятельства, превращает простые задачи в чрезмерно сложные.

Если вы программист, то спешу предупредить, что эта заметка содержит некоторые юмористические аллюзии и воспринимать дословно её не стоит :)

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

Давайте придумаем пример, хотя бы немного взаимосвязанный с реальностью. Поступила задача из точки A в точку B перевезти группу пассажиров. Пример похож на обычную школьную задачу. В таких мысленных упражнениях нельзя нанять таксиста или использовать Бла-бла-кар, всё нужно делать самому. А под это дело нужно сделать подходящий механизм. Как это решается в обычной IT-компании? Исполнители оценили сроки, утвердили требования и приступили к работе. Требования, конечно по Ягни, соответственно получился каркас с сиденьями на колесах и подходящим мотором. Добавим еще тормоз, ведь в точке В нужно остановиться для высадки пассажиров. Мы помним про принцип - ничего лишнего. К тому же есть дедлайн и он вполне достижим.

Устройство выехало из гаража в городе А и направилось в В. Разработчики уже готовы открывать шампанское, чтобы отпраздновать деплой, но тут внезапно пошел дождь. К слову, водителя там тоже не было, так как любой пассажир мог нажать на педаль тормоза в конечном пункте. Клиенты начинают промокать и названивать в техподдержку. Техподдержка передает программистам. Те судорожно ищут решение. Наконец, оно найдено, ведь коробка передач, взятая у строннего вендора, содержит дополнительно заднюю скорость. Принцип Ягни на сторонних производителей, как ни странно, не распространяется. Хорошо, тарантас этот вернулся на доработку задним ходом. Все дружно выдохнули, но это только начало.

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

Условия изменились и пассажирам теперь нужно в город C. Не буду уточнять, что там изменилось, но такое часто бывает по ходу разработки. От таких поворотов сюжета никто не застрахован. Только вот поворачивать-то нечем, никакого руля и в помине нет. Тимлид открывает задачу и объявляет, что все в порядке, в задаче такого нет, значит это форс-мажор, следствие непреодолимой силы случая. Вы заметили, как следуя некоему принципу в устройстве, похожем на автомобиль не оказалось руля?

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

Итог этого костыльного, но вынужденного решения, уже напоминает абсурд. Вдобавок менеджер проекта проявил инициативу и договорился с фаундером о сокращении срока дедлайна. Из точки A в точку С прямым путем ведь ближе, чем было из A в B. А то, что клинты где-то там посередине застряли... Это технические подробности. Новые сроки утверждены. Тем временем механик отправляется в путь, прикручивая руль на ходу, а бывшие пассажиры, крайне недовольные, тащут крышу по трассе по направлению к городу C. Единственным выходом оказалось перехватить их там по дороге и чуть-чуть времени на этом съэкономить. А ведь как просто все начиналось. Всего два фактора вмешалось, атмосферные осадки и изменение места назначения. В реальных продуктовых командах таких изменений может быть множество.

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

Как же быть? Если бы разработчик ПО мог предсказывать будущее, то он работал бы c хрустальным шаром и картами Таро, а не вот это всё. Но он хотя бы может подключить здравый смысл и потом не оказаться на ходу прикручивающим руль, хотя может быть решение зависело не совсем от него. Может быть, он станет кричать навстречу ветру: "Я вас предупреждал!", и от этого станет легче.

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

Начал искать подкрепительные ссылки по теме и нашел такую YAGNI — друг, или враг?

А также интересный вопрос Нарушает ли OCP и DIP (из SOLID) принцип YAGNI? на stackoverflow.