Спілкуючись із розробником, постійно ігноруючи крайові випадки у своїй роботі

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

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

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

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

Деякі відомості:

1. Щоб він не відчував себе відокремленим, це потрібно створити для всієї вашої команди. Потрібно від усіх написати автоматизовані тести на одиницю для нового коду чи коду, які вони модифікують.
2. Потрібно, щоб назви одиничних тестів були описовими щодо випадку, який вони перевіряють.
3. Покрийте тести автоматизованих одиниць у огляді коду на високому рівні. Нехай рецензенти шукають пропущені тестові справи (тобто ті крайові випадки, які він постійно пропускає). Після деякої кількості відгуків від його команди про пропущені крайові справи, він, ймовірно, навчиться розглядати їх перед оглядом.
4. Застосовуйте це правило для всієї команди: Якщо QA виявляє помилку, відповідальний розробник зобов'язаний автоматизованому тестуванню, який підтверджує збій, а потім доводить, що вони його виправили. (перш ніж робити будь-яку іншу роботу)

Дайте йому контрольний список, наприклад

• нульові входи
• входи в надзвичайно великому кінці діапазону
• входи в крайньому малому кінці діапазону
• комбінації
• входи, що порушують припущені інваріанти (наприклад, якщо x = y)

Люди з питань якості можуть допомогти розробити контрольний список

Надайте контрольний список усім розробникам, а не лише цьому.

Хороший інженер.

Гаразд.

Але з ним є проблема - дуже часто він не вдається розглянути крайові випадки у своєму коді.

Це якість, яку хороші інженери не поділяють.

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

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

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

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

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

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

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

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

Існує нескінченна кількість крайових справ, покриття їх усіх нездійсненно. Що робити, якщо хтось робить #define TRUE FALSE? Це додає крайові корпуси, чи ви їх також перевірите?

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

Я вибрав підхід для коду, який повинен бути дуже міцним і стабільним:

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

Таким чином ви отримуєте міцні демпінгові програми в QA, а до моменту виходу до програми додаток є надійним та безпечним.

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

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

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

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

Захоплення крайових випадків є причиною QA. Програмісти несуть відповідальність за своєчасну роботу. Витрачати весь свій час на пошуки крайових справ дуже неефективно. Якщо у вас досить швидкий ітераційний цикл, то це взагалі не повинно бути проблемою. Корпусні кромки близькі до нескінченної кількості. Якби це була проблема з "основними" випадками, я б трохи хвилювався. Так само, як розробники знають розробників, тестер повинен бути експертом у тестуванні. Коли тестер виявить проблему, вони надсилають її назад до розробки. Розробник виправляє проблему. Проблема вирішена. Час, щоб розробник відстежував кожен крайній випадок, значно довший, ніж повинен тривати цикл ітеративного тестування. Також зверніть увагу, коли я говорю про тестування, я маю на увазі не тести білого блоку, а строго чорні тести.

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