Пятничное чтиво

Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

—————————————

AI Doesn't Fix Your Real Bottleneck

Часто вижу истории истории о том, как ллм ускоряет TTM компании в десятки раз. Помня о теории ограничений и очередях, каждый раз интересно разобраться в деталях такого ускорения (и реальное ли ускорение ттм на самом деле). Поэтому сегодня статья от автора learning DDD, в которой автор задается похожим вопросом.

Начинается текст с кратким объяснением теории ограничения. Т.е. ускоряя «узкое» место процесса — ускоряем процесс целиком. Ускоряя другое место — делаем хуже (появляются очереди и увеличиваются запасы). Дальше, автор, задается вопросом, а что за «узкое» место в SDLC и делает предположение, что не написание кода, а понимание кода, который изменяется. Далее мыль приходит к тому, что чем больше кода пишется, тем больше страдает понимание существующего кода. А как решение, автор предлагает посмотреть в сторону модульности (и сложности) и связей между элементами системы. Ну и в конце найдете рекламу balancing coupling, как способе работы с модульностью.

#SDLC #llm

—————————————

Choose Boring Technology

Может показаться, что работа над архитектурой и принятие решений по технологиям строится вокруг построения звездолетов и новых технологий. На деле, в реальности, выбор сводится к безопасным решениям, которые на деле скучны. А что-то «не скучное» выбирается только когда проверенные решения не справляются. Поэтому сегодня рубрика «интернет археология». Статье больше 11 лет и главная мысль текста — выбирайте проверенные технологии.

Текст начинается с определения «скучной» технологии. При этом, скучное =/= «плохое», так есть «хорошие» скучные технологии (постгрес, как пример). Для автора это изученная технология, особенно причины отказа. Т.е. автор приводит к «известному неизвестному» и «неизвестному неизвестному». Далее автор подводит к тому, что основная цель software — сопоставить бизнес проблему с техническим решением. И что термин «лучший» инструмент для работы — трактуется по разному. Ну и в конце найдете, когда стоит выбирать новые технологии.

#decision_making

—————————————

The Cost of Cognitive Debt

Еще одна статья о проблемах в процессах, где используют ллм и «неизвестное неизвестное» (и модульность как решение). Так вышло случайно, правда. Если Влад говорил о модульности как решении проблемы, то в статье выше, автор приводит термин «когнитивный долг». Долг связан с ухудшением понимания системы. А для измерения долга предлагается использовать метрику Cost of Cognitive Debt.

Начинается текст с того, что когнитивный долг не выдумка автора. В 1985 году Peter Naur писал о том, что в разработке, кроме кода, есть еще «теория» в головах людей, которые писали код. И без этой «теории» теряются причины возникновения кода. А в с нейронками, такой причины изначально может не быть. Далее, идут рассуждения о том, как оценивать «понимание». Для этого предлагается матрица «когнитивная сложность» и «серьезность» (в плане влияния на бизнес). Ну и в конце, как возвращать когнитивный долг.

#SDLC #tech_debt