Привет!

Полезняшка. А для кого-то может и целых три за раз:)

Если вы не знали - с одним гит-репозом можно использовать несколько рабочих деревьев. Которые будут разделять между собой директорию .git.
Это экономит место на диске (и время синхронизации в облако, если пользуетесь) и позволяет фетчить origin только один раз.

Я этим активно пользуюсь - у меня всегда есть ворктри для основной текущей задачи, для быстрых фиксов, и для ревью каждого члена команды. Соответственно между всеми этим активностями можно переключаться по щелку. И не чертыхаться каждый раз, что надо зафетчиться.

А ещё если не знали - для Gradle есть плагин, который позволяет закинуть в проект git.properties-файл с инфой о сборке (дата, ветка, тэг, автор и т.д.), который можно добыть в рантайме через Actuator.

Но есть была проблема - плагин не умеет в worktrees и по дефолту взрывает всю сборку при запуске из директории со вторичной копией.
Я года 4 хачил это комментированием плагина во вторчных директориях. И раза три это случайно коммитал и откатывал.

И вот наконец написал 8 строк, которые костыляют эту проблему аккуратнее

// build.gradle.kts

gitProperties {
    val dotGit = File(".git")
    if (dotGit.isFile) {
        val actualGitDir = dotGit.readText().substringAfter("gitdir: ").substringBefore("/worktrees")
        this.dotGitDirectory.set(File(actualGitDir))
    }
}

Важное уточнение - это именно костыль и в git.properties при этом попадут данные из основной рабочей директории, а не той, где была запущена сборка

#tools@ergonomic_code #tips@ergonomic_code #git@ergonomic_code

Привет!

Полезняшка.

Вы наверняка слышали, что коммиты в гите должны быть маленькими и сфокусированными.

Я про эту идею узнал лет 10 назад минимум. Но всё равно коммиты получались... сильно разные.
Думаю вы и сами прекрасно знаете как так получается - берёшься делать маленькую задачку в один сфокусированный коммит, но походу дела тут что-то подчистил, там что-то подравил, споткнулся о непредвиденное ограничение базового метода, который пришлось подрихтовать и от которого ещё 5 мест зависят и оп - к вечеру уже гора изменений в 30 файлах.

Я как-то пробовал всё равно такие пачки разбивать на коммиты, но тогда идея не умела сплитить чанки, а проваливаться ради этого в консоль не хотелось и если пытаться из горы изменений коммитать только какие-то части - всё равно в некоторых коммитах что-то забывал или добавлял что-то лишние и они получались нерабочие.

В общем я по этому поводу не парился и коммитался как получится.

А в прошлом году я узнал про The Mikado Method больших рефакторингов.
Суть идеи в том, что вы первым делом делаете целевое изменение, смотрите что ломается, откатываете исходное изменение, делаете следующее изменение, которое чинит поломку, смотрите что опять сломалось, откатываете второе изменение, делаете третье изменение и т.д.
Я попробовал эту штуку, но для меня это вышло как-то гемморойно.

Однако этот метод подтолкнул меня к версии создания сфокусированных коммитов, с приемлимым для меня кол-вом оверхеда и геммороя.
Выглядит он так:
1. пилите фичу до победного ваще не парясь про размер
2. шелвите всё что есть.
3. глазами просматриваете изменения в шелве выглядывая там сфокусированные коммиты и их примерный порядок
4. аншелвите изменения первого вспомогательного коммита, прогоняете тесты, коммитаете
5. повторяете п. 4 пока не закоммитаете все предварительные изменения
6. аншелвите изменения целиком (решая конфликты идеевской волшебной палочкой), ещё раз просматриваете, что там нет ничего лишнего и коммитаете финальный коммит
6.1 если нашли что-то лишнее - повторить с п. 2

Эта процедура в зависимости от тяжести случая занимает от 15 минут до пары часов, но даёт таки сфокусированные коммиты.

Это не то чтобы прям гениальное изобретение, но я 10 лет не мог додуматься - может кому-то сэкономлю пару лет:)

#tips@ergonomic_code #git@ergonomic_code

Привет!

У нас в группе вчера зашла речь про использование ИИ в кодировании.

А я как раз последний месяц сам код практически не пишу и активно занимаюсь отстройкой процесса разработки на базе ИИ:)
Поэтому я и в группе подробно ответил и сюда решил репостнуть:)

Общий сетап:
1. Платная подписка на OpenAI за 23 евро
2. Идея для работы с кодом самому
3. VS Code + Codex для работы с агентом

Сейчас у меня процесс устроен так:
1. Я: завожу рабочую директорию задачи
2. Я: в режиме потока сознания сливаю постановку задачи в файл
3. Я: пуляю exec-spec-space-prompt.md (см. аттачи) в модель
4. Gpt-5.2 medium reasoning (в сложных на мой взгляд случаях - high/extra high): задаёт вопросы
5. Я: отвечаю
6. Модель: генерит 4 варианта реализации
7. Я: вот тут идёт самая вариативная часть
7.1. выбираю вариант
7.2. задаю доп вопросы и выбираю вариант
7.3. вижу что какой-то рефакторинг упростит решение -> обсуждаю его с моделью -> прошу сгенрять краткую постановку задачу на рефакторинг -> "делаю" рефакторинг -> на п. 6 с новыми вводными
7.4. даю уточнения к одному из вариантов модели и выбираю его
7.5 вкидываю свой вариант -> на п. 6
8. Модель: генерит 02-solution-options.md, 03-solution-hld.md и пишет транскрипт чата
9. Я: полуяю exec-spec-prompt.md в новый чат
10. Модель: генерит ТЗ
11. Я: тщательно ревьювлю ТЗ.
11.1 Если есть замечания: мелкие правлю сам, больше отдаю модели
12. Я пуляю промпт "реализуй ТЗ" в новый чат с GPT-5.2-Codex low
13. Модель реализует ТЗ
14. Я: смотрю результаты запуска тестов в чате и если их нет, или запущен не полный набор - запускаю сам. Если не прошли - скидываю логи модели и говорю починить.
15. Я: ревьювлю код и
15.1 мелочь правлю сам
15.2 большие куски прошу поправить модель
16. Я: прошу модель записать транскрипт чата реализации
17. Профит

