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

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

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

161 голос | спросил 5 revs, 3 users 43%
user8
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

28 ответов


358

Не кодам вообще.

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
122

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

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

  

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

     

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
96

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

  • Будьте скромными - вы и будете совершать ошибки. Многократно.
  • Будьте в курсе ограниченного размера вашего черепа. Подходите к задаче с полным смирением и избегайте умных уловок, таких как чума. [Edsger Dijkstra]
  • Борьба комбинаторный взрыв
  • Избавиться от изменчивого состояния (где это возможно). Да, изучите функциональное программирование.
  • Уменьшить количество возможных путей кода
  • Понять (величину) размер ввода & amp; (ваши функции), и попытайтесь уменьшить их, чтобы приблизиться к 100% -ному охвату тестирования.
  • Всегда предполагайте, что ваш код не работает - докажите это иначе!
ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
26

TDD

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

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

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
19

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
17

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

  • Это непросто. Вы не улучшитесь за ночь. Поэтому не разочаровывайтесь и не сдавайтесь.
  • Напишите меньше и напишите умнее. Меньше кода, как правило, лучше кода. Естественно хотеть планировать заранее и пытаться создавать удивительные шаблоны дизайна, но в конечном итоге просто писать то, что вам нужно, экономит время и предотвращает ошибки.
  • Сложность - это враг. Меньше не считается, если это неясный сложный беспорядок. Code golf - это весело, но это чертовски понять, и худший ад для отладки. Всякий раз, когда вы пишете сложный код, вы открываете себя в мир проблем. Держите вещи простыми и короткими.
  • Сложность субъективна. Код, который когда-то был сложным, становится простым, когда вы становитесь лучшим программистом.
  • Опыт. Один из двух способов стать лучшим программистом - это практиковать. Практика - это не написание программ, которые вы знаете, как писать с легкостью, это программы, которые немного болят и заставляют вас думать.
  • Другой способ стать лучше - это прочитать. Есть много трудных тем в программировании, чтобы учиться, но вы никогда не сможете их изучать, просто программируя, вам нужно их изучить. Вам нужно прочитать тяжелые вещи. Такие вещи, как безопасность и параллелизм, невозможно, чтобы они учились правильно, просто написав код, если вы не хотите учиться, очищая бедствия. Если вы не верите, что я смотрю на эпические проблемы безопасности, такие как gawker. Если они нашли время, чтобы узнать, как правильно сделать безопасность, а не просто сделать что-то, что сработало, беспорядок никогда бы не произошел.
  • Прочитайте блоги. Там есть тонна интересных блогов, которые дадут вам новые и интересные способы взглянуть и подумать о программировании, это поможет вам ...
  • Изучите грязные детали. Небольшие детали того, как неясные части вашего языка и работы приложений очень важны. Они могут хранить секреты, которые помогут вам избежать написания сложного кода или могут быть части, у которых есть собственные ошибки, которых вам нужно избегать.
  • Узнайте, как пользователи думают. Иногда ваши пользователи безупречны и будут работать с вашим приложением так, как вы не понимаете и не можете предсказать. Вам нужно войти в их головы достаточно, чтобы узнать, что незнакомые вещи они могут попробовать, и убедитесь, что ваше приложение может справиться с этим.
ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
8

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
7

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
7

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
6

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
6

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

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
5

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

  • Получить тестер. См. Тест Joel для чего.
  • Широко использовать библиотеки; вероятно, были отлажены лучше. Я большой поклонник CPAN для Perl.
ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
5

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

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
4

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
2

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

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

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

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
1

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
1

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

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
0

Защитите программу: http://en.wikipedia.org/wiki/Defensive_programming

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
0

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
0

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
0

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

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
-1

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

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

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
-1

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
-1

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

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
-2

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

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

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

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

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
-3

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

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

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

  • Прекратить использование компьютеров.
  • Делать все вручную.
  • Всегда есть второй человек, проверяющий результаты.
ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
-3

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54
-4

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

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 31 MaramFri, 31 Mar 2017 10:25:54 +03002017-03-31T10:25:54+03:0010 2017, 10:25:54

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132