Работет ли экстремальное програмирование?

Даже банальный офис подразумевает, что ты не можешь подремать (хотя лично я этим занимался в офисе).

Банальный офис подразумевает что к тебе не будут вламываться домашние с «кагдила» и «сходи в магазин, все равно дома сидишь». Ну плюс синхронизация рабочих периодов, если надо взаимодействовать.

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

Вообще говоря подобное можно сказать не только про agile. Довести любую методологию до абсурда дело не хитрое. Помниться когда у нас начали внедрять iso9000 я прикинулся ветошью и не отсвечивал, старательно делая вид, что так же как и все впервые слышу этот страшный набор букавок и цифирек. Ну а далее я наблюдал очередную версию изнасилования.
Вот кстати на предыдущем месте, где собстно и довелось учиться 9000-му, главный инженер оказался догадливей и для особо тяжелых случаев как раз привлекал программистов. :) Запомнился эпичный момент, первый раз приходим к нему и с нами увязался наш начальник, главный смотрит на него и говорит «А ты мне зачем? Я тебя не звал.» :) Ну а дальше на достаточно продолжительное время мы фактически вышли из под юрисдикции нашего непосредственного начальника, а что особенно для нас было приятно это то, что распределения премий оно тоже коснулось :)

Знаешь, иногда ведь дешевле заменить, если есть альтернативы.

Ну в его случае с альтернативами тяжеловато, точнее в наличии в конторе их просто не было, а человеку со стороны нужно достаточно времени только что бы просто понять с чем имеем дело. Да и найти сильного программиста не такая простая задача. Уволившийся фактически вырос в нашем коллективе, но тогда это был именно отдел программистов (8 голов) от которого после его увольнения остался один человек. То есть по большому счету даже если найти супермегапрограммиста, передавать тайные знания уже некому.
Мне несколько лет назад довелось на аутсорсе выполнять работу для них, вполне ощутил на себе, что значит годы отсутствия. В целом задачу представляю, а вот мелочи уже подзабыл. Из запомнившегося, спрашиваю про какую-то часть, на что получаю потрясающий ответ «Это же ты изначально придумал и написал» :)

Плотные опенспейсы - зло для всех, а не для кого-то конкретного.

У него был не попенспейс, просто много разного народу, разного это в смысле тут и эникеии и админы и погромисты, все в кучу.

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

Я к тому, что твоя история не связана с экстремальным программированием. Там просто долго клали болт на проблему и доклались. Могли решать разными способами (дать поспать, заменить, продублировать), но видимо класть болт было выгоднее.

Из запомнившегося, спрашиваю про какую-то часть, на что получаю потрясающий ответ «Это же ты изначально придумал и написал» :)

У меня в детстве было круче. Как-то через месяц пытался понять собственный код, и с ужасом осознал что он работать не может (хотя работал).

Но вообще, у меня по опенсорсам суровая школа - «если в логику сходу не может врубиться левый чел, значит код написан/оформлен плохо». И с тех пор ни каких проблем. Регулярные ревью кода решают.

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

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

У меня в детстве было круче. Как-то через месяц пытался понять собственный код, и с ужасом осознал что он работать не может (хотя работал).

А что в конце концов оказалось правдой? Он работал или не работал?

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

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

Однозначно Классный случай!!!

ЗЫ После вашей фразы «пытался понять почему оно работает правильно если не должно» какое-то чувство дежавю возникло. Подобное в моей жизни случалось. Смотришь на код «он не должен выдавать результат Р/приводить к ситуации С» но при этом выдает/приводит. И самое главное, что по задуманной логике это правильно. :) И вот ты уже из принципа погружаешься в код, только для того что бы понять почему же так происходит? Как говориться: «а оно тебе надо?» В результате всё как обычно оказывается в мелочи, которую при поверхностном взгляде просто не заметил или не придал значения :)

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

Не манагеры код ваяют. Вот женщины, например, предпочитают работать с человеками а не программами. А тут тебе и то и другое и третьи побочные эффекты.

Вот женщины, например, предпочитают работать с человеками а не программами. А тут тебе и то и другое и третьи побочные эффекты

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

Господа vertexua и Miguel, мне кажется истина «где-то посередине».

