Чи важливо володіти індивідуальним кодом? [зачинено]

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

Я величезний прихильник призначити кожному члену команди приблизно рівну частку кодової бази. Це дозволяє людям пишатись їхнім творінням, дає екраністам помилок очевидне перше місце при призначенні вхідних квитків та допомагає полегшити "синдром розбитих вікон".

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

Більш за все, він говорить остаточне слово щодо основних рішень з однією людиною, яка має чималий внесок, а не з комітетом.

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

Але, пропонуючи це своїм колегам, я отримав тонну віддачу, безумовно, набагато більше, ніж я очікував.

Тож я запитую у спільноти: яка ваша думка щодо роботи з командою на великій кодовій базі? Чи щось мені не вистачає у пильному збереженні колективної власності?

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

Вам просто потрібно переглянути наступні два сценарії, щоб зрозуміти, чому концентрація знань на мінімальній кількості людей є менш ідеальною:

• Учасника команди зустрічає нещасний випадок
• Член команди відповідає кращим можливостям працевлаштування

Природно, людина / люди, які пишуть певні розділи, матимуть більше знань про це, але не піддавайтеся спокусі зробити їх єдиним силосом знань. Силоси принесуть вам короткострокові виграші від тривалих болів.

Тільки тому, що у вас немає індивідуального права власності на секції коду, оскільки ви його написали, це не означає, що ви все ще не матимете аспектів "гордості за своє створення" тощо. Я не вірю, що володіння командою буде сильно зменшити будь-які особисті почуття власності на написаний код.

Зрештою, команді належить код. Але з усіх зазначених вами причин ми визначили окремих авторів для конкретних частин коду. Кожен автор несе основну відповідальність за свою частину коду та вторинну відповідальність за кодову базу в цілому.

Якщо проблема з частиною базової поверхні коду, я намагаюся повернутися до людини, яка спочатку написала код для виправлення. Звичайно, ніщо не заважає членам команди застосувати виправлення; очікується, що всі члени команди знайомі з кодом інших. Але ми завжди намагаємось отримати виправлення від оригінального автора спочатку. Зрештою, вони написали код; вони - це найвідоміше з цим.

Я працював у командному середовищі, тому що люди не відчували почуття власності у написаному, вони не були змушені писати відмінний код, а просто середній код.

Хоча я погоджуюся з ділової позиції щодо причин поширення знань про товар; реальність полягає в тому, що людина, яка зосереджує свої зусилля на певній ділянці будь-чого, з часом стане набагато більш розбирається в даній області.

Ігнорувати це - ігнорувати науку. Мозок, на жаль, не в змозі утримати все, з чим стикається. Він нагадує, що є дійсним і цінним в даний момент, але навіть, що сховище зменшується з часом.

Я схильний би погодитися з вами, що право власності на певний модуль або відділення в межах більшої кодової бази загалом дасть кращі результати. Хтось, хто піде без жодного повідомлення, перешкоджатиме успіху? Звичайно. Але робити вигляд, що всі в команді повинні мати однаковий обсяг знань щодо кодової бази, наївно і нічого не робить для покращення коду; він намагається захистити код. Захист коду - це роль бізнесу з зрозумілих причин. Тривалість зусиль, які бізнес докладе до захисту коду, часто може стати згубною.

Ви не впевнені, що кожен гравець у вашій команді може грати з противником? Я б стверджував, що переконання, що будь-який член члена команди має частку в кодовій базі, йде так само, як і спроба змусити кожного гравця вашої команди грати в чвертьбек на задовільному рівні ... це не додається. У вас є резервні копії? Впевнені, що ви робите ... але члени команди повинні мати особу в команді. Вважати, що всі однакові - це просити біль різного роду ...

Я не знаю, що власність індивідуального коду - це гарна ідея. Принаймні, не в тому сенсі, що люди можуть сказати «Це мій код, і я з ним зроблю все, що хочу». Можливо, краще сказати, що ви повинні мати індивідуальне управління кодом : код повинен належати команді, але є одна конкретна людина, якій команда делегує відповідальність і повноваження за неї.

Причиною цього є те, що якщо це відповідальність кожного, то це не є відповідальністю нікого.

Я б підтримував власність команди над особою з наступних причин:

