Як бути програмістом з нульовою помилкою? [зачинено]

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

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

Не кодуйте взагалі.

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

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

Нульові помилки неможливі для нетривіальної програми.

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

Це програмне забезпечення без помилок. Це ідеально, так само досконало, як досягли люди. Розглянемо цю статистику: в останніх трьох версіях програми - кожна 420 000 рядків - мала лише одна помилка. В останніх 11 версіях цього програмного забезпечення було загалом 17 помилок.

Оновіть програмне забезпечення, щоб шаттл мав змогу орієнтуватися на супутники Global Positioning Satelites, що змінює лише 1,5% програми або 6,366 рядків коду. Технічні умови для однієї зміни містять 2500 сторінок, об'єм товщі, ніж телефонна книга. Технічні умови для поточної програми заповнюють 30 томів та містять 40 000 сторінок.

"Програміст з нульовими помилками" - це оксиморон, як тихий співак, але за останні 60 років програмування було створено кілька дистильованих шматочків мудрості, що зробить вас кращим програмістом, наприклад:

• Будь покірним - ти є і будеш робити помилки. Неодноразово.
• Будьте в курсі обмеженого розміру черепа. Підійдіть до завдання з повним смиренням і уникайте розумних хитрощів, як чума. [Edsger Dijkstra]
• Боротьба з комбінаторним вибухом
• Позбудьтеся стану, що змінюється (де це можливо). Так, вивчіть функціональне програмування.
• Зменшити кількість можливих кодових шляхів
• Зрозумійте (величину) розмір вхідних та вихідних просторів (ваших функцій) та спробуйте зменшити їх, щоб наблизитися до 100% тестового покриття
• Завжди вважайте, що ваш код не працює - доведіть це інакше!

TDD

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

Підхід TDD дає щонайменше дві переваги.

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

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

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

Я вважаю, що команди розробників, які добре вживаються в TDD, доставляють код з найменшими дефектами.

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

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

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

• Це непросто. Ви не покращитесь за ніч. Тож не відволікайтесь і не здайтеся.
• Пишіть менше і пишіть розумніші. Менше коду, як правило, кращий код. Закономірно планувати заздалегідь і намагатися робити дивовижні дизайнерські зразки, але в кінцевому рахунку просто написання того, що вам потрібно, економить час і запобігає появі помилок.
• Складність - ворог. Менше не рахується, якщо це незрозумілий складний безлад. Код гольфу - це весело, але це зрозуміло пекло, і це ще гірше пекло. Щоразу, коли ви пишете складний код, ви відкриваєте себе перед світом проблем. Зберігайте речі простими та короткими.
• Складність суб'єктивна. Код, який колись був складним, стає простим, як тільки ви стаєте кращим програмістом.
• Досвід має значення. Один із двох способів стати кращим програмістом - це практикувати. Практика НЕ ​​пишіть програми, які ви вмієте писати легко, це написання програм, які трохи шкодять і змушують задуматися.
• Інший спосіб оздоровитись - читати. У програмуванні є багато важких тем, які потрібно вивчити, але ви ніколи не зможете їх вивчити просто програмуванням, вам потрібно вивчити їх. Вам потрібно прочитати важкі речі. Такі речі, як безпека і одночасність, неможливі, це правильно вчитися з просто написання коду, якщо ви не хочете вчитися, очищаючи катастрофи. Якщо ви не вірите, я подивіться на епічні проблеми безпеки, як-от у гаукера. Якби вони зайняли час, щоб навчитися правильно робити безпеку, а не просто зробити щось, що спрацювало, що безлад ніколи не трапився б.
• Читайте блоги. Є багато цікавих блогів там, які дадуть вам нові цікаві способи подивитися і подумати про програмування, це допоможе вам ...
• Дізнайтеся брудні деталі. Невеликі деталі того, як працюють незрозумілі частини вашої мови та додатків, є дуже важливими. Вони можуть зберігати секрети, які допоможуть вам не писати складний код, або можуть бути частинами, у яких є власні помилки, яких вам потрібно уникати.
• Дізнайтеся, як думають користувачі. Іноді ваші користувачі збиваються з розуму і працюватимуть із вашим додатком так, як ви не розумієте і не можете передбачити. Вам потрібно ввійти в голову достатньо, щоб знати незнайомі речі, які вони можуть спробувати, і переконатися, що ваш додаток може це впоратися.

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

• Розробники смокчуть тестування. Це правда, і ти це знаєш. (Я розробник!) Хороша команда з питань якості завжди знайде ті кращі випадки, про які розробники ніколи не замислюються.
• Розробники добре кодують. Нехай вони повернуться до того, чим вони найкращі (і, як правило, те, що вони воліють робити в будь-якому випадку.)
• Команда QA може знайти помилки, пов’язані з декількома завданнями розробника за один прохід.

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

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

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

