* Власник коду * Система: це ефективний спосіб? [зачинено]

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

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

Як ви вважаєте, підхід буде добре працювати для системи середнього розміру (розробка сайту в соціальній мережі)?

Як і багато таких питань, я думаю, що відповідь:

Це залежить

Є підстави вважати, що зайняття позиції, згідно з якою кожен програміст повинен знати кожен рядок коду, є помилковим.

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

• Програміст A: має глибоке розуміння
• Програміст В: немає

Скажімо, програміст А отримує 1 одиницю виконаної роботи на день. За 4 тижні 5 робочих днів він може отримати 20 одиниць роботи.

Таким чином, програміст B, починаючи з 0,2 одиниці роботи на день і закінчуючи 0,96 одиниць роботи на 20-й день (на 21 день вони такі ж хороші, як програміст А), виконає 11,6 одиниць роботи за той же самий час 20-денний період. Протягом цього місяця програміст B досяг 58% ефективності порівняно з програмістом А. Однак у вас зараз є інший програміст, який знає цей модуль, як і перший.

Звичайно, у проекті пристойного розміру у вас може бути ... 50 модулів? Отже, ознайомлення з усіма ними займає близько 4 років, а це означає, що програміст, який навчається, працює в середньому на 58% ефективності порівняно з програмістом А ... хм.

Тому врахуйте цей сценарій: ті ж програмісти, той самий проект (A це все знає, а B нічого не знає.) Скажімо, що в році є 250 робочих днів. Припустимо, що навантаження розподіляється випадковим чином на 50 модулів. Якщо ми розділимо обох програмістів рівномірно, A і B отримують по 5 робочих днів на кожному модулі. А може виконати 5 одиниць роботи на кожному модулі, але B отримує, згідно з моїм маленьким моделюванням Excel, 1,4 одиниці роботи, виконаної на кожному модулі. Всього (A + B) - 6,4 одиниці роботи на модуль. Це тому, що B проводить більшу частину свого часу без будь-яких навичок за допомогою модуля, над яким вони працюють.

У цій ситуації оптимальніше зосередитись на Б меншій підмножині модулів. Якщо B зосереджується лише на 25 модулях, вони отримують 10 днів на кожен, що складає 3,8 одиниці роботи на кожному. Потім програміст А може витратити 7 днів кожен на 25 модулів, над якими B не працює, і 3 дні кожен працює над тими ж, що і B. Загальна продуктивність коливається від 6,8 до 7 одиниць на модуль, в середньому 6,9, і це значно вище ніж 6,4 одиниці на модуль, що ми зробили, коли A і B розподілили роботу рівномірно.

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

Навчання

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

Оптимальне рішення

Ось чому я думаю, що оптимальне рішення має базуватися на таких питаннях:

• Наскільки ваша команда? Чи є сенс, щоб усі проходили тренування на кожній частині, або якщо у нас є команда з 10 осіб, чи можемо ми просто переконатися, що кожен модуль знає щонайменше 3 людини? (Маючи 10 програмістів і 50 модулів, кожен програміст повинен знати 15 модулів, щоб отримати 3-кратне покриття.)
• Яким чином обіг вашого працівника? Якщо ви переводите працівників в середньому кожні 3 роки, і це займає більше часу, ніж це дійсно знає кожен куточок системи, то вони не будуть довгі, щоб навчання окупилося.
• Вам дійсно потрібен експерт для діагностики проблеми? Дуже багато людей використовують виправдання "що робити, якщо ця людина їде у відпустку", але мене не раз телефонували, щоб діагностувати проблему в системі, з якою у мене не було досвіду. Це може бути правдою, що досвідчена людина може знайти це набагато швидше, але це не означає, що ти не можеш прожити без них тиждень-два. Небагато програмних систем настільки критично важливі, що проблему доведеться діагностувати за 1 годину замість 5 годин, інакше світ закінчиться. Ви повинні зважити ці ризики.

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

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

Ви повинні кодувати як команда . Людям, природно, будуть розподілятися завдання та зосереджуватися на певних сферах, але обмін робочим навантаженням та спільна робота повинні заохочуватися, а не перешкоджати.

