February 24th, 2010

Перевод "97 Things Every Software Architect Should Know"

97 вещей, которые должен знать каждый архитектор ПО



Оригинал лежит вот тут: 97 Things Every Software Architect Should Know

К сожалению, near-time решило чего-то непонятное замутить с переименованием себя в strategy nets, в результате чего доступа к оригиналам этой серии не стало. Пока переводы приостанавливаются (вдруг оригиналы таки где-то еще появятся).

Переведено: 56 из 97.

И да, ссылки на оригиналы, конечно же, работать перестали.

Collapse )

Они же на моем сайте avl2.info

Текст оригиналов выложен под лицензией Creative Commons Attribution 3. C переводами можете поступать так же :)

Позитив

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

Но вот вчера бросаю я туда 1 евро, а молока мне наливается максимум на 15 центов. На млекомате никаких ошибок и сигналов о том, что молоко закончилось, нет (как-то на другом млекомате я такое сообщение наблюдал). Что делать? Набираю указанный на млекомате номер - там никто не отвечает. Так и уехал ни с чем домой...

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

И ведь привезли еще минут через двадцать! Человек, привезший его, сказал, что да, именно этот млекомат не выдает сообщений о том, что молоко закончилось, и если что, то звоните, привезем :)

Вот такая забота о клиенте по-словенски :) Буду значит и дальше молоко и другие продукты покупать у них :)

26. Не игнорируйте ошибки.

(В оригинале - Don't Ignore that Error!)

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

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

Но ведь я же спешил на встречу с друзьями! И когда я добрался до бара, боль стала невыносимой. Я не получил никакого удовольствия из-за боли. А когда утром я пошел к врачу, оказалось, что у меня сложный перелом голени. Остановись я сразу, как только почувствовал боль, проблем было бы гораздо меньше – ходьба на сломанной ноге ни к чему хорошему не приводит. Возможно, это было худшим утром в моей жизни.


Слишком много программистов пишет столь же неосмотрительно, как вел себя я той ночью.

Ошибка? Какая еще ошибка? Она наверняка несерьезная. Честно. Я могу не обращать на нее внимания. Однако это проигрышная стратегия. А если честно, это всего лишь лень (причем лень неконструктивная!). Какой бы ничтожной ни была на ваш взгляд ошибка в вашем коде, она обязательно должна быть исправлена или обработана. Всегда. Вы не выиграете время, если не сделаете этого. Вы лишь спрячете потенциальную проблему на будущее.

Мы оповещаем об ошибках во время выполнения различными способами:

  • Код возврата. Он может применяться для оповещения о том, что «что-то пошло не так». Код возврата слишком просто проигнорировать. И вы ничего не заметите вообще. Более того, игнорирование кодов возврата некоторых стандартных функций стало уже традицией. Как часто вы проверяете код возврата функции printf()?
  • errno. Это такая особенность С, глобальная переменная, хранящая код последней случившейся ошибки. Его легко проигнорировать, сложно использовать, к тому же его использование вызывает множество других проблем – представьте многопоточную систему, в которой вызывается одна и та же функция. Некоторые платформы что-то делают, чтобы облегчить использование errno, другие не делают ничего.
  • Исключения. Более структурированная языковая конструкция для сообщения об ошибках. К тому же, вы не можете их игнорировать. Или все же можете? Как насчет вот такого кода?


try {
// ...do something...
}
catch (...) {} // ignore errors

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

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

Игнорирование ошибок приводит к:

  • Ненадежному коду. Коду, наполненному неуловимыми и сложноисправляемыми ошибками.
  • Небезопасному коду. Хакеры часто используют игнорирование кодов ошибок, и очень часто делают это весьма успешно, «ломая» системы.
  • Плохо структурированному коду. Если аккуратная обработка ошибок слишком скучна, скорее всего, это результат плохо продуманного интерфейса. Переделайте его так, чтобы обрабатывать ошибки было не так обременительно.


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

Почему мы не проверяем ошибки? Есть несколько общепринятых отговорок. С какими из них вы согласитесь?

  • Обработка ошибок загромождает код, делая его нечитаемым и не позволяя легко отследить основной поток выполнения.
  • Обработка ошибок требует дополнительных усилий, а у меня дедлайн надвигается.
  • Я уверен, что эта функция никогда не вернет ошибку (printf работает всегда, malloc всегда выделит запрашиваемый объем памяти, а если нет – мы все равно ничего не сможем сделать, ведь это значит, что не работает вся система)
  • Это несерьезная программа, нет смысла ее писать с промышленным качеством.


Автор оригинала - Pete Goodliffe

Перевод мой, при использовании ссылка на мой живой журнал обязательна!