Що ви вважаєте основною причиною дефектів програмного забезпечення (і як їх мінімізувати) [закрито]

Я визначаю дефект як:

"щось в рамках програми або коду, що заважає функціонувати відповідно до вимог."

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

Основна причина дефектів програмного забезпечення - інтерпретація.

Інтерпретація функції замовника відрізняється від дизайнерської інтерпретації.

Дизайнерська інтерпретація відрізняється від інтерпретації програміста.

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

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

Основною причиною дефектів програмного забезпечення я вважаю програмістів.

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

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

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

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

Основна причина дефектів - це погане управління ;)

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

Також управління наймом поганих розробників також допомагає збільшити кількість помилок.

Погане управління .

(відмова від відповідальності: я повинен наймати розробників та керувати ними)

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

Більшість практик розробки, які я вивчаю, зводяться до скорочення N, оскільки складність програми є принаймні O(N^2)та можливою O(k^N). Визначення Nзалишається читачем як вправа, але я думаю про такі речі, як цикломатична складність. Інкапсуляція логіки та даних призводить до зменшення N шляхом розподілу проблеми.

Нездатність думати про все.

Будучи неповноцінним

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

Соціальний етикет. Соціально неприйнятним називати когось недієздатним.

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

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

Errare humanum est

Графік тиску є, безумовно, сильним джерелом.

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

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

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

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

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

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

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

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

Основною причиною дефектів програмного забезпечення є написання коду.

Напишіть менше коду, і у вас буде менше помилок ;-)

На одному рівні управління. Але це не лише ПХБ. Це управління самим кодом, яке може бути, а може і не бути відображенням корпоративного управління.

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