Re: prod access. По моему мнению тут важен баланс удобства / рисков / бюрократии. Вы абс точно не хотите раздавать доступ в prod налево / направо. Не должен условный «рядовой кодер» его иметь. Да, это упрощает отладку. Да, я считаю невозможно писать эффективный код без чёткого понимания где он будет крутиться, и как именно настроено это железо, итд. Но, great power comes with great responsibility. Одно дело если Вы уроните условно какой-то онлайн магазин по продаже детских колясок, на 4е часа в ночь на Вск (да кого волнует, как говориться). А теперь представьте - Ваши действия привели к параличу загруженного аэропорта, на 4е часа в busy hours (ну там, например весь багаж законопослушных граждан перемешался, а ещё хуже - резьехался по неправильным самолётам и улетел, и его теперь надо собирать по всему миру). За это по головке не погладят. А если ещё выяснится что это было сделано умышленно - Вам светит уголовка и Вы всю жизнь будете расплачиваться и бегать от приставов. Оно Вам надо?

Off topic: В этом контексте - что я думаю произвошло с конторой Miguel - был некий startup, затем pet-project превратился в что-то что приносит реальный доход, пришли инвесторы и установили свой контроль. И я их полностью понимаю. Как ещё то?

Re: XP and agile. Для меня это прежде всего частые релизы. Да, они должны быть как можно чаще, это позволит Вам понять что Вы уклонились от курса и подкорректироваться «пока ещё не поздно». Пример - всё что я закончу сегодня уйдёт в релиз (limited release) завтра. Peer review очень важен, но парами программировать смысла не вижу. Unit-tests хороши, но всё ими покрыть невозможно (там довольно быстро комбинаторный взрыв происходит).

Re: JIRA. Для меня это не столько planning / reporting tool, сколько нечто что позволяет ответить на вопрос «зачем». Перефразирую - у меня есть возможность посмотреть на diffs между 2мя executables before release. И я всегда вижу что эти изменения делают. Но оно мне не даёт ответ на вопрос «зачем и почему». И вот этот весь logging становится очень критичным, особенно когда разгребаешь чьи то коммиты 5-10-15ти летней давности. Как я уже говорил - «что» конкретное изменение делает я и так вижу, а вот «зачем», какие проблемы решались, и почему оно сделано именно так как сделано - тут JIRA & Confluence вне конкуренции. Конкретно в нашей конторе нынче невозможно сделать commit без соответствующих ссылок на и флажков в JIRA.

Re: релизы по cron (если я не ошибаюсь vertexua за это топил). Это дичь. Сумасшедшая дичь. Любой релиз should be targeted, в смысле Вы должны себе отдавать отчёт «что», «куда», и самое главное - «зачем» Вы релизите. И ещё - Вы должны заранее знать что Вы будете делать если что-то пойдёт не так. ВСЕГДА.

Re: мотивация. Кнут - этот последнее дело, гораздо более важен пряник. Если человек понимает что его премия очень сильно будет коррелировать с тем что контора заработает - да он на изнанку вывернется, лишь бы всё сделать хорошо. Ну и здесь конечно лучше «не жадничать». Люди которые регулярно f-up’ят должны посылаться нафиг ввиду некомпетенции. Единичные f-ups - ну тут по ситуации.

PS. Сразу оговорюсь - я технарь и гик до мозга костей, и в принципе мне manage ppl не особо то и интересно (хотя приходится, но исключительно потому как сам не справляюсь - тупо ни времени ни сил не остаётся). Но я уже давно не берусь за проекты если я не понимаю «зачем» и «какую business цель мы преследуем». И ещё - прежде чем меня критиковать: контора в среднем зарабатывает от 0.5 до 1мил уе на сотрудника в год, наверное что-то мы делаем правильно…

Ты хочешь частые релизы НЕ по крону? Чтобы кто-то другой работал кроном?

Ты хочешь частые релизы НЕ по крону? Чтобы кто-то другой работал кроном?

Да. Однозначно. Единственное исключение - условная «песочница» где крутиться весь nightly в целях smoke test.

был некий startup, затем pet-project превратился в что-то что приносит реальный доход, пришли инвесторы и установили свой контроль

Нет.

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

Снова нет.

за счёт того, что в присутствии напарника сидеть в рабочее время на лоре не получается

ЛОЛИРУЮ. Я как-то под трекерами так работал. Через несколько лет развился прямо таки невроз «ска фигли я лежу, надо срочно что-то печатать» и дроч на «ещё часик поработаю». Отходняк потом был пол-года.

