Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

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

3 Причин такой катастрофической разницы довольно много. Вот некоторые из них:

4 <ul><li>Ошибки топ-менеджмента в бизнесе. Если бизнес делает не то, что надо, то не важно насколько эффективно он делает это - в конце концов бизнес закроется. Эта тема выходит за рамки текущего гайда.</li>

5 <li>Ошибки топ-менеджмента в области процессов. Если на этом уровне все плохо, то все остальное вторично. Даже неверная система бонусов может привести к разладу в команде и полной блокировке разработки в конечном счете.</li>

6 <li>Человеческий фактор. Личные качества и человеческие пороки могут создать проблемы как остальным членам команды, так и всему проекту в целом. Главная проблема в том, что эту часть невозможно выправить никакими процессами. Только изменение поведения. Либо расставание.</li>

7 <li>Плохой процесс разработки. Эта тема касается всех инженеров без исключения. Сюда входит все, начиная от взаимодействия и работы с задачами, заканчивая тестированием и проведением ревью кода.</li>

8 </ul>На некоторые проблемы повлиять либо сложно, либо невозможно (с уровня разработчика). Но другие, особенно относящиеся к инженерным практикам, нужно постоянно улучшать и менять. Программисты должны принимать в этом самое активное участие.

9 <ul><li><a>Книги</a><ul><li>Человеческий фактор. Успешные проекты и команды</li>

10 <li>Мифический человеко-месяц, или Как создаются программные системы</li>

11 <li>Идеальный программист. Как стать профессионалом разработки ПО</li>

12 <li>Цель. Процесс непрерывного совершенствования</li>

13 </ul></li>

14 <li><a>Manifesto for Agile Software Development</a></li>

15 <li><a>Bus Factor</a></li>

16 <li><a>Карго культ</a></li>

17 </ul>И хотя практик довольно много, в конечном итоге все сводится к тому, как быстро клиенты получают результат вашей работы и насколько они им удовлетворены. Ниже приводится чек-лист, который позволяет понять, используются ли в команде те инженерные практики, которые считаются наиболее удачными.

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

19 <h2>Содержание</h2>

20 <ul><li><a>Код</a></li>

21 <li><a>Среда разработки</a></li>

22 <li><a>Качество</a></li>

23 <li><a>Процесс разработки</a></li>

24 <li><a>Выкатка новых версий (более актуально для веб-проектов)</a></li>

25 </ul><h2>Код</h2>

26 Хорошо

27 <ul><li><a>VCS</a>. Код находится под контролем версий (как правило гит).</li>

28 <li><a>Общий код</a>. Любой член команды в любой момент времени может изменить любую часть системы.</li>

29 <li><a>Единый стиль кода</a>. В команде все придерживаются стандартов кодирования, принятых для данного стека (языка, платформы).</li>

30 </ul>Плохо

31 <ul><li>Отсутствие единого стиля. Каждый пишет код в том стиле, к которому он привык. Нет общих стандартов либо есть, но свой, совершенно отдельный от общепринятого.</li>

32 <li>Не используется контроль версий. Вместо этого используются бекапы кода, а разработчикам приходится договариваться, чтобы не перетереть изменения друг друга.</li>

33 <li>Код имеет "владельца". Программисты защищают свой участок кода от посягательства других участников.</li>

34 </ul>Ссылки

35 <ul><li><a>Trunk Based Development</a></li>

36 </ul><h2>Среда разработки</h2>

37 Хорошо

38 <ul><li>Девелопмент среда. Разработка ведется в специальной development (dev) среде. Как правило, это локальная машина (возможно, с использованием Vagrant или Docker Compose). Эта среда у каждого разработчика полностью своя, и изменения в одной среде не могут влиять на другие среды разработки.</li>

39 <li>Разворачивание среды автоматизировано и происходит "одной кнопкой". Это позволяет легко вводить в проект новичков, быстро и в автоматическом режиме распространять инфраструктурные изменения, работать без страха что-либо поломать, так как легко восстановить.</li>

40 <li>Инфраструктура как код. Распространение изменений конфигурации происходит через код проекта. Достаточно еще раз выполнить развертывание дев среды (с новым кодом проекта), как подхватятся все обновления.</li>

