Це має бути розумним поєднанням усіх відповідей поки що. Зрештою, коли ви говорите про групу розумних людей (розробників), ви повинні їм пояснити, чому поведінка важлива, і надати їм достатній контроль над тим , як реалізується така поведінка, що вони вкладаються в те, щоб зробити це правильно. Мандати зверху, як правило, розкуті з розумними людьми, тому що якщо вони не погодилися, що проблема є проблемою, вони, швидше за все, витратять більше часу, працюючи навколо мандату, ніж дотримуючись правила.
Ось кілька моїх тактик:
Здійснення змін:
По-перше, команді потрібно погодитись, коли взяти на себе зобов’язання та що робити. Абсолютно важливим є налаштування побудови, яке має сенс, щоб люди не трималися лише тому, що не знають, куди щось поставити. І консенсус щодо того, коли / як часто зареєструватися. "Не порушуйте складання" - це очевидно хороше правило, але як це перевіряється, і хто про це повідомляє? Інший базовий рівень - "це не робиться, якщо він не зареєстрований".
Більшість розробників, яких я знаю, більш ніж раді перевірити код ЯКЩО:
- Процес реєстрації простий
- Процес синхронізації простий (враховуючи зміни від інших розробників)
- Побачити зміни та переходити між версіями легко
Одне, що я нещодавно помітив, - це те, що чеки стали частішими та менш болючими, коли ми скакали вперед до нового інструменту CM. Наша команда є піонерським концертом Раціональної команди, який раніше використовував Clearcase. Я не маю на увазі рекламувати інструменти, але нова (для мене) хвиля потокових чеків з великою кількістю маленьких, швидких злить робить її більш привабливою для перевірки рано і часто.
Якщо розробники нестимуть відповідальність за усунення болю від КМ, зазвичай збільшується кількість перевірки.
Дотримання архітектури - не запитання проблем з моделями в представленнях та контролерах
Я кажу про це в загальній групі "зробіть архітектуру правильно". Я погоджуюся з тим, хто сказав експертні огляди - тиск з боку однолітків відмінно підходить для цього. Один із способів я, як правило, бачу, як люди вступають у кращі кращі практики в цій галузі, коли їхні ровесники запитують їх, чому вони зробили це іншим способом (не дуже правильним способом). Взагалі питання "чому" призведе людей до того, щоб зрозуміти для себе, чому вони повинні були зробити це по-іншому. Коли люди добре розуміють причину найкращої практики, дотримуватися її набагато простіше.
Крім того, якщо існує якась формальність, яка пов’язує людину з рішенням, то призначати помилки в цій області може бути простіше ... тож якщо людина несе відповідальність за виправлення помилок у зоні несправного дизайну, потрібно щось передбачити правильно вони можуть перейти до чогось нового і захоплюючого, можуть стати великим мотиватором.
Уникайте жорсткого кодування
Я б почав із чітких стандартів кодування та інтеграції огляду стандарту кодування в експертні огляди. Жорстке кодування - це одна з тих речей, яка легко може бути галочкою для порядку денного експертної оцінки.
Я боюся, що така річ - це одне, де я бачив, як це стає роллю команди, яка веде за собою виконання цього правила. У командах, якими я керував, ми, як правило, не дозволяємо комусь рухатися далі, поки вони не виправлять коментарі з експертної оцінки коду. І "відсутність жорсткого кодування" є частим коментарем експертного огляду.
В загальному
Маючи майже будь-яку найкращу практику, я думаю, що вам доведеться вибирати свої битви. Жодна команда не стане абсолютно досконалою. Але ви можете стежити за своїми основними больовими точками і почати вирішувати їх у скупченнях. Я думаю, що роль ведучого стає реально знати, що є больовим моментом для команди проти прикрої химерності конкретної людини.
Якщо вашій команді не вистачає конкретних найкращих практик, я думаю, що першим питанням має бути "скільки шкоди це завдає?" якщо відповідь "мінімальна", то, мабуть, часу не варто. Деякі найкращі практики є найбільш актуальними для конкретних типів систем - хоча вони в цілому хороші, вони, можливо, не вартують битви за системи, де ця практика не є частою появою чи основною частиною системи.
Якщо відповідь на "скільки дамби?" "АЛЕ !!!", тоді ви можете почати створювати випадок, щоб показати команді, що весь цей біль і страждання можна усунути, виправивши цю красну точку в кращих практиках. Більшість людей із задоволенням уникають болю і страждань, і це змінює діалог з "роби це, тому що я тобі сказав", на "ми вирішили це зробити, тому що це краще".