Не мы, это Toyota и Microsoft

да пожалуйста Электросамокаты (комментарий)

голландский штурвал. а потом наоборот

«парное ревью» я не знаю, можешь меня просветить.

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

Это парное программирование. Ревью тут совершенно ортогонально.

Делают минимальную систему и релизят, потом делают выводы о реакции рынка и уже после этого переписывают по человечески.

Сам то в таком принимал участие хоть раз?
Работающий PoC пихают в продакшен, каким бы уродливым он не был.

Переписываниями с нуля обычно энтузиасты занимаются, и это 50% шанс смерти проекта.

Да.

Неплохо работает.

Не зависит от размера конторы

я не говорил что переписывают с 0, просто код в порядок приводят и больше внимания уделяют архитектуре.

Про что и ноет автор Agile Manifesto. Они написали 10 общих разумных правил, которые можно свободно интерпретировать и применять когда вам это удобно. А это превратили в карго-культ религию с всякими прибамбасами и занимаются эти вместо работы

Люди в принципе по своей природе очень любят правила. Это значительно проще для мозга думать в рамках «Делай вот так и все.» чем в рамках «Если сделать вот это то будут вот такие последствия»

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

Есть гипотеза,

может быть эффективность всякого парного+ программирования есть результат привлечения в индеустрию экстравертов и прочих гиперсоциальных человеков. Если им толпой проще (есть основания так считать, хоть я бы удавился), будет выгода и от их настроения и от дополнительной рабсилы + вышеупомянутое. А потом они, в силу указаной особенности, обеспечивают surviour bias в пользу групповухи.

Спасибо.

Да. Меня как-то раз прохватил лютый понос, я думал что сдохну. И случайно со мной в туалете был ноутбук. Пару багов на таком экстриме вполне починил.

Все пишут про успешные тесты, и никто не пишет, в итоге сам-то код написали или нет...

Пару багов на таком экстриме вполне починил.

Diarrhea Driven Development

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

Есть понятное простонародное слово «манагеры».

экстрЕмальное

дисректальное

А вот что за DDD в вакансиях пишут! Теперь буду знать!

Так-то парами программировать это нормально. Если один завтра помрёт, второй останется и все секреты того, над чем они работали, не уйдут в могилу. Другое дело, что это надо в 2 раза больше программистов.

Так-то парами программировать это нормально. Если один завтра помрёт, второй останется и все секреты того, над чем они работали, не уйдут в могилу

Интересная теория. Но на практике сами писавшие забывают что писали год спустя. Особенно если они писали лапшу.

По факту аналогичная политика, но другими методами, ведется той же студией Лебедева, где кодер обязан документировать всё-привсё, обязан писать код, который после него поймет любой даун.

Но на практике сами писавшие забывают что писали год спустя.

Это легко восстанавливается терморектальным восстановителем, например.

По факту аналогичная политика, но другими методами, ведется той же студией Лебедева, где кодер обязан документировать всё-привсё, обязан писать код, который после него поймет любой даун.

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

Spotify вроде пример agile development.

Spotify вроде пример agile development

«С 2006 и до конца 2018 года компания являлась убыточной, она существовала на средства инвесторов и выплачивала больше авторских отчислений, чем зарабатывала»

Всё, что тебе нужно знать про Agile и микросервисы.

Ну зато она дала заработать владельцам авторских прав. Это же тоже неплохо.

2-3 кодера

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

Если же ваши разрабы целый год в понедельник приступают к проекту с удивленным выражением лица, мол «а у нас такой проект есть?», и будто в первый раз узнают про его назначение — этот проект никуда не уедет.

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

Работает, когда не надо думать, а надо делать. Особенно, когда надо фиксить прод прямо сейчас. А когда надо обдумать промлему, попробовать одно решение, другое, экстремальное программирование только в напряг.

Работает, когда не надо думать, а надо делать. Особенно, когда надо фиксить прод прямо сейчас

Ну да, Legioneer уже как бы намекал, что это авральный режим работы, но каждый день так писать код будет совсем не комильфо.

Нет, не работает.

Хорошая команда сможет работать и через ХРень. Плохой не поможет.

