Бесконечное ИТ

Старый код не умирает вам нужно его убить. - Grady Booch

На канале The Pragmatic Engineer вышло интервью с живой легендой Software архитектуры Grady Booch!

И на мой взгляд оно получилось мега крутым! Очень интересные рассуждения про историю развития архитектуры и программирования в целом, его мысли на текущее положение вещей и LLM/AI в целом. Кратко законспектировал как менялось история разработки именно в контексте архитектуры.

60-70 - Маинфреймы, компьютеры в лабораториях. Осознание разработки и языков программирования в целом.
70-80 - Появляются мини компьютеры, первое появление распределенных систем. Бурный рост терминалов и терминальных систем. Так появляется потребность понимания как будут связываться такие системы и как они будут работать.
1980 - 1990 - Восхождение ООП, Рождение Rational Software где участвовал Буч и Которую потом купит IBM. Рост темпов разработки корпоративного ПО и как следствие потребности в best practices.
90 - 00 - Рождение и бурный рост интернета, HTML, TCP/IP. В 94-95 в Rational Software создали UML. До середины 00 MS/IBM и прочие гиганты несут знамя корпоративной разработки в массы. Системы становятся еще сложнее.
00 - 10 - 2001 год создание Agile манифеста. Появляется альтернатива корпоративной разработке. Развитие XP практик.
10 - present - Первое появление Solution Architect как роли в cloud компаниях. Строительные блоки становятся крупнее, и появляется потребность продавать клиентам решения созданные из этих блоков.

Ну и пара фраз от Гради Буча которые очень зацепили.

Про Легаси:

"У всех есть легаси, Facebook, Google, даже у OpenAI есть легаси. Как только вы написали строчку кода она становится легаси. Старый код не умирает вам нужно его убить. Если у вас нет саморазрушающегося кода вам прийдется работать с легаси."

Про OpenAI/LLM Гради Буч очень критичен):

"They allow us to build global scale bu...it generator"

Я настоятельно рекомендую посмотреть все интервью, возможно даже не один раз, потому что интересных мыслей действительно много!

https://www.youtube.com/watch?v=u7WaC429YcU

Использование связки Data aggregation + LLM + vector database для агрегирования разных внутренних источников информации и предоставления пользователям интерфейса к ним, потихоньку переходит из разряда диковинки в разряд обычных помогающих инструментов. Uber запустили внутреннего бота который помогает on-call инженерам быстрее выдавать ответы из внутренних вики и прочих систем документации, в ответ на запросы.

https://www.uber.com/en-IN/blog/genie-ubers-gen-ai-on-call-copilot/

Какой интересный код оказывается есть.

451 Unavailable For Legal Reasons
HTTP-код ответа 451 Unavailable For Legal Reasons указывает, что пользователь запросил ресурс, который недоступен по юридическим причинам, например веб-страница, заблокированная из-за судебных исков.

https://developer.mozilla.org/ru/docs/Web/HTTP/Status/451

Хочу сегодня поделится с вами обзором новомодного CursorAI. Это такая IDE/Code editor которая очень плотно интегрируется с многими LLM/AI сервисами. Самая главная фишка это то, что сервис будет понимать полный контекст вашего проекта. И тут лучше посмотреть видео чтобы понять насколько это интересно выглядит в работе.

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

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

https://www.youtube.com/watch?v=gqUQbjsYZLQ

Замечательная статья от Kent Beck, статья компиляция его нескольких лет опыта коучинга в Facebook. Очень круто видеть подтверждения своим мыслям и размышлениям у реально крутых авторов.

- Longevity/diversity. Elite engineers stick with projects long enough to see the consequences of their decisions. Insight is best mined deep in maintenance. At the same time, elite engineers have enough diversity of projects to separate context-dependent lessons from more general ones.

- Success/failure. Elite engineers need to succeed enough to maintain confidence and initiative but they also need to fail enough to question themselves and their assumptions when doing so is valuable.

- Mentored/self-directed. Most elite engineers can point to one or more mentors who changed the trajectory of their career. Elite engineers are also self-directed learners, trusting their curiosity as a compass pointing towards future growth.

- Urgency/slack. Elite engineers work hard, but lots of folks work hard. Elite engineers have the habit of investing the margin in personal growth. When that odd hour or two isn’t likely to yield a great new feature, it can still yield useful learning.

https://tidyfirst.substack.com/p/the-impossibility-of-making-an-elite

Back pressure (Backpressure) - это такая техника управления потоком данных, когда клиент отправляет слишком много данных и сервер может ответить, "не могу все обработать" и клиент уменьшит скорость передачи.
Например rate-limiting по сути является одной из стратегий реализации Back pressure.

Чаще всего выделяют 3 основных.
- Игнорирование данных (определенная часть данных просто игнорируется, в данном случае умышленно, а не потому что сервер просто не успевает их вычитывать). Сюда можно включить rate-limit. Само собой не тогда когда rate-limit например ограничивает ваш тарифный план например а когда это реальный ограничитель рассчитанный исходя из мощности системы.
- Буферизация данных (Накапливаем пиковые волны данных и обрабатываем позже). Немного более затратный метод, какие волны будут? Как часто? Какого размера может быть волна?
- Контроль генератора данных (Сервер контролирует скорость клиента, ускоряет или замедляет его) Клиент получает ответ от сервера что ему слишком быстро и замедляется. Эта реализация требует поддержки на уровне вашей инфраструктуры/фреймворков. Те реализации про которые знаю Kafka producers/consumers, Redis, MongoDB, RxJava, Sping Webflux, скорее всего и другие RX библиотеки других языков программирования тоже, потому что этот концепт популярен в реактивном программировании.

