По суті, ні, але ви все одно повинні робити все можливе. Я поясню, чому (або просто перейти до висновку, якщо у вас недостатньо терпіння)
Розглянемо проблему, як тривіальну, як реалізацію бінарного пошуку. Одна дуже популярна реалізація мала помилку, яка виявилася непоміченою протягом приблизно двох десятиліть. Якщо двадцять рядків потребують двадцяти років, щоб широко не використовувати помилок і навіть нібито доведено їх правильність, чи можна насправді очікувати, що величезна програма буде відсутня?
Скільки помилок ми можемо очікувати у величезній програмі? Я знайшов одне число «10 дефектів на 1000 рядків» (Code Complete 2nd edition, стор. 517 - просто використано приклад, не цитуючи жодних даних). Це дає нам близько 200 000 до 300 000 помилок у вашому програмному забезпеченні. На щастя, у нас є способи покращити якість програми. Як відомо, одиничне тестування, огляд коду та звичайне ручне тестування дозволяють зменшити кількість помилок. І все-таки кількість все ще буде високою.
Якби ми могли вирішити 95% всіх помилок, це було б неймовірно. І все ж у нас все ще буде від 10 000 до 15 000 помилок у програмному забезпеченні.
На щастя, оскільки програмне забезпечення широко використовується (і, отже, широко перевірене) помилки збираються. Так ми поступово отримаємо менше помилок. Однак менше помилок також означає, що решти їх важче знайти - тому не чекайте лінійної кривої у виправлення помилок. Останні кілька помилок буде дуже складно знайти і можуть уникнути виявлення протягом декількох років (якщо припустити, що вони коли-небудь знайдені).
Ви також, здається, помилково припускаєте, що якщо програмне забезпечення не зміниться, нові помилки не з’являться. Якщо програмне забезпечення залежить від сторонніх бібліотек, нові версії можуть порушити деякі функції - введення нових помилок, хоча код програми все-таки той самий. Нові операційні системи також можуть зламати додаток, який раніше працював ідеально (популярний приклад див. У Windows Vista). Розглянемо також помилки компілятора тощо.
Незрозуміло, чи справді інструменти для підтвердження коду можуть вирішити проблему програмного забезпечення. Звичайно, неможливо вирішити проблему зупинки для будь-якої програми, але можна довести, що програма веде себе як зазначено ... Але що тоді? Можливо, у програмі підтвердження є помилка. Можливо, у самій специфікації є помилка.
Очевидно, що ми можемо значно зменшити кількість помилок, але насправді навряд чи ми досягнемо нуля.
Тому що існує думка, що кожне виправлення, яке ви робите, створює більше помилок, але я не думаю, що це правда.
(наголос додано)
Ви праві. Це твердження неправильне. Ось приклад:
int main() {
int x[10];
x[10] = 8; //Buffer overflow here
return 0;
}
Тепер давайте виправити цю помилку:
int main() {
int x[11];
x[10] = 8; //No buffer overflow here
return 0;
}
Побачити? Ми виправили помилку і не ввели нових.
Однак, безумовно, правильно, що кожного разу, коли ви виправляєте помилку, ви ризикуєте створити нову, хоча цей ризик можна зменшити (наприклад, за допомогою тестування одиниць).
Скажімо, що на кожні 100 помилок, які я виправляю, я випадково ввожу новий. Тому якщо я виправляю 10 000 помилок, я ввожу 100 нових помилок. І якщо я виправляю ці нові помилки, я ввожу одну помилку. Але так що? Зараз у програмі на 9 999 менше помилок, тож це, мабуть, краще, ніж це було (якщо припустити, що ця помилка не в 10 000 разів гірша за попередню).
Також виправлення помилки може викрити нові. Але ці помилки також можна виправити. Якщо ви все зробите правильно, з часом програмне забезпечення буде в кращому стані, ніж було запущено.
Я був старшим кількома топ-програмістами, що краще не виправляти багато помилок через поняття, яке я згадував в ОП.
Така поведінка є недбалою. Якщо є помилка, і ви можете її виправити. Зроби це. Звичайно, ви повинні зробити все можливе, щоб запобігти додаванню нових, але якщо я введу одну маленьку помилку на кожні 10 серйозних помилок, які я виправляю, це не є вагомою причиною припинення виправлення помилок. Насправді це вагома причина продовжувати виправляти помилки .
Так менше помилок виправляєте, тим менше помилок повернеться до вас у майбутньому
Чим менше помилок виправите, тим більше помилок залишиться у вашому програмному забезпеченні, дратуючи користувачів. Дійсно, вони не "повернуться до вас у майбутньому". Вони не повернуться, тому що ніколи не виїжджали в першу чергу. Поняття "повернутися" пов'язане з регресіями. Знову ж таки, можна зменшити ризик регресії.
Деякі помилки неможливо виправити, оскільки вони стали настільки широко використовуватися, що люди почали залежати від них, і виправлення помилки порушить програму для цих користувачів. Це буває. Однак чи дійсно їх можна вважати помилками в такому випадку?
Менталітет "виправити помилку, зробіть помилку" може бути пов'язаний з тим жахливим монстром - кодом, який є настільки нечитабельним і нездійсненним, що лише торкаючись його створює помилки. Якщо у вашій кодовій базі є монстр, вам, можливо, потрібно спочатку зняти монстеризацію, перш ніж щось робити.
Нарешті, якщо ви грізний програміст, є ризик, що все, що ви торкаєтесь, створить нові помилки. Це, очевидно, нервує старших програмістів. Однак, кажучи: "Не робіть нічого. Не чіпайте нічого. Навіть не дихайте". мабуть, не правильний спосіб створити здорове робоче середовище. Освіта краща.
Висновок:
- Програмне забезпечення, яке постійно отримує багато нових функцій, але жодних виправлень помилок неминуче не витягне.
- Програмне забезпечення, яке отримує помірну кількість нових функцій, але виправляє помилки, має більше шансів на користь.
- Ті, хто намагається мати кілька помилок, мають (в середньому) менше помилок, ніж ті, кому це все одно.
- Нерозумно сподіватися на те, що програма врешті-решт стане вільною від помилок.
- Старші програмісти не обов'язково компетентні.
- Виправте ваші помилки.
- Прийняти методики, які покращують якість вашого програмного забезпечення.