■ Разделяйте личный интерес и требования проекта.
Задание
Пофантазируйте. Представьте, что ваш текущий проект – «песочница» и здесь можно пробовать любые технологии и языки. Черт, да вы можете использовать по языку на каждый имеющийся у вас сервис! Подумайте, насколько сложно было бы совместить разные подходы к разработке, архитектуре, инструментам в одном проекте. Попробуйте оценить, насколько бы затянулась по времени реализация одной из ваших задач, если бы для этого использовался другой язык программирования.
История из жизни
Я люблю языки программирования, я люблю пробовать каждый, чтобы понять, каков он, чем он может быть интересен. И так как время мое не резиновое, мне всегда приходится искать способ уместить максимум интереса в минимум времени. С какого-то момента, пробуя новый язык, я стал делать с его помощью «Франкенштейна» – небольшой проект, буквально несколько файлов, в которые старался уместить все особенности языка, используя их так, чтобы они делали хоть что-то осмысленное. Со временем это стало забавной традицией и незамысловатым способом поднять себе настроение.
Ошибки
Любой код содержит ошибки. С увеличением объема кода в нем увеличивается и количество ошибок. Вы можете быть гениальным разработчиком, но никогда не станете разработчиком, не допускающим ошибок. И это хорошо. Ошибки позволяют нам развиваться, делаться более бдительными и интуитивно чувствовать слабые места кода, потенциальные проблемы и способы их устранения.
Как разработчик вы должны писать код, содержащий минимальное количество ошибок. Пытаться классифицировать ошибки – пустая трата времени, поскольку ошибка может заключаться в чем угодно (вы поделили на ноль или на диске закончилось свободное место).
Почти все языки программирования предоставляют определенный уровень контроля ошибок, который вы должны использовать. Однако учитывайте, что во всем должна быть мера. Не нужно писать код так, чтобы на каждую строку было две проверки на ошибки. Соблюдение баланса в контроле ошибок приходит с опытом, когда вы будете предугадывать проблемные места и уделять им чуть больше внимания.
А пока старайтесь регулярно задавать себе вопросы: насколько вероятно, что данная ошибка произойдет? Какие последствия она будет иметь для продукта и пользователя?
Ответ на первый вопрос может быть достаточно непредсказуем (как вы помните, пользователи могут сделать что угодно), поэтому второй вопрос будет для вас более приоритетным. При любой ошибке желательно минимизировать урон для продукта и пользователя. Если существует вероятность, что в случае ошибки пользователь потеряет все свои данные, сделайте все, чтобы была возможность их восстановить. Если же в случае ошибки у пользователя изменится цвет заголовка его личной страницы, это тоже плохо, но вас хотя бы не сожгут на костре.
Старайтесь подходить к обработке ошибок прагматично, исходя из их потенциальной угрозы; не используйте больше контроля, чем необходимо. Возможно, это прозвучит не совсем логично, но вы ХОТИТЕ, чтобы определенные ошибки случались. Система без ошибок невозможна, и некоторые из них помогут вам лучше понять, с какими проблемами столкнулся продукт. Когда ошибки случаются, старайтесь собрать по ним всю доступную информацию, какую только можете получить (логи, stack traces, дампы данных), но, опять же, не пишите в лог каждое действие. В лучшем случае это просто оставит терабайтные файлы логов, в худшем – будет мешать работе пользователей или замедлять ваш продукт.
Тезисы
■ Не бывает кода без ошибок.
■ Используйте системы контроля ошибок с умом.
■ Относитесь к ошибкам прагматично, некоторые из них вам нужны.
■ Спрашивайте себя: как эта ошибка может случиться? Какой вред она причинит продукту и пользователю?
Задание
Проанализируйте код вашего проекта, узнайте, каким образом вы контролируете потенциальные ошибки. Оцените, какие области кода требуют больше внимания (если у вас есть подсистемы, работающие с денежными переводами пользователей, я очень выразительно смотрю в их сторону).
История из жизни