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

Я недавно начал использовать Subclipse, и имейте метод, который работает на меня. Мы работаем с приложениями PHP, таким образом, я создаю новый проект SVN через мастер проекта Eclipse, выбирая к 'Проектам контроля через SVN'. Я затем настраиваю тот проект с помощью мастера конфигурации проекта и выбираю PHP как тип проекта. Я называю проект так, чтобы в моей рабочей области у меня было название проекта на верхнем уровне проводника проекта.

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

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

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

12
задан RED SOFT ADAIR 9 September 2009 в 10:15
поделиться

28 ответов

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

1) УТВЕРЖДЕНИЯ.
2) Регистратор отладки, который может выводить сообщение отладки, консоль или файл.
3) Инструменты отслеживания памяти.
4) Модульное тестирование.
5) Умные указатели.

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

16
ответ дан 2 December 2019 в 02:49
поделиться

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

0
ответ дан 2 December 2019 в 02:49
поделиться

всевозможные «следы».

0
ответ дан 2 December 2019 в 02:49
поделиться

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

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

1
ответ дан 2 December 2019 в 02:49
поделиться

It's already been mentioned here, but I'll say it again because I believe this cannot be said enough:

Unnecessary complexity is the arch nemesis of good engineering.

Keep it simple. If things start looking complicated, stop and ask yourself why and what you can do to break the problem down into smaller, simpler chunks.

1
ответ дан 2 December 2019 в 02:49
поделиться

Согласованность стиля кодирования во всем проекте.

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

1
ответ дан 2 December 2019 в 02:49
поделиться

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

В общем, строгая типизация - это лучший путь imho

1
ответ дан 2 December 2019 в 02:49
поделиться

Предлагаемые книги: "Код завершен" и "Освободить его" - две книги по этой теме, которые необходимо прочитать.

1
ответ дан 2 December 2019 в 02:49
поделиться

Модульное тестирование с последующей непрерывной интеграцией.

1
ответ дан 2 December 2019 в 02:49
поделиться

Using an IDE like IntelliJ that inspects my code as I write it and flags dodgy code as I write it.

1
ответ дан 2 December 2019 в 02:49
поделиться

Требования.

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

3
ответ дан 2 December 2019 в 02:49
поделиться

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

3
ответ дан 2 December 2019 в 02:49
поделиться

Модель-Представление-Контроллер и вообще все, что связано с контрактами и интерфейсами, которые можно тестировать автоматически.

4
ответ дан 2 December 2019 в 02:49
поделиться
  1. Стремитесь к простоте и лаконичности .
  2. Никогда не оставляйте случаев, когда поведение вашего кода не определено .
  3. Ищите возможности для использования type system и пусть компилятор как можно больше проверяет во время компиляции. Шаблоны и генерация кода - ваши друзья, пока вы придерживаетесь здравого смысла.
  4. Сведите к минимуму количество синглтонов и глобальных переменных.
  5. Используйте RAII !
  6. Используйте утверждения ]!
  7. Автоматическое тестирование некоторых номинальных и всех угловых случаев.
  8. Избегайте изменений в последнюю минуту, как чумы.
14
ответ дан 2 December 2019 в 02:49
поделиться

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

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

5
ответ дан 2 December 2019 в 02:49
поделиться

Изучение функционального программирования как-то помогает. ЗДЕСЬ
Научи вас хаскеллом для большого блага.

5
ответ дан 2 December 2019 в 02:49
поделиться

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

asserts

5
ответ дан 2 December 2019 в 02:49
поделиться

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

15
ответ дан 2 December 2019 в 02:49
поделиться

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

13
ответ дан 2 December 2019 в 02:49
поделиться

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

8
ответ дан 2 December 2019 в 02:49
поделиться
18
ответ дан 2 December 2019 в 02:49
поделиться

Automated Unit Testing .

32
ответ дан 2 December 2019 в 02:49
поделиться

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

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

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

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

20
ответ дан 2 December 2019 в 02:49
поделиться

Проверка кода; Я лично обнаружил множество ошибок в коде своих коллег, и они нашли ошибки в моем.

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

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

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

2
ответ дан 2 December 2019 в 02:49
поделиться

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

7
ответ дан 2 December 2019 в 02:49
поделиться

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

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

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

4
ответ дан 2 December 2019 в 02:49
поделиться

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

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

0
ответ дан 2 December 2019 в 02:49
поделиться

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

Буквально вчера обнаружил действительно неприятную ошибку, не отладив ни одной строки:

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

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

0
ответ дан 2 December 2019 в 02:49
поделиться
Другие вопросы по тегам:

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