От джуна до сеньора

Тезисы

■ Не бывает кода без ошибок.

■ Используйте системы контроля ошибок с умом.

■ Относитесь к ошибкам прагматично, некоторые из них вам нужны.

■ Спрашивайте себя: как эта ошибка может случиться? Какой вред она причинит продукту и пользователю?

Задание

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

История из жизни

Моя самая дорогая ошибка обошлась бы мне в 3 миллиона рублей плюс сильный удар по репутации. Я занимался разработкой системы биллинга, и из-за досадной цепочки моих недосмотров были утеряны данные платежей пользователей за сутки. Ситуация складывалась весьма неприятная, но у меня был запас времени: до момента, когда компания собиралась сделать заявление и рассылку с извинениями, оставалось два выходных дня. Это были крайне непростые два дня, за которые я все же сумел придумать и написать решение, способное восстановить историю покупок, хоть и с опозданием. Старайтесь воспринимать все свои ошибки серьезно. Какие-то обойдутся вам легко – только в то, что, обнаружив их, вы скажете «ОЙ». А другие станут очень ценным (иногда буквально) опытом, про который вы никогда не забудете.

Паттерны проектирования

Использование паттернов проектирования в коде – давний предмет споров и стычек на рабочем месте. Особое место в спорах эта тема занимает из-за того, что разработчики очень любят декомпозицию и качественные, элегантные решения. Если бы в разработке программного обеспечения был свой пророк Моисей, то, вероятно, с горы Синай он спустился бы с паттернами проектирования. Вам нужно будет хотя бы поверхностно ознакомиться со списком паттернов, чтобы понять, о чем я буду вести речь (да, вам опять понадобится Google).

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

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

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

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

Будьте рассудительны. Если перед вами гвоздь – пожалуйста, беритесь за молоток, но, если вы не уверены до конца, потратьте чуть больше времени, принесите все инструменты и проверьте, что подойдет лучше всего.