Коллективное владение кодом

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

И все вроде бы получается и все довольны. Но что если взять рядового программиста и посмотреть на его работу. Дали, скажем. ему задание — исправить баг в каком-то функционале. Полез он туда — нихрена не понятно. Разбирался несколько дней как оно все должно работать по части бизнес логики, три дня дебажил код, в итоге баг исправил и в системе порядочно разобрался — какой такой класс что делегирует и какие контракты методы заключают. Через месяц а то и два получает программист задание исправить другой баг в том же функционале. Обрадовался — все классы то знакомы, баг на раз два сделаю, в остальное время форумы почитаю. А не тут то было — там уже все переписано и отрефакторено так что родная мать не узнает. Подумает он молча — а нах было все это переписывать, но делать нечего, засучит рукава и пойдет дальше код дебажить...

Когда то работал на одном проекте — клиент-серверная система состоящая из нескольких модулей. И к каждому программисту были привязаны какие-то модули. И тут как бы понятно все ему было, что нужно делать, как и зачем, исправление бага — это дело 20 минут...

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

Но что-то мне кажется все же что такая схема была эффективнее.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

спасут только тесты с высоким уровнем покрытия (этак 90% и больше), Continuous integration и высокая культура команды. Если не будет одного из этиз компонентов- будет черти что.

Система с владением компонентами ведет к тому что в компонентах образуется болото. Рано или позно.

Что такое «владение кодом» вообще? На большом проекте весь код удержать в голове нереально даже если его сам написал (за пару лет). Для решения этой проблемы применяют декомпозицию, инкапсуляцию и абстрагирование.
В итоге если код проекта состоит из мелких классов (Single Responsibility), с понятными названиями, с простыми интерфейсами (Interface Segregation), покрытые юнит-тестами + есть хорошие UML диаграммы то в большинстве случаев в код этих классов смотреть вообще не надо.
Суть Open/closed принципа в том, что один раз написанный и протестированный код лучше никогда не менять. Разве что там нашелся явный баг, не выловленный юнит-тестами. Если же изменились требования — лучше писать новую реализацию.
Что имеем в итоге: девелоперу не нужно «владеть» всем кодом. Сначала он смотрит «с высоты птичьего полета» на диаграммы и отсекает 80% не нужных ему в данный момент классов. Потом он спускается «вглубь» и с помощью тулзов вроде Dependency Graphs (msdn.microsoft.com/...y/dd409453.aspx) и смотрит взаимодействие, строит диаграммы последовательностей вызовов и т.д. В итоге остается несколько классов, в реализацию которых уже надо вникать. Дальше ему в помощь юнит тесты: посмотрел, прогнал, прошел в отладчике, если непонятно.
Как результат чаще всего приходится поменять что-то во взаимодействии классов (настройках Dependency Injection контейнера) или уже написать свою реализацию и подложить в нужное место.
Если же чужой код совсем непонятный — есть правило «Refactor To Understand». Перепиши его по-своему и если юнит-тесты по прежнему проходят — все ок.
Подводя итог: надо писать хороший код! Документация, коллективное или персональное владение, обмен опытом, коммуникация — это то же нужно, но второстепенно. Ну и правильные средства разработки, конечно:

msdn.microsoft.com/...y/dd409365.aspx

Но ведь как же сильно подмывает набыдлокодить побыстрее и получить с полки пирожок за скорость! Потом хрен кто разберет такой код... но только потому√ что они все тупые√ а я — умный. Я могу разобраться и мне за это полагается еще одна плюшка! Слава коллективному коду)) :trollface:

так этож времени потери сколько. в условиях когда все надо навчера, а еще хочется на доу попостить — переписовать все с нуля ужасно не эффективно.

Описанные проблемы не являются порождением collective ownership per se, это больше симптомы других defficiencies, просто хорошо проявившиеся раньше, а не позже. Посмотрим внимательнее. Имеется активно поддерживаемый и развиваемый участок кода. Новый для него девелопер несколько дней разбирается и дебажит его чтобы понять что к чему. Налицо плохая слаженность командной работы (никто не помог) и плохое состояние / читабельность кода (некоторые в комментах ниже еще добавляют документацию — но я лично считаю что лучшая документация это отсутствие ее необходимости). Далее незаметно происходит значительный рефакторинг, неожиданно для этого девелопера — правая рука не знает что делает левая. А когда узнает — еще и задается вопросом «зачем это было делать?».
Итого. Коммуникация в команде не работает. Отсутствует consistent подход к решению проблем. Зачастую наблюдается в неопытных «agile» командах, где скажем collective ownership понимается как «в любой момент могу открыть любой класс и отрефакторить как захочу».
Возможные пути решения: строгий код review с вовлечением всей команды; поощрение обмена и опытом и вопросов к команде прежде чем начинать многодневные копания; воспитание командного духа — «не достаточно только хорошо делать свою работу, важно и то что делают другие, время потраченное на передачу знаний другому возращается сторицей».
С другой стороны, опять же бездумное — «наивное» применение принципа collective ownership может ради мнимой «простоты» управления проектом игнорировать факт различной погруженности разных разработчиков в различными части системы и таким образом приводить к неоптимальному планированию.
В действительности истина скорее всего где-то посередине. С одной стороны мы хотим иметь людей, имеющих глубокое знание подсистемы, видение ее развития и способных быстро и эффективно вносить в нее изменения. Это в принципе не противоречит само по себе идее collective code ownership, но сложно достичь на достаточном уровне всеми везде на нетривиальных проектах. С другой стороны мы хотим избежать возникновения «удельных» подсистем имеющих неоправданно кардинально различные подходы и стили решения похожих проблем, так же мы хотим иметь возможность эффективно перераспределять наличные человеческие ресурсы в зависимости от текущих задач а так же не иметь незаменимых кадров. В этом однозначно collective code ownership очень помогает.

Где-то так.

Да, в целом правильно . Но очень часто случается, что разработчик(и), который писал код или ранее работал с ним, уже возможно не работает в этой фирме/компании/студии или его даже нет в живых (у меня было на практике). По этому не всегда получается узнать и расспросить о том, как это работает и зачем это нужно. Действительно в этом случае может помочь командный код ревью и другое вышеперечисленное. Конечно, лучше не иметь документации и хорош код тот, который говорит сам за себя, но ведь так бывает редко, а идеальный код это утопия.

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

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

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

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

но опять же не серебряная пуля...

Особенно когда некоторые, просто удаляют свалившиеся тесты. БЛ...!!!!111АДЫН

ха-ха, да есть такие «кросавцы», аля «я потом напишу». Эт еще что, если работаете в одной команде нормально, а если несколько команд распределенных и есть общие либы, тут начинается сбор камней за пазухой )

Скорее согласен с тобой.

Хотя тут, как вобщем-то и везде, «серебряной пули не существует». От проекта всё зависит, в проекте который 10 лет на супорте часто нужнее «универсальность». В проекте, который активно развивается — как правило код попадает в «часную собственность» того кто его разрабатывал. Менеджеры частную собственность ужесно не любят — конвеер в этом случае плохо получается. Хотя реальность рано или поздно всё равно расставляет всё по своим местам. Документирование всего и вся — вещь полезная, но не панацея.

Комментирование кода, создание «внутренних» Wiki, нормально-написанная докумментация.. Не помогают? :-)

Это говорит о непрофессиональном менеджменте или «непритязательности» заказчика. Написание доков — это такой же важный участок работы, как и разработка. %IMHO%

Подписаться на комментарии