Skip to content

code

Два скилла дисциплины. Скилл проектирования для opus и скилл реализации для sonnet

«Дисциплина — это мост между целями и достижениями.»

— Jim Rohn

В предыдущей статье мы вывели дисциплину: программа = дерево модулей с контролем диапазонов, юнит-тесты по формуле «1 + ветки антецедента», корректность доказывается по построению. Там была теория, оформленная как практическая методичка.

Этой статьёй закрываем разрыв между «понятно как» и «понятно что положить в Claude Code». На выходе — два самостоятельных артефакта:

  • program-design.skill — скилл для opus. Принимает функциональное требование, отдаёт пакет проектной документации.
  • program-implementation.skill — скилл для sonnet. Принимает пакет, отдаёт код по тикетам через Trunk Based Development.

Связующая нить — vertical slice architecture: каждый вход API режется в отдельный поток сверху вниз, со своим адаптером, своей бизнес-логикой, своим модулем I/O. Это резко упрощает и проектирование, и сборку бэклога, и параллельную работу нескольких агентов.

В следующей статье оба скилла прикручиваются к ubik-life/passkey-demo-api. Здесь — только сами скиллы и обоснование, почему они выглядят именно так.

Дисциплина проектирования программ. Скилл для opus и бэклог для sonnet

«Тестирование программ может служить для доказательства наличия ошибок, но никогда не докажет их отсутствия.»

— Edsger W. Dijkstra

Это практическая статья для вайб-кодера и джуна. Без академической мути. Цель — дать одну дисциплину проектирования, по которой opus проектирует программу, а sonnet получает готовый бэклог и реализует его в Claude Code.

Статья — концентрат четырёх разборов на codemonsters.team: структурное программирование, модульность, правильность программы, компонентные тесты.

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

Применение и доработка скилла компонентных тестов. Сессия с opus и хендофф sonnet'у

«Если карта не сходится с местностью — права местность.»

— старая военная пословица

В предыдущей статье мы зафиксировали скилл компонентных тестов как артефакт: положили SKILL.md рядом с проектом, написали процедуру, посчитали для passkey-demo-api по формуле семь сценариев. Всё красиво.

Реальность вмешалась на первой же минуте применения. Эта статья — журнал двух смежных сессий: opus прошёл от теории до зелёного smoke, потом sonnet за один день написал восемь сценариев по готовому шаблону. Карта (скилл) встретилась с местностью (реальный репозиторий), оба после этого изменились.

Компонентные тесты на практике. Скилл для агента и разбор passkey-demo-api

В предыдущей статье мы вывели формулу:

N_тестов = 1 + Σ (число различимых веток в адаптере i)

Теория готова. Время превратить её в инструмент, который работает каждый день — на любом сервисе, в руках любого вайб-инженера, в связке с ИИ-агентом.

Сколько компонентных тестов нужно сервису. Логический вывод

«Тестирование программ может служить для доказательства наличия ошибок, но никогда не докажет их отсутствия!»

— Edsger W. Dijkstra

В предыдущих статьях мы прошли путь:

Складываем три кирпича — и приходим к вопросу, на который индустрия не даёт внятного ответа: сколько компонентных тестов нужно сервису?

Ответ выводится логически. И он мал.

README — это продукт. Документация по JTBD с ИИ-агентом

В первой практике мы собрали сервис авторизации — OpenAPI-спека, README, devlog. Всё работает. Но документация получилась «для всех» — а значит ни для кого.

В этой сессии разбираем: у README четыре потребителя, и каждый нанимает его на свою работу. Проектируем структуру документации с Claude Opus, применяем через Claude Sonnet в терминале.

Репозиторий с результатом: service-template

GL HF DD!

Passkey Demo API — собираем сервис авторизации с ИИ-агентом | API First

Это разбор процесса: какие промпты писать агенту, какие решения принимать, почему именно так. Не туториал «скопируй и запусти» — а маршрут, который можно пройти самому.

Репозиторий с результатом: passkey-demo-api

Правильность программы

«Тестирование программ может служить для доказательства наличия ошибок, но никогда не докажет их отсутствия!»

— Edsger W. Dijkstra

Введение

В предыдущей статье мы разобрали модульность программ и нисходящее проектирование. Теперь возникает фундаментальный вопрос: как убедиться, что спроектированная программа работает правильно?

Традиционный подход — тестирование — имеет принципиальное ограничение: он может показать наличие ошибок, но не может доказать их отсутствие. Для этого нужен другой метод.

Правильная программа — это программа, корректность которой доказана формальными методами. Доказательство строится на математических утверждениях о состоянии программы до и после выполнения каждой инструкции.

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

В этой статье изучим классические работы Edsger W. Dijkstra, Niklaus Wirth и Harlan D. Mills, заложившие математические основы верификации программ. Эти принципы остаются актуальными и сегодня — они лежат в основе Domain-Driven Design, Type-Driven Development и контрактного программирования.

Модульность программы

«Всё не так легко, как кажется...»

— Закон Мерфи

Введение

Здоровый интерес к структурному программированию может быть как проявлением постепенного осознания правоты Мерфи, так и наступлением определенной зрелости в вычислительном деле. Структурное программирование возникло именно из-за того, что «все сложно, тянется дольше и стоит дороже, чем ожидалось». Нисходящая разработка призвана уменьшить сложность программы и дать возможность закончить ее вовремя. Если «что-то портится», то предлагаются средства, которые помогают обнаружить такие места как можно раньше и оставить достаточно времени на их устранение.

Нисходящая разработка (top-down design) может применяться на всех фазах проектирования системы, включая как проектирование программ этой системы, так и проектирование модулей для этих программ.

Структурирование программ

Программы не люди, а ошибки не микробы программа не может нахвататься ошибок, общаясь с другими дефектными программами. Ошибки всегда допускают программисты.

— Харлан Милла (Harlan Mills)

Введение

По-моему, программирование с изначальными тестами — одна из самых эффективных методик разработки ПО, возникших в 90-х. Но это не панацея, потому что такой подход тоже страдает от общих ограничений тестирования (описаны ниже), выполняемого разработчиками. Что мы сделаем — рассмотрим доказательства правильности программ от отцов-основателей из IBM и других авторов, которые описывали структурное программирование в (70,80)-х годах. Увидим, что надежное ПО — это хорошо спроектированное ПО.

Хорошо спроектированное ПО — это правильно структурированное ПО.

Правильно структурированное ПО — ПО, модули (классы) которого отвечают требованиям (описаны в Характеристики Модулей).

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