по поводу документации, написанной человеком - она быстро устаревает или не пишется от слова совсем. как заставить разработчиков другого домена написать её. когда тысячи микросервисов это сложно. код - главный источник знаний что происходит сейчас с данной фичей, какое её поведение
ещё раз хочу подсветить, что проблема возникает именно на этапе ресерча. разработчик собирает неполные требования, моделька пропускает краевые случаи , в итоге получается неполная спека , из которой нарезаются неправильные задачи и все это выливается в неправильный код. идея как раз на этапе проработки решения на несколько сервисов дать ллмке как можно больше контекста, как это сделать , ничего не забыв - расскажу во второй и третьей части
CLAUDE.md не должен раздуваться и часто ллм его игонрирует а например в superpowers это явно указывается что правила в спекек перекрывают правила CLAUDE.md. Общий CLAUDE.md будет при этом огромный если описывать несколько сервисов. я так изаначльно и делал. фича может задевать несколько сервисов поэтому работая только в одном сервисе контекста будет не достаточно. Также портянки трудно ревьюить - нужно схемы, диаграммы - что может ревьюить сам разработчик. И самое главное если явно не скажешь клоду на что обратить внимание - он может это с лёгкостью пропустить. в этом самая большая проблема. а в голове держать всеэти проверки тоже сложно.
Spec т.е. specification - спецификация, или можно проще документация. Нам надо перед написанием создать эту спецификацию которую ещё и легко менять. например с помощью superpowers, openspec, speckit. Но вот тут как раз и проблема. Часто такое происходит что ты пропускаешь краевые сценарии и не видишь каких то моментов и условно начинаешь кодить и давать задание клоду когда твоя спецификация неполная. Вот в этом и самая большая проблема. Перед кодингом как раз надо удоствовериться что все учтено.
спасибо за статью - по полочкам разложил. из недочётов - можно было чуть сократить и прогнать через humanizer - моделька, с помощью которой ты писал статью, все равно местами выдаёт странные предложения.
В статье как раз затронул этот момент. Traces намеренно вынес за скоуп. При одном инстансе приложения трейсинг не даёт практической ценности: запрос не проходит через цепочку сервисов. При этом тот же Jaeger добавляет нагрузку по памяти, которой и так в обрез. Назвал "observability", потому что подход и инструменты из этой парадигмы, просто с прагматичным выбором того, что реально нужно на данном этапе.
Согласен, что Alloy более актуален на перспективу, и его стоило бы рассмотреть в статье. Мне показалось, что в нём тяжелее разобраться. Документация объёмная и рассчитана на сложные кейсы, готовых примеров под простой сценарий с Docker меньше, плюс свой язык конфигурации River вместо привычного YAML.
сам использую минмок на проекте, вот он простой в использовании как автомат калашникова. никаких проблем с ним нет. любой джун разберется. трогал уберовский - вообще не зашло
Полезная статья, реально по онбордингу можно понять что это за компания а главное как устроены процессы в ней, мне кажется в стартапе мало чего из этого можно встретить, но если это крупная компания - все что здесь описано must have
зло - это каждый день красить кнопки и строки исправлять) задача нетривиальная и сложная - внедрение BDUI в проект, и чем больше проект тем сложнее это реализовать
по поводу документации, написанной человеком - она быстро устаревает или не пишется от слова совсем. как заставить разработчиков другого домена написать её. когда тысячи микросервисов это сложно. код - главный источник знаний что происходит сейчас с данной фичей, какое её поведение
ещё раз хочу подсветить, что проблема возникает именно на этапе ресерча. разработчик собирает неполные требования, моделька пропускает краевые случаи , в итоге получается неполная спека , из которой нарезаются неправильные задачи и все это выливается в неправильный код. идея как раз на этапе проработки решения на несколько сервисов дать ллмке как можно больше контекста, как это сделать , ничего не забыв - расскажу во второй и третьей части
CLAUDE.md не должен раздуваться и часто ллм его игонрирует а например в superpowers это явно указывается что правила в спекек перекрывают правила CLAUDE.md. Общий CLAUDE.md будет при этом огромный если описывать несколько сервисов. я так изаначльно и делал. фича может задевать несколько сервисов поэтому работая только в одном сервисе контекста будет не достаточно. Также портянки трудно ревьюить - нужно схемы, диаграммы - что может ревьюить сам разработчик. И самое главное если явно не скажешь клоду на что обратить внимание - он может это с лёгкостью пропустить. в этом самая большая проблема. а в голове держать всеэти проверки тоже сложно.
в 3 части буду как раз описывать как будет выглядеть полная спецификация
Spec т.е. specification - спецификация, или можно проще документация. Нам надо перед написанием создать эту спецификацию которую ещё и легко менять. например с помощью superpowers, openspec, speckit. Но вот тут как раз и проблема. Часто такое происходит что ты пропускаешь краевые сценарии и не видишь каких то моментов и условно начинаешь кодить и давать задание клоду когда твоя спецификация неполная. Вот в этом и самая большая проблема. Перед кодингом как раз надо удоствовериться что все учтено.
спасибо за статью - по полочкам разложил. из недочётов - можно было чуть сократить и прогнать через humanizer - моделька, с помощью которой ты писал статью, все равно местами выдаёт странные предложения.
В статье как раз затронул этот момент. Traces намеренно вынес за скоуп. При одном инстансе приложения трейсинг не даёт практической ценности: запрос не проходит через цепочку сервисов. При этом тот же Jaeger добавляет нагрузку по памяти, которой и так в обрез. Назвал "observability", потому что подход и инструменты из этой парадигмы, просто с прагматичным выбором того, что реально нужно на данном этапе.
Согласен, что Alloy более актуален на перспективу, и его стоило бы рассмотреть в статье. Мне показалось, что в нём тяжелее разобраться. Документация объёмная и рассчитана на сложные кейсы, готовых примеров под простой сценарий с Docker меньше, плюс свой язык конфигурации River вместо привычного YAML.
сам использую минмок на проекте, вот он простой в использовании как автомат калашникова. никаких проблем с ним нет. любой джун разберется. трогал уберовский - вообще не зашло
Полезная статья, реально по онбордингу можно понять что это за компания а главное как устроены процессы в ней, мне кажется в стартапе мало чего из этого можно встретить, но если это крупная компания - все что здесь описано must have
зло - это каждый день красить кнопки и строки исправлять) задача нетривиальная и сложная - внедрение BDUI в проект, и чем больше проект тем сложнее это реализовать