Comments 51
Три несовместимых вещи: большой рефакторинг + частые мерджи + тесты. На то он и большой рефакторинг, что требует заморозки другого тех долга.
От начала и до конца рефакторинга система будет находится в неконсистентном состоянии. Практически до последнего коммита
"Рефакторинг — это применение небольших шагов, сохраняющих поведение, и внесение больших из менений путем связывания воедино последовательности упомянутых малых ша гов, сохраняющих поведение. Каждый отдельный рефакторинг сам по себе либо довольно маленький, либо представляет собой комбинацию маленьких шагов.
В результате, когда я выполняю рефакторинг, мой код не оказывается надолго в неисправном состоянии, что позволяет мне останавливаться в любой момент, даже если я еще не закончил всю намеченную работу полностью.
Если кто-то говорит, что его код был неработоспособен в течение не- скольких дней во время выполнения рефакторинга — можете быть увере ны, что никакого рефакторинга не было."
"Рефакторинг", 2 издание, 2018 год, Мартин Фаулер
Попробуйте поднять версию MUI4 на MUI5/6/7 или React 17 на 18/19.
У компаний уходят на это месяцы и то не факт, что получается с первого раза
Есть технологии постепенного внедрения больших изменений. Как человек, который постоянно пользуется ими, могу сказать, что ничего невозможного тут нет. Ими не все пользуются, потому что не все понимают, зачем. Но если понимание зачем есть, то достаточно только чуть-чуть подумать, и сразу придумается решение.
Некоторые изменения по своей сути атомарны, несмотря на то, что объёмные. Их не сделаешь постепенно - это фундаментальная их особенность.
Можно раздробить изменения до уровня атомарных, но не дальше.
Есть технологии постепенного внедрения больших изменений.
В общем случае их нет. Есть они только тогда, когда есть последовательность состояний, в каждом из которых программа работоспособна, и перейти от одного к другому можно путем мелких и, что важно - обратимых, иззменений.
Если такой послелдовательности нет, то есть два работоспособных состояния, между которыми - пропасть (например, замена достаточно большого блока логики работы программы). А пропасть нельзя перепрыгнуть даже в два прыжка, а тем более - мелкими шагами.
Обновления библиотек - это не рефакторинг, а обновление библиотек
Из моего опыта по поводу "большой рефакторинг + частые мерджи + тесты" - часто (ежедневно) вливайте изменения из мастера в вашу ветку и будете спать спокойнее. Но всё равно законченные части работы лучше сливать в мастер и закрывать feature flag'ами. Потому что паралельно может разрабатываться другое "большое изменение" о которым в даже и знать возможно не будете.
Не очень понятен наезд на инженеров эксплуатации в первом абзаце. Ведь если "Непрерывная интеграция - это вообще не про джобы в дженкинсе и гитлабе" - забирайте эту правильную интеграцию себе, а джобы оставьте им, просто у себя в голове называйте как-то иначе - и спите спокойно :) Или всё ради крестового похода за именование?
Ну то есть вы предлагаете отказаться от практик code review, под предлогом того, что они мешают идее из 90-х, и даже отражают недоверие в команде.
Что касается другой трактовки CI, в целом это нормально когда идея развивается и видоизменяется со временем, не все из них хороши сразу, некоторые требуют адаптации к реальности.
PS
Я не критикую идею постоянных мелких комитетов, которая вполне может работать в маленькой однородной и сильной команде. Но в современных условиях команды часто большие и неоднородные и включают не только опытных разработчиков, знающих код, но и просто начинающих и даже интернов. Парное программирование, когда аллоцируется целый разработчик на интерна, дороговато выходит, дешевле всё-таки code review. Само code review похоже все та же идея парного программирования, адаптированная к реальности и сделанная асинхронной практикой.
Как я и написал в статье, практика подходит далеко не всем командам. Использовать или нет - ваше решение)
> дороговато выходит, дешевле всё-таки code review.
Обычно так говорят, когда не считают:
- стоимость задержек и ожиданий
- стоимость переделок (чем позже, тем дороже)
- стоимость хорошего код-ревью (не просто поскроллить дифф, а пойти узнать, что за задача, и разобраться, почему она была решена именно так).
И когда не разбираются в том, как устроено обучение, и почему code reivew в большинстве случаев - не оно :)
Бардак
Хочу сказать Вам большое спасибо за проработанный структурированный материал с исторической базой
Мы проблему с ревью решили раскидыванием ревью на всех поровну. Так-то непрерывная интеграция — великая сила. Иметь всегда рабочий мастер — очень удобно.
Вот это другой разговор! 💪
Но непрерывная интеграция это не всегда рабочий мастер. "Поломал - быстрее чини" это же сломанный мастер, пускай и ненадолго. Всегда рабочим он будет, например, если туда код только через пулл-реквесты пускать с прогоном тестов по эфемерному мёрджу. Но это уже идёт вразрез с непрерываной интеграцией в том аутентичном виде, о котором пост рассказывает.
Всегда рабочим он будет, например, если туда код только через пулл-реквесты пускать с прогоном тестов по эфемерному мёрджу.
Тут нет противоречия. Если можно собрать набор тестов, которые достаточно быстро оценят изменения, то можно и прогонять тесты и тогда "всегда" будет настоящим "всегда".
Но, на практике, стопроцентный "всегда" не всегда нужен. Иногда достаточно и 95%, и 90%.
Смысл последовательной интеграции, в том, что бы скрытые интеграционные траты сделать явными. Чтобы не было такого, что все задания выполнены, а в пятницу в обед выясняется, что они друг с другом конфликтуют и до релиза ещё два дня. Ради этого можно пожертвовать некоторой доступностью.
Все верно!
Как всегда логично, структурированно и от самого Рюрика. Статья огонь, спасибо! Именно этому нужно учить-учить-учить младших, пока есть силы и время. А промпты они и сами сочинять научатся, если захотят.
Частые коммиты порождают хаотичную историю. Впрочем как и редкие. Они должны быть обдуманными и хорошо выверенными, а как часто их делают -- это каждый для себя выбирает сам. А в мерж конфликтах не вижу ничего страшного. Да и вообще, главное не код, а его понимание: если есть мерж конфликт на изменении, которое ты понимаешь, не проблема это изменение адаптировать к новой реальности.
Как часто вас интересует история коммитов в целом, чтобы беспокоиться об её хаотичности? По моему опыту - лишь бы строка кода до тикета в трекере прослеживалась (чтобы из git blame понять). Количество merge-коммитов на это не влияет. А уж какая там портянка при взгляде на всю историю - вообще не важно. Весь этот хаос нивелируется тем, что старые ревизии мало кому нужны. Не везде, конечно, но по умолчанию это так.
Но, если ответ положительный, вам для этого все равно потребуется решить проблему доверия одним или несколькими способами из списка:
Весь это список - паллиативы.
Фундаментально, на уровне интересов (поясню: интерес в данном случае - это про деньги и другие вполне материальные блага - менее интенсивно работать, получить опыт для строчки в резюме и т.п.), проблема доверия в условиях нынешнего коммерческого производства ПО не решается: наемные программисты объективно не заинтересованы в результате работы - иначе говоря, производимое ПО отчуждается от работников. Реально программу делает не команда единомышленников, объединенных общим интересом, а группа индивидумов, каждая из которых объективно работает на себя, общих интересов у них объективно нет. Поэтому и требуется дисциплина, котрую нужно поддерживать, чтобы программисты работали согласованно на благо предприятия.
А раз это дисциплина, то это означает, что она имеет очень строгий алгоритм действий:
И да, не всякую дисциплину поддерживать легко и удобно. В частности, в той дисциплине, которую далее по тексту предлагаете вы, есть громадный недостаток: непонятно, кто за что отвечает. То есть, с позиции конкретного работника непонятно, что в каждом конкретном случае он дожжен делать и, главное, что ему за это будет. Но раз вы менеджер - имеете право попробовать поддержать такую вот дисциплину. Мне, кстати, интересно было бы узнать о результатах.
Мне, кстати, интересно было бы узнать о результатах.
Уже третий год наша замечательно команда работает в таких процессах, всем нравится, добровольно покинувших команду пока нет.
Проблемы недоверия в команде нет. Работает, как единый механизм, а не как группа людей, работающих для строчки в резюме. Покрытие тестами полное, ответственность высочайшая, самодисциплина на высоте, атмосфера дружеская. Никакой бюрократии и принуждения тоже нет - наоборот, все члены команды ценятся, их интересы, пожелания, эмоции внимательно отслеживаются и учитываются.
Если интересно последить за успехами и неудачами нашей команды - добро пожаловать в https://t.me/RakovskyXP
Работаю в таком режиме последние 5 лет, 80 разработчиков успешно пушат в мастер ежедневно, делаем большие рефакторинги, запиливаем, выпиливаем и перепиливаем продукты, меняем куски инфраструктуры. Активно пользуем фича-флаги и миграции со старого сервиса на новый прямо под нагрузкой.
Да, периодически что-то валится, но культура компании утверждает что лучше уметь быстро поднимать упавшее чем затягивать доставку продукта клиентам из за страха облажаться.
Проблема с доверием решается просто - на испытательном сроке блокирующее код ревью, если прошел - асинхронное. Если начинаешь систематически косячить - вон из класса одним днëм. Платят очень достойно, уходить не хочется - делаешь всë чтобы не допускать ошибок по небрежности. Отбор жесточайше строгий, текучка свежаков присутствует, ветераны уходят редко.
Интересное место. Что за компания?
Платят очень достойно
То есть, компенсируется это затратами на оплату труда разработчиков выше рынка. Источник заинтересованности работников понятен, экономика предприятия - не очень. Впрочем, в истории такое было - Генри Форд в какой-то момент пытался нанимать лучших, пока компания его имени не вернулась к более общепрринятым практикам.
А в чем проблема с экономикой если компания делает востребованные продукты и получает достаточно прибыли с них?)
Проблема - в конкурентах: у них, при оплате по рынку, себестоимость ниже получается.
Звучит логично. Однако я не думаю что в нашей нише рынка себестоимость разработчика сильно решает)
Не спорьте — это бессмысленно и бесполезно. Человек Вам впихивает аргумент, который не ни в какие ворота не лезет.
Ему сказали, что компания есть, работает. А он пытается вас обанкротить. Условно.
Короче. Чо им объяснять и доказывать? Что компания в которой Вы работайте успешная?! Ну пусть идет по указаной выше ссылке и все сам проверяет. Ищет отчеты в открытых источниках и так далее.
Ему сказали, что компания есть, работает.
Мне сказали то, что называется анекдотическое свидетельство: — "утверждение или доказательство, основанное на случаях или эпизодах из личной жизни или невоспроизводимых опытных данных". Это - довольно слабый тип аргумента.
Плохо во всех рассказах про "команды", типа обсуждаемой статьи, то, что они навязывают наемным работникам интересы предпринимателей, т.е. - в общем случае снижают оплату. Я рад, что в данном конкретном случае это не так, но что-то подсказывает мне что это редко и/или ненадолго.
А в ответ у меня на это есть аргумент типа "аналогия": в промышленом производстве концепция использования эксклюзивной дорогой рабочей силы отнюдь не победила. Логично ожидать, что то же самое будет и с производством ПО, когда оно из нынешнего ремесленного станет индустриальным - если станет, конечно.
А вот спорить действительно бесмысленно - и тот, и другой аргумент - он весьма косвенный. Просто, как всегда, есть две стороны, и IMHO полезно видеть обе. А не только ту, которая нравится.
Bravo 👏
наемные программисты объективно не заинтересованы в результате работы
Это вполне верно для амана (бывш. фаанги), где процессы бюрократизированы, а вклад отдельных разработчиков (за исключением очень немногих) незначителен. Но не вполне верно (а иногда и глубоко ошибочно) для средних и небольших компаний. Дело в том, что маржа таких компаний может быть сравнимой с зарплатой старшего разработчика, а большая часть выручки уходить на ФОТ. Таким образом появляется экономическая заинтересованность в результатах. А если при этом бизнес компании кажется сотрудникам важным и интересным, то появляется ещё и сверхэкономическая заинтересованность.
Дело в том, что маржа таких компаний может быть сравнимой с зарплатой старшего разработчика, а большая часть выручки уходить на ФОТ.
Состояние похоже на неустойчивое: прибыль скорее будет либо больше, чем оплата труда предпринимателя, который он в подобном предприятии занят (организация производства ведь, внезапно, тоже труд), либо меньше. И нет никакого механизма, поддерживающего "справедливую" опллату труда предпринимателя по организации производства.
Таким образом появляется экономическая заинтересованность в результатах.
Не появляется. Если конкретный бизнес не в состоянии платить по рынку, то наемный работник уйдет и будет работать на того, кто в состоянии, а больше чем по рынку бизнес платить не заинтересован сам.
А если при этом бизнес компании кажется сотрудникам важным и интересным
Ключевое слово - кажется. А я тут про материальное пишу, про интерес.
И нет никакого механизма, поддерживающего "справедливую" опллату труда предпринимателя по организации производства.
Конкуренция аналогичных мелко-средних компаний доведёт маржу до минимально приемлемой.
Не появляется. Если конкретный бизнес не в состоянии платить по рынку, то наемный работник уйдет и будет работать на того, кто в состоянии
Экономическая заинтересованность появляется от справедливого распределения плодов труда. Если половину плодов моего труда будет забирать какой-нибудь тунеядец и тратит их на блядей и ламбу, то, конечно, у меня не будет заинтересованности. А если собственник вкалывает в два раза больше всех, а зарабатывает, допустим, тоже в два раза больше старшего разработчика, то имеется справедливое (с социалистической точки зрения) распределение, и соответственно, говорить об отчуждении не приходится. Или приходится в меньшей степени.
больше чем по рынку бизнес платить не заинтересован сам
Заинтересован, если данный работник приносит денег больше "среднего"
Ключевое слово - кажется. А я тут про материальное пишу, про интерес.
Люди не являются экономически рациональными агентами. Так что, мировоззренческое совпадение целей компании с ценностями работников имеет значение. Причём, со временем, по мере удовлетворения базовых потребностей, финансовые стимулы будут иметь всё меньшее значение, а ценностные — всё большее.
Конкуренция аналогичных мелко-средних компаний доведёт маржу до минимально приемлемой.
Мелко-средние предприятия проигрывают конкуренцию крупным. Тем более это справедливо для производства ПО, где эффект масштаба - очень сильный.
Экономическая заинтересованность появляется от справедливого распределения плодов труда.
"Справедливый" - это вообще не про экономику. Тем более - "с социалистической точки зрения": социализм на текущем уровне развития производительных сил и наобозримую перспективу экономически не эффективен.
Люди не являются экономически рациональными агентами.
Люди всего лишь не принимают все решения чисто рационально. Но их сознание подстраивается под то, чтобы механизмы принятия решений - пусть и иррациональные - соответствовали их интересам. У Фромма в "Бегстве от свободы" есть достаточно подобно описание, как это происходило при переходе от Средних Веков к Новому Времени, к капитализму. За такую подстройку отвечает отбор. То есть, мировоззрение подстраивается этим самым отборам под интересы экономики ("общественное бытие определяет общественное сознание").
Причём, со временем, по мере удовлетворения базовых потребностей, финансовые стимулы будут иметь всё меньшее значение, а ценностные — всё большее.
Это когда, когда "все источники общественного богатства польются полным потоком" (цитата из Программы КПСС), то есть - при коммунизме? Ну да, я эти мечты даже лично застал. Но они не сбылись.
Но это уже другая история.
Отличная статья и про главное — организованость! (Поэтому Вы и любите «списки»/структурированость.
Устал я ужк писать об неорганизованости в отрасли. Но ваш тезис полностью поддерживаю.
Верните непрерывную интеграцию разработчикам