С ним все прекрасно... в теории :) На практике — это что-то типа делания работы за себя и того парня (либо два сидят кодят за одного, а могли бы каждый свое :)) В итоге «А вы, друзья, как ни садитесь...» Все от желаний эффективных менеджеров наколоть физику с биологией, точно соблюдая взаимоисключающие параграфы, не составляя график с критическим путем. Из манямирков уровня «толковый менеджер с джунами пишет больше кода чужими руками» (нет, не пишет :))) Желательно еще чтоб «оно само». Но это квадратно-гнездовое применение работает только в достаточно узких рамках, в которых не хотят сидеть примерно никакие заказчики :)

Не ясно зачем что-то делать если можно что-то не делать

Любой релиз should be targeted, в смысле Вы должны себе отдавать отчёт «что», «куда», и самое главное - «зачем»

Совсем не очевидно почему. Звучит как мантра, «так потому что так».

Вы релизите. И ещё - Вы должны заранее знать что Вы будете делать если что-то пойдёт не так. ВСЕГДА.

И мы это знаем. Даже без релизов, даже если мы просто scale up количество инстансов той же версии. Даже просто так, когда ничего не меняется.

Совсем не очевидно почему. Звучит как мантра, «так потому что так».

Релиз только ради релиза бессмысленен, он должен решать конкретную прикладную задачу.

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

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

Но да, тут у нас FAANG монорепозиторий и своя атмосфера. Когда кто-то в библиотеке меняет API это из отвественность сделать изменения во ВСЕХ приложениях, использующих библиотеку. А приложение может вообще не менять свой код и получать нашару новые версии библиотек, потому имеет смысл делать релизы автоматический и прогонять их через различного рода тестирование и деплоймента постоянно. Мы смирились что в 99% случаев мы не знаем полную разницу между релизами, хотя сможем ее вычислить когда будем исследовать конкретные баги

Когда кто-то в библиотеке меняет API это из ответственность сделать изменения во ВСЕХ приложениях

Это-то понятно. Не понятно какое отношение «оно собралось» имеет к «оно работает». Деплоя по cron Вы по сути постоянно деплоите рандомные сборки, даже на них не глянув. Для меня одно это уже граничит с безумием. Не говоря о том что непонятно куда оно деплоится таким образом, и конкретно в этом ли месте ждут вот конкретно этих вот изменений больше всего.

У нас нет возможности глянуть на сборки. У нас начинаешь что-то собирать и там 10000 файлов зависимостей собирается от 300 команд. Это бессмысленная борьба, проиграная битва - понимать и осознавать все изменения между релизами. Каждый ответственнен за стабильность своей части через очень продвинутое автоматическое тестирование. Потом каждая end команда ответственна за проверку здоровья конечного сервиса при его последовательном деплйоменте на серию environments.

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

У нас своя атмосфера, но я бы сказал что если в компаниях поменьше люди делают apt-get upgrade базового образа при сборке докер контейнеров, то они ровно в той же позиции

У нас начинаешь что-то собирать и там 10000 файлов зависимостей собирается от 300 команд

Я правильно понимаю что все вот эти 10000 файлов релизятся «атомарно» (как один «пакет»), сидят в своей «песочнице» и с «песочницами» других релизов не общаются?

Не совсем понял вопрос. У нас громадный монорепозиторий в котором нету версий. Чистый HEAD.

Собираешь релиз и его сборка начнется с самых базовых библиотек до финального образа. Потом это начнет путешествовать через фазы тестирования, а потом через фазы релиза, разные envs, а потом через фазы кусков продакшна.

Не совсем понял вопрос.

до финального образа

Что является unit’ом релиза? Этот образ в котором сидит куча апликух / сервисов которые общаются только между собой?

XP and agile. Для меня это прежде всего частые релизы. Да, они должны быть как можно чаще, это позволит Вам понять что Вы уклонились от курса и подкорректироваться «пока ещё не поздно»

Это тупо перекладывание работы программистов и аналитиков на заказчика/пользователя. «Я тут что-то налепил — тебе нравится? Нет? Ну будем переделывать». Я здесь не имею в виду тестовые релизы для собственных тестеров — в таком случае контора отрабатывает уплаченные заказчиком деньги. Потому что заказчик, как правило, все равно ничерта не понимает в программе, и вполне может получиться, что «он думал, а мы думали, что они думали» — фича реализована так, но не так, а мы думали что так, и они думали что так, но на самом деле не так. Потому ТЗ пишут аналитики и дорабатывают программисты, а от заказчика нужны только требования. Особенно это касается глубоких технических деталей, вроде масштабирования.