Peer review вообще обязателен

Это несомненно.

А вот тут не согласен. В самой лучшей конторе, где я работал, была установка: не важно, кто ревьюил твой код, если оно сломало продакшен — за это ответственен ТЫ.

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

Я как-то раз уронил прод на несколько часов, причём сделать с этим ничего было нельзя. Побеседовали с начальником, выяснили, что всё было сделано правильно, ошибка проскочила через редчайшее сочетание нескольких недосмотров и просто неудачных стечений обстоятельств (DBA как раз пообедать вышел), и сделать ничего нельзя. Ну и успокоились.

Я как-то чинил код из трамвая, с айфона, через TeamViewer.

Вот, кстати: https://yosefk.com/blog/extreme-programming-explained.html

В самой лучшей конторе, где я работал, была установка: не важно, кто ревьюил твой код, если оно сломало продакшен — за это ответственен ТЫ.

Какое-то деление на ноль. Звучит как токсичный коллектив. Я там несколько абзацев распинался почему blame free culture важна. Могу ссылок накидать

https://www.blameless.com/sre/sre-culture

https://devops.com/how-sre-creates-a-blameless-culture/

И Священное Писание:

https://sre.google/sre-book/postmortem-culture/

Нет, коллектив был ни разу не токсичный. Как раз наоборот. Умение брать на себя ответственность — это очень важно для нетоксичных коллективов.

Не совсем ясно что такое «ответственность» в данном случае. Ответственность это пока вы еще ничего не сделали, знать кто за что отвечает, делать это и не наступать друг другу на пятки. Ответственность чтобы не было эффекта свидетеля.

То о чем ты говоришь, это не взять ответственность, а взять наказание. Как минимум в форме порицания

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

Ну дык если и правда накосячил — почему нет-то?

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

В blame free culture считается что ваш процесс наема людей нанял людей с двумя качествами - профессионализм и хорошие намерения. Допустим у вас есть красная кнопка, которая убивает продакшн. Вася ее нажал. Почему профессионал Вася с хорошими намерениями ее нажал? Это же невозможно. Значит кнопка на стуле и нажать ее можно очень легко жопой даже если ты этого не заметил. Уберите кнопку со стула или переместите ее в ящик с тремя ключами. Тогда ее не нажмет случайно больше никто. Или лучше выдать Васе 100 розг? А потом Грише 100 розг? И так каждому последующему работнику заново

А кто сказал «чморить»? Как раз того, кто признаёт свои косяки, чморить не будут, по причинам, которые я указал.

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

А «убирать кнопку в ящик» стали под конец моей работы в той конторе. Сменилось руководство, и новые хозяева стали последовательно проводить именно эту политику. Девелопер задеплоил код с багом? Запретить девелоперам деплоить вообще, пусть этим специальные люди занимаются. Теперь замёржили хрень и деплоер не заметил (да и не мог)? Запретить мёржить, пусть вместо этого помечают бранч как «готовый к мёржу» и пусть специальный человек мёржит. И так всё. Работать стало невозможно в принципе, и я оттуда ушёл.

Девелопер задеплоил код с багом? Запретить девелоперам деплоить вообще, пусть этим специальные люди занимаются. Теперь замёржили хрень и деплоер не заметил (да и не мог)? Запретить мёржить, пусть вместо этого помечают бранч как «готовый к мёржу» и пусть специальный человек мёржит. И так всё. Работать стало невозможно в принципе, и я оттуда ушёл.

А почему это сделало условия работы невозможными? Это же нормальная практика ограничить доступ к проду и мастеру гита.

Это же нормальная практика ограничить доступ к проду и мастеру гита.

Сочувствую. В каком же говне тебе приходится работать...

Так какие у тебя конкретно были претензии ко всему этому?

Претензии — что работать невозможно. Фикс, который я за год до того сделал бы в одно рыло (не считая ревью) за пару часов, теперь требовал две недели. Сколько-нибудь крупный проект, о котором раньше мы бы поговорили с начальником и начали бы спокойно пилить, теперь нельзя было даже начать.

Фикс, который я за год до того сделал бы в одно рыло (не считая ревью) за пару часов, теперь требовал две недели.

