Покращення огляду коду та практики тестування одиниць

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

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

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

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

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

Або вони просто намагаються відкинути ідею цим виправданням?

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

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

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

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

Ключовим для перегляду коду є те, що ви хочете переглянути якомога менше коду, як можна швидше. Таким чином легше отримати час на його перегляд, код свіжий у свідомості людей, і впровадити запропоновані вдосконалення буде простіше. В крайньому випадку, ви хочете переглянути кожен заїзд. Хороший інструмент для автоматизації цього - http://code.google.com/appengine/articles/rietveld.html . Це варіант інструменту, який Google використовує внутрішньо, щоб змусити перевірку коду відбуватися при кожному заїзді.

Проблема перегляду коду була описана десятиліттями тому в класиці «Психологія комп’ютерного програмування» . Проблема полягає в тому, що програмісти, як правило, прив'язують своє зображення до своїх навичок програмування. Що означає, що програмісти будь-коли стикаються з доказами того, що їхні навички не піддаються нюху, є тенденція сприймати це особисто. Це може спричинити серйозні конфлікти. Якщо ви підберете класичний швидкий розвиток Стіва МакКоннелла, він пропонує ряд пропозицій щодо налаштування процесу перегляду коду, який зменшує шанси такого конфлікту. (Ключовим елементом є переконання, що керівництво ніколи не бере участі в процесі.) Зауважте, що це зменшує шанси конфлікту, але не запобігає конфлікту.

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

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

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

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

Впроваджувати tdd проти волі розробників дуже складно. Це важкий спосіб навчитися любити tdd.

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

Ця розробка tdd є гарною відправною точкою для перегляду коду. Обговоріть, як tdd вплинув на архітектуру програми та як полегшує управління програмним забезпеченням.