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

Я не буду писать почему закомментированный код это плохо. Давайте разберемся откуда берется закомментированный код и каковы причины.

Первый вариант. Была реализована некоторая функциональность, которая теперь не нужна. Что делает разработчик в рамках новой таски? Правильно, комментит код! Почему он выбирает такой путь?

- Так проще! И на самом деле при большом давлении сроков мы выбираем здесь и сейчас не самые оптимальные решения.
- Разработчик не уверен в решении. Мы комментим, запускаем код, оцениваем результат глазами или через тесты. Если нет результата - комментим что-то другое, раскомменчиваем пока не получим нужное поведение. Получили? Льем в репу, ведь (см. пункт первый) так проще!
- Разработчик не верит продакту/аналитику/постановщику задачи. У многих был опыт когда фичу требовали вернуть. И проще просто раскомментить нужный кусок, чем что-то делать средствами гита.

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

Третий вариант, который приходит в голову - копипаста чужого кода и отсекание комментами всего ненужного (почувствуй себя великим скульптором!). Но по большей части этот вариант сводится к первым двум.

Что же делать? Можно пообещать разные кары и периодически публично высмеивать коллег. Можно настроить проверки в гите и реджектить такие коммиты. Но это борьба с последствиями. И она может только частично замаскировать существующие проблемы.

Попробуем повлиять на причины.

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

Коммуникация с продактом.
Зачастую у нас нет прямого влияния на продакта. Но есть способы которые мне помогали: обратная связь, коучинг и обучение. Да, вы можете развивать вашего продакта, учить его, наставлять. Хорошие продакты готовы принимать новое и не воротят нос, если вы с ними разговаривает не на языке красоты кода, а объясняете влияние тех или иных решений на систему.

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

Неуверенность в решении.
Что нам дает уверенность в нашем решении? Компилятор, юнит-тесты, автотесты, регресс, телеметрия с прода, продуктовые метрики и иной фидбек. Чем быстрее мы можем получить обратную связь, тем более мы уверены в нашем коде. Инвестируйте в автотесты, практикуйте TDD, BDD, Test-First и другие подобные практики. Также нам поможет правильная нарезка на модули-сервисы, снижение coupling, единая ответственность и другие подобные подходы.

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

А как у вас?

Недавно Дима Павлов рассказывал про корпкультуру в целом и в Додо в частности (https://news.1rj.ru/str/on_vision/314)

Культура – это то, как люди ведут себя в трудных ситуациях и на распутье. В критические моменты мы откатываемся к базовым настройкам. То, какие поступки мы при этом совершаем – это и есть культура.

И очень классно, когда эта культура не только есть, не только поддерживается, но и зафиксирована в виде какого-то артефакта, который можно давать на входе и шарить наружу.
Внезапно для себя узнал, что у Thoughtworks (это те самые кто выпускает техрадар и у кого работает Мартин Фаулер) есть такой артефакт – Sensible defaults.

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

Что внутри - набор принципов и практик, которые считаются хорошими отправными точками. Например:
- Relentlessly pursue value and business benefits
- Ensure visibility of work
- Prioritize asking hard questions
- Incorporate observability for monitoring functional and infrastructure components

etc.

Рекомендую ознакомиться - буквально 30 страниц, разбитых на блоки.

Хотите обсудить или узнать глубже? У меня есть анонс для вас от Жени @elukianov и Сергея @Bukharovsi_sg

В следующий Понедельник, 15 Июля в 19:00 собираемся на стрим обсуждать Sensible Defaults: кодекс поведения четких разработчиков.

В этот раз начнем с разрабов, секьюрити и девопса

Формат: Встрерча в Zoom, бурное обсуждение. Лимит 1.5 часа, приносить свое пиво, чай, кофе. Приготовьтесь живо участвовать в обсуждении!

Записываться у бота

Друзья из Health Samurai проводят 8 августа архитектурный митап: про модели, cqrs — всё что мы любим 💪

Всем привет!
Самураи организуют онлайн-митап по архитектуре систем и кода. Мероприятие состоится 8 августа в 17:00 (Por). Поделимся нашими инсайтами, опытом и хотим послушать вас :)

