Как быть программистом без ошибок? [закрыто]

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

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

Не кодируйте вообще.

Это единственный способ, которым вы можете быть программистом без ошибок.

Ошибки неизбежны, потому что программисты - люди, и все, что мы можем сделать, это сделать все возможное, чтобы предотвратить их, быстро реагировать на ошибки, учиться на наших ошибках и оставаться в курсе.

Нулевые ошибки невозможны для нетривиальной программы.

Можно подойти очень близко, но производительность страдает. И это стоит только для определенного программного обеспечения с высоким риском. Программное обеспечение Space Shuttle приходит мне в голову. Но их производительность составляет порядка нескольких строк в день. Я сомневаюсь, что твой босс хочет этого.

Это программное обеспечение не содержит ошибок. Он совершенен, настолько совершенен, насколько достигли люди. Посмотрите на эту статистику: последние три версии программы - каждая длиной 420 000 строк - имели только одну ошибку в каждой. Последние 11 версий этого программного обеспечения имели в общей сложности 17 ошибок.

Возьмите обновление программного обеспечения, чтобы позволить шаттлу перемещаться с помощью спутников глобального позиционирования, изменение, которое затрагивает всего 1,5% программы или 6 366 строк кода. Спецификации для этого изменения составляют 2500 страниц, объем которых больше, чем у телефонной книги. Спецификации для текущей программы заполняют 30 томов и занимают 40000 страниц.

«Программист с нулевыми ошибками» - это оксюморон, как молчаливый певец, но за последние 60 с лишним лет программирования появилось несколько искаженных кусочков мудрости, которые сделают вас лучшим программистом, например:

• Будь скромным - ты и будешь делать ошибки. Несколько раз.
• Будьте полностью осведомлены об ограниченном размере вашего черепа. Подходите к задаче с полным смирением и избегайте хитрых уловок, таких как чума. [Эдсгер Дейкстра]
• Бой комбинаторный взрыв
• Избавьтесь от изменчивого состояния (где только возможно). Да, учиться функциональному программированию.
• Уменьшить количество возможных путей кода
• Поймите (величину) размера входных и выходных пространств (ваших функций) и постарайтесь уменьшить их, чтобы приблизиться к 100% охвату теста
• Всегда предполагайте, что ваш код не работает - докажите это иначе!

TDD

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

Подход TDD дает как минимум два преимущества.

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

Это не доказывает ноль ошибок, поскольку это было бы невозможно (на это уже указывали бесчисленные другие ответы). Но после того, как я выучил TDD и стал хорошим (да, это тоже навык, требующий практики), я стал гораздо увереннее в своем собственном коде, потому что он тщательно протестирован. И что еще более важно, я могу изменить существующий код, который не понимаю полностью, не беспокоясь о нарушении функциональности.

Но TDD не поможет вам полностью. Вы не можете написать безошибочный код, если вы не полностью понимаете архитектуру системы и подводные камни этой архитектуры. Например, если вы пишете веб-приложение, которое обрабатывает несколько запросов одновременно, вы должны знать, что вы не можете совместно использовать изменяемые данные между несколькими запросами (не попадите в ловушку новичка для кэширования изменяемых данных для повышения производительности).

Я считаю, что команды разработчиков, которые хорошо разбираются в TDD, предоставляют код с наименьшим количеством дефектов.

Дело в том, что ошибки - это то, что вы не узнаете. Если вы не обладаете какими-то энциклопедическими знаниями о языке программирования / компиляторе, а также обо всех средах, в которых будет работать ваше приложение, вы действительно не можете ожидать, что код будет на 100% без ошибок.

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

Да, в вашем коде никогда не может быть ошибки, но не может быть и меньше ошибок. Позиция «Это глупо, у вас всегда будут ошибки» - всего лишь коп, чтобы избежать уменьшения количества ошибок в вашем коде. Никто не совершенен, но мы можем и должны стремиться быть лучше. В моих собственных усилиях по улучшению я нашел следующие пункты полезными.

