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

168

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

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

user8
источник
Никто на самом деле не создает идеальный код с первого раза, кроме меня. Но есть только один из меня. - Tech Talk: Линус Торвальдс на Git, Google, 15 августа 2007 г. izquotes.com/quote/273558
JensG
Нет такого понятия, как программирование с 0 ошибками. Читайте математика Годеля, чтобы понять почему.
Майкл Мартинес
Это неверная цель, смотрите: yegor256.com/2015/06/18/good-programmers-bug-free.html
yegor256

Ответы:

365

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

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

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

wildpeaks
источник
73
+1 Продолжение: Или вы можете стать некодирующим (слоновой костью) архитектором и все равно получать много денег! Это лучшее
Мартин Уикман,
26
Чтобы человек ошибался, исправляй свои божественные ошибки.
Уорд Мюйлаерт
11
Раньше у меня была сотрудница, которой босс нравился, потому что у нее постоянно было небольшое количество ошибок. Как она это сделала? Проще говоря, она присваивала ошибки, которые не хотела кому-то другому, и всегда брала на себя самые простые / маленькие функции.
Тоби
46
Я не знаю, кто первым это сказал, но «если отладка - это процесс удаления ошибок, то программирование должно быть процессом их исправления».
Брюс Олдерман
8
Еще лучше: станьте боссом и заставьте своих подчиненных чувствовать себя несчастными, не неся ответственности за что-либо.
biziclop
124

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

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

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

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

CodesInChaos
источник
3
Не возможно. Но крайне маловероятно.
Билли Онил
36
Что заставляет вас думать, что FB не содержит ошибок? Модель безопасности и конфиденциальности Facebook - одна огромная ошибка. Например, учетная запись Facebook боссов Facebook была взломана на прошлой неделе из-за недостатков безопасности.
Стивен С.
6
Философия @Elaine Facebook заключается в том, чтобы «действовать быстро и ломать вещи» ( geek.com/articles/news/… ), и у них было бесчисленное множество ошибок ( facebook.com/board.php?uid=74769995908 ), включая многие, которыми я руководил в себя. Твиттер ничем не отличается, он известен тем, что его часто отключали ( engineering.twitter.com/2010/02/anatomy-of-whale.html ) и такими ошибками, как «follow bug» ( status.twitter.com/post/587210796/… ).
Евгений Брикман
9
Не забывайте о движущихся стойках ворот. Функция в вашей PerfectProgram 1.0 может быть ошибкой в ​​2.0
Карлос
4
@CodesInChaos: теория гласит, что существуют программы, для которых невозможно доказать их поведение. Это не говорит о том, что невозможно доказать поведение всех программ. Я бы предположил, что большинство распространенных программ относятся к доказуемому типу, и утверждение «В моем коде нет ошибок из-за проблемы остановки» является неправильным применением теории.
эндолит
98

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

  • Будь скромным - ты и будешь делать ошибки. Несколько раз.
  • Будьте полностью осведомлены об ограниченном размере вашего черепа. Подходите к задаче с полным смирением и избегайте хитрых уловок, таких как чума. [Эдсгер Дейкстра]
  • Бой комбинаторный взрыв
  • Избавьтесь от изменчивого состояния (где только возможно). Да, учиться функциональному программированию.
  • Уменьшить количество возможных путей кода
  • Поймите (величину) размера входных и выходных пространств (ваших функций) и постарайтесь уменьшить их, чтобы приблизиться к 100% охвату теста
  • Всегда предполагайте, что ваш код не работает - докажите это иначе!
Maglob
источник
2
Я был бы рад доказать, что мой код работает ... но тестирование может только доказать, что это не так. Вы говорите формальное доказательство или представляете задачу отладки здесь?
Матье М.
Первый полезный ответ в этой теме. @Matthieu: Вы можете доказать для каждой возможной комбинации двух байтов, что функция возвратит правильный результат (например, max), который снова является байтом. У вас может быть две и более таких функций, и теперь вы можете объединить их в цепочку и получить большое количество возможных комбинаций таких функций, которые снова будут производить только один байт. Идея, что вы только можете доказать, что что-то не так, неверна. Популярно, но неправильно.
пользователь неизвестен
@Matthieu M .: Тестирование доказывает, что все работает так, как вы ожидаете. Если вы можете доказать, что все элементы работают так, как вы ожидаете, то оттуда вы докажете, что имеете дело с поведением ввода, которого вы не ожидали. Как только вы поймете, что это за поведение и каким оно должно быть, вы пишете для него новый тест. Теперь это часть вашего ожидаемого поведения.
deworde
1
@deworde: Я понимаю идею тестирования, однако, за исключением нишевых ситуаций, большая часть реальной работы, которую я сделал, не может быть протестирована исчерпывающе, просто потому, что возможное количество комбинаций было слишком большим (и я даже не добавляю вопросы времени). Таким образом, кроме нишевых ситуаций, тестирование зашло так далеко (все еще полезно проверить, что хотя бы номинальный падеж прошел!)
Матье М.
«Избегайте хитрых уловок, таких как чума», - это одно даст хороший ответ. Как это - это здорово.
BЈовић
25

