Эргономичный код
описание
Канал о разработке поддерживаемых бакэндов - про классическую школу TDD, прагматичное функциональное программирование и архитектуру и немного DDD. Группа: https://t.me/+hrqD87p0Oa Канал в Max: https://max.ru/id544512614458_biz https://azhidkov.pro
826
подписчиков
Охват к подписчикам
71,3%
ERR
Реакции к просмотрам
1,11%
396 на 49 постов
Пересылки к просмотрам
0,67%
238
Постов в день
0,1
всего 79
Где отзываются чаще
доля реакций к просмотрам- 29 июн.Привет! Сыновей я делаю в три раза лучше, чем пишу книги и блоги - в канале снова будет (ещё большее) затишье на пару месяцев, пока жизнь переустоканится:)9,06%
- 14 авг.Привет! Простые 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_code5,60%
- 29 янв. 2025 г.без подписи3,75%
- 9 мар. 2025 г.без подписи2,10%
- 19 нояб. 2024 г.без подписи2,04%
- 9 авг.Привет! Историческая минутка. Если вы интересуетесь функциональным стилем, то возможно слышали про статью "Can Programming Be Liberated from the von Neumann Style?" Это опубликованная версия лекции Бэкуса - автора Fortran-а и соавтора Backus-Naur Form - прочитанной при вручении ему премии Тюринга (нобелевки в мире информатики), в которой он критикует императивное программирование с операторами присваивания и в качестве альтернативы предлагает функциональный (хотя и довольно своеобразный) стиль программирования. И если вы интересуетесь ФП, но не слышали про статью - это уже первая полезняшка:) Но не последняя - я тут недавно около этой статьи накопал ещё пару интересных ссылок. Во-первых, Бэкус занимался этой темой до своего выхода на пенсию в 91-ом году и было несколько попыток реализовать систему из статьи, чему в интернете посвящена целая страница :) На этой же странице есть ссылка на сайт некоего Paul McJones, который кажется, может быть интересен любителям ИТ-археологии, но я в него не закапывался - меня таки накрыл дефицит времени, после рождения третьего ребёнка. Во-вторых, Дейкстра (тоже лауреат премии Тюринга и мужик, который решил, что Go To плохо, придумал стурктурное программирование, семафоры, "separation of concerns", слоёную архитектуру и много ещё чего) для своих "подписчиков" сделал разгромное ревью доклада Бэйкуса, которое дошло до самого Бэйкуса через третьи руки, после чего у них случился научный махач. Много лет спустя, разбирая свои бумаги для Библиотеки Конгресса, Бэкус каталогизировал эту переписку с комментарием: This guy’s arrogance takes your breath away -- От высокомерия этого парня захватывает дух А Дейкста и правда был тем ещё токсиком: Object-oriented programming is an exceptionally bad idea which could only have originated in California. — Объектно-ориентированное программирование — исключительно плохая идея, которая могла зародиться только в Калифорнии The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. — Использование COBOL калечит разум; поэтому его преподавание следует считать уголовным преступлением Fascination with the equipment is the hallmark of the amateur — Очарованность оборудованием — отличительный признак дилетанта — В общем если у вас есть время - покопайтесь в этих ссылках от души за меня:) #fp@ergonomic_code #papers@ergonomic_code1,60%
- 7 апр. 2025 г.без подписи1,53%
- 7 февр. 2025 г.без подписи1,50%
- 27 нояб. 2024 г.без подписи1,44%
- 23 дек.Привет! Наткунлся на любопытную публикацию об исследовании характеристик поддерживаемых кодовых баз от настоящих учёных - Questioning Software Maintenance Metrics: A Comparative Case Study :) Публикация любопытна в первую очередь тем, что базируется на данных предыдущего исследования, в котором они заказали реальную разработку реального (но небольшого - 2-3 месяца разработки) проекта в 4-ёх разных конторах. Затем они посчитали для этих систем различные метрики поддерживаемости в духе размера, цикломатической сложности, глубины наследования и т.п. Затем они наняли 6 новых профессиональных и примерно равных по квалификации разработчиков, чтобы они внесли по 3 одинаковые правки в двух системах, с замером времени работы над задачами с помощью плагина в ИДЕ. А потом посмотрели, как трудозатраты связаны с метриками поддерживаемости. И тут мы приходим ко второй любопытной штуке - TLDR-у исследования: лучшими метриками поддерижваемости системы являются её общий размер (в строках кода) и не низкая cohesion (в виде TCC - проценте пар методов, которые используют хотя бы одно обшее поле). И этот результат для меня неоднозначен. С одной сторны, в ЭП много практик, которые уменьшают общий размер системы - отказ от DIP-а по дефолту, открытая архитектура (обращение из контроллеров в репозы в обход сервисов/юз кейсов), минимизация маппинга (прямой маппинг sql result set -> final dto в простых операциях чтения данных), разделение доменной и персистеной модели только по необходимости. С другой стороны, есть практика, которая плодит много кода. Я её ещё не полностью сформулировал, но она во много базируется на make illegal states unrepresentable. В частности, например, если ей следовать и у вас есть операции создания и получения сущности, с генерацией ИДа бэком, то это значит, что вам надо завести две практически идентичных дтошки - с идом для ответов и без него для запросов. И под каждый контекст надо завести по дтошечке с актуальным для него набором полей И когда у сущности меняется состав полей - вносить правки во все дтошки не то чтобы прям боль, но дико бесит:) И тут, как назло, ещё и Котлин со своей нуллабельностью не помогает - теоретически можно сделать одну дтошку с нуллабельным идом на все случаи жизни, но тогда везде кроме операции создания вам надо будет как минимум !! на иды развешивать, что будет бесить не меньше. В общем. Не пишите лишний код. А какой код лишний - вопрос открытый:) #papers@ergonomic_code1,39%
- 22 июн. 2025 г.без подписи1,39%
- 19 июл.Я никогда на самом деле не работал с историями, но общий посыл на сто процентов плюсую - задачи надо ставить в терминах и интересах пользователей.1,39%