Всем привет, это я, Орландо. Я фанат Apple и инженер-программист в arconsis. Время от времени я публикую статью из серии «Орландо думает», в которой освещаю конкретную тему, которую считаю важной или волнующей. Иногда это могут быть просто отдельные аспекты повседневной жизни, а иногда это могут быть подсказки, намеки, размышления или призывы — но не исключена и бессмыслица.
Хочу написать о сроках сборки. О долгом времени сборки. И о разочаровании, которое здесь может возникнуть. Но сначала я хочу поблагодарить Майка Хэя, чей твит вдохновил меня на написание этой статьи в блоге.
Ссылка на Twitter (Подсказка: это тред)
Майк Хэй приводит 5 баллов на тему "Почему разработчики жалуются на длительное время сборки?".
- Автоматизированным системам тестирования нужны полные сборки для запуска тестов.
- Медленное наращивание убийственного импульса.
- Когда инструменты настолько медленные, что кажется, что они не работают, они становятся новой проблемой, которую нужно решить.
- Инструменты иногда вызывают полную сборку — это неизбежно
- Разработчикам приходится строить десятки раз в день
Особенно пункт 3 мне очень понравился, и я хотел бы подробно рассмотреть его.
Но — прежде чем мы продолжим — почему бы нам не позаботиться об этом раньше, чтобы сократить время сборки?
«Забытый» технический долг
Следует ли избегать изменений, которые в первую очередь приводят к увеличению времени сборки? Да, конечно, желательно. Всегда погашайте любой технический долг через равные промежутки времени. Это как прибираться и убираться в квартире — лучше делать понемногу каждую неделю, чем со временем погрузиться в хаос.
Плохо то, что время сборки часто считается поздним. Независимо от того, насколько модульным и архитектурно обоснованным является проект, время сборки может пострадать. Например, здесь пагубно сказываются необходимые рамки. (Многие из вас, возможно, знают: вы должны включать Framework X по маркетинговым причинам. *вздох*). Кроме того, проект органично растет с его функциями, что всегда увеличивает время сборки. Менее заметно, если это слишком сильно увеличилось во многих разных точках. Если мы потом поймем, что это просто больше не работает — мы давно упустили момент для своевременных контрмер.
По общему признанию, это также относится к техническому долгу, который вы естественным образом накапливаете в своей программной архитектуре — только теперь мы лучше его видим.
Итак, если предположить, что наше время сборки слишком велико. Почему это проблема?
Функционально сломан
Проблема в том, что то, что работает очень медленно, кажется сломанным.
Мы все знаем этот эффект, когда пытаемся загрузить веб-сайт с медленным интернет-соединением. Когда я вижу индикатор загрузки в течение длительного времени, я замечаю, что рефлекс хочет перезагрузить напрямую — он выражает «слишком долго, кажется сломанным, попробуйте еще раз». В настоящее время это также моя проблема с интернет-провайдерами в Германии, которые ограничивают мою скорость до «пограничного века» после того, как мой объем данных заканчивается. Да, на самом деле, у меня еще есть связь. Но на самом деле он функционально сломан. Это именно тот эффект, который вы испытываете как разработчик с длительным временем сборки.
И то, что вы считаете сломанным, вы хотите починить.
Вы пытаетесь решить проблему
Что-то начинает происходить, и фокус внутри команды смещается. Таким образом, вы начинаете тратить много времени на техническое обслуживание. Для достижения быстрого успеха лучше действовать итеративно. Как я уже говорил выше — понемногу, а не все сразу. В принципе, это правильно. Но я думаю, что этот итеративный подход легче работает, например, для проблем с производительностью во время выполнения. Таким образом, вы можете ввести новый поток в одном месте и сделать алгоритм X немного более эффективным. Или с монолитным кодом, где тоже можно попробовать сделать хотя бы небольшую часть более читабельной и модульной.
С другой стороны, зачастую только радикальные и более значительные изменения оказывают заметное влияние на время сборки. Это особенно верно, когда небольшие настройки производительности, повышающие производительность на несколько секунд, уже были достигнуты в качестве «быстрого выигрыша».
Но если разработчики осознают, что они не могут просто работать над настройкой проекта и инструментами в течение двух месяцев, они пытаются вложить гигантскую гору работы в «техническую дорожную карту». Именно здесь «техническая дорожная карта» начинает конкурировать с реальной дорожной картой продукта.
Фокус теряется
Ну вот, вы начинаете планировать «технические истории» и пытаться оправдать их перед владельцами продукта. Как разработчик, борьба начинает облегчать ежедневную боль, которую не-разработчики могут не понять в полной мере. Параллельно вы игнорируете действительно полезные функции, которых ждут ваши пользователи.
Правда, такие моменты могут случиться при любом техническом долге. Поэтому мы всегда должны четко понимать: момент, когда технический долг мешает вашему проекту, — это не тот момент, когда вы внезапно осознаете, что ваш продукт вряд ли можно будет выпустить. Вместо этого он начинается намного раньше — когда больше времени тратится на встречи, вопросы инфраструктуры и настройку проекта.
Остерегайтесь этих симптомов на ранней стадии — это сигнал тревоги!
Иметь дело с этим?
Сама установка в порядке; вы понимаете код, вы думаете, что кодовая база достаточно модульная, и пока нет реальных причин для беспокойства? Тогда почему бы нам просто не смириться с тем, что сборка иногда занимает 30–40 минут?
Как упоминалось выше, если что-то кажется сломанным, с этим трудно жить. Но есть более опасные вещи, чем потеря внимания к реальной дорожной карте. Помимо того, что вы можете дойти до точки, когда релизы становятся трудными, психологическая составляющая часто полностью забывается.
Разработчики, которые смотрят только на индикаторы загрузки и постоянно ждут сборки своего кода, становятся недовольными. Вы никогда не войдете в состояние естественного «потока». Даже самые незначительные изменения, такие как скрытие метки в пользовательском интерфейсе, настройка соответствующего модульного теста, отправка, а затем ожидание в CI, пока сборка не станет зеленой, становятся делом 1–2 часов. Это не то, что разработчики видят в эффективной работе.
Еще хуже становится, когда внутри коллектива наступает отставка: «Так было всегда — мы все равно мало что можем с этим поделать». Это тот момент, когда открываются окопы, и вы как работодатель должны быть осторожны, чтобы разработчики не сбежали толпами.
Решение?
К сожалению, если вы ожидаете от меня «решения» сейчас, вы будете разочарованы. Командные созвездия — это всегда сложная структура. Каждая ситуация и каждая настройка очень индивидуальны. И долгое время сборки не всегда является долгим временем сборки.
Просто важно понимать: со временем сборки он ведет себя как с любым другим техническим долгом — откладывание проблем никогда не делает его лучше.
Регулярно и как можно раньше устраняйте проблемы!
И если проблемы продолжают повторяться в течение длительного времени, и вы замечаете, что объем работ по обслуживанию не снижается даже после того, как вы снова и снова пытаетесь работать над ними, вы можете подумать о фундаментальных проблемах.
Особенно в крупных компаниях часто не принято подвергать сомнению решения, которые 4–5 лет назад считались инновационными, и отбрасывать их при необходимости.
Но мы должны принять эту недолговечность в сегодняшнем сложном техническом мире. Нет такой вещи, как гарантия будущего. Мы можем только гарантировать, что всегда остаемся на связи.
Однако долгие сроки сборки здесь, к сожалению, не помогают 😊
Убедитесь, что ваши владельцы продукта/менеджеры/кто-то еще знает об этом! Время сборки — это рабочее время. А рабочее время — это время жизни. И мы не любим тратить время жизни на бессмысленное ожидание.
Ура 🍻
Орландо