• Это не легко. Ты не поправишься за ночь. Так что не отчаивайтесь и не сдавайтесь.
• Пишите меньше и пишите умнее. Чем меньше кода, тем лучше код. Естественно хотеть планировать заранее и пытаться создавать удивительные шаблоны проектирования, но в конечном итоге просто написать то, что вам нужно, экономит время и предотвращает ошибки.
• Сложность - враг. Меньше не считается, если это запутанный сложный беспорядок. Кодовый гольф это весело, но это ад, чтобы понять и хуже, чтобы отлаживать. Всякий раз, когда вы пишете сложный код, вы открываете себя миру проблем. Держите вещи простыми и короткими.
• Сложность субъективна. Когда-то сложный код становится простым, когда вы становитесь лучшим программистом.
• Опыт имеет значение. Одним из двух способов стать лучшим программистом является практика. Практика - это НЕ написание программ, которые ты умеешь писать с легкостью, это написание программ, которые немного повреждают и заставляют тебя думать.
• Другой способ стать лучше - это читать. В программировании есть много сложных тем для изучения, но вы никогда не сможете выучить их, просто программируя, вам нужно изучить их. Вы должны прочитать трудные вещи. Такие вещи, как безопасность и параллелизм невозможны, он может научиться правильно, просто написав код, если вы не хотите учиться, устраняя бедствия. Если вы не верите мне, посмотрите на эпические проблемы безопасности, как у gawker. Если бы они потратили время на то, чтобы научиться правильно делать безопасность, а не просто делать что-то, что сработало, такого беспорядка никогда бы не случилось.
• Читайте блоги. Существует множество интересных блогов, которые дадут вам новые и интересные способы взглянуть и подумать о программировании, это поможет вам ...
• Узнайте грязные детали. Незначительные детали того, как непонятные части вашего языка и приложения работают, очень важны. Они могут содержать секреты, которые помогут вам избежать написания сложного кода, или могут быть частями, в которых есть свои ошибки, которых нужно избегать.
• Узнайте, как думают пользователи. Иногда ваши пользователи просто безумны и будут работать с вашим приложением способами, которые вы не понимаете и не можете предсказать. Вам нужно достаточно проникнуть в их головы, чтобы узнать незнакомые вещи, которые они могут попробовать, и убедиться, что ваше приложение справится с этим.

Лично я считаю, что стремление к программированию без ошибок кажется более дорогим (как по времени, так и по деньгам). Чтобы достичь нулевой или даже почти нулевой ошибки, разработчикам необходимо тщательно протестировать. Это означает регрессионное тестирование всего перед отправкой кода для проверки исправления. Эта модель не кажется мне экономически эффективной. Лучше, если разработчики проведут тщательное тестирование и предоставят углубленное тестирование команде QA. Вот почему:

• Разработчики отстой в тестировании. Это правда, и вы это знаете. (Я разработчик!) Хорошая команда QA всегда найдет передовые примеры, о которых разработчики никогда не задумываются.
• Разработчики хороши в кодировании. Пусть они вернутся к тому, в чем они преуспели (и обычно в любом случае предпочитают).
• Команда QA может найти ошибки, связанные с несколькими задачами разработчика за один проход.

Примите, что когда вы пишете код, в нем регистрируются ошибки. Вот почему у вас есть процесс обеспечения качества, и все это является частью того, чтобы быть разработчиком. Конечно, это не означает, что вы отправляете что-то, как только напишите свою последнюю точку с запятой. Вы все еще должны гарантировать качество своей работы, но вы можете переусердствовать.

Сколько профессий вы можете назвать, чтобы с первого раза выполнить свою задачу правильно, без экспертной оценки и / или тестирования?

Ноль ошибок? Похоже, вам нужен Lisp (следуйте по скептическому пути и избегайте музыкального видео).

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

Сохранение кода настолько простым, насколько это возможно , поможет вам избежать ошибок.

Убедитесь, что вы используете инструменты анализа кода (такие как FindBugs , PMD и т. Д.) , Которые - в сочетании со строгими предупреждениями компилятора - выявят все виды проблем с вашим кодом. Обратите внимание на то, что они говорят вам, действительно постарайтесь понять природу ошибки, а затем предпримите шаги, чтобы изменить идиому программирования, чтобы код казался неестественным таким образом, чтобы снова вводить эту ошибку.

Все "Не кодируйте вообще". ответы полностью упускают суть. Кроме того, ваш босс определенно не выглядит идиотом!

