Лучшие практики для [закрытой] устойчивости
9 ответов
Я реализую множество методов, чтобы предотвратить и восстановиться с ошибок:
1) Обработайте все исключения. Как Вы заявили, "обработайте каждую ошибку". Если пользователь нажимает кнопку на форме, не должно быть никакой возможности приложения, просто исчезающего ("пуф") из необработанного исключения. По этой причине я переношу обработчики событий с универсальной выгодой попытки.
2) Ошибки журнала с полным отслеживанием стека. Когда я повторно бросаю исключение, я всегда создаю новый и добавляю перехваченную исключительную ситуацию как внутреннее исключение. Мой код входа разворачивает сообщения рекурсивно, который предоставляет немного больше подробной информации, чем я имел бы иначе.
3) Решите, будут ли Ваши классы допускающими повторное использование или нет. Если не документируют его. Рассмотрите реализацию интерфейса в Вашем коде, чем-то как IRestartable или IReusable. Любой объект не реализация его должна быть выброшена после того, как это будет использоваться однажды.
4) Никогда не принимайте потокобезопасность. Я научился на горьком опыте, что.NET является чрезвычайно многопоточной. Много событий обрабатываются на произвольных потоках. Данное приложение, записанное в.NET, могло иметь много одновременного выполнения потоков и не иметь одну строку кода, явно создающего один.
5) Сохраните переменный объем максимально узким. Инстанцируйте объектов рядом, где они используются вместо в большом блоке в начале метода. Вы потенциально сократите жизнь объектов, и Вы не забудете о ненужных или снова использованных переменных, находящихся в огромном блоке наверху класса или метода.
5) Простой, но я все еще вижу, что он происходит. Избегайте globals как чумы. Я видел код с сотнями неиспользованных/снова использованных переменных. Это была путаница, чтобы выяснить и осуществить рефакторинг.
Я - поклонник методов, описанных в "Прагматически настроенном Программисте". Я также использую TDD, а не DBC, поскольку я нахожу это более гибким и продуктивным. Например, некоторые techniqes, описанные в 'pragprog', включают:
- Тестируйте часто. Тест рано. Протестируйте автоматически
- Не повторяйте себя
- Используйте саботажников для тестирования тестирования
- Используйте исключения для исключительных проблем
- Не живите с разбитыми окнами
- Не используйте ручные процедуры
Они все походят на здравый смысл, но ее удивительное, как быстро команды отклоняются от этих принципов основы, когда сталкивающийся с крайними сроками.
Я люблю вторую пару глазного метода: после того, как я запишу и протестирую некоторый критический код, я буду иногда просить, чтобы коллега рассмотрел его конкретно с намерением поиска способов повредить его.
Интересно произвести креативность людей этот путь.:-)
Кажется, что у Вас уже есть эти два вниз:
Перестали работать быстро. http://en.wikipedia.org/wiki/Fail-fast
Безопасный сбой. http://en.wikipedia.org/wiki/Fail-safe
Эти три, вероятно, служат мне лучше, чем кто-либо другой:
Избегайте состояния, когда это возможно. Создайте и используйте неизменные объекты - их легче протестировать и менее вероятно предать Вас.
Не пишите ненужный код. Этот тверд. Проверьте недавний цветок статей, связывающих "Элементы Стиля" Strunk и White к программированию.
Спрашивайте себя каждые 10 минут или так: "Действительно ли это является немым?" Будьте честны. Этот более тверд.
- Jason
Я пытаюсь использовать Дизайн контракта как можно больше. Но я нахожу, что это редко практично в моем поле работы.
Мне нравится к... предельным значениям документа в (Java) документ. (параметр может быть пустым? быть пустыми?)
Тот путь, когда мой код используется (или когда я использовал свой собственный код), я знаю то, что я могу ожидать. Простая рекомендация, но так редко реализовываемый ;)
Та документация также включает четкое разделение статических и исключений на этапе выполнения. Тот путь, если программа должна перестать работать как можно скорее для улучшения устойчивости, я знаю, перестало ли это работать из-за предсказанного исключения (статичный, с нужно иметь дело при кодировании канавки времени выгода или перебросок), или если это из-за неправильных параметров (исключения на этапе выполнения, только обнаруженные в течение времени жизни приложения).
Если оба типа исключения ясно документируются (особенно, когда оно приходит к предельным значениям для параметров), полную устойчивость легче осуществить.
Я - поклонник не инициализации локальных переменных. Они должны быть установлены при необходимости. Иначе программисты, читающие Ваш код, могли быть смущены как в "hmm why is this 0 at the beginning...". Если Вы не инициализируете его, ясно, что это еще не используется.
Когда это возможно, я спрашиваю мнение кого-то, кто специализируется на чем-то еще. Это часто раскрывает один или несколько совершенно новых способов повредить вещи.
Быть параноидальным является чертой выживания для программистов. Постоянно спрашивайте себя, как это может перестать работать? Затем попытайтесь выяснить, как предотвратить тот отказ.