Почему у вас так получалось? Просто делаешь фикс, делаешь пулреквест, его ревьюит тимлид и пушит в мастер, потом выкатит когда посчитает нужным. Для этого не требуется доступ к проду.

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

Как это вообще связано с доступом к проду или мастеру гита?

его ревьюит тимлид

Пир-ревью должен делать пир, то есть рядовой разработчик.

потом выкатит когда посчитает нужным

И в результате фикс не появится в продакшене до морковкина заговенья.

Как это вообще связано с доступом к проду или мастеру гита?

Это связано с тем, что у девелоперов систематически отбирали нужные инструменты. Не только прод и мастер.

Пир-ревью должен делать пир, то есть рядовой разработчик.

Это ничего не меняет, попросил ближайшего сделать ревью и все.

И в результате фикс не появится в продакшене до морковкина заговенья.

Тимлиду виднее когда и что ему выкатывать в прод, тебе то какая разница? В некоторых компаниях по 2 раза в день выкатывают. В некоторых компаниях время выката может быть согласовано с продуктом.

Это связано с тем, что у девелоперов систематически отбирали нужные инструменты. Не только прод и мастер.

Какие? Прод и мастер не требуются для разработки.

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

Запретить - ленивая мера. Лучше больше автоматизации проверяющей здоровье

Не ясно как запрет деплоить улучшает здоровье. Ты все равно деплоишь тот же код

Это ничего не меняет

Так кто пуш в мастер-то будет делать?

Тимлиду виднее когда и что ему выкатывать в прод

Да. А мне виднее, что и когда МНЕ выкатывать в прод.

тебе то какая разница

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

В некоторых компаниях по 2 раза в день выкатывают.

А мы до этой бредятины выкатывали новый код в продашен по сорок раз в день.

Прод и мастер не требуются для разработки.

Прод и мастер, разумеется, требуются для разработки. Не в смысле «без них нельзя», потому что можно и в гамаке, и в ластах, и вприсядку. А в смысле «без них работа тормозится».

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

Лучше больше автоматизации проверяющей здоровье

Так а при чём тут «убрать кнопку в ящик» тогда? Если убрать кнопку в ящик, то, когда она понадобится, сначала будут искать, куда её убрали, потом — где тот ящик, ибо мебель с тех пор передвинули по фен-шую, потом — у кого ключ от ящика, потом — когда он должен выйти из отпуска.

А с автоматизацией у нас был полный порядок, автоматизировали всё, что можно. Но толку с той автоматизации, если метрика бьёт тревогу, система лежит, а тот, кто в данный момент дежурит, не может ничего сделать, ибо, опять-таки, доступа к проду у него нет.

Так кто пуш в мастер-то будет делать?

Тот у кого есть права на это. Обычно тимлид или техлид.

Да. А мне виднее, что и когда МНЕ выкатывать в прод.

Тебе нравится быть клиентом у компаний которые дают доступ к проду любому васяну-фрилансеру?

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

Если твой патч добавлен в мастер то что тебе еще нужно? Ты что прямо на проде код пишешь?

А мы до этой бредятины выкатывали новый код в продашен по сорок раз в день.

Это был сайт на друпале и вы синкали новый код через ftp?

Прод и мастер, разумеется, требуются для разработки. Не в смысле «без них нельзя», потому что можно и в гамаке, и в ластах, и вприсядку. А в смысле «без них работа тормозится».

Ты до сих пор не смог объяснить какие конкретно процессы тормозятся.

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

Конечно же нет) Зачем им это?

Больше о ненужных дурацких кнопках. Их может лучше удалить вообще. А ты перешел к нужной фиче - деплоймент. То что у вас запретили деплоить - это прикладывание подорожника к тому факту что у вас все равно можно выкатить говно в прод.

если метрика бьёт тревогу, система лежит, а тот, кто в данный момент дежурит, не может ничего сделать, ибо, опять-таки, доступа к проду у него нет.

Прекрасно, в вашем самом лучше в мире коллективе еще один детский антипаттерн - unactionable monitoring. Трата времени разработчиков.