41 <li>Среда разработки максимально приближена к условиям продакшена. Если сервис работает на Linux, то и разработка ведется на Linux. То же самое касается и других аспектов.</li>

42 </ul>Плохо

43 <ul><li>Разворачивание среды и настройка происходит по мануалам, либо методом "попробовал запустить - прочитал сообщение об ошибке - погуглил - исправил". Дорого и неэффективно. Мануалы устаревают практически сразу после того, как их пишут. Новый человек может тратить дни на разворачивание среды с нуля.</li>

44 <li>Ручное обновление конфигурации. Всем разработчикам рассылается директива произвести локальные изменения настройки среды (например, доставить что-нибудь новое) для работы нового кода.</li>

45 <li>Общая база данных для всех разработчиков. Нагрузка от одного человека влияет на всех. Случайная поломка также тормозит всех остальных.</li>

46 </ul><h2>Качество</h2>

47 Хорошо

48 <ul><li>Кодовая база покрыта тестами. Тесты повышают уверенность в работоспособности кода. Хорошие тесты положительно влияют на дизайн самого кода. Как правило, код, покрытый тестами, сам по себе лучше кода без тестов. Хотя есть корреляция.</li>

49 <li>Частично протестированная фича или вовсе - фича без тестов - не считается выполненной. Наличие тестов значительно снижает нагрузку на всех остальных членов команды и положительно влияет на качество решения задачи. К тому же часто происходит, что если тесты не написать сразу, то потом на них времени не останется.</li>

50 <li>Программист отвечает за фичу до самого конца. Фича считается выполненной, только когда она работает на продакшене. Каждый человек в команде должен понимать, что наиважнейшая цель - это доставка ценности клиенту. Пока фичей никто не пользуется, то не важно, написана она или нет, потому что бизнес в этот момент остается в пролете.</li>

51 <li>Команда ревьювит код друг друга (без фанатизма). Ревью - не только способ найти ошибки, но и способ учиться друг у друга.</li>

52 <li><a>Парное программирование</a>. Техника эффективна не только между программистами. Она очень полезна в парах "программист и тестировщик", "новичок и опытный".</li>

53 <li><a>Continuous integration (CI)</a>. Репозитории проекта подключены к серверу непрерывной интеграции, на котором после каждого коммита проверяется стиль кодирования (через запуск линтеров), прогоняются тесты, осуществляется сборка проекта (например, компиляция).</li>

54 <li>В случае инцидентов проводятся<a>пост мортемы</a>.</li>

55 <li><a>Ретроспектива</a>. Процесс непрерывно улучшается и на изменения влияет каждый член команды.</li>

56 </ul>Плохо

57 <ul><li>Нет тестов. Работа нового кода проверяется только ручным способом, через прокликивание. Последствия катастрофические - скорость доставки низкая, а качество кода, скорее всего, неудовлетворительное.</li>

58 <li>Отсутствует код ревью. Разный стиль кодирования, изоляция программистов друг от друга, слабый обмен опытом, плохие решения в продакшене.</li>

59 <li>Программист считает, что фича закрыта, когда код попал в основную ветку. Новый код лежит мертвым грузом и не приносит пользы. Может устареть до попадания клиенту.</li>

60 <li><a>KPI</a>. Активно используются количественные метрики: строки кода, выпущенные фичи, закрытые баги. Вместо ориентации на результат, разработчики стремятся выполнить KPI. Даже в случае, если это идет вразрез с задачами бизнеса.</li>

61 <li>Высокий уровень формализации процессов. Замедляется скорость, падает мотивация.</li>

62 </ul>Ссылки

63 <ul><li><a>Экстремальное программирование</a></li>

64 <li><a>Парное программирование (доклад Николая Рыжикова)</a></li>

65 <li><a>Как распространять инженерную культуру в своей компании</a></li>

66 </ul><h2>Процесс разработки</h2>

67 Хорошо

68 <ul><li>Разработчики руководствуются принципами<a>12factors</a>. Приложения проще разворачивать, масштабировать и мониторить.

69 </li>

70 <li>Запуск одного теста выполняется за доли секунды. Разработка через тесты подразумевает очень частый запуск тестов в процессе отладки. В такой ситуации крайне важна скорость старта конкретного теста - она должна быть настолько быстрой, чтобы разработчик оставался в контексте.