Це залежить від сфери проблеми.

Якщо це загальні речі (тобто прості дії CRUD тощо), то я згоден з Томом Сквайрсом (будь-хто повинен мати можливість над цим працювати та редагувати його).

Однак ...

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

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

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

Це зводиться до одного: дисципліни . Скільки одиноких програмістів ви знаєте, хто по-справжньому дисциплінований у своєму стилі кодування? Якщо ви не кодуєте дисципліну, ви приймаєте ярлики (тому що ви «виправите це пізніше»), і ремонтопридатність коду страждає. Ми всі знаємо, що "пізніше" ніколи не приходить. Факт : важче приймати ярлики, коли ви негайно підзвітні своїм колегам в команді. Чому? Тому що ваші рішення будуть поставлені під сумнів і виправдати ярлики завжди важче. Кінцевий результат? Ви створюєте кращий, більш підтримуваний код, який також є більш надійним.

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

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

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

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

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

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

Це не означає, що в команді з 50 розробників кожен повинен знати весь код, але команда з 5-7 повинна мати модуль, достатньо великий, щоб ті люди працювали. Жодна людина нічого не повинна володіти.

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

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

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

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

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

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

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

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

Причини, чому це погано:

• Якщо власник коду бере відпустку, і якась велика помилка вискакує в їхніх речах, буде дуже важко і забирати багато часу спробувати вивчити код І виправити помилку
• Якщо власник коду покине компанію, їхні проекти будуть суворо повернуті назад, оскільки вся спадщина та племінні знання просто вийшли за двері
• Документація погана. Якщо я єдина людина, кодована в ньому, навіщо я це документувати? Пов’язане питання полягає в тому, що будь-яка документація, яка буде вимушена створюватися, також, ймовірно, буде поганою, оскільки ніхто не буде знати про код, щоб дійсно сказати, чи документація повна або навіть точна.
• Священні війни можуть легко розпалитись, коли у кожного є своя маленька пісочниця, оскільки інші згадували про це, дуже швидко можна отримати дуже нерозумно. Де ця проблема полягає в тому, що двом людям доводиться працювати разом, і жоден не звик робити компроміси ні з чим.
• Через те, що навички роботи в команді ніколи не формуються - люди ніколи не повинні працювати з іншими.
• Fiefdoms легко утворюють маленькі королівства, виготовлені з кишень сміття, які нічого не купують у компанії. Ви не знаєте, що це відбувається, поки не пізно, тому що модуль чи інструмент X - це відповідальність Боба, і горе вам, хто навіть повинен запитати, що Боб робить у своєму коді.
• Огляди коду та експертні огляди страждають, оскільки про код ніхто нічого не знає. Якщо ви не знаєте коду, ви не можете помітити місця, які не відповідають правилу, і обмежуються лише коментуванням форматування тексту та іменними умовами.
• А якщо ви працюєте на мене ... компанія володіє кодом, а не ви. Ми маємо гордість за те, що ми робимо, і що ми робимо, і тим, що пишемо, але це групова справа, як, коли ваша команда виграє складний матч. Будь-який працівник, який працює в компанії, володіє кодом однаково, і під час виконання своєї роботи дозволяється редагувати його будь-яким способом, який він бажає виконувати свою роботу, яка полягає в тому, щоб передати цілі компанії.

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

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

• Виправити будь-який дефект у цій області
• Додайте незначні або помірні нові функції або вдосконалення

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

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

Див. Номер вантажівки aka Bus Busctor

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

"Попадання автобусом" може мати різні форми. Це може бути людина, яка приймає нову роботу, народжує дитину, змінює спосіб життя чи життєвий стан, або буквально потрапляє в автобус: ефект буде таким же ...

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

Недолік - важкий; "номер вантажівки" вашої команди в значній мірі стає 1.

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

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

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

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

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

Ціль не в тому, щоб ваша команда грала у «гру винних» або не приймала рахунків помилок (вони все одно не рівні). Засновуйте його на тому, хто останній перевірив код, або керівник повинен прийняти рішення та призначити його комусь, а не переглядати кожну частину кожного рядка коду.

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