Чому програмне забезпечення все ще випускається з відомими помилками? [зачинено]

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

Чому? Чому проект з відкритим кодом або проект взагалі випускається з відомими помилками? Чому б вони не чекали, поки у трекера помилок з'явиться 0 відкритих помилок?

Будь-яка кількість причин, включаючи:

1. Компанія взяла на себе зобов’язання базу користувачів випустити в певний час
2. Помилки не були критично важливими для місії, а то й великими
3. Розробка нової функції розглядалася як важливіша (правильно чи ні)

Малою мірою це як запитання, чому ви працюєте програмістом, хоча ваші знання з програмування не "повні". У більшості складних проектів буде багато-багато помилок. Робота з ними під час додавання нових функцій - це складне, складне завдання.

Тому що програмне забезпечення з помилкою краще, ніж програмне забезпечення взагалі.
З тієї ж причини:

• Транспортні компанії заважають складати графіки, хоча завжди є затримка.
• Фармацевтичні компанії продають ліки з відомими (і в основному документально підтвердженими) побічними ефектами.
• Школи у всьому світі викладають фізику Ньютона, хоча вона має відомі обмеження.

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

Або сказати це словами Вольтера: "Le mieux est l'ennemi du bien".

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

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

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

Майте на увазі, що програмний продукт, який не випускається, ні для кого не має значення. Програмний продукт, у якого 200 неполадок, але 90% його функціональності працює, має значення для всіх людей, які задоволені тим, що працює на момент випуску.

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

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

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

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

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

Потенційні відповіді:

• Навряд чи хтось зіткнеться з помилкою.
• Існують обхідні проблеми для помилок.
• Програмне забезпечення потрібно випустити колись, і досконалості навряд чи вдасться досягти.

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

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

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

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

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

У найпростішому програмному тесті:

if (management->perceived_cost_to_fix > management->perceived_benefit_release_now) {
    release;
}

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

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