Пишу я более функциональной парадигме
Почему решил выбрать такую?
Из-за преимуществ простоты тестирования кода: Иммутабельность, персистентность, ссылочная прозрачность, функциональная чистота
Всё это позволяет создать меньше итоговых инвариантов, которые в будущем надо будет протестировать
Использую я библиотеку Effect-TS
Она позволяет удобно писать в функциональной парадигме на TypeScript cоздавая удобные конструкции для обработки ошибок (и не только) "Effect<Success, Error, Requirements>"
Файловую структуру я пока делю вот так:
- CORE: Исключительно чистые функции, неизменяемые данные, математические операции
- SHELL: Все эффекты (IO, сеть, БД) изолированы в тонкой оболочке
- Строгое разделение: CORE никогда не вызывает SHELL
- Зависимости: SHELL → CORE (но не наоборот)
Так же у меня есть папка app где лежит главный файл (условный main.ts)
В качестве анализаторов я использую: biome, eslint, jscpd
У меня очень строгие правила статического анализа кода и поиска дублей
Правила:
Максимум строчек кода на файл: 300
Максимум строчек кода в методе: 50
Максимум переданных параметров в метод: 5
Максимальная глубина вложенности блоков: 4
Максимальная сложность(ветвление): 8
Так же я блокирую любое отключение правил:
/* eslint-disable no-console, eqeqeq */
В коде у меня заблокированы "any" и "unknown" потому что LLMка начинает переиспользовать данные конструкции и ломать любое понимание кода
Так как я использую библиотеку Effect то у меня заблокирован "async" и "Promise" весь мой код должен полностью реализовывать красоту библиотеки Effect используя "Effect.Effect<A, E, R>"
Для библиотеки тестов я использую vitest (Пока ещё не везде) по причине того, что Effect имеет поддержку vitest
При любом измении в коде я всегда заставляю LLMку писать комментарии в такой форме: https://t.me/ProverCoderAI/11
/**
* CHANGE: Insert file record into mutable tree.
* WHY: Centralizes hierarchy creation logic.
* QUOTE(ТЗ): "Каждая функция — это теорема."
* REF: user-request-project-info
* FORMAT THEOREM: insert(record) ensures ∃path node containing file metrics
* PURITY: CORE (mutation локальна)
* INVARIANT: Directories auto-created; duplicate paths append once
* COMPLEXITY: O(d) где d = глубина пути
*/
Вот проекты в которых я пытаюсь реализовать свою "правильную" архитектуру:
https://github.com/ton-ai-core/vibecode-linter
https://github.com/ton-ai-core/eslint-plugin-suggest-members
Разумеется оно ещё не готово до конца
Например в eslint-plugin-suggest-members я использую jest и много где promise
А вот vibecode-linter ближе всего к тому что я описываю
Но пока единственный минус у меня это реализация тестов
С тестами у меня пока всё очень криво
Если кому-то интересно присойдениться к разработке то велком:
К поиску багов в коде и созданию последующих анализаторов, которые будут бить по рукам LLMку
Ну или к дискусии о том как лучше реализовать архитектуру проекта
Можете создавать issues или писать комментарии
Подход которого я придерживаюсь: Весь код пишет AI, а программисты только пишут "пруверы" "анализаторы" которые валидируют AI код
Именно он поможет придти к тому, что AI будет работать полностью автономно по 20 часов + (Я об этом писал тут https://t.me/ProverCoderAI/2)
