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

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

Ответ 1

Я считаю следующее довольно удобным.

1) ЗАДАЧИ.
2) Отладочный журнал, который может выводить на отладочную команду, консоль или файл.
3) Инструменты отслеживания памяти.
4) Единичное тестирование.
5) Умные указатели.

Я уверен, что есть тонны других, но я не могу думать о них с головы:)

Ответ 2

Автоматическое тестирование устройств.

Ответ 3

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

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

Да, модульное тестирование очень важно, и я уверен, что другие могут дать вам лучшие советы, чем я, но не пренебрегайте своим тестированием системы/интеграции.:)

.. и эй, это независимая от языка техника!

Ответ 4

Обзор кода, Тестирование устройств и Непрерывная интеграция может помочь.

Ответ 5

RAII, чтобы избежать ошибок утечки ресурсов.

Ответ 6

Стремитесь к простоте и лаконичности.
Никогда не оставляйте случаи, когда ваш код работает undefined.
Посмотрите на возможности использовать систему типов и проверить компилятор как можно больше во время компиляции. Шаблоны и генерация кода - ваши друзья, пока вы держите свой здравый смысл.
Свести к минимуму количество синглетонов и глобальных переменных.
Используйте RAII!
Используйте assertions!
Автоматическое тестирование некоторых номинальных и всех угловых случаев.
Избегайте изменений в последнюю минуту, таких как чума.

Ответ 7

Я использую мышление.

Ответ 8

Сокращение объема переменных до максимально узкого. Меньше переменных во внешнем масштабе - меньше шансов посадить и скрыть ошибку.

Ответ 9

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

Ответ 10

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

утверждает,

Ответ 11

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

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

Ответ 12

Обучение функциональному программированию помогает. ЗДЕСЬ
Узнайте, что вы haskell для хорошего.

Ответ 13

Model-View-Controller, и вообще ничего с контрактами и интерфейсами, которые могут быть подвергнуты автоматическому тестированию.

Ответ 14

Я согласен со многими другими ответами здесь.

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

Кроме того, наличие политики "без предупреждений" помогает найти ошибки.

Ответ 15

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

Ответ 16

Требования.

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

Ответ 17

Кодовые обзоры; Я лично нашел много ошибок в коде моих коллег, и они обнаружили ошибки в моем.

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

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

Конечно, парное программирование делает это до крайности.

Ответ 18

Использование среды IDE, такой как IntelliJ, которая проверяет мой код, когда я его пишу, и флагов изворотливого кода, когда я его пишу.

Ответ 19

Тестирование устройств, за которым следует непрерывная интеграция.

Ответ 20

Предложения по книге: "Code Complete" и "Release it" - две обязательные для чтения книги по этой теме.

Ответ 21

В дополнение к уже упомянутым вещам я считаю, что некоторые функции, введенные с С++ 0x, помогут избежать некоторых ошибок. Приходят на ум такие функции, как строго типизированные перечисления, петли for-in и удаление стандартных функций объектов.

В целом сильная типизация - это способ пойти imho

Ответ 22

Консистенция стиля кодирования в проекте.

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

Ответ 23

Это уже упоминалось здесь, но я скажу это снова, потому что считаю, что этого нельзя сказать достаточно:

Ненужная сложность - это армейский заклинание хорошей инженерии.

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

Ответ 24

Нанять кого-то, кто тестирует/проверяет ваше программное обеспечение.

У нас есть парень, который использует наше программное обеспечение перед любым нашим клиентом. Он обнаруживает ошибки, которые наши автоматизированные тестовые процессы не обнаруживают, потому что он считает себя клиентом не как разработчик программного обеспечения. Этот парень также оказывает поддержку нашим клиентам, потому что он очень хорошо знает программное обеспечение с точки зрения клиента. НЕОЦЕНИМО.

Ответ 25

все виды "трассировки".

Ответ 26

Что-то еще не упоминалось - когда происходит даже полу-сложная логика, назовите свои переменные и функции так точно, как можете (но не слишком долго). Это создаст несоответствия в их взаимодействии друг с другом и с тем, что они должны делать, лучше. "Значение", или часть, анализирующая язык вашего мозга, будет иметь больше возможностей для захвата. Я нахожу, что с неопределенно названными вещами ваш мозг затмевает то, что на самом деле там, и видит то, что/предполагается/должно происходить, а не то, что на самом деле.

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

Ответ 27

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

Ответ 28

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

Вчера я нашел очень неприятную ошибку без отладки одной строки:

vector<string> vec;
vec.push_back("test1");
vec.push_back(vec[0]); // second element is not "test1" after this, it empty string

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