TDD

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

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

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

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

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

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

Пит
источник
19

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

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

user7007
источник
1
+1. По словам Twisted Sister, то, что ты не знаешь, может причинить тебе боль / То, что ты не видишь, заставляет тебя кричать.
инженер
17

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

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

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

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

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

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

Себастьян Мартин
источник
8

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

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

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

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

Gary Rowe
источник
3
Иногда жуки похожи на скрытых монстров, живущих там, они прячутся во время моего многократного тестирования и самоконтроля кода ... но как только я делаю рецензирование, я обнаружил, что монстры были невероятно видимы и внезапно выскочили ко мне. Это действительно странно. В зависимости только от человеческого «глаза» и «мозга» кажется невозможным прикоснуться к линии без ошибок. модульный тест не работает во всех случаях. Инструменты анализа кода? звучит захватывающе, я никогда не использовал это, я буду проводить исследования в этой области.
Элейн
Я бы сказал, что вам нужна Ада, но Лисп веселее. ;-)
Orbling 30.01.11
1
@Elaine Где я работаю, это среда Java, и код может передаваться команде только в том случае, если он прошел через Findbugs и PMD. Новые члены команды проходят через пять этапов: отрицание, гнев, торг, депрессия и затем принятие. После этого они никогда не оглядываются назад.
Гари Роу
@ Гэри Роу, я понимаю эти реакции, лол, я когда-либо был в компании, где был отдел контроля качества, сотрудники там еженедельно проверяли все коды, созданные на этой неделе, чтобы увидеть, соответствуют ли все строки кода «правилу». «(Я понятия не имею, использовали ли они какие-то инструменты, такие как Findbugs / PMD), но это немного похоже на тот шаг, на котором вы находитесь.
Элейн
1
@ Гэри: Я не спорю, но в нескольких местах, где я работал, нарушения стиля рассматриваются как ошибки. И у них, как правило, были правила стиля, такие как «каждый класс должен объявлять статические поля CLS_PKG и CLS_NAME, которые содержат имена пакетов и классов». Я обычно поддерживаю стандарты кодирования, но не тогда, когда они превращаются в подобные вещи!
TMN
8

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

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

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

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

Патрик Клуг
источник
«с каждой ошибкой, с которой вы сталкиваетесь или читаете о ней, вы можете добавить ее к вещам, о которых вы, возможно, захотите подумать, когда в следующий раз напишите / измените что-либо», - это отличный момент Я создал документ Google, связанный с ошибками, которые я видел или написал, только для этой цели.
Бен
7

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

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

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

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

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

оборота FabianB
источник
6

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

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

JeffO
источник
5

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

  • Получить тестер. См. Тест Джоэла, почему.
  • Широко использовать библиотеки; вероятно, были отлажены лучше. Я большой поклонник CPAN для Perl.
Брайан Карлтон
источник
1
… Но если вы используете библиотеки, убедитесь, что их ошибки не могут утащить вас вниз (например, имея источник, чтобы вы могли проверить его или исправить ошибки самостоятельно, если это будет необходимо).
Милленоми
5

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

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

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

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

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

dietbuddha
источник
4

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

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

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

Даррен
источник
2

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

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

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

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

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

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

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

Стивен С
источник
1

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

джулио
источник
1

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

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

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

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

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

Алексей Полханов
источник
+1 за упоминание однозначных спецификаций. Я знаю, что это тема двухлетней давности, но я должен подчеркнуть, что ваш единственный ответ, указывающий на то, что неверно полагать, что ошибка соответствует ошибке программирования.
Брэндон
0

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

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

Джейсон Маккаррелл
источник
0

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

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

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

алчный
источник
0

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

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

SpacePrez
источник
0

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

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

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

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

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

оборота Роберт Коритник
источник
-1

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

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

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

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

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

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

Пау Фернандес
источник
-1

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

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

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

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

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

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

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

Джон Биккерс
источник
-2

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

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

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

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

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

Uberto
источник
-3

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

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

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

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

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

dbramhall
источник
-4

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

Карл Кориелл-Мартин
источник