Я не могу вспомнить, как часто я видел программистов, которые просто не знали, что делает их код. Их единственная философия развития, казалось, была методом проб и ошибок (и довольно часто также копировать / вставлять / модифицировать). Хотя метод проб и ошибок является верным способом решения некоторых проблем, часто вы можете проанализировать проблемную область, а затем применить очень конкретное решение, основанное на вашем понимании используемых вами инструментов и с небольшой дисциплиной и усердием, которых у вас не будет. Решил только проблему, но и большинство угловых случаев (потенциальных ошибок), прежде чем развернуть ее в первый раз. Можете ли вы гарантировать, что в коде нет ошибок? Конечно, нет. Но с каждой ошибкой, с которой вы сталкиваетесь или читаете о ней, вы можете добавлять ее к вещам, о которых вы, возможно, захотите подумать, когда в следующий раз напишите / измените что-то. Если вы сделаете это, вы получите большой опыт написания кода, который почти не содержит ошибок. - Есть множество ресурсов о том, как стать лучшим программистом, который может помочь вам в путешествии ...

Лично я никогда не передам код, в котором я не могу объяснить каждую строку. У каждой строки есть причина быть там, иначе она должна быть удалена. Конечно, иногда вы будете делать предположения о внутренней работе методов, которые вы вызываете, в противном случае вам нужно будет знать внутреннюю логику всей структуры.

Ваш начальник совершенно прав, говоря, что вы должны понимать результаты и влияние кода, который вы пишете, на существующую систему. Будут ли ошибки возникать? Да, конечно. Но эти ошибки будут из-за вашего неполного понимания системы / инструментов, с которыми вы работаете, и с каждым исправлением ошибки вы будете получать лучшее освещение.

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

Если вы хотите протестировать программное обеспечение, всегда имейте в виду, что тесты могут только доказать наличие ошибок, а не их отсутствие.

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

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

Таким образом, в зависимости от вашего определения «ошибок», вы можете попробовать формальную проверку или просто попытаться найти как можно больше ошибок в своем программном обеспечении.

Либо не пишите ничего более сложного, чем "Hello World!" или если вы говорите всем никогда не использовать его.

Спросите своего босса о некоторых примерах этого так называемого кода без ошибок.

Я согласен с другими. Вот как бы я подошел к проблеме

• Получить тестер. См. Тест Джоэла, почему.
• Широко использовать библиотеки; вероятно, были отлажены лучше. Я большой поклонник CPAN для Perl.

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

• задействовать несколько методов тестирования (кроме ATDD)
• создавать формальные проверки нашего программного обеспечения
• иметь отдельную команду QA
• провести тщательный анализ каждого изменения, внесенного в базу кода
• используйте язык, который больше склоняется к безопасности и осторожности

Я не делаю эти вещи, потому что они стоят слишком дорого для программного обеспечения, которое я пишу. Если бы я делал эти вещи, я бы, вероятно, продвинулся бы дальше к нулевым ошибкам, но это не имело бы делового смысла.

Я создаю внутренние инструменты, которые используют большую часть нашей инфраструктуры. Мои стандарты для тестирования и кодирования высоки. Тем не менее, есть баланс. Я не ожидаю ноль ошибок, потому что я не могу заставить людей вкладывать такое время в одну работу. Все могло бы быть иначе, если бы я создавал программное обеспечение для управления рентгеновским аппаратом, реактивными двигателями и т. Д. Если мое программное обеспечение сломается, жизни не будет, поэтому мы не участвуем в таком уровне гарантии.

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

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

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

Как только это станет вашим отношением, ошибки быстро исчезнут. В поисках способов устранения ошибок вы столкнетесь с разработкой на основе тестирования. Вы найдете множество книг, сообщений в блогах и людей, предлагающих бесплатные советы по лучшим методам. Вы поймете, как важно улучшить свои навыки на практике (например, писать коды или пробовать что-то новое дома). Вы начнете работать лучше на работе, потому что начнете работать над своим ремеслом дома. И, надеюсь, когда вы видите , что это возможно , чтобы написать хорошее программное обеспечение, ваша страсть для вашего корабля будет расти.

В некотором смысле, ваш начальник прав. Можно написать программное обеспечение, которое приближается к нулю ошибок.

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

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

• Используйте методы доказательства теорем, чтобы формально доказать, что ваша программа реализует спецификацию.

• Создавайте обширные наборы и наборы тестов для юнитов, регрессионных и системных тестов, чтобы проверять все возможные ошибки. (И этого недостаточно само по себе.)

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

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

