Блог заявил: у совершенства один ответ. HN построил бетонный домик на дереве

Тезис: затяните ограничения, и останется только один ответ

Ключевой ход поста: переопределить привычную жалобу. Переусложнение, утверждает автор, не избыток мастерства: «переусложнение — это решение не той задачи. Вот и всё определение». Честно разберитесь в требованиях, продолжает он, затяните все реальные ограничения (сроки, бюджет, реальные навыки команды, реальную потребность в производительности), и вы сойдётесь к единственной форме, которая подходит под все они. Эта форма, какой бы вычурной она ни казалась со стороны, и есть идеальное решение для этого случая, а не переусложнённое. Автор переосмысляет внутренние инструменты, библиотеки и API как продукты с реальными пользователями и утверждает, что большинство жалоб на «переусложнение» означают одно: требования никто честно не проработал. В пример приводится выбор serverless вместо других способов хостинга: решение, продиктованное ограничениями, верное для одной команды и неверное для «кого-то ещё», кто не знает Python.

Именно этот ход (переусложнение как провал в работе с требованиями, а не избыток заботы) весь остаток дня разбирал тред по кусочкам.

«Слишком упрощённо»: инженер, работающий над трейсерами Google, возражает

«Я согласен с самим принципом, который, как мне кажется, пытается донести статья... но категорически не согласен с подачей... Ограничения не жёсткие и неизменные вещи, а гибкие, способные подстраиваться под задачу... И поскольку они конкурируют друг с другом, их затягивание оставляет несколько решений, каждое со своим компромиссом... Так что нет, я не думаю, что вы перечисляете ограничения и находите единственное подходящее решение: это слишком упрощённый взгляд на сложность разработки софта.» — старший штатный инженер Google, работает над трейсером Perfetto

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

Тест домиком на дереве от сооснователя WebAssembly

«Переусложнённость — это слишком много фич, слишком много механизмов, слишком много движущихся частей. Переинженеринг — это когда вы намного превышаете требования без всякой пользы. Например: постройте мне домик на дереве... Если вы сделали его из бетона и стали, он, может, куда прочнее и простоит куда дольше... Слишком прочный, и это уже переинженеринг. А если вы сделали домик на дереве с 13 спальнями, лифтом, стеклянными окнами, солнечными панелями и водопроводом, то это уже переусложнённость.» — сооснователь WebAssembly, бывший техлид компилятора V8

Разница важна, потому что исходный пост сводит оба провала к одному: «решению не той задачи». Бетонный домик на дереве решает как раз ту задачу (укрытие, прочность), просто далеко за пределами того, что кто-либо просил. Никакая проработка требований не превращает избыточность в логическую ошибку.

Провал, который один комментатор до сих пор не может забыть

«Худшее месиво, над которым я работал: веб-приложение, которое неплохо решало реальную задачу, но команда тратила время на нелепую конструкцию Руба Голдберга из микросервисов, хотя у всей платформы было меньше активных пользователей в месяц, чем у моего хобби-сайта. Задача была верной, но переусложнение точно было.» — инженер, вспоминающий худший код в своей карьере

Конвертер JPEG в PNG получил ту же трактовку под другим углом: один комментатор описал гипотетическое решение на кастомных CUDA-декодерах и системе плагинов против одной команды ImageMagick через find — инженер, высмеявший определение однострочником на ImageMagick отметил, что оба варианта решают заявленную задачу, значит, «не та задача» не может быть тем, что их разделяет. Разделяют их, согласились в нескольких ответах, усилия, потраченные сверх того, что кто-либо заметит или оценит: категория, для которой у исходного поста просто нет названия.