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

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

эксКРЕмальное

Я пробовал парное программирование непродолжительное время. Реально ускоряет работу раза в 3. Но в основном за счёт того, что в присутствии напарника сидеть в рабочее время на лоре не получается, приходится работать, в итоге в конце дня выжатый как лимон. Подозреваю, что в перспективе от такого выгоришь и уволишься.

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

Понятно теперь, что с тобой стало...

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

Блин, а это ведь хорошо подмечено. У меня уже давно возникло подозрение, что все методы, преподаваемые коучами, по сути сводятся к «маши веслами быстрее, раб». То есть, они ничего не упрощают и не оптимизируют, а являются очередным кнутом, взамен того кнута, к которому работник уже привык и не обращает на него внимания. По этой же причине много кто эксплуатировал всякие опенспейсы и прочее порно. Даже банальный офис подразумевает, что ты не можешь подремать (хотя лично я этим занимался в офисе).

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

Ну можно же с дружбаном так сидеть, это самое лучшее и ограничивать по времени. К сожалению практически не реализуемое.

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

Я только не понял, чем это круто. Ты сам не можешь автотесты и доки написать в VSCode?

Не знаю что там в VSCode, но вдвоём в 1,5 раза больше идей как правильно сделать приходит и в 1,5 раза быстрее, что даёт 2,25 скорости разработки на заданном качестве на 2 или 1,125 на рыло. Ну это грубо конечно.

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

а лоровского инцела-шизика ttt пидорнули из редхата за дремание на рабочем месте! так-то!

Так, я не понял, вы голубые что ли, чё вы весь день там сидите вдвоём? Какое парное программирование, выдумщики, расселись быстро! ©

Дело в том, что одновременная (!) работа двух людей (3 уже толпа) поднимает продуктивность больше, чем при изолированной работе двух людей по одиночке. Вы вот оба пишите один код, находитесь постоянно в контакте (аудио/видео), обмениваетесь идеями. Это тяжело объяснить. Плагин Live Share позволяет работать как в облачной IDE, только без облака. Один выступает мастером, остальные подключаются слейвами.

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

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

Не религиовед, потому не разбираюсь в разных брендах методологий на продажу - scrum, XP, etc.

Но конкретные вещи которые ты по ли работают очень хорошо.

Peer review вообще обязателен, я работаю исключительно так уже 7 лет. Это must всегда, почти без исключений.

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

100% test coverage скорее вредно. Вы обрастете detection tests, а это очень плохо. Это частный случай правила «если людям дать метрику, они начнут оптимизировать под эту метрику, забыв что она собой представляет изначально»

100% test coverage скорее вредно. Вы обрастете detection tests, а это очень плохо. Это частный случай правила «если людям дать метрику, они начнут оптимизировать под эту метрику, забыв что она собой представляет изначально»

Тесты на ревью нужно проверять.

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

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

Не знаю что там в VSCode, но вдвоём в 1,5 раза больше идей как правильно сделать приходит и в 1,5 раза быстрее, что даёт 2,25 скорости разработки на заданном качестве на 2 или 1,125 на рыло. Ну это грубо конечно

Да, конкретно в моем случае я могу подтвердить фактор «вместе веселее». Правда, по поводу «в 1.5 раза больше идей» я не уверен. Сто раз наблюдал ровно обратное: 2-3 кодера очень «эффективно» взаимодействуют и обсуждают софтину, но по итогу ничерта не работает, потому что нужно было читать код и делать прототипы, а не «весело обсуждать».

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

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

вы делаете какую-то новую софтину, под которую даже прототипа нет, и вам нужно по два раза на день фундаментальные вещи переделывать.

Вот уже на этом моменте можно сказать, что проект ни куда не уедет.

лишь изредка собираясь для обсуждения новой рахитектуры

Чем дольше живет проект тем важнее становятся архитектурные вопросы.

Че то у тебя все с ног на голову.

Ставишь правило 100% тестовое покрытие - я гарантирую тесты на всякую фигню. Всякие самые замшелые error ветви будут тестировать ниочем

Agile

https://www.youtube.com/watch?v=a-BOSpxYJ9M

Видео от автора термина Agile

Так для меня 100% кавередж это норма последнии несколько лет, я же говорю просто на ревью нужно следить.

Дело в том, что одновременная (!) работа двух людей (3 уже толпа) поднимает продуктивность больше, чем при изолированной работе двух людей по одиночке. Вы вот оба пишите один код, находитесь постоянно в контакте (аудио/видео), обмениваетесь идеями. Это тяжело объяснить

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

В остальном я ответил:

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

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

Этому «никому» ты и отвечаешь. Я не помню, чтобы когда-то кнуты на меня эффективно работали — я тупо начинаю работать против них, и по итогу вместо работы получается видимость работы. Кнут допустим как исключительная мера, но если часто ею пользоваться, то она теряет силу.

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

Конечно же помогает, вы обладаете разными знаниями о системе.

Этому «никому» ты и отвечаешь. Я не помню, чтобы когда-то кнуты на меня эффективно работали — я тупо начинаю работать против них, и по итогу вместо работы получается видимость работы. Кнут допустим как исключительная мера, но если часто ею пользоваться, то она теряет силу.

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

Не религиовед, потому не разбираюсь в разных брендах методологий на продажу - scrum, XP, etc

Так все-таки это развод на доллары? Я только не совсем понимаю, почему продавцы методологий до сих пор не собрались в стада, как обычные манагеры? Ниша не такая жирная и на всех не хватит?

Peer review вообще обязателен, я работаю исключительно так уже 7 лет. Это must всегда, почти без исключений

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

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

Да, согласен про очень отдельные случаи.

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

Ну это уже не 100% покрытие.

Почему?

Плохо, что ты не можешь даже описать задачу, для которой эта «продуктивность» поднимается