Я достиг статуса "нулевой ошибки". Я говорю своим пользователям, что это недокументированная функция, или они просят новую функцию, и поэтому это улучшение. Если ни один из этих ответов не принят, я просто говорю им, что они не поняли своих собственных требований. Таким образом, нет ошибок. Программисты идеальны.

Вот шаги, чтобы сделать баг бесплатной программой:

1. Никогда не начинайте кодирование, если у вас нет УНИКАЛЬНЫХ ТЕХНИЧЕСКИХ ХАРАКТЕРИСТИК для вашей функциональности.
2. НЕ ИСПЫТАТЬ, или, если вы НЕ ИСПОЛЬЗУЕТЕ ИСПЫТАНИЕ, чтобы обнаружить дефекты в программном обеспечении.
3. Примените все ОТЗЫВЫ от дефектов, обнаруженных во время тестирования, проверок и производства, к процессу и разработчикам, которые в первую очередь вставили дефект. Откажитесь от всех дефектных компонентов полностью, как только дефекты будут обнаружены. Обновите свои контрольные списки и переподготовьте своих разработчиков, чтобы они не повторяли подобных ошибок снова.

Тестирование может только доказать, что у вас есть ошибки, но обычно бесполезно доказывать обратное. Что касается обратной связи - если у вас есть машина для изготовления монет, которая производит монеты, и каждая монета в 10 с в среднем имеет дефект. Вы можете взять эту монету, сплющить ее и снова вставить в машину. Монета, из которой изготовлен этот переработанный бланк, будет не такой хорошей, но, возможно, приемлемой. Каждую сотню монет нужно будет перепечатывать 2 раза и так далее. Будет ли легче починить машину?

К сожалению, люди не машины. Чтобы стать хорошим программистом без дефектов, вам нужно потратить много времени, обучая и повторяя каждый сделанный дефект. Разработчики должны быть обучены формальным методам проверки, которые часто трудно освоить и применять на практике. Экономика разработки программного обеспечения также работает против этого - вы бы потратили 2 года на обучение программиста, который может сделать меньше дефектов, просто чтобы увидеть, как он переходит к другому работодателю? Вы можете купить машину, которая делает идеальные монеты, или нанять еще 10 обезьян для кода, чтобы создать кучу тестов по той же цене. Вы можете воспринимать этот исчерпывающий процесс как свою «машину», ваш актив - инвестиции в обширную подготовку отличных разработчиков не окупаются.

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

Программа для защиты: http://en.wikipedia.org/wiki/Defensive_programming

Если кто-то будет следовать правилам программирования в обороне, то изменения будут легко прослеживаться. Объедините это с подробными отчетами об ошибках во время разработки и надежной документацией, как, например, с doxygen, и вы сможете точно знать, что делает весь ваш код, и очень эффективно исправлять возникающие ошибки.

Может ли это быть результатом неправильного понимания хорошей методологии, а не просто общей тупости?

Я имею в виду, что, возможно, ваш начальник слышал о «методологии отсутствия дефектов» (см. Раздел № 5) и не беспокоился о том, что это значит?
Конечно, руководству неудобно откладывать разработку новых функций в пользу ошибок, которые вы не должны были вносить ...
И, конечно, это угрожает его бонусу, поэтому, конечно, вы его не получите, потому что "хорошие программисты этого не делают есть ошибки "...

Можно делать ошибки, если вы можете их найти и исправить (в разумных пределах, конечно).

Одна из фундаментальных концепций тестирования программного обеспечения заключается в том, что вы НИКОГДА не можете быть абсолютно уверены, что программа идеальна. Вы можете проверить его навсегда, но это никогда не доказывает, что программа завершена, потому что она быстро становится невозможной даже для проверки всех комбинаций ввода / переменной.

Ваш босс, похоже, один из тех, кто "не понимает, что такого сложного в программировании, поскольку он просто печатает"

Если мы предполагаем, что крупные разработчики программного обеспечения знают, как получить первоклассных разработчиков (как в программисте с нулевыми ошибками ), мы можем сделать вывод, что программное обеспечение Microsoft должно быть без ошибок. И все же мы знаем, что это далеко от истины.

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

Если вы не разрабатываете что-то более сложное, чем простой калькулятор, невозможно избежать ошибок вместе. Черт даже у НАСА есть избыточность на их транспортных средствах и ошибках. Хотя у них много строгих испытаний, чтобы избежать катастрофических сбоев. Но, тем не менее, даже у них есть ошибки в их программном обеспечении.