Хорошая обзорная статья

Пример на java

Очень подробная статья от Notion как они переходили от монолитной postgresql к шардированию БД.

Сервис проработал первый 5 лет на одном инстансе БД и только в 2020/2021 году они перешли на шардирование. Подробно описан процесс выбора схемы шардирования, непосредственно переход.

И самое главное выводы.
- Команда хорошо знала об опасности преждевременной оптимизации и откладывала переход на шардинг до последнего. Это сыграло против них, база стала неповоротливой и сузило выбор инструментов для миграции.
- Жалеют что не потратили немного времени и не реализовали zero downtime обновление.

https://www.notion.so/blog/sharding-postgres-at-notion

Несколько раз видел статьи про использование UUID в качестве ключа в postgresql, наконец-то добрался почитать. Вообщем кратко, если вам по какой-то причине пришлось использовать UUID в качестве PK то рассмотрите использование UUID v7, он показывает хороший прирост производительности в отдельных случаях. Дефолтный Java randomUUID выдает v4. Поэтому нужно будет подключение внешней библиотеки.

https://maciejwalkowiak.com/blog/postgres-uuid-primary-key/

Люблю такие статьи в стиле lessons learned и сам люблю говорить на эту тему. Правда в последнее время прихожу к мысли что некоторые советы даже если их прочитать и понять логику, просто не получится применить или прочувствовать/понять. В молодости всегда хочется доказать, что ты умнее/сильнее и у тебя другой путь. Ну это как родительское "одевай шапку зимой" чувствуешь только после того как пару раз сляжешь с серьезным воспалением чего-нибудь.
Но! Это не значит, что про это не надо говорить, такие статьи помогают структурировать и уложить в голове хотя бы то, через что уже точно прошел сам, а значит может появится доверие и к другим советам.

Вынес пару советов которые понравились, остальные читайте в оригинальной статье.

Do things in the most straightforward way possible. It’s easy to fall into the trap of clever solutions, or clever applications of technology, or overbuilding something because you’re anticipating the future. Don’t do it. You will hate yourself for it later when you have to maintain it. Build the thing in the simplest way you can, as fast as you can. You can improve it over time as needs demand.

The software we are building right now will one day be decommissioned and not be used anymore, probably before your career is over. I’ve lost track of all of the software I’ve delivered that isn’t running anywhere anymore. Some of that is because my career is 35 years long. But even some of the software I worked on five or ten years ago isn’t running anymore. This is another good reason to build small increments, just good enough, get them out there, and iterate from there. Anything more and you’ve overbuilt some software that isn’t going to run forever anyway.

https://dev.jimgrey.net/2024/07/03/lessons-learned-in-35-years-of-making-software/

Бывают такие статьи который читаешь и прямо перед глазами пробегают ситуации из прошлых проектов. Сегодня статья о 8 ошибках при переписывании проектов/систем. Автор собрал замечательный список. Чаще всего здесь идет речь о переписывании системы в которых вы не принимали участия при проектировании/написании. Выбрал несколько которые особо понравились и откликнулись, остальные читайте в оригинале.

- Планировать миграцию только когда новая система будет "почти готова" - при позднем планировании миграции могут реализоваться риски по несовпадению форматов, стандартов, объема данных. Что-то чего вы не сможете учесть или увидеть при планировании. Что тогда? Возможно откат на пару шагов назад. Что делать? Помнить что есть например паттерны Strangler Fig, Parallel Run они помогут спланировать миграцию с меньшими рисками.

- Недооценивать усилия. Чаще свойственно middle или начинающим senior разработчикам, они уже могут брать на себя много ответственности но еще не попадали в капканы легаси 🥲. Это когда одна хитрая строчка может стоить пары дней нервных клеток. Что делать? Оценивайте функциональность и объем системы, планируйте по этапам. По поводу планирования связаны две следующие ошибки

- Не спрашивать о функциональности системы, пытаться копировать ее 1:1 и Пытаться заменить всю систему целиком. Спланируйте что вы меняете и почему, возможно у системы есть стабильное ядро и его можно не трогать, или возможно нарекания вызывает только системы которую вполне можно изолировать?

- Оверинжиниринг. Наша любимая программисткая ошибка. Иногда старая система так задалбывает своей отсталостью, что хочется вложить в новую версию все самое свежее и новое. Будьте очень осторожны. История разработки программного обеспечения уже знает такие истории. Легендарный Фредерик Брукс сформулировал Second-System Effect. На смену небольшим и компактным системам приходят неповортливые и раздутые монстры.

Что еще почитать на эту тему?
Patterns of Legacy Displacement (Effective modernization of legacy software systems)

Оригинальная статья "The 8 biggest mistakes when rewriting software systems (that I have seen so far)"