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

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

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

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

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

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

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

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

Инструменты

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

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

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

Ответы [ 18 ]

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

Несколько идей:

  1. Занимайтесь написанием юнит-тестов. Это спасло мою жизнь (не буквально) несколько раз.
  2. Использовать контроль источника
  3. Используйте инструмент покрытия кода - например, в Java я использую Emma или Cobertura
  4. Используйте инструмент для непрерывной интеграции, такой как Cruise Control
  5. Используйте утверждения, чтобы проверить свои предположения. Прагматичный программист (книга) расскажет об этом более подробно. На самом деле это книга, которую я настоятельно рекомендую прочитать.
  6. Функциональные тесты - например, в Java вы можете посмотреть jFeature

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

Очевидно, и, может быть, даже самое главное, вам нужно, чтобы кто-то тестировал ваше программное обеспечение (т.е. не только автоматизированные тесты), прежде чем оно будет развернуто / отправлено.

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

Прежде всего: Программное обеспечение без ошибок - миф!

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

  • Хороший редактор
  • Хорошая система контроля версий
  • Правильные этапы разработки (функциональный дизайн, технический дизайн и т. Д.)
  • Подходящая команда испытаний
  • Неподходящая команда тестировщиков (в основном, молочника, уборщицу и водителя автобуса, которых вы привели ... людей, которые понятия не имеют, что делают, если речь идет о компьютерах и интерфейсах)
  • Способ указать, что вы хотите без отвлекающих факторов вообще
  • Время, когда можно решить проблемы, когда вы застряли на них
4 голосов
/ 22 сентября 2008

cosmo0, прости, но мне тебя жаль.

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

Есть код без ошибок. Код с нулевой функциональностью не содержит ошибок. Но это бесполезно.

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

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

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

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

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

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

Часто цитируемый (и, вероятно, не имеющий отношения к делу) пример - обратный порядок ваших сравнений, например: 

"bar" == foo

вместо 

foo == "bar"

чтобы вы не выполняли задание (foo = "bar"), когда хотите выполнить сравнение (foo == "bar"). Если вы измените порядок в обратном порядке, случай ошибки ("bar" = foo) будет легко обнаруживаемой синтаксической ошибкой, а не намного более трудной для поиска логической ошибкой. Но это действительно полезно, только если вы регулярно совершаете такую ​​ошибку.

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

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

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

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

1 голос
/ 27 января 2019

TL; DR использовать формальную проверку или любой вид статической проверки!

На самом деле есть способ избавиться от ошибок на 99,999%. Но вам нужно полностью изменить свой подход к программированию. Полностью откажитесь от всех ваших тестов! Вместо этого используйте формальную проверку. Сначала вы должны ознакомиться с соответствием Карри – Говарда и лямбда-исчислением. Затем изучите зависимые типы:

Или какой-нибудь формальный чекер:

Есть проекты, которые действительно "без ошибок". Взгляните на:

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

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

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

Но я думаю, что "программное обеспечение без ошибок" относится к научной фантастике ...

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

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

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

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

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

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

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

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

Страница:
...