Как сделать программу без ошибок (или с наименьшим количеством возможных ошибок) - PullRequest
9 голосов
/ 22 сентября 2008

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

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

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


Итог: код без ошибок невозможен. Однако вот что можно сделать:

Тестирование

Инструменты

Практика, управление, окружающая среда

Формальная проверка

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

Ответы [ 18 ]

0 голосов
/ 22 сентября 2008

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

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

0 голосов
/ 11 мая 2009

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

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

0 голосов
/ 22 сентября 2008

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

Но вы можете использовать TDD (Test Driven Developent) в вашем проекте для минимизации ошибок в версиях выпуска. Но это не тотальное решение. некоторые ошибки очень сложны и могут быть вызваны обновлением стороннего компонента или чего-либо еще.

0 голосов
/ 22 сентября 2008

Все как указано в отношении лучших практик, хорошего процесса разработки + TTD, НО также использовать ... Мутационное тестирование - очень крутой инструмент для измерения качества юнит-тестов! http://nester.sourceforge.net/

Удачи.

/ Ievgenii

0 голосов
/ 22 сентября 2008

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

Очевидно, что это не работает в одиночку, и вам нужно иметь хорошие методы разработки, подобные тем, которые упоминали Фил, Манрико, Твен и другие ...

0 голосов
/ 22 сентября 2008

Какие дефекты у вас в программном обеспечении?

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

Неполное понимание требований? Здесь помогает разработка на основе тестирования и культура обзора.

Проблемы с дизайном? Опять же, обзоры очень помогают.

Используете устаревший код? Это требует контроля версий.

И: ведите журнал дефектов, чтобы вы знали, какие дефекты вы делаете.

0 голосов
/ 22 сентября 2008

Модульное тестирование! Это не серебряный булл, но он экономит много времени на отладку.

0 голосов
/ 22 сентября 2008

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

Ключевые моменты

  • Автоматизированные тесты
  • частое выполнение тестов
  • Убедитесь, что контрольные примеры соответствуют известным требованиям
  • создавать тестовые случаи, когда вы находите ошибки; эти тесты не проходят, пока ошибка не будет исправлена ​​
...