?

Log in

No account? Create an account
entries friends calendar profile Previous Previous Next Next
мысли о командной разработке - ruik-ruik! röhh-röhh!
raydac
raydac
мысли о командной разработке
    Я абсолютный противник группового владения кодом, т.е. момента когда над одним модулем работает команда из нескольких человек, из того что я видел никакой скорости или качества это не прибавляет, но идут немеряные затраты времени на согласование и понимание "что же сделал в коде другой член команды?", так что скорость такой командной разработки имхо можно рассматривать как обратно пропорциональную количеству задействованного народа (а то и квадрату количества). Тоже самое можно сказать о легаси коде, достался легаси код? фактически досталась "фантомная команда" с которой придется работать и которая еще страшнее тем что никто не даст ответов и обоснований (и которая не могла ошибаться даже в своих заблуждениях), лучше всего такое в топку сразу: так как формула производительности будет та же
     В команду не удастся найти совершенно копирующих друг друга клонов с совершенно идентичным мышлением и навыками и каждый член команды это скорее "шум" для другого чем польза и помощь, возмущение в сигнале которое надо минимизировать.. при таком правильная стратегия разработки - программист на функциональную часть с полным владением кода и ответственностью, чем больше данная часть тем выше будет скорость разработки, так как один программист это очень много если он программирует, а не занимается херней, однако херня это основное занятие в большинстве программерских контор
     Есть вероятность конечно что если работает команда совместно сосуществующая несколько лет (думаю от пяти) без изменений в составе(!), такая может и  будет показыветь высокую производительность, за счет того что члены команды построили в голове модели других участников команды и многое взаимодействие как бы закешировано "зеркальными нейронами" в голове каждого участника, но такие команды настолько редки, что скорее погрешность в современном ИТ мире имхо и на такие примеры ориентироваться вредно и опасно (если не можете загнать их всех в "шарагу")

Tags:

25 comments or Leave a comment
Comments
vitus_wagner From: vitus_wagner Date: June 26th, 2013 03:11 am (UTC) (Link)
Групповое владение кодом нужно не для повышения скорости разработки. Он нужно для того, чтобы при уходе одного человека из команды, написанный им код не превращался в legacy. Или чтобы не пришлось отзывать человека из отпуска если через неделю после его ухода нашли critical bug, затрагивающий его код.
raydac From: raydac Date: June 26th, 2013 03:26 am (UTC) (Link)
или ты делаешь или ты занимаешься анальным огораживанием, надо выбирать одно из двух
vitus_wagner From: vitus_wagner Date: June 26th, 2013 03:36 am (UTC) (Link)
Деланье - не самоцель. Цель - существование работоспособного результата.
А тут, увы, выбирать не получается, приходится идти на компромиссы.
Потому что неподдерживаемый результат никому не нужен.
Ivan Sopov From: Ivan Sopov Date: June 26th, 2013 03:21 am (UTC) (Link)
Вы меня пугаете. У меня начинается подозрение, что ситуация на моей первой работе, где было прекрасное коллективное владение кодом командой пяти человек, является достаточно уникальной. Я, действительно, повторения пока не видел, но как-то надеюсь...
raydac From: raydac Date: June 26th, 2013 03:26 am (UTC) (Link)
не видел я нормального группового владения и разработки, как правило то что видел скатывалось к "группе главного хирурга" (и эффект от такой системы разработки, далеко не групповой, выдавался за эффект от командной) и одну работу назад группа из 5 человек мучалась с легаси микропроектом всего в 75000 строк кода полгода на внесение одной простенькой фичи, и за полгода так её и не сделало, но да, всё как положено, групповое копание в коде, мы - команда!
Ivan Sopov From: Ivan Sopov Date: June 26th, 2013 03:51 am (UTC) (Link)
Я кажется понял, в чем логическая ошибка.
"...идут немеряные затраты времени на согласование и понимание "что же сделал в коде другой член команды?" - это согласование требуется независимо от того, какого механизма работы придерживаются. Только в случае применения лучших практик "коллетивного владения кодом" - это согласование проходит часто и практически без затрат. А если эти практики не применяются, то и начинаются "немеряные затраты времени".
raydac From: raydac Date: June 26th, 2013 04:26 am (UTC) (Link)
на это согласование никогда не будет
1. времени
2. нормальных презентационных навыков что бы один член команды донес свою точку зрения до других членов команды (а нафига ему при таком вообще кодить? сейчас domain architects то зачастую не могут донести свою точку зрения)
vitus_wagner From: vitus_wagner Date: June 26th, 2013 05:28 am (UTC) (Link)
Не без затрат. Затрат в общем-то столько же. Но они естественным образом включаются во время разработки, учитываются в эстимейтах и в итоге - в стоимости проекта. А если этих практик не применять, эти затраты сваливаются внезапно.
Ivan Sopov From: Ivan Sopov Date: June 26th, 2013 06:17 am (UTC) (Link)
ИМХО, ситуация очень похожа на автоматическое тестирование. Человек, который им не пользуется не тратит время на написание теста, но зато каждое изменение в коде требует от него что-то сделать в браузере/консоле/окне программы. Человек, который написал тест, потратил время на тест, но зато каждое изменение в коде он контролирует одной-двумя новыми строчками теста или вообще без них, и взглядом на картинку - зеленая она или красное, что гораздо быстрее.

