Как уменьшить количество ошибок при кодировании?

Никто не идеален, и независимо от того, что мы делаем, мы собираемся создавать код, в котором время от времени появляются ошибки. Каковы некоторые методы /методы для сокращения количества ошибок, которые вы производите, как при написании нового программного обеспечения, так и при изменении /сохранении существующего кода?

bug
30 голосов | спросил GSto 1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

17 ответов


58

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

Используйте доступные библиотеки. Самый простой способ не иметь ошибок при написании служебной программы - не писать.

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

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

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

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

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

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
30

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

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
9

+1 на обоих тестовых комментариях модуля.

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

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

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
9

В дополнение к тому, что было упомянуто:

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

Множество других вещей, о которых я забываю в данный момент, но другие наверняка подумают о них. :)

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
9

Я разработал довольно функциональный стиль программирования, несмотря на то что мои основные языки были C ++ и Python. Я обнаружил, что если я передаю весь контекст функции (или методу), которой эта функция должна выполнять свою работу, и вернуть значимые данные, которые я ищу, что мой код стал намного более надежным.

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

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

Идите, все эти вещи также оказывают положительное влияние на производительность. Win!

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
8
  • Напишите меньше кода, который делает больше.
  • Подумайте о последствиях низкого уровня и о последствиях высокого уровня.
  • Сопоставьте абстракцию, которую вы создаете в своем коде.
  • Напишите, если это возможно, существенную сложность.
ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
8

Немного менее технический ответ: не программируйте, когда вы устали (достаточно 9 часов /день), пьяный или «испеченный». Когда я устал, у меня нет необходимого терпения, чтобы писать чистый код.

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
7

Напишите тесты unit и интеграции .

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
5

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

Вовлекайте ваши тестеры уже в начале

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

  • Узнайте, что их план тестирования. Просмотрите их тестовые примеры с ними - вы покрываете их все своим кодом?
  • Попросите их понять их требования. Это то же самое, что и у вас?
  • Дайте им ранние рабочие сборки для проведения пробных испытаний - вы будете поражены улучшениями, которые они будут предлагать.

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

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
4

Инструменты статического анализа

Плагины и приложения, такие как FindBugs , сканируют ваш код и находят места, где есть потенциал ошибки. Места, где переменные не инициализируются и не используются, или просто сумасшедшие вещи, которые 9 раз из 10, облегчают появление ошибок. Инструменты, подобные этому, помогают мне не допустить, чтобы мои кости шли вниз по дороге, даже если это еще не ошибка.

P.S .: Помните, что всегда исследуйте , почему инструмент говорит вам, что что-то плохое. Никогда не боится учиться (и не все правильно во всех ситуациях).

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
3

Проверка кода или другие формы экспертной оценки, такие как парное программирование.

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

Peer Reviews в программном обеспечении Karl Wiegers - отличная книга на эту тему.

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
2

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

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

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
2

Много хороших ответов здесь, но несколько вещей, которые я хотел добавить. Убедитесь, что вы действительно понимаете это требование. Я видел много ошибок, когда пользователь считал, что это требование означает X, и программист подумал, что это означает Y. Отправляйтесь назад для разъяснения по плохим или неоднозначным требованиям. Я знаю, что нам всем нравится вскакивать и кодировать, но чем больше времени потрачено на обеспечение понимания, тем меньше будет исправление и исправление ошибок.

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

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

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
1

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

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

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
1

Я следую практике Test-Code-Test вместо Code-test-code-test. Это помогает мне думать о случаях использования и надлежащим образом создавать логику

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
1

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

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38
1

Удивительно, но еще не упомянуты следующие три очень важных момента:

  • Используйте утверждения либерально. Вопрос, который вы всегда должны задавать себе, - это «не следует ли это утверждать?». но «есть ли что-нибудь, что я забыл утверждать?»

  • Выбирайте неизменность. (используйте final /readonly liberally.) Чем меньше измененное состояние у вас есть, тем меньше ошибок может пойти не так.

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

ответил Jacquez 31 Jpm1000000pmWed, 31 Jan 2018 19:45:38 +030018 2018, 19:45:38

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

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

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