Comments 77
Три несовместимых вещи: большой рефакторинг + частые мерджи + тесты. На то он и большой рефакторинг, что требует заморозки другого тех долга.
От начала и до конца рефакторинга система будет находится в неконсистентном состоянии. Практически до последнего коммита
"Рефакторинг — это применение небольших шагов, сохраняющих поведение, и внесение больших из менений путем связывания воедино последовательности упомянутых малых ша гов, сохраняющих поведение. Каждый отдельный рефакторинг сам по себе либо довольно маленький, либо представляет собой комбинацию маленьких шагов.
В результате, когда я выполняю рефакторинг, мой код не оказывается надолго в неисправном состоянии, что позволяет мне останавливаться в любой момент, даже если я еще не закончил всю намеченную работу полностью.
Если кто-то говорит, что его код был неработоспособен в течение не- скольких дней во время выполнения рефакторинга — можете быть увере ны, что никакого рефакторинга не было."
"Рефакторинг", 2 издание, 2018 год, Мартин Фаулер
Попробуйте поднять версию MUI4 на MUI5/6/7 или React 17 на 18/19.
У компаний уходят на это месяцы и то не факт, что получается с первого раза
Есть технологии постепенного внедрения больших изменений. Как человек, который постоянно пользуется ими, могу сказать, что ничего невозможного тут нет. Ими не все пользуются, потому что не все понимают, зачем. Но если понимание зачем есть, то достаточно только чуть-чуть подумать, и сразу придумается решение.
Некоторые изменения по своей сути атомарны, несмотря на то, что объёмные. Их не сделаешь постепенно - это фундаментальная их особенность.
Можно раздробить изменения до уровня атомарных, но не дальше.
Есть технологии постепенного внедрения больших изменений.
В общем случае их нет. Есть они только тогда, когда есть последовательность состояний, в каждом из которых программа работоспособна, и перейти от одного к другому можно путем мелких и, что важно - обратимых, иззменений.
Если такой послелдовательности нет, то есть два работоспособных состояния, между которыми - пропасть (например, замена достаточно большого блока логики работы программы). А пропасть нельзя перепрыгнуть даже в два прыжка, а тем более - мелкими шагами.
А пропасть нельзя перепрыгнуть даже в два прыжка, а тем более - мелкими шагами.
пропасть действительно нельзя перепрыгнуть мелкими шажками, но надвигать мост по два сантиметра в час можно! И это действительно звучит как технология, но чтобы этот мост начать надвигать его надо где-то построить и как то доставить на место применения, и это уже на просто технология - это супер-технология! Проблема в том что пропасти везде разные и мосты и их крепления, опоры,... тоже будут везде разные, поэтому:
действительно одной универсальной
технологии постепенного внедрения больших изменений
не существует.
Вам же привели выше пример про React. Могу ещё: расскажите, как итеративно перейти с Vue2 на Vue3 (теоретически можно, но с феноменальным количеством геморроя).
А главное - зачем?
Обновления библиотек - это не рефакторинг, а обновление библиотек
Из моего опыта по поводу "большой рефакторинг + частые мерджи + тесты" - часто (ежедневно) вливайте изменения из мастера в вашу ветку и будете спать спокойнее. Но всё равно законченные части работы лучше сливать в мастер и закрывать feature flag'ами. Потому что паралельно может разрабатываться другое "большое изменение" о которым в даже и знать возможно не будете.
Не очень понятен наезд на инженеров эксплуатации в первом абзаце. Ведь если "Непрерывная интеграция - это вообще не про джобы в дженкинсе и гитлабе" - забирайте эту правильную интеграцию себе, а джобы оставьте им, просто у себя в голове называйте как-то иначе - и спите спокойно :) Или всё ради крестового похода за именование?
Ну то есть вы предлагаете отказаться от практик code review, под предлогом того, что они мешают идее из 90-х, и даже отражают недоверие в команде.
Что касается другой трактовки CI, в целом это нормально когда идея развивается и видоизменяется со временем, не все из них хороши сразу, некоторые требуют адаптации к реальности.
PS
Я не критикую идею постоянных мелких комитетов, которая вполне может работать в маленькой однородной и сильной команде. Но в современных условиях команды часто большие и неоднородные и включают не только опытных разработчиков, знающих код, но и просто начинающих и даже интернов. Парное программирование, когда аллоцируется целый разработчик на интерна, дороговато выходит, дешевле всё-таки code review. Само code review похоже все та же идея парного программирования, адаптированная к реальности и сделанная асинхронной практикой.
Как я и написал в статье, практика подходит далеко не всем командам. Использовать или нет - ваше решение)
> дороговато выходит, дешевле всё-таки code review.
Обычно так говорят, когда не считают:
- стоимость задержек и ожиданий
- стоимость переделок (чем позже, тем дороже)
- стоимость хорошего код-ревью (не просто поскроллить дифф, а пойти узнать, что за задача, и разобраться, почему она была решена именно так).
И когда не разбираются в том, как устроено обучение, и почему code reivew в большинстве случаев - не оно :)
Бардак
Хочу сказать Вам большое спасибо за проработанный структурированный материал с исторической базой
Мы проблему с ревью решили раскидыванием ревью на всех поровну. Так-то непрерывная интеграция — великая сила. Иметь всегда рабочий мастер — очень удобно.
Вот это другой разговор! 💪
Но непрерывная интеграция это не всегда рабочий мастер. "Поломал - быстрее чини" это же сломанный мастер, пускай и ненадолго. Всегда рабочим он будет, например, если туда код только через пулл-реквесты пускать с прогоном тестов по эфемерному мёрджу. Но это уже идёт вразрез с непрерываной интеграцией в том аутентичном виде, о котором пост рассказывает.
Всегда рабочим он будет, например, если туда код только через пулл-реквесты пускать с прогоном тестов по эфемерному мёрджу.
Тут нет противоречия. Если можно собрать набор тестов, которые достаточно быстро оценят изменения, то можно и прогонять тесты и тогда "всегда" будет настоящим "всегда".
Но, на практике, стопроцентный "всегда" не всегда нужен. Иногда достаточно и 95%, и 90%.
Смысл последовательной интеграции, в том, что бы скрытые интеграционные траты сделать явными. Чтобы не было такого, что все задания выполнены, а в пятницу в обед выясняется, что они друг с другом конфликтуют и до релиза ещё два дня. Ради этого можно пожертвовать некоторой доступностью.
Все верно!
Как всегда логично, структурированно и от самого Рюрика. Статья огонь, спасибо! Именно этому нужно учить-учить-учить младших, пока есть силы и время. А промпты они и сами сочинять научатся, если захотят.
Частые коммиты порождают хаотичную историю. Впрочем как и редкие. Они должны быть обдуманными и хорошо выверенными, а как часто их делают -- это каждый для себя выбирает сам. А в мерж конфликтах не вижу ничего страшного. Да и вообще, главное не код, а его понимание: если есть мерж конфликт на изменении, которое ты понимаешь, не проблема это изменение адаптировать к новой реальности.
Как часто вас интересует история коммитов в целом, чтобы беспокоиться об её хаотичности? По моему опыту - лишь бы строка кода до тикета в трекере прослеживалась (чтобы из git blame понять). Количество merge-коммитов на это не влияет. А уж какая там портянка при взгляде на всю историю - вообще не важно. Весь этот хаос нивелируется тем, что старые ревизии мало кому нужны. Не везде, конечно, но по умолчанию это так.
Периодически плачусь, что в индустрии выжил гит, а не меркуриал с его полноценными ветками (где ветка – это не указатель на её голову, а совокупность всех сделанных в неё коммитов). В меркуриале чистая история мастера (ну или релизной ветки) получалась сама собой, а в гите нужны костыли.
Проблемы не в инструменте, а в руках.
Справиться можно любым, но некоторые инструменты удобнее.
Плюс в данном случае недостаточно настроить что-то себе, чтобы история приняла нормальный вид – нужно форсить определённую политику использования git (как минимум – отсутствие fast-forward merge в мастер, тогда можно будет просматривать линейную историю в виде "только текущая ветка + только первый родитель в мерже") на всю команду.
Но, если ответ положительный, вам для этого все равно потребуется решить проблему доверия одним или несколькими способами из списка:
Весь это список - паллиативы.
Фундаментально, на уровне интересов (поясню: интерес в данном случае - это про деньги и другие вполне материальные блага - менее интенсивно работать, получить опыт для строчки в резюме и т.п.), проблема доверия в условиях нынешнего коммерческого производства ПО не решается: наемные программисты объективно не заинтересованы в результате работы - иначе говоря, производимое ПО отчуждается от работников. Реально программу делает не команда единомышленников, объединенных общим интересом, а группа индивидумов, каждая из которых объективно работает на себя, общих интересов у них объективно нет. Поэтому и требуется дисциплина, котрую нужно поддерживать, чтобы программисты работали согласованно на благо предприятия.
А раз это дисциплина, то это означает, что она имеет очень строгий алгоритм действий:
И да, не всякую дисциплину поддерживать легко и удобно. В частности, в той дисциплине, которую далее по тексту предлагаете вы, есть громадный недостаток: непонятно, кто за что отвечает. То есть, с позиции конкретного работника непонятно, что в каждом конкретном случае он дожжен делать и, главное, что ему за это будет. Но раз вы менеджер - имеете право попробовать поддержать такую вот дисциплину. Мне, кстати, интересно было бы узнать о результатах.
Мне, кстати, интересно было бы узнать о результатах.
Уже третий год наша замечательно команда работает в таких процессах, всем нравится, добровольно покинувших команду пока нет.
Проблемы недоверия в команде нет. Работает, как единый механизм, а не как группа людей, работающих для строчки в резюме. Покрытие тестами полное, ответственность высочайшая, самодисциплина на высоте, атмосфера дружеская. Никакой бюрократии и принуждения тоже нет - наоборот, все члены команды ценятся, их интересы, пожелания, эмоции внимательно отслеживаются и учитываются.
Если интересно последить за успехами и неудачами нашей команды - добро пожаловать в https://t.me/RakovskyXP
Работаю в таком режиме последние 5 лет, 80 разработчиков успешно пушат в мастер ежедневно, делаем большие рефакторинги, запиливаем, выпиливаем и перепиливаем продукты, меняем куски инфраструктуры. Активно пользуем фича-флаги и миграции со старого сервиса на новый прямо под нагрузкой.
Да, периодически что-то валится, но культура компании утверждает что лучше уметь быстро поднимать упавшее чем затягивать доставку продукта клиентам из за страха облажаться.
Проблема с доверием решается просто - на испытательном сроке блокирующее код ревью, если прошел - асинхронное. Если начинаешь систематически косячить - вон из класса одним днëм. Платят очень достойно, уходить не хочется - делаешь всë чтобы не допускать ошибок по небрежности. Отбор жесточайше строгий, текучка свежаков присутствует, ветераны уходят редко.
Интересное место. Что за компания?
Платят очень достойно
То есть, компенсируется это затратами на оплату труда разработчиков выше рынка. Источник заинтересованности работников понятен, экономика предприятия - не очень. Впрочем, в истории такое было - Генри Форд в какой-то момент пытался нанимать лучших, пока компания его имени не вернулась к более общепрринятым практикам.
А в чем проблема с экономикой если компания делает востребованные продукты и получает достаточно прибыли с них?)
Проблема - в конкурентах: у них, при оплате по рынку, себестоимость ниже получается.
Звучит логично. Однако я не думаю что в нашей нише рынка себестоимость разработчика сильно решает)
Не спорьте — это бессмысленно и бесполезно. Человек Вам впихивает аргумент, который не ни в какие ворота не лезет.
Ему сказали, что компания есть, работает. А он пытается вас обанкротить. Условно.
Короче. Чо им объяснять и доказывать? Что компания в которой Вы работайте успешная?! Ну пусть идет по указаной выше ссылке и все сам проверяет. Ищет отчеты в открытых источниках и так далее.
Ему сказали, что компания есть, работает.
Мне сказали то, что называется анекдотическое свидетельство: — "утверждение или доказательство, основанное на случаях или эпизодах из личной жизни или невоспроизводимых опытных данных". Это - довольно слабый тип аргумента.
Плохо во всех рассказах про "команды", типа обсуждаемой статьи, то, что они навязывают наемным работникам интересы предпринимателей, т.е. - в общем случае снижают оплату. Я рад, что в данном конкретном случае это не так, но что-то подсказывает мне что это редко и/или ненадолго.
А в ответ у меня на это есть аргумент типа "аналогия": в промышленом производстве концепция использования эксклюзивной дорогой рабочей силы отнюдь не победила. Логично ожидать, что то же самое будет и с производством ПО, когда оно из нынешнего ремесленного станет индустриальным - если станет, конечно.
А вот спорить действительно бесмысленно - и тот, и другой аргумент - он весьма косвенный. Просто, как всегда, есть две стороны, и IMHO полезно видеть обе. А не только ту, которая нравится.
вот только за дурачка нас не надо держать, пожалуйста!
Прочитайте статью от корки до корки, и вы поймете, что человек реально ведущий программист, и работает он в в более менее крупном Банке.
Выводы очевидны. Хотя конечно, доверять всему сказаному не стоит в каждом отдельном случае— ну огонь тогда, проверьте инфу в открытых источниках. Е мое. Двадцать первый век на дворе
Не вы проверьте — а тот кто усомнился. Мне и так все нравится.
вот только за дурачка нас не надо держать, пожалуйста!
Вот только хамить не надо, пожалуйста.
Прочитайте статью от корки до корки, и вы поймете, что человек реально ведущий программист, и работает он в в более менее крупном Банке.
Статью прочитал, потому что я вообще имею смысл читать, что комментрую (я, вот, даже Пастернака читал). Статья - ничего особенного, обычное мыкоманда от линейного менеджера. А поскольку банк и открытые источники есть две вещи несовместные, то проверить там ничего нельзя. Впрочем, я вполне верю, что автор никого тут специально не обманывает.
Просто у меня тут ощущение, что вся эта лепота, даже если она есть где-то в реале, преходяща. Именно это ощущение я и выразил.
И я не понимаю, почему вы так против моих ощущений.
Вооо, прикольно. Приятно общаться в таком тоне.
На счет: «за дурака держите…» — я часто вкладываю эмоцию (даже из вульгарной речи) для пущей краски конечно! Не хамил, а скорее для красочной убедительности такие перлы кидаю.
Просто у меня тут ощущение, что вся эта лепота, даже если она есть где-то в реале, преходяща. Именно это ощущение я и выразил. И я не понимаю, почему вы так против моих ощущений.
А мне показалось, что вы не ощущение передаете, а настаивайте… что-то такое. думаю, чего это он агрится.
Да и тут в соседних темах я пытаюсь донести важную идею, а они все о другом и о другом болтают.
Да знаю, что пишу сумбурно. Из-за нехватки времени, тупых и неудобных девайсов. Однако идеи важные для меня, и приходится жертвовать форматом выражения. Короче говорю бегло, самбурно, и прочее.
Мне чувак в соседней теме говорит, что ПДД фуфло. Подменяя ценность обсуждаемой проблемы. Я ему пример нарисовал. А он говорит, что аварии все равно есть. Та коечно— если не соблюдать ПДД то пварии будут. А если соблюдать, ио оно гарантирует, считай, почти 100% безопасность (форс-мажоры, и прочая неидеалтнсть мира).
Так о чем мы говорим? Я ему про Ивана, а он мне про Балвана.
Я ему, — что надо строитт условное ПДД для решения проблем с ПО, а он мне, что я мальчик-мечтатель.
Ну о чем мы говорим?!! Детский сад. А еще архитекторы, ведущие разарабочтики. Миры мне свои описывал.
Е мое.
Код мне дай — безопасный и стабильный. Поограмму — нормальную. А не вот это вот все.
Единичные случаи - действительно слабый аргумент. Хорошим аргументом является по-научному крепое исследование. И вот тут я вас отсылаю в отчёты state of devops 2016 и 2017, где вопросу continuous integration и trunk based development посвящены соответствующие разделы. Почитайте, пожалуйста, там не много. Но связь с экономикой прямая: high performers типа той компании, ссылку на которую опубликовал наш коллега, имеют заметно более высокие шансы экономического успеха. И такие компании гораздо реже используют долгоживущие ветки или ветки вовсе.
И вот тут я вас отсылаю в отчёты state of devops 2016 и 2017, где вопросу continuous integration и trunk based development посвящены соответствующие разделы.
Где читать? В статье ссылки нет, так что есть шанс, что я прочитаю не то, что вы имели в виду.
Но связь с экономикой прямая: high performers типа той компании, ссылку на которую опубликовал наш коллега, имеют заметно более высокие шансы экономического успеха.
Имели в 2016 или 2017? и с тех пор у них эти практики чуть менее чем все не переняли - но, так чтобы не платить при этом программистам лишнего?
И вообще, я пока не понял в чём вы меня пытаетесь убедить. В том, что расхождение версий надо бы устранять как можно быстрее? Дык, я не против, я всего лишь утверждаю, что это не всегда возможно. Например, если появляются новые требованя, идущие поперек той архитектуры, которая была изначально заложена в проект, то поменять мелкими шажками базовые вещи в архитектуре, чтобы сохраить ее целостность, просто не удастся. Удастся мелкими шажками - заплатки наложить и платилином приклеить.
Но самый главный вопрос - как соблюдать дисциплину среди людей, у которых нет интереса в ее соблюдении. Я вижу два варианта - советский (много лапши на уши, я если чо, в таком возрасте, что на это успел нагдяеться) и нормальный - делать людям, лучшим, уникальное предложение поработать за свой интерес (лавэ или какой другой не менее материальный эквивалент). Но номальный вариант, как я понимаю - штука временная: все (ну как все - все, кто сможет, но и н рынке останутся только они) в течение недолгого времени освоят правильную организацию работы и начнут конкурировать в рамках этой организации - и делать уникальные предложения больше не получится.
Поймите, я не против поддержания единства версии (в конце концов, я когда-то и сам так работал, ибо застал времена, когда даже CVS не было). Но, во- первых, я сомневаюсь, что это всегда (или достатчно часто) возможно, а во-вторых - что требуемую для этого дисциплину наемные работники захотят поддерживать при прочих равных условиях.
https://dora.dev/research/2016/
https://dora.dev/research/2017/
Информация есть в обоих отчётах.
Ответ на пассаж про то, что не вся индустрия так работает. Есть самые экономически эффективные способы работать, а есть спектр того, как компании работают в реальности. Компания может иметь ужасное айти, но шикарный продукт; плохое все, но хороший маркетинг. И там ещё сотни разных комбинаций, которые позволяют компаниям иметь неэффективные процессы.
Пассаж про разработчиков. Если нанимать, бог знает кого, то и проблемы с мотивацией и дисциплиной будут соответствующие. В статье чётко написано: не нанимайте людей, которым вы не будете доверять.
Bravo 👏
наемные программисты объективно не заинтересованы в результате работы
Это вполне верно для амана (бывш. фаанги), где процессы бюрократизированы, а вклад отдельных разработчиков (за исключением очень немногих) незначителен. Но не вполне верно (а иногда и глубоко ошибочно) для средних и небольших компаний. Дело в том, что маржа таких компаний может быть сравнимой с зарплатой старшего разработчика, а большая часть выручки уходить на ФОТ. Таким образом появляется экономическая заинтересованность в результатах. А если при этом бизнес компании кажется сотрудникам важным и интересным, то появляется ещё и сверхэкономическая заинтересованность.
Дело в том, что маржа таких компаний может быть сравнимой с зарплатой старшего разработчика, а большая часть выручки уходить на ФОТ.
Состояние похоже на неустойчивое: прибыль скорее будет либо больше, чем оплата труда предпринимателя, который он в подобном предприятии занят (организация производства ведь, внезапно, тоже труд), либо меньше. И нет никакого механизма, поддерживающего "справедливую" опллату труда предпринимателя по организации производства.
Таким образом появляется экономическая заинтересованность в результатах.
Не появляется. Если конкретный бизнес не в состоянии платить по рынку, то наемный работник уйдет и будет работать на того, кто в состоянии, а больше чем по рынку бизнес платить не заинтересован сам.
А если при этом бизнес компании кажется сотрудникам важным и интересным
Ключевое слово - кажется. А я тут про материальное пишу, про интерес.
И нет никакого механизма, поддерживающего "справедливую" опллату труда предпринимателя по организации производства.
Конкуренция аналогичных мелко-средних компаний доведёт маржу до минимально приемлемой.
Не появляется. Если конкретный бизнес не в состоянии платить по рынку, то наемный работник уйдет и будет работать на того, кто в состоянии
Экономическая заинтересованность появляется от справедливого распределения плодов труда. Если половину плодов моего труда будет забирать какой-нибудь тунеядец и тратит их на блядей и ламбу, то, конечно, у меня не будет заинтересованности. А если собственник вкалывает в два раза больше всех, а зарабатывает, допустим, тоже в два раза больше старшего разработчика, то имеется справедливое (с социалистической точки зрения) распределение, и соответственно, говорить об отчуждении не приходится. Или приходится в меньшей степени.
больше чем по рынку бизнес платить не заинтересован сам
Заинтересован, если данный работник приносит денег больше "среднего"
Ключевое слово - кажется. А я тут про материальное пишу, про интерес.
Люди не являются экономически рациональными агентами. Так что, мировоззренческое совпадение целей компании с ценностями работников имеет значение. Причём, со временем, по мере удовлетворения базовых потребностей, финансовые стимулы будут иметь всё меньшее значение, а ценностные — всё большее.
Конкуренция аналогичных мелко-средних компаний доведёт маржу до минимально приемлемой.
Мелко-средние предприятия проигрывают конкуренцию крупным. Тем более это справедливо для производства ПО, где эффект масштаба - очень сильный.
Экономическая заинтересованность появляется от справедливого распределения плодов труда.
"Справедливый" - это вообще не про экономику. Тем более - "с социалистической точки зрения": социализм на текущем уровне развития производительных сил и наобозримую перспективу экономически не эффективен.
Люди не являются экономически рациональными агентами.
Люди всего лишь не принимают все решения чисто рационально. Но их сознание подстраивается под то, чтобы механизмы принятия решений - пусть и иррациональные - соответствовали их интересам. У Фромма в "Бегстве от свободы" есть достаточно подобно описание, как это происходило при переходе от Средних Веков к Новому Времени, к капитализму. За такую подстройку отвечает отбор. То есть, мировоззрение подстраивается этим самым отборам под интересы экономики ("общественное бытие определяет общественное сознание").
Причём, со временем, по мере удовлетворения базовых потребностей, финансовые стимулы будут иметь всё меньшее значение, а ценностные — всё большее.
Это когда, когда "все источники общественного богатства польются полным потоком" (цитата из Программы КПСС), то есть - при коммунизме? Ну да, я эти мечты даже лично застал. Но они не сбылись.
Но это уже другая история.
Мелко-средние предприятия проигрывают конкуренцию крупным. Тем более это справедливо для производства ПО, где эффект масштаба - очень сильный.
Это противоречит наблюдаемой вокруг реальности, где массу ниш занимают небольшие предприятия. Особенно в области ПО, где контора в сотню бойцов может разрабатывать продукт с миллиардом пользователей.
"Справедливый" - это вообще не про экономику
Экономика — это производство и обмен плодами труда. Если человек не считает обмен справедливым, он не будет его осуществлять
социализм на текущем уровне развития производительных сил и на обозримую перспективу экономически не эффективен
Тот-то самые богатые страны и те, где права рабочих защищены наилучшим образом — это одни те же страны. Просто совпадение, наверное.
механизмы принятия решений - пусть и иррациональные - соответствовали их интересам
Верно. Просто интересы эти лежат не только в области экономики. Отсюда получается экономически нерациональное поведение.
Ну да, я эти мечты даже лично застал. Но они не сбылись.
Пока. Вы же не станете отрицать, что доступность базовых товаров непрерывно растёт? Еда, одежда, транспорт, связь, а кое-где даже и жильё с каждым годом доступны в изобилии всё большему числу людей. Очевидно, со временем перечисленных благ будет производиться достаточно для всех.
Особенно в области ПО, где контора в сотню бойцов может разрабатывать продукт с миллиардом пользователей.
Не похоже.
Ну, а вообще-то может - но недолго: помирает или вырастает.
Если человек не считает обмен справедливым, он не будет его осуществлять
Ну, справедливость может быть разная. К примеру, некоторые считают справедливым, чтобы с ними делились, просто так ("тебе чо, жалко?"). Ну, а как цены определятся в обществе - это надо смотреть не по отделным робизонам, а по всему обществу в целом - спрос и предложение, издержки на производство и т.д.
Тот-то самые богатые страны и те, где права рабочих защищены наилучшим образом — это одни те же страны. Просто совпадение, наверное.
Нет, не совпадение. Это - страны центра мировой капиталистической системы (система эта, внезапно, едина), и их хорошая жизнь обеспечивается за счет неэквивалентного обмена с периферией. Этот обмен - явно не эквивалентный, потому что деятельность в центре и на периферии за одно и то же затраченное время работы приносит сильно разные деньги - на порядок и более.
Пока. Вы же не станете отрицать, что доступность базовых товаров непрерывно растёт? Еда, одежда, транспорт, связь, а кое-где даже и жильё с каждым годом доступны в изобилии всё большему числу людей. Очевидно, со временем перечисленных благ будет производиться достаточно для всех.
В обозримом времени, колько я ещё в ппринципе могу расситывать прожить, это не ожидается. А что будет во времена, до которых я заведомо не доживу, я обсуждать не желаю.
И вообще, разговор ушел куда-то про свелое будущее, и я не вижу для себ смысла его продолжать.
Ну, справедливость может быть разная. К примеру, некоторые считают справедливым, чтобы с ними делились, просто так
Ну и люди существую не в вакууме, а являются продуктами системы. С одной стороны. А с другой, сами создают эту систему. По-этому, есть некое усреднённое понятие справедливости. И при соблюдении этой самой справедливости, работники проявляют заинтересованность в плодах труда. А если они ещё и сознательные, и в курсе, что труд является общественной необходимостью, то ещё большую заинтересованность. Тут объективное и субъективное густо намешано. Отделить одно от другого вряд ли получится.
Нет, не совпадение. Это - страны центра мировой капиталистической системы (система эта, внезапно, едина), и их хорошая жизнь обеспечивается за счет неэквивалентного обмена с периферией
То есть, мало того, что они могут эффективно производить что-то у себя, им ещё хватает сил нагибать "переферию"? И это по вашему низкая эффективность?
Очевидно, со временем перечисленных благ будет производиться достаточно для всех.
Их производится достаточно для всех уже десятки лет. Бедные страны бедны не потому, что реально чего-то не хватает, а из-за плохости своих общественных институтов (коррупция и т.д.)
Отличная статья и про главное — организованость! (Поэтому Вы и любите «списки»/структурированость.
Устал я ужк писать об неорганизованости в отрасли. Но ваш тезис полностью поддерживаю.
Отличная статья.
Отдельный респект за XP, TDD и DDD
Тут еще крайне желательно добавить, что в XP огромное внимание уделяется архитектуре. Именно это позволяет определить рефакторинг как набор действительно небольших, атомарных изменений. Когда архитектура не находится в центре внимания - рефакторинг превращается в русскую рулетку. Поэтому им особо страются не заниматься - пока еще возможно костылями подпереть чтобы не так шаталось.
Вообще, XP придуман крайне неглупыми людьми, и не просто так представляет собой целостную практику, а не набор разрозненных и произвольно применяемых методик.
Одна проблема: собрать команду, способную практиковать XP - очень непросто.
Статья действительно хорошая, жаль только толку от нее не будет, потому что забыть про статью гораздо проще, чем про настоящее назначение и смысл непрерывной интеграции, о которых уже все давно забыли.
Частые, раз в два часа пуши в master
Штааа???!
А вы работу по разным фичам как разделяете? А интеграционные, UAT и прочие тесты как проводите? А релизная политика у вас где?
вам для этого все равно потребуется решить проблему доверия
Доверие то тут причём? Обычное знание человеческой натуры говорит нам о том, что ошибаются все, без исключений. Вы этот простой факт очень неудачно скрещиваете с проблемой отношений внутри команды, вплоть до оценки личности.
непрерывное парное программирование
Нет, спасибо, мы уж лучше будем работать как обычно
в сравнении с распространенным тогда Водопадом
А вот вы сможете так легко найти, что же это такое - пресловутый Водопад, и откуда истоки этого мифа, что раньше работали по Водопаду?
И мне подобное знакомо - у меня однажды был конфликт на эту тему, когда мой ПР с большим рефакторингом, залетел в мастер на день раньше, чем большой ПР коллеги. Товарищ, столкнувшись с огромной кучей конфликтов, полыхал мне потом в личку весь день. И был прав, ведь я, не проконсультировавшись с ним, откинул его прогресс по работе на целый день назад.Он тогда так и сказал: "Давайте больше не делать таких больших рефакторингов". Классная идея.
Эту проблему проще решать на уровне планирования задач лидом+командой и учитывать возможные конфликты в областях кода. Просто минимизируйте риски путём сдвига конфликтующих задач по времени и всё. К тому же, в целом, странно делать одновременно и большую фичу и рефакторинг в одной области кода. Рефакторинг не будет учитывать новых изменений, а фича будет полагаться на старую логику. А просто подвинув по времени, например, запланировав рефакторинг на следующий спринт, разработчикам будет провести рефакторинг и проще и он будет учитывать больше проблем. Да это эффективнее просто с любой стороны, начиная от качества кода и заканчивая потраченным временем разработчиков.
Верните непрерывную интеграцию разработчикам