Точно также и здесь. При нескольких людях в команде, и ситуации "все разбираются и хорошо себя чувствуют во всём коде" можно не тратить полдня на интеграцию какой-нибудь библиотеки, а передать эту задачу другому человеку, который сделает это за полчаса. Причем в конечном итоге изначальный человек, который отдал задачу после чтения кода решения и нескольких слов человека, который его делал, будет понимать библиотеку лучше, чем из чтения документации, примеров, и т.д. Так что в некоторых ситуациях может быть и выигрыш.
vitus_wagner From: vitus_wagner Date: June 26th, 2013 06:22 am (UTC) (Link)
Насчет такой экономии времени это, пожалуй, фантастика.
А вот экономии средств за счет использования возможностей людей разной квалификации и, соответственно, с разными зарплатами, достичь можно.

И квалификационного роста людей за счет парной работы добиться можно. Что тоже способствует
supermega From: supermega Date: June 26th, 2013 07:28 am (UTC) (Link)
Дописывать свой собственный код гораздо легче конечно же. Но вот у меня в конторе довольно часто бывает ситуация, когда на один и тот же момент времени существует сразу несколько довольно срочных задач, которые затрагивают код, написанный одним и тем же человеком.
Разорваться теперь что ли? :)
Да и вообще, когда только один человек разбирается в участке кода - это плохо. Бывают критические ситуации, особенно в хайлоаде, когда грубо говоря всё упало, хотя казалось бы никак не могло, и надо очень быстро понять, что происходит, потому что простой системы стоит безумных денег. В этом случае очень здорово иметь несколько человек для мозгового штурма, которые хорошо разбираются в большей части системы. Если единственный человек, который мог знать, что там происходит - уволился, то всё, пиздец. Может уйти безумное количество времени на то, чтобы отдебажить проблему. И, опять же, если есть несколько человек, которые владеют хотя бы крупицами информации, то уже гораздо легче.
Короче, любой бизнес зиждется на двух основаниях: прибыль и риски.
Прибыль можно увеличить уменьшением совместного владения кодом
Риски можно снизить увеличением совместного владения кодом
т.е. они похоже ортогональны

Можно достигнуть некоторого компромиса, если серьёзно относиться к читабельности кода. Т.е. должен быть кто-то, кто постоянно делает code review и анально карает за нечитабельный код. Пофиг какие парадигмы используются: SOLID, DDD, тупо коментарии и т.д. - главное чтобы код был архичитабельным. Но опять же в случае emergency это слабовато поможет.
vitus_wagner From: vitus_wagner Date: June 26th, 2013 07:33 am (UTC) (Link)

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

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

Снижение рисков это ВСЕГДА лишние затраты. А лишние затраты - снижение прибыли.
alll From: alll Date: June 26th, 2013 03:48 am (UTC) (Link)
> В команду не удастся найти совершенно копирующих друг друга клонов с совершенно идентичным мышлением и навыками

Угу, именно за этим и нужно парное программирование, а вовсе не для экономии столов. ;)

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

Опять же, можно практиковать не жёсткое владение, а "носителей vision", они же по-совместительству "knowledge hubs". Пришла задача, посмотрел, сформулировал вопросы - пошёл к "ответственному", прояснил что-как. Собственно, зачастую лид команды именно в таком режиме и функционирует и по-идее все сеньёры такими же должны быть.
raydac From: raydac Date: June 26th, 2013 04:29 am (UTC) (Link)
парное программирование частично решает проблемы, но если у тебя программеры юны и горячи... если старые и злые, то они пересрутся передерутся обложат друг друга матами и поувольняются... если хитрожопые то они не будут ругаться.. вобщем с парным программированием ты всегда снизиш свои ресурсы в два раза и редко поднимешь производительность труда (это кстати в игровых конторах выяснили крупных, где очень "горячо" и надо выжать максимум)

Edited at 2013-06-26 08:29 am (UTC)
alll From: alll Date: June 26th, 2013 05:00 am (UTC) (Link)
Парное программирование обычно нужно сильно поначалу, для притирки членов заново создаваемой команды. Дальше достаточно код ревью (да и то со временем всё меньше) плюс изредка усилия по притирке нового члена команды. Хотя если в команде текучка выше 20-30% за год, то оно нужно будет постоянно. Но при такой текучке опаньки будут при любом процессе. ;)