Будет 2 доклада по 25 минут и время на вопросы и обсуждение:
🔉 Системы движимые моделями
— Николай Рыжиков, CTO at Health Samurai
🔉 CQRS в действии
— Артем Бурыкин, Founder at AVE Systems

Приглашаем опытных инженеров и архитекторов. Участие бесплатное, необходима регистрация!
Подробности про мероприятие 👉 здесь

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

С Днём знаний! Вперёд к новым вершинам! 🚀

Не DDD единым
Утомился от споров про ивент шторминг, cqrs, границы контекстов? Устал перемапливать джейсоны? Хочется копаться в кишочках?

Новый сезон курса по базам данным от Andy Pavlo ждет тебя! Только с++, только хардкор!

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

Почему агрегаты должны хранить свои секреты

Когда в чате обсуждают агрегаты, то в первую очередь упоминают инварианты и транзакционные границы, но есть еще один критический аспект, который нельзя игнорировать: сокрытие деталей внутренних сущностей. Агрегаты должны быть не просто контейнерами для реализации бизнес-правил - они также должны защищать свою внутреннюю структуру. Одна из важнейших функций агрегата - обеспечить, чтобы его внутренние сущности и объекты значений не использовались (и тем более не изменялись) внешним кодом. Например, агрегат Order может содержать список элементов Product. Вместо того чтобы разрешать доступ, например order.Products.Add(product), лучше добавить метод order.AddProduct(product).

Почему? Потому что таким образом агрегат контролирует все необходимые проверки и пересчеты внутри себя. Это сохраняет логику последовательной, гарантируя, что когда нам надо пересчитать что-то вроде TotalPrice, то мы сделаем это в одном месте и сразу для всех. Внешний код не должен знать, как именно это делается. Но это не все, самое важное:

Сохранение секретов == гибкость

Когда агрегаты скрывают свою внутреннюю структуру, наша система становится гораздо более гибкой. Вы можете рефакторить внутрянку, не переживая за другие части кодовой базы. Внешние компоненты взаимодействуют с агрегатами через четко определенный интерфейс (aggregate root, корень агрегата), что делает наш код более устойчивым к изменениям.

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

Прикольное упражнение, заряжаем в GPT промпт "Describe the domain, model of which consists of classes:" и далее copypaste список классов из модели домена. Оно вываливает кучу текста, похожего на правду, если вы используете термины из предметной области, а затем "provide clear and brief denoscription" и в догоночку "Provide bounded context name based on denoscription" и мэтчим с собственным названием ограниченного контекста :) Не то, что бы я открыл кейс для использования LLM, просто оно неплохо справляется в части "naming things", уже не первый раз дистиллирую термины и это работает.

Оказывается видео Эванса уже доступно (с другой конфы)

Эрик поделился своим взглядом на развитие LLM и их потенциал. Доклад местами капитанский, если вы последние год-два хоть что-то копали по этой теме.
Что важно, если коротко: 1. будущее непредсказуемо, 2. надо экспериментировать с LLM уже сейчас.

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

Поделитесь вашими инсайтами 🙏

Какое хорошее сравнение!

Я всегда стараюсь подсветить продактам и разработчикам, если часть айтемов в беклоге уже давно покрылась плесенью. Особенно "люблю" статусы а-ля PAUSE или WAITING.
Почему для инженеров в продуктовой команде важен чистый (дистиллированный) бэклог?

"Нельзя управлять тем, что невозможно измерить"

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

Спам достал, решил по совету @irrationality попробовать предбанник. Посмотрим как с ним будет.

Оверимплоймент: исследование от NEWHR

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

Цель исследования:

• Понять, насколько распространено совмещение работ и в каких компаниях чаще встречается.

• Узнать отношение работодателей: какие риски и преимущества они видят?

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

• Оценить, влияет ли запрет удалёнки на распространение явления.


Почему стоит участвовать?

• Доступ к эксклюзивным материалам с результатами исследования.

• Ранний доступ к итогам и закрытый эфир с экспертами NEWHR.


Результаты выйдут в начале 2025 года.


👉 [опрос] — займёт около 6 минут

Документация многими считается обязательной для успешных проектов, но действительно ли она так эффективна? Я зачастую вижу чрезмерные ожидания, но есть ряд проблем:



1️⃣ Устаревает быстрее, чем кажется: Код меняется, а документация — нет. Поддерживать её в актуальном состоянии сложно, а устаревшие документы только путают.

2️⃣ Иллюзия контроля: Красиво оформленный документ создаёт ложное чувство понимания и контроля. Кажется: «раз написано, значит, всё ясно». На деле же это может быть не так.

3️⃣ Синдром «написал и забыл»: Многие пишут документацию потому, что «так надо», а не потому, что она действительно полезна. Её почти никто не читает, и уж тем более не обновляет.

4️⃣ Валидация у доменных экспертов? Почти никогда. Техническая документация редко проверяется экспертами предметной области, что приводит к пробелам в знаниях и ошибочным допущениям.

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

Друзья, с Новым годом! ☃️
Желаю всем интересных проектов, крутых коллег и непрерывного развития. К последнему я постараюсь приложить свою руку. И начнем с короткого списка относительно свежих/ожидаемых книг.

The Hundred-Page Language Models Book — Андрий Бурков https://thelmbook.com

Андрей, автор известной The Hundred-Page Machine Learning Book, готовит к выходу The Hundred-Page Language Models Book. Эта лаконичная книга фокусируется на фундаментальных основах LLM и станет незаменимым пособием для инженеров, дата-сайентистов и AI-энтузиастов, желающих разрабатывать или использовать LLM.

The Developer Experience book — Николь Форсгрен и Аби Нода https://developerexperiencebook.com

Николь Форсгрен и Аби Нода, соавторы и эксперты в области производительности разработчиков (Accelerate), исследуют тонкости DevEx. Жду, когда эта книга будет опубликована.

Become a Great Engineering Leader — доктор Джеймс Стэниер https://www.theengineeringmanager.com/book/

Доктор Джеймс Стэниер, автор Become an Effective Software Engineering Manager, представляет новую книгу Become a Great Engineering Leader. Это практическое руководство для старших руководителей, таких как директора по инженерии, вице-президенты и технические директора. Оно охватывает такие темы, как управление менеджерами, разработка стратегий и построение карьерного пути, предоставляя дельные советы по созданию высокоэффективных организаций.

Facilitating Software Architecture — Эндрю Хармел-Лоу https://facilitatingsoftwarearchitecture.com

Эндрю Хармел-Лоу, эксперт в области гибкой архитектуры, предлагает новый взгляд в своей книге Facilitating Software Architecture. Эта книга переосмысливает роль архитектора в современных программных системах, акцентируя внимание на сотрудничестве вместо централизации. Хармел-Лоу делится практическими методиками, позволяющими объединить архитектуру и гибкие практики, чтобы создать устойчивые и эффективные системы.

Flow Engineering: From Value Stream Mapping to Effective Action — Стив Перейра и Эндрю Дэвис https://flowengineering.org

Стив Перейра и Эндрю Дэвис, эксперты в области value stream mapping, представляют книгу это руководство по оптимизации рабочих процессов и согласованию команд. Объединив принципы value stream mapping и системы Toyota, они предлагают практические инструменты для ускорения инноваций и улучшения взаимодействия команд.

Что читаете вы? Поделитесь, дополню свой вишлист🙏

Завтра планируется интересный стрим. Рекомендую послушать, особенно если не очень знакомы с концепцией CDC в целом и с Debezium в частности https://www.youtube.com/live/IPV6WVx71k8

Влад @vladik_kh пообщался с ребятами из {между скобок}

