Каковы хорошие стратегии для исправления ошибок, когда код становится более сложным? - PullRequest
17 голосов
/ 13 февраля 2009

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

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

Итак, насколько важны ошибки для людей с профессиональной подготовкой?

Спасибо - Эл С.

Ответы [ 14 ]

24 голосов
/ 13 февраля 2009

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

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

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

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

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

15 голосов
/ 13 февраля 2009

Вы автоматизируете свои тесты ? Если вы этого не сделаете, вы регистрируетесь, создавая ошибки, не находя их.

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

Вы пишете юнит-тесты ? Если нет, вы регистрируетесь на длительные сеансы отладки, когда тест не пройден.

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

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

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

5 голосов
/ 13 февраля 2009

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

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

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

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

  4. Изучение деталей, зависящих от языка, помогает избежать ошибок в коде. Например, я узнал, что scanf () - это зло в C!

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

  6. Временами сложно сохранять представление о коде, поэтому я всегда документирую свой код.

  7. Я использую методы, чтобы удостовериться, что существует минимальная зависимость между различными частями моего кода. Интерфейсы, иерархии классов и т. Д. (Отделенный дизайн)

  8. Думать перед тем, как я пишу код, и быть дисциплинированным во всем, что я пишу, - еще один важный навык. Я знаю людей, которые не форматируют свой код, чтобы его можно было читать (содрогаться!).

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

  10. Не будьте парализованы анализом. Написать тесты, затем код, затем выполнить и протестировать. Промыть, промыть, повторить!

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

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

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

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

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

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

  17. Как сказал Джей Баззузи - Код рефакторинга. Я только добавил этот пункт после прочтения его ответа, чтобы сохранить мой список полным. Вся заслуга ему.

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

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

Не обижай никого, кто не согласен. Я надеюсь, что этот ответ поможет.

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

5 голосов
/ 13 февраля 2009
  1. Существует два способа написания безошибочных программ; только третий работает. ~ Алан Дж. Перлис

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

3 голосов
/ 13 февраля 2009

Все остальные ответы великолепны. Я добавлю две вещи.

  1. Контроль источника обязательный . Я предполагаю, что вы здесь на окнах. VisualSVN Server бесплатно и, возможно, 4 клика для установки. TortoiseSVN также бесплатен и интегрируется в Windows Explorer, что позволяет обойти ограничения VS Express, касающиеся отсутствия надстроек. Если вы создаете слишком много ошибок, вы можете вернуть свой код и начать все сначала. Без контроля источника это почти невозможно. Кроме того, вы можете синхронизировать свой код, если у вас есть ноутбук и рабочий стол.
  2. Люди будут рекомендовать множество методов, таких как модульное тестирование, макетирование, инверсия управления, разработка через тестирование и т. Д. Это отличные практики, но не пытайтесь втиснуть все это в свою голову слишком быстро. Вы должны писать код, чтобы лучше писать код, поэтому медленно используйте эти методы в написании кода. Вы должны ползти, прежде чем идти и ходить, прежде чем вы сможете бежать.

Удачи в ваших приключениях по кодированию!

3 голосов
/ 13 февраля 2009

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

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

2 голосов
/ 13 февраля 2009

Если вы просто программист-любитель, изучение полнопроходных TDD и ООП может занять больше времени, чем вы готовы вкладывать. Итак, исходя из того, что вы не хотите тратить время на них Вот несколько легко усваиваемых предложений по устранению ошибок:

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

  2. Превратите магические струны в константы. То есть вместо использования:

    люди [ "мама"]

используйте вместо

var mom = "mom";
people[mom]
  1. Создайте свои функции так, чтобы они либо делали что-то (команда), либо получали что-то (запрос), но не оба одновременно.

Чрезвычайно короткий и легко усваиваемый подход к ООП приведен здесь http://www.holub.com/publications/notes_and_slides/Everything.You.Know.is.Wrong.pdf. Если вы понимаете это, вы получаете суть ООП и откровенно опережаете многих профессиональных программистов.

2 голосов
/ 13 февраля 2009

Ошибки являются общими для всех - профессиональных или нет.

Чем крупнее и распределен проект, тем более осторожным он должен быть. Один взгляд на любую базу данных ошибок с открытым исходным кодом (например: https://bugzilla.mozilla.org/) подтвердит это для вас.

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

Таким образом, обучение имеет очень положительное значение для качества кода ... Но, в конце концов, ошибки все еще пробиваются.

2 голосов
/ 13 февраля 2009

Если бы ошибки не были проблемой, я мог бы написать программу на 100 000 строк за 10 минут!

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

Да: это центральная проблема, даже единственная проблема (для любого достаточно всеобъемлющего определения «ошибка»).

2 голосов
/ 13 февраля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...