Пожалуй единственная глобальная боль в программировании, которую пока никому не удалось решить хотя бы с минимально приемлемым КПД — это то достаточно абстрактное, что понимают под проектированием

Пожалуй единственная глобальная боль в программировании, которую пока никому не удалось решить хотя бы с минимально приемлемым КПД — это то достаточно абстрактное, что понимают под *проектированием* (или software design). Важно его не путать с технической архитектурой, system design, все эти серверы воркеры кэши балансировщики, диаграммки с квадратиками — это совсем про другое.

Условно говоря, вот мы наворотили базу из тысячи тесно связанных таблиц, и теперь поверх этого надо запилить сложную бизнес-логику (далеко не CRUD). Или ТЗ объёмом 1000 страниц, в котором значимых существительных из домена насчитывается около тысячи (по сути тысяча классов, просто чтобы описать достаточно очевидные типы данных и достаточно очевидные взаимосвязи между ними). То есть мы построили некую базовую модель домена, некую базовую систему типов, но дальше начинается самый хардкор.

Если взять например Dwarf Fortress, количество игровых сущностей с подтипами в нём скорее всего и будет порядка тысячи. Собственно, правильно их "запрограммировать" — определить соответствующие классы с достаточно очевидными полями и методами, способен любой джуниор. По сути это достаточно тупая работа, надо просто внимательно вчитываться в контекст. Думаю, что сегодня и хорошая нейронка уровня Claude 4 с этим как-то справится минимально удовлетворительно.

upd: на самом деле нет :)

=> https://t.me/lambda_brain/1942

=

Ok, вот мы получили эту тысячу классов, описывающих основные сущности игры, ну и? По большому счёту, в реализации самой игры мы не продвинулись ни на 1%, так как её даже невозможно запустить: запускать просто нечего. Самой игровой логики пока ноль, и, честно говоря, не стало ни на 1% понятнее, а какой сделать вообще самый первый шаг?

Полагаю, вы понимаете, куда я клоню. Собственно, ровно с этого места и начинается то, что называется проектирование/software design.

L: Существует множество методик, приёмов, концепций проектирования, да и без них достаточно опытный программист сперва будет собирать какой-то минималистично живой прототип: нагенерит на карте ресурсы, научит простых гномов их автоматически собирать, добавит несложный UI и начнёт потихоньку - маленькими шагами - добавлять новые и новые фичи.

И всё будет идти хорошо примерно до того момента, когда в логике окажутся совместно задействованы порядка 50 классов сущностей (из 1000): человеческому уму станет не под силу удерживать логику взаимодействия между ними, код начнёт стремительно запутываться, обрастать множеством неприятных зависимостей и приляпок, сложность добавления новых фич начнёт расти экспоненциально, а сама система даже на таком базовом уровне прототипа станет громоздкой и крайне медлительной.

И ни один человек в мире вам не подскажет, как это делать правильно с самого начала :)

=

В программной инженерии конечно накоплено множество проектных эвристик, которые в сочетании с опытом позволяют сдвинуть этот критический порог превращения проекта в Big Ball of Mud — например, с 50 до 200 классов. Но корень проблемы так и остаётся.

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

Но даже если мы возьмём Водопад: вот у нас есть полное и непротиворечивое идеальное ТЗ, мы приступили к этапу проектирования ну а что делать-то? GoTo L ?

Проектирование конечно десятки лет стараются упростить: тут и паттерны проектирования, и UML-диаграммы, и всяческие итеративные аджайлы, и TDD, и BDD, и тяжёлые методологии вроде DDD; я обучаю ребят объектно-ориентированному анализу и проектированию Бертрана Мейера, который во многом концептуально близок DDD, но в целом полегче и попроще, и т.д. и т.п.

И тем не менее, сделать самый первый шаг в проекте с исходной тысячью базовых типов Dwarf Fortress - учитывая при этом 2-й, 4-й, 128-й, 4096-й и множество последующих шагов до конечного результата - сегодня в мире под силу наверное от силы десятку человек уровня Алана Кэя.

=

Моя цель — добавить немножечко формализма всем этим подходам, чтобы,

придерживаясь некоторого достаточно строгого фреймворка, но в то же время не требующего объёмной ресурсозатратной работы в стиле BDD/DDD,

любой крепкий миддл с минимальным опытом проектирования,

просто следуя определённым технологиям (в смысле, рабочим процессам, активностям),

смог бы спроектировать систему любой сложности *линейным* (а не экспоненциальным) ростом усилий.

Источник: t.me

Комментарии: