Бугаенко Егор. Наш код. Ремесло, профессия, искусство.pdf

Егор Бугаенко. Наш код. Ремесло, профессия, искусство.

Глава 1

Говорит что разработчики всегда должны быть в доступе на рынке труда, рассматривая варианты и сравнивая свое положение и состояние с рынком, ходить на собеседования. Другое дело, что ваше CV не должно быть идентифицированно с вами, она должно быть конфиденциальным, иначе вас просто уволят из-за отсутвия лояльности в текущей компании. Увы таковы правила игры, разработчики растут когда свободны, и компании хотят лучших разработчиков но которые теперь станут преданным лично им и откажутся от роста.

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

Вселенная не против воровства

Законы мироздания (физические, экономические) не содержат встроенного морального кодекса. Гигантское неравенство — это факт, который существует не потому, что он "правильный" или "неправильный" с точки зрения Вселенной, а потому что он возможен.

Бугаенко призывает для развития программиста быть автором открытого исходного кода, или по крайней мере активно с ним работать.

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

Глава 2

9 этапов прототипирования

1. Идея / концепция Придумать, что ты хочешь прототипировать — какую проблему решить, какую гипотезу проверить.

2. Сбор требований / исследование Понять пользователей, сценарии, ограничения, конкурентов — собрать входные данные, чтобы прототип был релевантным.

3. Определение минимального набора функций (MVP для прототипа) Выбрать, какие функции должны быть в прототипе, чтобы он всё ещё выполнял основную задачу — не пытаться сразу делать “всё”.

4. Проектирование / макеты / эскизы (wireframes / sketches) Нарисовать структуру, интерфейсы, взаимодействия — чтобы уже визуализировать, как будет работать прототип.

5. Построение прототипа Собрать прототип — может быть “чёрновым”, не завершенным, с ограниченной функциональностью.

6. Пользовательское тестирование / сбор обратной связи Дать прототип пользователям или заинтересованным сторонам, посмотреть, как они работают, что ломается, что неправильно понимают.

7. Улучшения / итерации На основании обратной связи вносить правки, дорабатывать прототип, делать новую версию.

8. Проверка зрелого прототипа / валидация Когда прототип близок к финальной версии, протестировать его по всем сценариям, проверить устойчивость, убедиться, что он готов стать основой для финальной реализации.

9. Переход к финальной реализации / создание продукта На базе проверенного прототипа начать разработку конечного продукта, взяв структуру, архитектуру, интерфейсы, найденные решения.

Комментарии и нюансы

• Эти этапы не обязательно линейны — часто переходят назад (итеративно).
• На ранних этапах прототипы могут быть “throwaway” — их не собираются превращать в финальный код, а используют как эксперимент.
• На финальных этапах прототип может стать “живым” — эволюционировать в реальный продукт.

Конфликты

Результаты конфликта могут быть:

• проигрыш - выигрыш
• проигрыш - проигрыш
• выигрыш - выигрыш

Компромис это типичная ошибка решения конфликтов, все в итоге в проигрыше т.е. случай проигрыш - проигрыш Конфликт должен привести к ободному выигрышу всех сторон.

Тестирование

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

Тестирование — это процесс попытки заставить программу провалиться (Glenford J. Myers)

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

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

Тестирование это процесс:

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

А обеспечения качества (QA) это более широкая область включающая в себя тестирования и им не занимается отдел тестирования, а занимается специалисты по обеспечению качества.

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

Архитектор

Какие обязанности и действия архитектора

На основе книги и интервью, можно вычленить конкретные обязанности:

• Определение стандартов кода: стиль, соглашения, структуры модулей, правила ошибок и обработки исключений, naming и другое.
• Принятие стратегических решений по архитектуре: как делить модули, как компоненты взаимодействуют, как проект масштабируется, как строятся API, как организовано развертывание и CI/CD.
• Ревью кода и отзывчивость команды: архитектор участвует в код-ревью, даёт обратную связь, помогает решать споры по архитектурным вопросам.
• Просвещение команды: объяснять почему приняты те или иные решения, учить техникам (например, как писать тестируемый, модульный код, как избегать “антипаттернов”).
• Наблюдение за качеством: тесты, покрытие, производительность, отказоустойчивость, мониторинг. Архитектор не просто “задаёт структуру”, но и следит за тем, как она жива: как развиваются зависимости, насколько быстро меняется код, нет ли боттл-неков.
• Компромиссы с реальностью: сроки, ресурсы, технический долг — архитектор не в мечтах, а в условиях бизнеса. Нужно уметь выбирать, что важнее сделать быстрее с хорошим качеством, а где можно пойти на компромисс.

Почему эта роль важна, особенно по концепции “Наш код”

• Потому что без роли архитектура т.е. человека взявшего на себя роль диктатора и ответвенного, проект часто превращается в “ползущую лаву”: части, создаваемые разными людьми, растут, разрастаются, и в конце концы трудно изменять, сложно понимать, часто ломка поведения, техдолг.
• Архитектор — как защитник проекта от “программиста-себя”: ошибок, которые сам же кодер может допустить, если нет стандартов, дисциплины, ответственности.
• Эта роль помогает сохранять код “понятным, управляемым, развиваемым” — что для Бугаенко ключ к хорошему ремеслу, профессии, искусству.

Проигравшие и победители

Бедные люди зарабатывают деньги, багатые - отнимают их у других.

Сама вера в то, что русурсы в мире распределены справедливо, делает нас рабами.

Тяжелая работа не ведет к успеху,а чаще всего становится препятсвием на пути к нему.

Быть хорошим и честным человеком и быть богатым и успешным - противоречащие друг другу цели.

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

Хакеры и дизайнеры

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

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

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

Дизайнеры наоборот, они стремятся использовать простые структуры кодирования, пишут поддерживаемый код и их можно легко заменить.

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

Метрики производительности

Эффективное управление должно опираться на цифры и факты.

Количество закрытых тикетов + уровень сложности тикета + количество строк кода у тикета + потраченное время на тикет

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

Давай разберём это не «по книжкам менеджмента», а как инженер, который смотрит и на систему, и на людей, и на архитектуру процесса.

💥 Итог — эффект "метрической ловушки"

Когда вводятся механические метрики без системного смысла, люди начинают оптимизировать под метрику, а не под ценность. Это называется Goodhart’s Law:

«Когда метрика становится целью, она перестаёт быть хорошей метрикой».

В итоге:

• команда перестаёт помогать друг другу,
• общая архитектура деградирует,
• растёт техдолг,
• падает инновационность (все боятся делать нестандартные вещи, ведь их трудно измерить).

✅ Что измерять вместо этого

1. Качество и устойчивость кода

• Количество багов после релиза.
• Покрытие тестами и стабильность CI/CD.
• Количество "горячих фиксов" (hotfixes).
• Скорость восстановления после ошибки (MTTR).

Это измеряет не “трудозатраты”, а результат в надёжности.

2. Вклад в архитектуру

• Снижение сложности модулей (Cyclomatic Complexity).
• Уменьшение технического долга.
• Улучшение перформанса, памяти, времени сборки.

Это уже ближе к инженерной сути — качество решений.

3. Командное взаимодействие

• Участие в ревью (кол-во и качество комментариев).
• Помощь другим разработчикам.
• Наставничество / передача знаний.
• Активность в обсуждениях архитектуры.

Это то, что реально повышает эффективность всей команды.

4. Продуктовые метрики

• Time-to-Market: как быстро идея превращается в фичу.
• Количество релизов без отката.
• Удовлетворённость пользователей (UX feedback).

То есть оценивается не “код”, а влияние кода на продукт.

Как совместить метрики и справедливость

Чтобы не демотивировать:

• Метрики должны быть диагностикой, а не “кнутом”. Они помогают увидеть проблемы, а не искать виноватых.
• Метрики должны быть агрегатные и командные, а не “индивидуальные KPI”.
• Оценку должен давать контекст — менеджер или архитектор, понимающий “почему” сделано именно так.

Как можно сделать правильно

Вместо “оцифровки” альтруизма — нужно делать его видимым:

• Признавать вклад через code review, mentoring, помощь.
• Ввести soft KPI — вовлечённость, инициативность, участие в улучшениях.
• Оценивать не “сколько сделал”, а “что стало лучше в проекте благодаря этому человеку”.

Идеальный баланс

Вывод

Ты абсолютно прав:

если вклад “невидим” и не оценивается, люди перестают его делать.

Но решение — не “оцифровать всё”, а создать систему, где такие действия поощряются культурно и организационно, а метрики служат зеркалом, а не батогом.