Чи потрібно виправити наявні дефекти, працюючи над чимось іншим?

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

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

Спасибі, Корі

Я працюю над дуже маленькою командою, тож це наче залежить від того, які зміни:

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

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

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

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

РЕДАКТУВАННЯ: Вам також потрібно спостерігати за часом на проекті. Очевидно, що в жорсткі терміни вам потрібно зосередитись на виконанні основної роботи, але якщо ви просто під «нормальним навантаженням», то я думаю, що невелике прибирання тут і там робить усіх щасливішими в довгостроковій перспективі.

Як завжди, це залежить.

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

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

Прагматичний програміст називає це "Зламані Windows".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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