Получилось как всегда интересно и полезно – https://www.youtube.com/watch?v=PRL3vVfv1dA

Влад нарасхват ☺️ https://www.youtube.com/live/7j6eoTMM-Xc

Сейчас пилотирую на одном пет-проекте ИИ помогатора.
Стек: реакт на фронте, dotnet8 (minimalapi aot) для апи. Для понимания – последний раз регулярно писал для прода на фронте во времена jquery/angular 1.x, c# - наоборот основной язык и что-то я в нем понимаю.

В качестве помогатора был взят Windsurf https://codeium.com/windsurf

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

Что могу сказать:
1. Это очень круто. Я не представляю сколько бы времени у меня ушло собрать все эти vite, husky, jest и прочий фронтендовый тулинг. И еще больше на разобраться с реактом, версткой и тп. Здесь же спустя пару часов тыкания, корнер кейсов и прочих объяснений у меня уже был проект с парой страниц, с тестами, с автодеплоем по пушу и прочим. Общался я с помогатором и CLI тулами, код руками не трогал.
2. Бекенд я начал писать сам, еще до windusrf. Да и потом некоторое время боялся отдавать, но хотелось ускориться и помогатор неплохо справился. Единственное но – в райдер сложно встраивать плагины и приходится писать в двух окнах: руками в райдере, помогатором в VSCode (точнее в их версии VSCode).
3. При больших изменениях жди больших бед, приходилось тормозить.
4. Помогатор владеет тулингом: доступ в бд, логи, гитхаб, облако. И классно этим пользуется, чтобы проверить результат свой работы, если видит свой продолб – сам исправляет, коммитит пушит.
5. Помогатор на фронте не видит своей работы. И этого очень не хватает. Говоришь:

– сделай по центру.
– Ага, вот да, вот поправим то, поправим это... Готово!
– Нет, ничего не поменялось, контент по-прежнему прибит к левому краю.
– Со сорри, я понимаю ваше разочарование. Да я вижу причину, сейчас мы все поправим...бамс-бамс-бамс... Готово!
– 🤬 все по старому!
...

Мне кажется это потенциальная точка роста для таких систем (ну пока пишут софт для кожаных мешков с колбочками).


Что важно?
А важно то, чему нас учили все эти ребята из книжек про разработку, только теперь это еще важнее:
1. Быстрая обратная связь: у вас должны быть юнит-тесты с принудительным запуском на пре-пуш хуке, у вас должен быть CI-CD, у вас должны быть e2e автотесты, у вас должен быть мониторинг и хелс-чеки. Вы начали писать код в разы быстрее и не можете себе позволить тратить дни на полный регресс.
2. Беби степы (как учил Кент Бек). Пару раз помогатор мне разваливал проект. Из-за отсутствия быстрой обратной связи я слишком поздно понимал, что ушел не туда, а так как это эпизодический пет-проект, то спустя неделю я уже не мог вспомнить как я пришел в эту точку. В итоге маленькое изменение, прогон тестов, выкладка и прочее, повторить.
3. Следите за тестами. Их надо писать, возможно даже больше чем хватило бы при обычной разработке. Можно попробовать писать по ТДД. И следите, чтоб помогатор при падении тестов фиксил код, а не переписывал тесты)
4. Размер контекста важен. LLM плохо умеет в огромные конексты. И вроде эту особенность пока не получается победить (к сожалению или к счастью). Так что вам надо здесь помочь помогатору и самостоятельно нарезать куски. Все это также верно и для человеческой разработки.
5. Без разработчика пока что никуда. Я читал посты продАктов как они собрали проект на флаттере с бекендом без технического бэкграунда. Но я не понимаю как. Может проекты совсем уж простые, но у меня пару раз уходил совсем не туда. И только мой опыт помогал мне вырулить ситуацию.
6. Мне кажется (хоть я пока и не пробовал) парное программирование (человек-человек-помогатор) это просто бомба. Быстро, качественно и весело!

Поделитесь вашим опытом/видением/мнением