• Послідовність коду для всього проекту
• Сприяє обговоренню коду, що завжди призводить до кращих, перевірених рішень
• Якщо один член команди хворий (або ще гірше), весь розділ коду не підлягає затримці
• Члени команди можуть працювати над усіма частинами проекту, що дозволяє зробити перегляд коду вбудованим у процес розробки

Спеціалізація прекрасна - для великої бази даних це може з часом заощадити зовсім небагато часу на спілкування - але право власності - ні.

Що я маю на увазі, це таке ставлення, що в команді є помилка, і ніхто не повинен говорити, що "о, тільки X може торкнутися цього коду, тому це не моя проблема". Якщо ви є частиною команди, ви також зобов'язані виправляти помилки у всій базі коду, якщо можете, і робити це належним чином. Особа X може бути найкращим вибором для цього, але слід очікувати, що це зробить будь-хто. Це, природно, вимагає написання коду таким чином, що дозволяє та запрошує членів команди працювати з ним. Наявність коду gnarly забороняє це, тому прагніть до кришталево чистого простого коду, оскільки це дозволяє більшості розробників працювати з ним. Ви можете піти з рецензування , щоб зберегти його таким чином.

Я повинен погодитися з вами: командна власність на кодову базу є набагато кращим варіантом, ніж індивідуальне право власності.

Очевидним недоліком індивідуального права власності є те, що якщо з одним працівником щось трапиться (звільняють, виходять на пенсію, хворіють і т. Д.), Тоді, якщо він / вона не написав дійсно чистий код, знадобиться певний час, щоб хтось інший прийняв цю особу код, особливо якщо їм також доведеться керувати власним кодом.

Вони також просто занадто багато інструментів, які спрощують володіння командою. Огляди коду, контроль над джерелами - це речі, які заохочують участь команди у всій базі коду. Крім того, як ви призначаєте певну частину кодової бази лише одній особі? Ви просто говорите, що лише ця людина може змінювати цей файл?

Нарешті, я думаю, що якщо одна частина кодової бази зламається, це занадто легко звинувачувати особу, яка відповідала за неї, і це просто спричиняє більше проблем.

Я думаю, що вам потрібно і те, і інше, тому що існує напруга між обома підходами.

Якщо на будь-якому фрагменті коду є лише одна людина, яка може над ним працювати, це дуже погано в довгостроковій перспективі для компанії, особливо як / якщо вона зростає, тому що кожен розробник стає точкою провалу. З іншого боку, індивідуальне володіння кодом (сподіваємось) дозволяє швидше час доставки, оскільки розробник, як правило, вважає за краще такий підхід (стимул), оскільки розробник дуже добре знає код тощо. Існує також питання про час: це повинно бути можливим перерозподіляти розробників на конкретні проекти залежно від потреб бізнесу, але якщо ви робите це щодня, це жахливо (хоча б тому, що розробники ненавидять це, але також і тому, що вартість комутатора просто занадто велика, і ви витрачаєте більшу частину часу на виконання нічого).

IMO, одна роль менеджера - знайти хороший баланс між обома. Огляд коду, стандарти кодування, стандартизація набору інструментів також повинні сприяти зменшенню проблеми помилок. Зрештою, головним моментом реконструктивного коду є вирішення цього питання.

Я думаю, що власність колективного коду незрівнянно краща, ніж володіння індивідуальним кодом.

Мене не так турбує аргумент вантажівки - в індивідуальній моделі власності втрата власника дорога з точки зору часу, необхідного для того, щоб хтось інший взяв на себе участь, але подія досить рідкісна, що амортизована вартість є низькою.

Швидше, я думаю, що власність колективного коду призводить безпосередньо до високоякісного коду. Це з двох дуже простих причин. По-перше, бо болісна правда полягає в тому, що деякі ваші програмісти не такі хороші, як інші, і якщо вони володіють кодом, цей код буде поганим; надання доступу до нього кращим програмістам покращить його. По-друге, перегляд коду: якщо кожен володіє кодом, кожен може переглянути його та вдосконалити; навіть хороші програмісти пишуть код підрозділу, якщо їх залишити на власні пристрої.

Я це кажу на основі досвіду мого поточного проекту. Ми прагнемо практикувати колективну власність, але є деякі біти системи, які стали спеціалізованими - я та інший хлопець фактично є власниками системи збирання, наприклад, є хлопець, який робить більшу частину роботи над вхідними каналами даних. , інший хлопець, що працює на імпорті зображень тощо. У деяких з цих областей (зокрема, я повинен зізнатися, в моєму районі!) Якість коду серйозно постраждала - є помилки, помилки, хитрості та хакі, які просто не переживуть уваги інших людей у ​​колективі.

