Як боротися з різними стилями програмування в команді?

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

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

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

Що ми зробили:

Дослідження стандартів кодування

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

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

Створення власних стандартів кодування

Звичайно застосовувати стандарти кодування іншого проекту до нашого проекту, оскільки це не має сенсу. Ми використовуємо документ Zend Framework як шаблон:

• Спочатку ми видалили все, що не стосувалося нашого проекту
• Тоді ми змінили все, що сприймали як питання стилю до нашого стилю
• І нарешті ми все записали

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

Бути вірним нашій обіцянці

Наша кодова база на той час становила близько 1 * 10 ^ 6 прогалин. Ми знали, що, оскільки ми прийняли формальні стандарти кодування, нам довелося почати рефакторинг нашого коду, але в той час на нас наштовхувались інші проблеми. Тож ми вирішили просто переробити наші основні бібліотеки, лише 5 * 10 ^ 3 прогалини.

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

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

Справа з новим хлопцем

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

Оскільки я був майстром стандартів кодування в той час, я повинен був оцінити його внесок і переглянути документ відповідно. Його пропозиціями були:

• Питання особистого стилю
• Стандарти, які мали сенс для його Java-фону, але не так сильно з PHP (відхилено)
• Конвенції, які він проводив із свого короткого опромінення з PHP (деякі були відхилені, але багато виявилися популярними умовами, про які ми ніколи не замислювались та не з'ясували в своїх початкових дослідженнях)

Наступні кілька тижнів перед ним було поставлено просте завдання: привести декілька частин нашої кодової бази у відповідність із стандартами. Мені потрібно було ретельно вибирати ті частини, виходячи з кількох правил:

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

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

А потім приїхав ще один новий хлопець. Ми повторили процес (цього разу різні майстри), і він знову працював. І знову.

На закінчення

1. Створіть документ зі стандартами кодування, але переконайтесь, що ваші стандарти не є виключно власними, але відображають загальні стандарти у широкій спільноті вашої платформи.
2. Визначте аналогічну роль нашому майстру стандартів кодування. Хтось моніторить принаймні новий код, а особливо новий код від нових членів. Переробити роль, як це надзвичайно нудно.
3. Завжди оцінюйте внесок нового члена. Завжди переглядайте свої стандарти, якщо це має сенс. Ваш документ із стандартами кодування повинен розвиватися, але повільно. Ви не хочете повторно рефакторировать свою кодову базу під час кожної ітерації.
4. Дозвольте на деякий час кожному новому члену дізнатися та адаптуватися до ваших стандартів та конвенцій. Вчіться, роблячи найкращі роботи в цих ситуаціях.
5. Wiki творить чудеса для таких документів.
6. Код оглядів творить чудеса для будь-якої ситуації!

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

• Автоматичне форматування коду SVN при реєстрації?
• Контроль версій та форматування кодування
• PHP codeniffer (phpcs) - як дозволити переосмислення при використанні у складі svn попереднього фіксації гачка?
• SVN попередньо здійснити гак, який повинен спрацьовувати для певної папки
• Реалізація стандартів кодування PHP

Деякі стосуються PHP, але відповіді стосуються всіх платформ.

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

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

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

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

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

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

1. Хтось відповідає - їм потрібно діяти так.
2. Якщо стиль кодування настільки важливий, чому цього не пояснили цій людині, і дайте їм знати, що вони не матимуть доступу до будь-якого коду, поки вони не вивчать правила.
3. Перегляд коду - мабуть, у вас його немає або він дуже слабкий. Див. №1.

Зробіть на замітку в процесі найму, що дотримання прийнятих стилів кодування є обов'язковою умовою роботи. Тепер що ви робите тим, хто не дотримується правил? Почніть з видалення доступу до прямого коду, поки не отримаєте програму.

.

Ось що можна зробити:

1. Напишіть документ, який пояснить необхідний стиль кодування і змусить усіх у команді вивчити його. Зберіть інформацію від кожного члена команди.
2. розділити завдання таким чином, щоб кожен член команди відповідав за свій власний фрагмент, і міг вирішувати конвенції цієї частини коду. Якщо будь-які проблеми знайдеться, той, хто це написав, вирішить проблеми.
3. додати автоматичний інструмент до контролю версій, який фіксує відступ та інші речі кожного разу, коли код буде введений до контролю версій
4. Різні програмісти завжди мають різний стиль програмування, і пізніше це може бути важко змінити. Найкращий спосіб впоратися з ним - це обмін інформацією між членами команди, щоб усі дізналися, якими стилями користувалися люди. Якщо у вас є член команди, який пише інший код, це шанс для ваших існуючих членів команди дізнатися новий стиль.
5. Один хороший трюк - ніколи не змінювати існуючий код. Замість зміни коду напишіть новий код, замінивши порожні рядки новим кодом. І як тільки код буде готовий, зробіть лише найменшу кількість змін у існуючій системі, щоб прийняти новий код у користування. Це дозволяє уникнути налаштування існуючого коду, можливо, порушити те, що вже працювало нормально.

Ось чого слід уникати:

1. вирішивши, що чийсь код кращий чи гірший, ніж інші члени команди. Це просто не працює так - всі знають певний підмножина мови досить добре, щоб використовувати її в коді. Кожен програміст обрав інший підмножина для навчання, і якщо вони не засвоїли це разом, це буде виглядати інакше.
2. Зміна того, як хтось пише код. Все, що ви отримуєте, змушуючи людей писати незнайомий стиль, - це те, що ви отримуєте велику кількість помилок у коді. Люди просто не знають достатньо деталей того, що вони використовують вперше. Програмісти завжди вибирають підмножину мови та використовують її окремо. Якщо ваші програмісти написали тисячі рядків коду, який заповнений gotos, то gotos передасть вам код, у якому є найменша кількість помилок.
3. Ви також не повинні думати, що ваша наявна база коду - це приємні, чисті, ремонтопридатні речі. Завжди є що покращити. Але також кожна зміна розмиває оригінальну ідею дизайну, яка була написана до неї. Намагайтеся писати ідеальний код з першого разу, щоб зміни не потрібні були пізніше. (новому хлопцеві не потрібно було б "зламати" ваш ідеальний код, якщо це було зроблено правильно з першого разу)

Наша існуюча база коду містить здебільшого читабельний, чистий та доступний код

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

При цьому новий хлопець повинен відповідати вашим стандартам, а не навпаки.

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

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

Інтернет-системи vcs, такі як bitbucket або github, підтримують цю функціональність. Якщо ви віддаєте перевагу приміщенному підходу, схожість здається найкращою ставкою на даний момент.

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

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

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

А з іншого боку, є стандарти якості. Ніколи не приймайте код, який не відповідає вашим стандартам якості.