Проектирование и рефакторинг *

Я использую LLM в повседневной разработке уже больше года и довольно быстро упёрся в типовую проблему: модель генерирует “красивый код”, но по мере роста проекта появляется дублирование, разъезжается стиль, растёт число заглушек и отладка становится дорогой. В статье покажу процесс, который мне помог: как разделять контекст по чатам, какие артефакты требовать на каждом шаге и какими чек-листами я проверяю результат.

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

Проблема: никто не знает, кто кого вызывает

В 2012 году биржевой брокер Knight Capital потерял $460 миллионов за 45 минут.
Причина — активация устаревшего модуля, который начал массово размещать ордера.
Отчёт SEC указал на ключевую ошибку:

Привет всем! И Это я мне 16 лет создал свой продукт FocusMind, который не отвлекаясь делал целый месяц сам. Это секрет успеха в создание моего проекта!

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

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

Совет от меня. Это личный опыт!...

У меня была привычка. Вижу классную статью про архитектуру —-сохраняю. Репозиторий с примерами DDD - в закладки. Видео про CQRS - в плейлист «Посмотреть потом».

Вы знаете, чем кончаются плейлисты «Посмотреть потом».

В какой-то момент закладок стало 300+. Половина ссылок битые, треть дублируют друг друга, остальное - статьи, которые казались гениальными в два часа ночи. Я сел и вычистил всё до 106 ресурсов. Собрал их в awesome-list на GitHub.

Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.

Четыре года мы пытались переписать нашу платформу для проведения IT-соревнований Codenrock. Четыре раза отступали. На пятый — два разработчика, тестировщик и UI-дизайнер справились за два месяца. У каждого — Claude Code на максимальной подписке. 

Это история о том, как технический долг накапливает проценты, как мы выбирали стек для новой платформы и что на самом деле значит «80% кода пишет AI».

По мере роста сложности программных систем документация становится не “сопроводительным текстом”, а инженерным активом, она участвует в принятии решений, согласовании требований, проектировании архитектуры, тестировании и эксплуатации. Однако на практике документация часто создаётся разрозненно, несколькими авторами, в несогласованных форматах. Это приводит к потере целостности и росту транзакционных издержек на коммуникации. В такой распределённой среде параллельно растёт применение AI-ассистирования при подготовке технических материалов, что повышает требования к формализации процесса и контролю качества создаваемых артефактов [1].

В программных проектах техническая документация представляет собой совокупность различных артефактов – требований, сценариев, диаграмм, описаний архитектуры и данных – распределённых между участниками и стадиями жизненного цикла. В условиях активного уточнения целей и решений, особенно на стадии исследовательско-опытных работ (research and development, R&D; далее – R&D), такие артефакты развиваются неравномерно, одни быстро детализируются и пересматриваются, другие остаются на уровне ранних гипотез. Это приводит к утрате целостности документационного контура, возникают противоречия между документами, различается уровень абстракции, дрейфует терминология, а изменения становятся трудно сопоставимыми друг с другом. Одновременно ослабевает трассируемость и затрудняется восстановление причинно-следственной цепочки “исходные данные → допущение → решение → требование → сценарий/диаграмма → проверка”, что увеличивает стоимость ревью и повышает риск ошибочных инженерных выводов [2–5].

Не так давно на моей текущей работе впервые за весь мой немногочисленный 4-летний опыт бэкендера понадобилось для нового микросервиса рассчитывать ресурсы под PostgreSQL для данного сервиса. Раньше для меня данная тема было чем-то, чем занимаются DevOps/DBA и никогда прежде не задумывался и не исследовал информацию о том, как качественно рассчитать необходимые ресурсы, чтобы бизнесу не пришлось переплачивать за очень дорогие железки лишние деньги, чтобы потом оказалось, что от купленных мощностей в реальности используется 20-40% (опыт на нескольких работах показывает, что такое случается ну очень часто).

Q: Для кого эта статья?
A: Да в целом для любых технических специалистов, которые так или иначе взаимодействуют с технической поддержкой PostgreSQL и которым впервые нужно для новой БД (например, под микросервис) и сформулировать задачу для DevOps команды на поднятие СУБД для вашего сервиса.

Q: «Зачем мне это? Ну прикину я на глаз, что здесь нужно 50ГБ диска, 64ГБ RAM и нормально поедет»
A: Очень часто в условиях микросервисной архитектуры используется парадигма database per service и в таком случае нельзя просто запросить максимально мощную виртуальную машину. Ресурсы стоят много денег, инфраструктура должна масштабироваться, а значит необходимо уметь определять, какой именно мощности ВМ требуется и какие параметры PostgreSQL следует задать на старте.