Надзвичайно важко досягти коду без помилок у середовищі основного кодування (Java, C #, PHP тощо). Я б зосередився на створенні добре перевіреного та рецензованого коду в коротко контрольованих ітераціях.

Збереження коду максимально просто допоможе вам уникнути помилок.

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

Усі "Не кодуйте взагалі". відповіді повністю не вистачають суті. Крім того, ваш начальник точно не здається дебілом!

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

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

Ваш начальник цілком правильно каже, що ви повинні розуміти результати та вплив коду, який ви пишете на існуючу систему. Чи виникнуть помилки? Так, звісно. Але ці помилки будуть пов’язані з вашим неповним розумінням системи / інструментів, з якими ви працюєте, і з кожним виправленням помилок ви матимете краще покриття.

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

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

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

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

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

Або не пишіть нічого складнішого, ніж "Hello World!" або якщо ви скажете всім ніколи його не використовувати.

Попросіть у свого начальника кілька прикладів цього так званого коду без помилок.

Я погоджуюся з іншими. Ось як я підійшов би до проблеми

• Отримайте тестер. Перегляньте тест Джоела.
• Широко використовувати бібліотеки; ймовірно, це було налагоджено краще. Я великий фанат CPAN для Perl.

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

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

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

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

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

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

Помилки неприйнятні, і я зроблю все, що в силах, щоб їх усунути.

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

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

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

• Використовуйте офіційні характеристики своїх вимог. Формально, як при використанні Z або VDM або деяких інших математично обгрунтованих позначень.

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

• Створіть великі набори, регресії та системні тестові набори та джгути, щоб перевірити будь-який шлях на помилки. (І цього само по собі недостатньо.)

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

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

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

Ось етапи створення безкоштовної програми про помилки:

1. Ніколи не починайте кодування, якщо у вас не є НЕВІДОМНІ СПЕЦИФІКАЦІЇ на свою функціональність.
2. НЕ ТЕСТУЙТЕ, або якщо ви цього не робите, НЕ ПОВЕРНУЙТЕ НА ТЕСТУВАННЯ, щоб виявити дефекти програмного забезпечення.
3. Застосуйте всі FEEDBACK від дефектів, виявлених під час тестування, оглядів та виробництва, до процесу та розробникам, які вставили дефект на перше місце. Як тільки виявлені дефекти, повністю відмовтесь від усіх несправних компонентів. Оновіть свої контрольні списки та перекваліфікуйте розробників, щоб вони більше не робили подібних помилок.

Тестування може лише довести, що у вас є помилки, але доводити інше зазвичай марно. Що стосується зворотного зв'язку - якщо у вас є машина для виготовлення монет, яка робить монети, і кожна монета в 10 секунд має середній дефект. Ви можете взяти цю монету, розрівняти її і знову вставити в машину. монета, яка зробила, що перероблена заготовка буде не такою хорошою, але, можливо, прийнятною. кожну монету за 100 років доведеться переклеювати 2 рази тощо. Чи легше було б виправити машину?

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

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

Програма оборонно: http://en.wikipedia.org/wiki/Defences_programming

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

Чи може це бути наслідком нерозуміння належної методології, а не просто загальної кістковості?

Що я маю на увазі, що можливо, що ваш начальник почув "методологію нульових дефектів" (див. Розділ №5) і не переймався розумінням того, що це означає?
Звичайно, керівництву незручно відкладати розробку нових функцій на користь помилок, які ти не повинен був би вставити ...
І, звичайно, це загрожує його бонусом, тому, звичайно, ти не отримаєш цього, бо "хороші програмісти не є помилки "...

Добре робити помилки, якщо ви зможете їх знайти та виправити (звичайно, в межах розуму).

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

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

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

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

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

Клопи неминучі так само, як і людська природа помиляються.

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

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

Я думаю, ви можете писати програми без помилок, але це, як правило, програми, які ви написали вже 10 або 12 разів. У 13-й раз ви пишете ту саму програму з нуля, ви вже знаєте, як це зробити: ви знаєте проблему, знаєте методи, ви знаєте бібліотеки, мову ... це ви бачите в своєму розумі. Усі зразки є на всіх рівнях.

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

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

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

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

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

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

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

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

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

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

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

Але якщо ви маєте на увазі: "нульові помилки за доставленим кодом" -> це можливо, і я працював у таких умовах.

Все, що вам потрібно, це: шалено висока якість коду та майже 100% тестовий покрив (одиничні тести + приймальні тести + інтеграційні тести).

На мій погляд, найкраща книга, яку слід вивчити, це: GOOS . Але звичайно книги недостатньо. Вам потрібно зайти до якоїсь групи користувачів і обговорити з цього приводу. Курси, конференції та ін. Якість нульових помилок непроста.

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

Рішення програміста:

• Зупиніть програмування.
• Побудуйте механічний комп'ютер.
• Замінюйте його кожні 5 років, щоб механічне носіння не прийшло в дію.

Рішення користувача:

• Перестаньте використовувати комп’ютери.
• Робіть все вручну.
• Завжди майте другу людину двічі перевірити результати.

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

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