Зауважу, що ви можете отримати деякі переваги власності колективного коду, маючи індивідуальне право власності на код, коли право власності на певний біт коду регулярно переміщується між різними програмістами (скажімо, кожні три місяці чи кожен реліз - можливо, навіть кожну ітерацію?) . Програмний еквівалент сівозміни. Це може бути весело. Я сам не збираюся спробувати це.

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

Наприклад, у нашій команді є пару хлопців, які роблять адміністративні веб-сторінки для наших серверних продуктів. Ми побудували користувацький серверний скрипт-движок, щоб ми могли мати необхідні функції виклику C на сервері прямо з наших сценаріїв Java або html. Я думаю, що важливіше, щоб наші "веб-" хлопці розуміли, як користуватися цим механізмом, на відміну від того, що вони є співвласниками програм для веб-сторінок.

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

Подумайте більше відповідальності та менше власності. Зрештою, той, хто пише чеки, все одно є справжнім власником.

Джіме, я з тобою на цьому 100%. Я в середині точно такого ж бою на своєму місці роботи - саме тому я натрапив на ваше запитання.

Я бачу це так: "коли всі володіють ним, ніхто не володіє ним".

Для мене немає жодного важливішого чинника якості коду, ніж власності та відповідальності.

Приклад з реального життя ілюструє це добре. про що б ви краще подбали: ваш приватний газон чи парк громади? Досить очевидно.

Це, до речі, не обов'язково потрібно торгувати за "гнучкість команди". Це просто означає, що коли людина володіє чимось, вона володіє нею - і хоча б на день.

Для мене це залежить від динаміки вашої команди.

Наприклад, якщо у вас є команда, яка не є уніфікованою за стандартами, експертним переглядом, методичним тестуванням, або якщо у вас є команда, де рівень компетентності сильно різниться серед членів, можливо, було б корисно шукати більш чіткого поняття про право власності на код з більш модульним мисленням у чорній коробці.

Якщо цього немає, наприклад, ваш ретельно розроблений інтерфейс, що відповідає принципам SOLID, може бути швидко зруйнований тим, хто навіть не знає засобів "SOLID" і хоче весь час додавати нові еклектичні функції в інтерфейс для "зручності", наприклад Це, безумовно, найгірше.

Ви також можете мати справу з неохайними співробітниками, чия ідея виправити помилку - це виправлення симптому, не розуміючи кореневої проблеми (наприклад: намагання відповісти на звіт про аварійну ситуацію, просто ввівши обхідні проблеми в код, щоб тільки приховати помилку та перенести смертельну ситуацію побічні ефекти для когось іншого). У цьому випадку це не так вже й погано, як диверсія дизайну інтерфейсу, і ви можете захистити свої наміри ретельно сконструйованими тестовими одиницями.

Ідеальне рішення - посилити свою команду, хоча ця концепція авторства та власності вже не набуває такої важливості. Експертна оцінка стосується не лише покращення якості коду, а й покращення роботи в команді. Стандарти - це не лише послідовність, вони покращують командну роботу.

Однак існують сценарії, коли рецензування та фактична відповідність усім стандарту є просто безнадійною і принесуть безліч безнадійно недосвідчених критиків. Я б сказав, що багато про те, чи має власник на код чи власність команди більш чіткий пріоритет, буде ґрунтуватися на здатності вашої команди фактично виконувати ефективну експертну перевірку і фактично залишати всіх, хто отримує користь від неї (як з точки зору самого огляду , і, як результат, наближаємось до думки та стандартів). У великих, розкутих та / або розрізнених командах це може здатися безнадійним. Якщо ваша команда може функціонувати як "загін", де ви ледве навіть можете сказати, хто що написав, то одноосібне володіння почне здаватися дурним поняттям.

У подібних сценаріях, далеких від ідеального, таке поняття власності на код може насправді допомогти. Він намагається виправити найгірший сценарій, але це може допомогти, якщо командна робота, як правило, безнадійно ставити огорожу навколо авторського коду. У цьому випадку це зменшується робота в команді, але це може бути краще, якщо "командна робота" призводить лише до наступання на ноги.