И я всегда вижу что эти изменения делают. Но оно мне не даёт ответ на вопрос «зачем и почему». И вот этот весь logging становится очень критичным, особенно когда разгребаешь чьи то коммиты 5-10-15ти летней давности

Эм-м-м... а разве у вас в тексте коммита не пишется «исправление бага #XXXX»? Более того, я иногда даже оставляю ссылки в сорцах, потому что лазить в историю ревизий за ссылками тоже не комильфо.

И ещё - прежде чем меня критиковать: контора в среднем зарабатывает от 0.5 до 1мил уе на сотрудника в год, наверное что-то мы делаем правильно

Что за контора?

Это тупо перекладывание работы программистов и аналитиков на заказчика/пользователя. «Я тут что-то налепил — тебе нравится?

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

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

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

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

релизнешь говно — потом не расхлебаешь проблем с обновлениями.

Ну, если у меня что-то взорвётся, то меня тоже по головке не погладят, знаете ли. Не хочу даже рассказывать сколько наши последние серьёзные f-ups нам стоили…

Но в вашем случае релизиться очень просто — почему бы это не делать регулярно?

Мне кажется мы с Вами говорим об одном и том же, и в принципе на одной волне. В случае embedded наверное нужно стремиться к тому чтобы отдать своим тестерам/QA сборку как можно раньше. И, конечно - то что уходит конечному потребителю в этом случае должно быть максимально вылизано.

«что» конкретное изменение делает я и так вижу, а вот «зачем», какие проблемы решались, и почему оно сделано именно так как сделано - тут JIRA & Confluence вне конкуренции. Конкретно в нашей конторе нынче невозможно сделать commit без соответствующих ссылок на и флажков в JIRA.

Я только так и не понял — почему в данном случае именно Jira-Confluence каким-то образом решает эту проблему так, как не решает ее никто другой?

Я только так и не понял — почему в данном случае именно Jira-Confluence каким-то образом решает эту проблему так, как не решает ее никто другой?

Пробовали многое (и не «одним глазком глянуть», а годами использовали). Конкретно эта связка по факту оказалась самой удобной, в частности из-за их взаимной интегрированности и встроенной возможности cross-references между tasks, epics etc. Вы можете предложить что-то получше?

Ну, и раз мы о более старых комментариях заговорили:

Эм-м-м… а разве у вас в тексте коммита не пишется «исправление бага #XXXX»?

Это довольно неудачный commit message: он вынуждает посмотреть на XXXX и больше никакой информации сам по себе не несёт. Лучше было бы что-нибудь в духе «XXXX: handle the case of …», я считаю.

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

Если под ссылками выше имеется ввиду полный URL то это тоже не лучший вариант: потом оно переезжает куда-нибудь, или контора переходит на что нибудь другое в качестве project tracking tool и Ваши ссылки начинают показывать «в никуда». Просто сослаться в коде на ID более чем достаточно, имхо.

Я только так и не понял — почему в данном случае именно Jira-Confluence каким-то образом решает эту проблему так, как не решает ее никто другой?

Конкретно эта связка по факту оказалась самой удобной, в частности из-за их взаимной интегрированности и встроенной возможности cross-references между tasks, epics etc. Вы можете предложить что-то получше?

Абсолютно любой трекер+вика. Поиск в жире традиционно говно, как база знаний она не особо выделяется. Ссылки между модулями делаются на любых опенсорсных платформах за минимальные сроки, если такой настройки/расширения еще нет готовой. Пользоваться жирой ради вики с трекером — это как пользоватся MS Excel в роли калькулятора. Технический уровень реализации у atlassian традиционно очень посредственный, так что уж лучше калькулятор — его хотя бы можно доработать под свои цели.

Это довольно неудачный commit message: он вынуждает посмотреть на XXXX и больше никакой информации сам по себе не несёт. Лучше было бы что-нибудь в духе «XXXX: handle the case of …», я считаю

Ну естественно, краткое описание плюс ссылку на развернутое описание баги.

Если под ссылками выше имеется ввиду полный URL то это тоже не лучший вариант: потом оно переезжает куда-нибудь, или контора переходит на что нибудь другое в качестве project tracking tool и Ваши ссылки начинают показывать «в никуда»

Эта проблема случится всегда, независимо от используемого инструмента. Если вы переедете с Jira на багзиллу и наоборот — будет одна и та же проблема. А там уже нужно выдумывать костыли, то ли hosts править, то ли ставить какую-то проксю с редиректом.