Если модель лажает в кодировании - я пока просто в режиме свалки скидываю указания в AGENTS.md.

Касательно эффективности этого процесса у меня объективных данных нет.
Субъективно:
1. Этап проектирования и написания ТЗ - эффективнее, так как я люблю затупить при генерации или выборе вариантов, а потом не люблю аккуратно их расписывать, поэтому делаю это со множеством перекуров, перекусов, переписов и перекаков.
2. Этап реализации - пожалуй, не быстрее чем делать самому, если в потоке. А если делать на морально-волевых - модель, пожалуй, быстрее справляется. Плюс тут пока модель работает, можно самому заняться чем-то другим
3. Как альтернатива работе со стажёрами/джунами - намного эффективнее. На самом деле, раньше я и с юниорами примерно в таком же режиме работал и это было очень долго. Плюс у модели лучше получается мимикрировать под окружающий код (читай: под ЭП).

Я несколько раз слышал, что соннет лучше код пишет, но не осилил подтвердить у них телефон:)

#ai@ergonomic_code #tips@ergonomic_code

Привет!

Простые CRUD-приложения - это сложно

Если помните, я уже писал, что с момента перехода GPT-4 -> GPT-5 я качественных скачков в росте пользы от агентов больше не видел.
И вот, вышел GPT-5.6-sol - а я снова не чувствую никакой разницы с GPT-5.*

Недавно я в Проекте Э сделал с ним не совсем тривиальную задачку: обеспечить синхронизацию обработки аутбокса на нескольких репликах, которая требует обращения во внешнюю систему.

И это был ужас.
В процессе он мне в несколько заходов генерял код, который напомнил мне тот ужас, с которым я работал в "лихих нулевых и десятых" и почему я вообще начал делать Эргономичный подход.
Но мне в итоге удалось свести этот ад к простому и изящному коду.
Ну точнее - мне удалось заставить гопатыча сделать это.

И при этом грешил гопатыч ровно тем, чем грешили мои коллеги из "лихих годов":

1. локальные хаки и костыли, вместо пересмотра модели
2. привнесение надуманной сложности, которая не имела практической пользы
3. бездумный перенос кусков кода из одного контекста в другой, где они теряли смысл и вообще ломали смысл окружающего кода
4. хрестоматийные ошибки дизайна - дублирование смысла кода, с немного разным выражением (DRY); нарушение CQS; нарушения баланса захвата/освобождения ресурсов; неуместные граничные/специальные случаи; нарушение зон ответственности (do one thing)

И вся эта история с чудесным преображением кода, решающего одну и ту же по сути задачу, навела меня на другую мысль.

В прошлом году я скрипя сердцем признал, что всю жизнь занимаюсь всего лишь "простыми CRUD-приложениями", которым не нужны ни ЧА, ни DDD, ни ФА, ни любая-другая-крутая-аббревиатура. И чтобы как-то повысить ценность и значимость своей работы, а так же обосновать необходимость ЭП, я даже придумал термин "сложные CRUD-приложения".

Так вот глядя на то, как гопатыч делал какую-то невероятно ацкую реализацию для простого CRUD-приложения, я понял, что простота моего кода - это не данность, не повсеместное состояние дел и не то, что доступно любой макаке - это достижение которым можно и нужно гордится и которое основывается на моих 20+ годах практической работы и поиска способов писать простой код.

И всё это сподвигло меня начать писать новый большой пост с разбором этих сессий кодирования с вариантами названия "Шок! GPT-5.6 не может написать простую крудилку!" и "Простые CRUD-приложения - это сложно".

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

Полезняшка №1: роллауты сессий

Если вы не знали, кодекс (думаю, другие агенты делают так же) хранит все чаты у себя в папочке в открытом виде.
И по этой папочке вполне можно делать поиск - у меня на это есть специальный скилл.

А у этого скилла куча применений:
1. основное у меня - я большинство правок своего фреймворка (он, кстати, жив и развивается) идёт через скилл fix-framework-context куда я пишу ид сессии, что агент сделал не так и как надо было. И гопатыч по роллауту разбирает почему агент в сессии сделал не то что надо и как это поправить.
2. я сейчас отчёты о работе за месяц для заказчика формирую гопатычем и на вход среди прочего подаю эти сессии
3. ну и в контексте этого поста - по этим сессиям гопатыч восстановил мне хронологию наших с ним метаний во время решения задачи с привязками ко времени, промптам и бэкапам - без чего я бы вряд ли смог так подробно разобрать что происходило, как это делаю сейчас

Полезняшка №2: Бэкапы

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

И одна из особенностей этой системы заключается в том, что для моих рабочих директорий у меня снимаются снапшоты каждые 5 минут и для 8 последних дней хранятся все эти снапшоты.

Благодаря этому для каждого своего промпта за последние 8 дней я могу откопать точный код на котором его писал и понять почему я его написал.
Что оказалось так же супер ценным, для написания поста, о котором я говорил выше.

Для бэкапов системы (на Linux) я использую Timeshift, для бэкапов рабочих файлов, архивов и конфигов - backintime, а для синка файлов между устройствами - syncthing с нодой с шифрованием на VDS-е за 900р/мес.

—

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

#ai@ergonomic_code #tips@ergonomic_code