Я согласен на 95% с вышенаписанным. Всё это конечно правильно, но есть 3 аспекта, которые необходимо учитывать.
1. Культура программирования. Пусть разработка ведётся на нектором процедурном языке программирования и положим, что мы умные парни и работаем по варианту 2. Даже если нам необходимо написать простую функцию преобразования какой-то строчной величины в число мы столкнёмся с тем, что наша функция будет возвращать не число, а строку
private String s2i ( String s, out int Result) И только в том случае, если код строки возврата соответствует коду успешного завершения можно смотреть содержимое Result. Возникающие при этом проблемы - все программисты работающие в проекте должны быть проинформированы о том, что мы возвращаем код ошибок - основные группы ошибок должны быть выделены и классифицированы и модуль их обработки должен быть написан или хотя бы продуман ДО того, как будут написаны другие модули. Проблемы: Количество кодов возврата нельзя всегда предугадать зарание. При достаточно сложных ошибках требуется их специальная обработка и сложность модуля обработки ошибок возрастает.
Поэтому используют расширяемую систему исключений. Однако принцип остаётся тем же. Модуль или система обработки ошибок должны быть написаны или хотя бы спроектированы ДО того как будут написаны другие слои системы.
На модуль/систему обработки ошибок возлагаются следующие требования - фиксация ошибки (логгинг) - обработка ошибки - уведомление пользователя об ошибке (в том числе на понятном ему языке) Но проектирование и разработка этой подсистемы должны быть выполнены или хотя бы продуманны до того, как будут написаны другие модули. Теперь представим ситуацию, в которой разработчик приходит в проект в котором горят сроки, этот проект уже запущен, но система обработки ошибок не спроектированы. Человеку нужно заработать свои деньги, и из самых лучших побуждений он может выполнить обработку ощибок только в ограниченном объёме в вверенной ему функциональности.
2. Интерграция legacy систем, third-party продуктов, EAI проекты - очень часто написать нормальную обработку ошибок тут бывает трудно, так как какая-та внешняя dll не предоставляет необходимой информации, а "умирает молча". И даже если чудесным образом найдены исходники, то затраты на обработку и отладку чужого кода могут быть очень велики.
3. Иногда сроки важнее качества или кто отвечает за ошибки.
Это звучит парадоксально, но бывает так, что у заказчика нет денег на крутую систему, которая работает надёжно и обрабатывает большинство ошибок. То есть денег сейчас нет, но они будут и выйдет вторая версия программы, а вот сейчас пожалуйста уложитесь в сроки, господа разработчики. Недавно меня ругали на рабочем митинге за то, что я делаю и заставляю других разработчиков делать валидацию клиентского ввода, а это не предусмотрено спецификацией. Я, безусловно, сделал так как я считаю правильным. Я являлся техническим руководителем проекта, а он был начальником подразделения, и сверху пришёл приказ экономить.
Если мы посмотрим на ситуацию с Тойотой и зададимся вопросом, кто пострадал, то увидим:
- да пострадали конечные пользователи автомобилей попавшие в аварию. К сожалению, в разработке программного обеспечения интересы конечных пользователей учитываются редко. Прежде всего учитываются интересы стейкхолдеров. И так как в подавляющем большинстве случаев конечные пользователи не являются стекхолдерами, то они получают продукты с которыми им приходиться мириться и к которым приходиться привыкать - репутация Тойоты пострадала мало. Более того, я считаю фирму признавшую свою ошибку и отозвавшую свою продукцию фирмой честной и заслуживающую уважения. - денежные потери Тойоты не являются такими большими, как кажется, так как её риски перенимают крупные страховые компании.
То есть налицо разделение ответственности за ошибки. И если была дана команда сделать программу быстро и названы очень сжатые сроки нельзя упрекать разработчиков, что сообщение об ошибке не отображается на французском языке.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2010-03-08 07:30 am (UTC)1. Культура программирования.
Пусть разработка ведётся на нектором процедурном языке программирования и положим, что мы умные парни и работаем по варианту 2. Даже если нам необходимо написать простую функцию преобразования какой-то строчной величины в число мы столкнёмся с тем, что наша функция будет возвращать не число, а строку
private String s2i ( String s, out int Result)
И только в том случае, если код строки возврата соответствует коду успешного завершения можно смотреть содержимое Result.
Возникающие при этом проблемы
- все программисты работающие в проекте должны быть проинформированы о том, что мы возвращаем код ошибок
- основные группы ошибок должны быть выделены и классифицированы и модуль их обработки должен быть написан или хотя бы продуман ДО того, как будут написаны другие модули.
Проблемы: Количество кодов возврата нельзя всегда предугадать зарание. При достаточно сложных ошибках требуется их специальная обработка и сложность модуля обработки ошибок возрастает.
Поэтому используют расширяемую систему исключений. Однако принцип остаётся тем же. Модуль или система обработки ошибок должны быть написаны или хотя бы спроектированы ДО того как будут написаны другие слои системы.
На модуль/систему обработки ошибок возлагаются следующие требования
- фиксация ошибки (логгинг)
- обработка ошибки
- уведомление пользователя об ошибке (в том числе на понятном ему языке)
Но проектирование и разработка этой подсистемы должны быть выполнены или хотя бы продуманны до того, как будут написаны другие модули. Теперь представим ситуацию, в которой разработчик приходит в проект в котором горят сроки, этот проект уже запущен, но система обработки ошибок не спроектированы. Человеку нужно заработать свои деньги, и из самых лучших побуждений он может выполнить обработку ощибок только в ограниченном объёме в вверенной ему функциональности.
2. Интерграция legacy систем, third-party продуктов, EAI проекты - очень часто написать нормальную обработку ошибок тут бывает трудно, так как какая-та внешняя dll не предоставляет необходимой информации, а "умирает молча". И даже если чудесным образом найдены исходники, то затраты на обработку и отладку чужого кода могут быть очень велики.
3. Иногда сроки важнее качества или кто отвечает за ошибки.
Это звучит парадоксально, но бывает так, что у заказчика нет денег на крутую систему, которая работает надёжно и обрабатывает большинство ошибок. То есть денег сейчас нет, но они будут и выйдет вторая версия программы, а вот сейчас пожалуйста уложитесь в сроки, господа разработчики.
Недавно меня ругали на рабочем митинге за то, что я делаю и заставляю других разработчиков делать валидацию клиентского ввода, а это не предусмотрено спецификацией. Я, безусловно, сделал так как я считаю правильным. Я являлся техническим руководителем проекта, а он был начальником подразделения, и сверху пришёл приказ экономить.
Если мы посмотрим на ситуацию с Тойотой и зададимся вопросом, кто пострадал, то увидим:
- да пострадали конечные пользователи автомобилей попавшие в аварию. К сожалению, в разработке программного обеспечения интересы конечных пользователей учитываются редко. Прежде всего учитываются интересы стейкхолдеров. И так как в подавляющем большинстве случаев конечные пользователи не являются стекхолдерами, то они получают продукты с которыми им приходиться мириться и к которым приходиться привыкать
- репутация Тойоты пострадала мало. Более того, я считаю фирму признавшую свою ошибку и отозвавшую свою продукцию фирмой честной и заслуживающую уважения.
- денежные потери Тойоты не являются такими большими, как кажется, так как её риски перенимают крупные страховые компании.
То есть налицо разделение ответственности за ошибки. И если была дана команда сделать программу быстро и названы очень сжатые сроки нельзя упрекать разработчиков, что сообщение об ошибке не отображается на французском языке.