В статье вы получите пошаговый расчёт диска, RAM, CPU и базовые рекомендации по конфигу PostgreSQL, а также в подарок готовый промпт для ИИ, если захотите делегировать все расчёты нейромозгу.

Итак, Вам не повезло, Вы – техлид (тимлид, главный инженер etc) большого и старого проекта на C#, который был написан в доисторические времена, когда async еще не завезли. Проект старый и большой, но живой и развивается. Может быть даже, что проект использует современный .NET, современную версию C#, но вот незадача – не использует async, а очень бы хотелось.

 Как осуществить такой рефакторинг и какие трудности ожидают на этом пути?

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

Всем привет, я хочу поделиться своим опытом AI разработки, используя (почти) бесплатные инструменты.

Дисклеймер (обязательно к прочтению)

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

Я не собираюсь тут никого учить «как правильно». Все мои знания — от противного. Я могу лишь рассказать, чего делать точно не стоит, чтобы не сжечь нервы и бюджет.

Привет!

На днях я потратил 3 дня на попытку мигрирвать свой проект с Hardhat v2.22.19 и Solidity v0.8.28 на Hardhat v3.1.6 и Solidity v0.8.33 (ради transient storage); затем понял, что мажор Hardhat менять не стоит и, если хочется обновиться, то можно обновить минор до v2.28.4; в итоге всех манипуляций пришел к стандартному выводу: "если работает - не трогай" (*сарказм).

Однако как бы не так...

Три недели. Скепсис, эйфория, разочарование, умиротворение бессонница. Как я месяц подряд экспериментирую c Claude. Через мою призму и призму Claude. 

Уже более 6 лет я использую кастомные идентификаторы - одна из классных штук, за которые обожаю go. Они незаменимы в описании бизнес-логики - невозможно перепутать порядок идентификаторов. Все вызовы становятся типобезопасными и самодокументируемыми. И писать такой легкочитаемый код очень приятно. Применяю кастомные id очень широко - от парсинга http-запроса до слоя данных.

В статье подробно рассказываю:
• «как было» раньше (и осталось для кадастровых номеров, например),
• переход от кастомизации строк к скрепным uuid.UUID и варианты типизации,
• немного запутаемся в важных условиях кастомизации,
• скопипастим компактное и готовое решение
• и бонусом посмотрим лаконичный синоним в коде.

Недавно я перешёл в новую команду и столкнулся с классической задачей — рефакторингом сложной продуктовой фичи. Путь от диагностики проблемы до «продажи» решения был тернист... и нереально интересен. Всеми знаниями, что из него вынес, делюсь в этой статье.

Текст будет полезен не только разработчикам продуктовых команд. Участникам core-команд расскажу про общие принципы рефакторинга, а менеджерам помогу понять, чем отличается зрелое предложение о рефакторинге от обычного «хочу всё переписать».

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

В статье о том, как паттерн Memento реализуется в Android через CustomView, SavedStateHandle, Compose и навигацию.

В своем кратком тексте 1998 года Энди Хант, отталкиваясь от закона Деметры и принципа разделения команд и запросов, просто и понятно излагает один из важных принципов объектно-ориентированного проектирования — «говори, а не спрашивай». Этот принцип учит делегировать объектам ответственность за их данные, что позволяет создавать слабосвязанные и устойчивые к изменениям системы.

Всем привет!

Читая очередную книгу по архитектуре ПО, я в который раз столкнулся с новым определением того, что же это такое. И всё бы ничего — я уже как будто привык к этому, но буквально те же самые авторы давали совсем другое определение в предыдущей книге!

— Да сколько можно! — подумал я. И тут во мне проснулось любопытство: а сколько вообще таких определений от разных авторов? Есть ли какое-то общепризнанное мнение?

Как оказалось, нет — разные авторы, фреймворки и спецификации дают разные определения. SEI (Software Engineering Institute) даже составил документ около 10 лет назад со списком разных определений. Но в рамках исследования для этой статьи я понял, что и он неполный.

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

Привет, коллеги!

Хочу поделиться подходом к логированию, который радикально упрощает архитектуру и усиливает SOLID.

Сделал пример кода GitHub, чтобы показать как работает теневое логирование (shadow decoupled logging) через события C#.

В эпоху цифровизации, Вы когда-нибудь задумывались, существуют ли способы значительно снизить затраты на разработку ИТ-решений? И речь не про жалкую экономию в 5-10%, а именно экономию в разы, когда от прототипа до ввода в промышленную эксплуатацию - достаточно несколько дней разработки. Не месяцы, не годы, а именно дни. Особенно это актуально для инжиниринговых, конструкторских или производственных компаний, которые по своей сути не являются разработчиками ИТ, но вынуждены здесь и сейчас обеспечивать собственные нужды различными ИТ-решениями.