Потому что я не рабинович, который по телефону поет.

вы делаете какую-то новую софтину, под которую даже прототипа нет, и вам нужно по два раза на день фундаментальные вещи переделывать

Вот уже на этом моменте можно сказать, что проект ни куда не уедет

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

Чем дольше живет проект тем важнее становятся архитектурные вопросы

У вас там архитектура приложения определяется после написания реализации, что ли?

https://www.youtube.com/watch?v=a-BOSpxYJ9M
Видео от автора термина Agile

Зачем? Там 40 минут — я должен все пересмотреть?

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

Если каждый день приходится переписывать фундаментальные вещи то эти вещи нужно отложить и заняться чем нибудь более определенным пока не появится ясность в фундаментальных вещах.

У вас там архитектура приложения определяется после написания реализации, что ли?

Чем больше кода в проекте тем сложнее его рефакторить и тем больше последствий от архитектурных решений.

Конечно же помогает, вы обладаете разными знаниями о системе

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

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

Ну так значит и не бьют кнутами — что и требовалось доказать.

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

Так все-таки это развод на доллары? Я только не совсем понимаю, почему продавцы методологий до сих пор не собрались в стада, как обычные манагеры? Ниша не такая жирная и на всех не хватит?

Собрались. Это гигантская индустрия, приходит за бабки и конвертировать людей в скрам.

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

Для этого достаточно коротких сообщений или вики.

Нет не достаточно. Проект постоянно меняется. Если его одновременно пилит 15 человек то про вики можно забыть.

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

Эту проблему нужно решать на ревью.

Ну так значит и не бьют кнутами — что и требовалось доказать.

Значит и парное программирование это не кнут.

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

А в чем проблема с тестированием всех кейсов в которых эта либка будет жить?

Если каждый день приходится переписывать фундаментальные вещи то эти вещи нужно отложить и заняться чем нибудь более определенным пока не появится ясность в фундаментальных вещах

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

Чем больше кода в проекте тем сложнее его рефакторить и тем больше последствий от архитектурных решений

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

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

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

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

Ты был не согласен с моим тезисом «Чем дольше живет проект тем важнее становятся архитектурные вопросы» Я сформулировал его по другому.

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

Ты снова меня радуешь чтением моих мыслей. Мне тоже показалось, что Agile не имеет никаких четких границ, то есть, нельзя сказать «мы работаем по аджайлу», потому что нельзя ни работать по нему, ни работать против него — это нечто эфемерное, которое везде и нигде одновременно. Вы исправили баг в релизнутой софтине? Аджайл. Вы уточнили требования в процессе разработки? Аджайл. А кто этим не занимается?

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

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

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

Если наверное пытаться выбрать методологию которая работает, у меня был отличный опыт с https://en.wikipedia.org/wiki/Kanban_(development)

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

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

Добавлю еще про peer review.

Эта штука идет намного дальше чем многим кажется. Это не о том чтобы защищать код от плохих изменений, нееет.

Это о психологическом комфорте коллектива. Коллектив который живет в культуре страха факапа - это коллектив который избегает риски и инновацию.

Бабахнул продакшн, начинаем искать проблему, нашли, таааак кто код закоммитил, о Вася. Васе публичную порку 100 розг. Так это его второй случай? Все, мы все знаем, Вася - факапщик. Эй факапщик, ух, то что ты делаешь наверное бабахнет еще раз, хахахаха, стыдно быть таким говнокодером как ты. В итоге Вася перестанет писать код, будет избегать сложные задачи и не будет расти. Коллектив нашел козла отпущения и ему временно комфортно, но следующим козлом может стать каждый

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

Если наверное пытаться выбрать методологию которая работает, у меня был отличный опыт с https://en.wikipedia.org/wiki/Kanban_(development)
Но там ничего военного, просто в коллективе мотивированых людей отлично работает одна очередь задач из которой ты выбираешь что-то себе когда закончил предыдущую вещь

На чем реализовывали канбан?

На внутренней штуке, у нас такая компания которая все пишет сама ) Размеры позволяют. Вообще наверное привычка, у нас с многими проблемами сталкивались впервые в мире, потому обычно свой костыль. Потом индустрия догоняет лет через 5-10

На внутренней штуке, у нас такая компания которая все пишет сама ) Размеры позволяют. Вообще наверное привычка, у нас с многими проблемами сталкивались впервые в мире, потому обычно свой костыль. Потом индустрия догоняет лет через 5-10

Неужели вы первыми канбан придумали? Я почему-то уверен, что у вас канбан не совсем стандартный был.

Джоэл вкинул важный тезис: если подход не работает в этих ваших опенсорсах, то это не значит, что он не работает вообще

Не читал Джоэла и не буду, но во-первых, если подход работает только в коммерсне, при том что опенсорс ориентирован на потребителя, а коммерсня против, однозначно говорит об этом подходе. Но, во-вторых, кто сказал что ЭП не работает в опенсорсе? В паре я бы СПО пописал, было бы с кем. В отличие от коммерсни где это, как уже было замечено, либо инструмент погонщика, либо карго культ, в СПО это может быть инструментом фана, улучшения качества кода и взаимного обучения.

Якобы есть какие-то проекты и команды, где программирование парами со взаиморевью кода и со 100% покрытием кода позволяет ускорять и упрощать разработку каких-то там проектов

Что-то тут всё в одной куче. Ревью кода и максимальное покрытие тестами - это давно уже норма в индустрии (и коммерсне, и СПО), ничего экстремального в этом нет. Вот пары - да, не часто встретишь.

Ссылка на драму?

Ревью кода и максимальное покрытие тестами - это давно уже норма в индустрии (и коммерсне, и СПО), ничего экстремального в этом нет

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

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

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