Продолжаю работу с ментатами 🤓

...Работа над pet-проектом застопорилась. Стало очевидно, что нужно уходить от системы, где в одну кучу свалены простые данные и системные ресурсы, а уровни абстракции перемешаны. Но как это сделать правильно?

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

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

Как это исправить я знаю, но принципиально не буду делать, потому что сперва крайне полезно пострадать, чтобы понять что как ни старайся, как ни пыхти, а без базы в программной инженерии и software design всегда будет получаться только Big Ball of Mud уже на единичных десятках сущностей :)

...С Иваном Закутным видел анонс стрима, но не удалось посмотреть, так как тушил пожар на проде(

...В-третьих, это неявные побочные эффекты - ещё хуже, чем явная завязка на внешнее состояние. Почему нельзя просто передать скорер в функцию? Потому что это какой-то объект с другим владельцем, ссылающийся на memory-mapped файл с третьим владельцем. А, да, там ещё обсерверы, которые обновляют файл при горячей загрузке (приложение может обновлять наборы данных без перезапуска).
Если рассматривать систему с точки зрения архитектуры портов и адаптеров, то она полностью состоит из адаптеров, а логика затерялась, потому что нет явных портов.

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

...Явно я переборщил, сильно "заклинило" на этом задании. Но было крайне познавательно. Многопоточность выпила много крови :)

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

...Попросил Opus 4.6 подготовить мне субагентов в ролях planner с уточняющим вопросами и формированием формальной спеки, implementer с навыком реализации на основе спеки, reviewer с навыком проверки соответствия спеке и опциональный explainer для описания формальной спеки человеческим языком.
Попросил создавать спецификацию в соответствии с работой A Generalized Algebraic Theory for Type Theory with Explicit Universe Polymorphism авторов Marc Bezem, Thierry Coquand, Peter Dybjer, Mart´ın Escard´o.

Вот что у ментата в итоге получилось, забирайте скиллс мд, и даже дсл есть :)

Почему кстати фреймворки наподобие OpenSpec имеют большие минусы, и как надо правильно, разобрал вчера на Функциональных архитектурах.

Другой ментат, вдохновившись ФА и гомотопической теорией типов, пишет материалы на хабре, поддержите :)

Спасибо вам за курсы, которые вдохновили на статью и постоянное развитие. :)