Телеграм канал «Эргономичный код»

Привет!

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

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

К моему удивлению, оказалось что на самом-то деле есть дофига матчасти, которую можно изучить:
1. Бесплатный курс от гугла по техписательству
2. Книга The Minto Pyramid Principle: Logic in Writing, Thinking and Problem Solving. Есть русский перевод, но ругают за "машинность" и то, что переводчики не разобрались в теме.
3. Книга Ясно, понятно: Как доносить мысли и убеждать людей с помощью слов
4. Diátaxis - фреймворк/архитектура документации.
5. The Science of Scientific Writing - научная статья о том как люди понимают научные статьи
6. Ну и тут ещё стоит упомянуть классическую (в моей картине мира) Пиши, сокращай

И так как на мой взгляд скоро нам всем придётся стать своего рода писателями - берите на вооружение:)

Сам пока только начал читать Diátaxis, поэтому отзывов пока не дам. Надеюсь в этот раз не выйдет как с архитектурой свободных сущностей.

#books@ergonomic_code

Привет!

Прочитал пост How to be more ambitious: A tutorial for humans with models антропиковского лида разработки Claude.ai, Cowork, и Code Desktop

И там есть совет:

Pick unreasonable goals and tell the model that they’re very reasonable: You need your website to load in 5s instead of 10s? Ask for 200ms.
А между тем, если делать нормально, то 200мс - это вполне себе решаемая задача. Для старомодных кожанных мешков, а не мясных прокси, во всяком случае.

Теперь в целом понятно, какой ценой Антропик получают свой кратный рост кол-ва мёржа ПР-ов - ценой моего времени. Клодом не пользуюсь, но за гопатыча могу с уверенностью сказать: он и тормозит, и багов в нём больше, чем звёзд на небе.

А я не хочу жить в мире, где на меня вендоры каждый день вываливают тонны нового шлака, который грузится по 5-10 секунд. Я хочу жить в мире, где мне ведоры через день дают грамм золота, который грузится 200мс.

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

#ai@ergonomic_code

Привет!

Выгуливаю я значит сегодня младшенького под дождём суровой сибирской осени и вдруг на меня нападает инсайт.

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

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

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

В этом смысле, на мой взгляд, и императивный ОО-подход (особенно с поддержкой тяжеловестных ОРМов) с его монолитным изменяемым графом модели домена и хардкорный ФП подход с его абстракциями уровня стратосферы хоть и сокращают общее количество кода, но при этом поднимают сложность его чтения (иногда - до той же стратосферы).

А вот мой пролетарский ФП стиль с его фокусом на простоту, декомпозицию, самоочевидность и локальность рассуждений - вполне может оказаться золотой серединой по соотношению сложности к количеству кода.

Про пролетарский стиль можно почитать тут:
https://azhidkov.pro/posts/24/09/what-is-fp/
https://azhidkov.pro/posts/22/12/why-fp-simpler/
https://azhidkov.pro/posts/22/11/ea-at-jpoint/
https://azhidkov.pro/posts/23/10/why-fp/#_для_того_чтобы_снизить_стоимость_разработки_не_надо_знать_теорию_категорий




И вот кажется, если мне удастся научить ИИ пролетарскому ФП - ревью начнёт проходить сильно проще и быстрее.

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

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

#ai@ergonomic_code #ergo_approach@ergonomic_code

Подписывайтесь: VK | MAX

Не, ну кстати, справедливости ради, есть у автора одна любопытная идея.

Чтобы защитить инварианты сущности, автор предлагает делать конструктор приватным, я для создания экземпляров делать внутренний интерфейс, у которого есть протектед метод, который делегирует вызов в конструктор:

public class Client
{
public interface IRepository : IBaseRepository<Client>
{
protected static Client Restore(
Guid id, string name, string address, Conditions condition)
=> new(id, name, address, condition);
}

private Client(
Guid id, string name, string address, Conditions condition)
{
// ...
}
}

В оригинальном виде, правда, это половинчатое решение - этот интерфейс может реализовать кто угодно и создать сущность без проверки инвариантов. И в шарпе (по словам гопатыча), нет возможности это как-то залечить. Зато в Котлине есть.

interface можно сделать sealed и тогда его реализовать можно будет только в той же директории.
Правда в котлине нельзя сделать протектед метод в интерфейсе, но можно сделать sealed класс.

В итоге получается такая конструкция:

// в файле my_app.clients.Client.kt

class Client private constructor(
val id: UUID,
val name: String,
) {
sealed class Repository {
protected fun restore(id: UUID, name: String) =
Client(id, name)
}
}

// в файле my_app.clients.ClientRepository.kt

class ClientRepository : Client.Repository() {
fun restoreFromDb(id: UUID, name: String) =
restore(id, name)
}

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

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

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

#kotlin@ergonomic_code

Блин. Я дочитал. И тотально разочаровался. Автор просто придумал JPA/Hibernate/NHibernate на ручной тяге поверх EntityFramework и передачу списка вообще всех репозов в методы сущностей/агрегатов/бизнес-логики. По сути, книга о том, как сделать производительность большого императивного кома грязи сносной, если ты хочешь остаться в ОО, но не знаешь про хибер. Не рекомендую к прочтению.

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

Собственно отрывок из черновика статьи Модель неизменяемых реляционных данных с чуть более подробным описанием идеи:

Для того чтобы справиться с этим несовершенством реального мира, функциональные программисты-практики идут на компромисс - они допускают появление в системе изменяемых объектов, но минимизируют количество их экземпляров, и делают изменяемыми не сами записи, а их коллекции (репозитории).

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

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

PS>

Вот и пиши после этого книги, чтобы аноны в интернетах их обсирали 🤦‍♂️🤣

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

Во многом мы с автором сходимся, но расходимся в условиях (у него есть та самая сложная бизнес-логика, которой у меня нет) и предпочтениях (он нашёл своё счастье в ООП и богатой доменной модели, в отличие от меня).

Prompt
by Christoph Niemann

Хорошей тебе недели!