Ошибки неизбежны, как и человеческая природа, чтобы ошибаться.

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

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

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

Это происходит со мной с очень простыми программами, потому что я преподаю программирование. Они простые для меня, но тяжелые для студентов. И я не говорю о решениях проблем, которые я делал много, много раз на доске. Конечно, я знаю их. Я имею в виду ~ 300-строчные программы, которые решают что-то, используя хорошо знакомые мне концепции (концепции, которым я учу). Я пишу эти программы без планирования, и они просто работают, и я чувствую, что знаю все детали, мне вообще не нужен TDD. Я получаю пару или три ошибки компиляции (в основном опечатки и тому подобное) и все. Я могу сделать это для небольших программ, и я также считаю, что некоторые люди могут сделать это для более сложных программ. Я думаю, что такие люди, как Линус Торвальдс или Даниэль Дж. Бернштейн, обладают такой ясностью ума, они ближе всего подходят к безошибочному кодеру. если тыпонимать вещи глубоко я думаю , что вы можете сделать это. Я могу сделать это только для простых программ, как я уже сказал.

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

Однако, если вы попытаетесь сделать что-то новое, но чуть выше вашего уровня, вы можете сделать вашу программу идеальной или почти идеальной. Я думаю, что действительно трудно узнать, какие программы находятся на вашей «границе знаний», но в теории это лучший способ обучения. На самом деле, я много переписываю программы с нуля. Некоторые люди делают, но вам нужно много времени и терпения, потому что в третий раз, когда вы повторяете нетривиальную программу, вы не волнуетесь, как в первый раз.

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

Имхо ошибки и внезапные, загадочные артефакты алгоритма должны появиться во время процесса кодирования: они вдохновляют и форсируют эволюцию кода.
однако возможно (обычно после некоторого тестирования) проверить каждую переменную, которая может использоваться до объявления, обрабатывать каждую ошибку, где бы она ни появлялась - чтобы программа не вызывала ошибок ... до тех пор, пока вы не получите запрос на функцию, которая рассматривалась невозможно, когда вы обсуждали архитектуру программы;)

Может быть, больше думать о природе ошибок, которые вы получаете. Если ошибки - это, как правило, незначительные упущения, то поможет более тщательное тестирование и небольшая корректура кода.

Если ошибки, как правило, связаны с неоптимальными решениями в области программирования, то, возможно, потребуется приложить больше усилий для улучшения дизайна. В этом случае я думаю, что возможно слишком зависеть от тестирования, чтобы повысить качество программного обеспечения, потому что применение исправления к дефектному коду может только усложнить будущее обслуживание. С одной стороны, вы получаете меньше ошибок по мере их обнаружения и исправления, но с другой стороны, вы готовите почву для будущих ошибок.

Один из способов определить, есть ли у вас проблемы с упущениями или с дизайном, может заключаться в том, чтобы определить, сколько усилий требуется для исправления ошибок. Если исправления имеют тенденцию быть большими, или вы чувствуете, что плохо их понимаете, это указывает на рисунок, который можно улучшить.

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

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

Если я имею в виду: «ноль ошибок при написании кода» -> это хорошая цель, но довольно невозможная.

Но если вы имеете в виду: «ноль ошибок в доставленном коде» -> это возможно, и я работал в таких средах.

Все, что вам нужно, это: безумно высокое качество кода и почти 100% тестовое покрытие (юнит-тесты + приемочные тесты + интеграционные тесты).

На мой взгляд, лучшая книга для изучения это: ГСНО . Но, конечно, книги недостаточно. Вам нужно пойти в какую-то группу пользователей и обсудить это. Курсы, конференции и т. Д. Качество нулевых ошибок непросто.

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

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

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

Решение пользователя:

• Прекратите использовать компьютеры.
• Делай все вручную.
• Всегда попросите второго человека перепроверить результаты.

Я согласен, что быть программистом без ошибок вы просто не можете программировать / кодировать. Это часть жизни каждого программиста - сталкиваться и разрабатывать ошибки. Ни один опытный разработчик не может сказать, от души, что они никогда не сталкивались с ошибками в своем коде.

Пара с другим инженером. Напишите провальный тест. Пусть каждый набранный вами символ будет необходим для успешного прохождения теста. Рефакторинг вашего кода, чтобы сделать его проще. Напишите еще один провальный тест и так далее и тому подобное.