От программистов, который систематически срутся с коллегами и не умеют корректно излагать своё мнение, надо избавлятся, если хочешь команду, а не хирурга с ассистентами. У нас например на аттестации на повышение грейда один из ключевых вопросов - нет ли проблем при взаимодействии с коллегами.
raydac From: raydac Date: June 26th, 2013 05:06 am (UTC) (Link)
вот поэтому сейчас "социальный" программист и имеет гораздо больше шансов чем "ассоциальный" (даже если последний гораздо толковее) )) помню на одной работе начали народ набирать юзая в качестве теста парное программирование, пришел мужик достаточно толковый и опытный лет 45, посадили "париться" с 27 летним программером, вобщем через 15 минут они пересрались между собой
насчет того каких надо набирать, тут играет большую роль сколько у тебя золотого запасу и какой нематериальный актив (трейдмарк), если скажем как в яндексе, то ты можешь набирать методом полного перебора фактически, но если тебе надо считать бабло и к тебе не стоит очередь, то тебе придется действовать более хитро

Edited at 2013-06-26 09:06 am (UTC)
tobotras From: tobotras Date: June 26th, 2013 04:20 am (UTC) (Link)
лучше всего такое в топку сразу: так как формула производительности будет та же

Главное, вовремя удачно менять инвестора, и каждому следующему рассказывать, что "вот мы тут сейчас всё перепишем, и вот тогда!"...

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

И, когда он увольняется, -- проект закрыть и всех уволить?..
raydac From: raydac Date: June 26th, 2013 04:24 am (UTC) (Link)
>>И, когда он увольняется, -- проект закрыть и всех уволить?..
зависит от того "кем покойный был при жизни", так как если нанять "васю" который не может договорится сам с собой, рожает код в беспамятстве, делает локальные переменные a,b,c и классы someclass1, someclass2 то он и прижизни не даст спокойствия, нормальный программер кодит более менее понятно и логично (т.е. можно сесть потратить время и разобраться) увольняясь пишет описание по тому что он проделал, иногда зачитывает лекцию на тему "что и как" и всегда доступен на новом месте работы для объяснения какихлибо непоняток
beldmit From: beldmit Date: June 26th, 2013 06:10 am (UTC) (Link)
Ну, у меня коллега выпадал по медицинским соображениям надолго. А описание можно делать или общее, или "программа хорошо документирована на языке XXX".
beldmit From: beldmit Date: June 26th, 2013 06:09 am (UTC) (Link)
Затраты на согласование и понимание есть всегда, где есть взаимодействие между кодом, создаваемым участниками проекта. Альтернатива - "владелец" куска говорит "будет так", остальные берут под козырек. По моим ощущениям, скорость при наличии коллективной разработки до некоторых пределов растет логарифмически или около того. Зато риски от ухода в отпуск или увольнения существенно снижаются.

Мне приходилось наблюдать кейсы, когда без одного ведущего разработчика часть кода оказывались недоступными к правкам - потому что вроде все как настоящее, а хрен разберешь. Так что как минимум должна быть связка "мастер - подмастерье".
chemodax From: chemodax Date: June 26th, 2013 08:23 am (UTC) (Link)
Я уже лет 7 работаю исключительно в условиях коллективного владения кодом и не представляю как можно жить иначе.
raydac From: raydac Date: June 26th, 2013 08:29 am (UTC) (Link)
стокгольмский синдром.. если проект древний и вы уже привыкли даж к его багам, то понятно что это теплое ламповое существование комфортно и команда не тратит время на разборки
p.s.
это всё imho

Edited at 2013-06-26 01:25 pm (UTC)
vit_r From: vit_r Date: June 26th, 2013 03:04 pm (UTC) (Link)
Беспроблемная командная разработка достигается строгим соблюдением стандарта на всё начиная с отступов и заканчивая тем, когда, что и зачем можно менять. Если уровень разный, что бывает часто, на это накладывается иерархия.

Я, даже, пару раз такое видел в живую.

Но в обычной фирме - да. Надо выстраивать вокруг своего кода забор и пытаться максимально отгородиться от всяких олухов.
tretiy3 From: tretiy3 Date: June 26th, 2013 05:20 pm (UTC) (Link)
про командный код все так, а про легаси нет.
легаси - ок. в доме должен быть один хозяин. когда он уходит/уволняется/умирает его место занимает новый программист и ему достается легаси. ну и ладушки. с легаси можно разобраться вполне. главное чтобы никто не мешал. главное чтоб сам. один.
raydac From: raydac Date: June 27th, 2013 02:08 am (UTC) (Link)
зависит от того кто писал и в каких условиях, часто легаси выгоднее переписать целиком (юзая существующее как справочник), чем его тянуть
25 comments or Leave a comment