71 </li>

72 <li>Тесты писать легко и приятно. Лакмусовая бумажка для определения того, насколько хорошо с тестами в проекте. Если приходится себя заставлять, то есть вероятность, что тесты написаны плохо (например, много моков) и их будет недостаточно.

73 </li>

74 <li><a>Test-driven development (TDD)</a>. По возможности тесты пишутся до кода. Есть несколько причин, по которым это важно:

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

76 Код в любом случае надо проверять. Если теста не будет, то это придется делать руками.

77 </li>

78 <li>Перед починкой бага сначала пишется тест, который его воспроизводит, затем происходит исправление. Только в этом случае тесты действительно помогают.

79 </li>

80 </ul>Плохо

81 <ul><li>Тесты есть, но приходится заставлять себя писать тесты, потому что их сложно писать, они долго выполняются, часто ломаются или постоянно приходится их переписывать.</li>

82 <li>Запуск одного теста занимает секунды. Такой тест тяжело запускать при разработке через тесты и общее время выполнения тестов становится слишком большим.</li>

83 <li>Код правится прямо на продакшене (то место где он работает). Без комментариев.</li>

84 </ul>Ссылки

85 <ul><li><a>12factors</a></li>

86 <li><a>Начинаем писать тесты (правильно)</a></li>

87 <li><a>Бережливое тестирование</a></li>

88 </ul><h2>Выкатка новых версий (более актуально для веб-проектов)</h2>

89 Продакшен-среда - инфраструктура (например, сервера), в которой развернут проект. Она обеспечивает доступ к проекту конечным пользователям.

90 Деплой (выкатка) - процесс, в рамках которого происходит обновление проекта в продакшен среде.

91 Хорошо

92 <ul><li>Автоматизация. Развертывание автоматизировано и выполняется одной кнопкой.</li>

93 <li>Частые небольшие релизы. Развертывание - рядовое событие, которое может выполняться в любой момент по готовности фич, без необходимости отвлекать команду.</li>

94 <li>Zero Downtime Deploy. Обновление версии происходит прозрачно для пользователей.</li>

95 <li>Развертывание, технически (то есть все хорошо автоматизировано), может выполнить любой член команды.</li>

96 </ul>Плохо

97 <ul><li>Выкладка происходит в ручном режиме. Например, через прямое управление с сервера. Самый ненадежный и не масштабируемый подход, подвержен ошибкам и может занимать значительное время. При наличии нескольких серверов просто не работает.</li>

98 <li>Выкладка кода сопровождается эмоциональным напряжением и вовлечением большого числа участников. В такой атмосфере все стремятся выкатываться реже, что приводит к еще большим проблемам и напрямую вредит бизнесу.</li>

99 <li>Процесс развертывания длится десятки минут или часы. Скорее всего, это означает, что процесс сборки проекта интегрирован с самим деплоем. Эти задачи нужно выполнять независимо.</li>

100 <li>Разворачивание происходит раз в неделю и реже. Чем больше изменений выкатывается сразу, тем выше шанс поломки. И тем сложнее отследить влияние каждой фичи на бизнес-показатели. Кроме того, происходит забывание тех изменений, которые были сделаны ранее и ждали своего часа до выхода в продакшен.</li>

101 <li>Во время разворачивания наблюдаются длительные даунтаймы. Пользователи вынуждены ожидать завершения деплоя. Такая ситуация мешает деплоить часто.</li>

102 <li>Развертывание выполняет один специальный человек. Знания хранятся в одной голове. Уход в отпуск или болезнь ломает весь процесс. Остальные программисты не понимают "как оно работает там".</li>

103 <li>Деплой конфигурации. Обновление конфигурации, не относящейся непосредственно к логике кода, требует повторного деплоя. Например, изменение пароля к базе данных или адреса базы. Эти параметры являются чисто инфраструктурными и должны попадать в код так, как описано в 12factors.</li>

104 </ul>Ссылки

105 <ul><li><a>Что такое DevOps?</a></li>

106 <li><a>Инжиниринг в букинге</a></li>

107 <li><a>Среды разработки. Мужики, выкатывай!</a></li>

108 <li><a>Вебинар: Как распространять инженерную культуру в своей компании?</a></li>

109 </ul>