От джуна до сеньора: Как стать востребованным разработчиком - Владимир Швец
Шрифт:
Интервал:
Закладка:
История из жизни
Моя самая дорогая ошибка обошлась бы мне в 3 миллиона рублей плюс сильный удар по репутации. Я занимался разработкой системы биллинга, и из-за досадной цепочки моих недосмотров были утеряны данные платежей пользователей за сутки. Ситуация складывалась весьма неприятная, но у меня был запас времени: до момента, когда компания собиралась сделать заявление и рассылку с извинениями, оставалось два выходных дня. Это были крайне непростые два дня, за которые я все же сумел придумать и написать решение, способное восстановить историю покупок, хоть и с опозданием. Старайтесь воспринимать все свои ошибки серьезно. Какие-то обойдутся вам легко – только в то, что, обнаружив их, вы скажете «ОЙ». А другие станут очень ценным (иногда буквально) опытом, про который вы никогда не забудете.
Паттерны проектирования
Использование паттернов проектирования в коде – давний предмет споров и стычек на рабочем месте. Особое место в спорах эта тема занимает из-за того, что разработчики очень любят декомпозицию и качественные, элегантные решения. Если бы в разработке программного обеспечения был свой пророк Моисей, то, вероятно, с горы Синай он спустился бы с паттернами проектирования. Вам нужно будет хотя бы поверхностно ознакомиться со списком паттернов, чтобы понять, о чем я буду вести речь (да, вам опять понадобится Google).
Появление концепции паттернов проектирования для разработки программного обеспечения было предрешено. Эта область как никакая другая подходит для попытки классификации типичных проблем и их решений. Паттерны проектирования дают разработчикам способ унификации своего кода для ряда повторяющихся проблем, делают его более единообразным, узнаваемым и интуитивно понятным. Но до определенного предела. Опасность использования паттернов проектирования кроется именно в их универсальности и абстрактности по отношению к проблеме. Как говорится, если у вас в руках молоток, все начинает напоминать гвозди.
Начинающие разработчики частенько влюбляются в паттерны проектирования и пытаются использовать их везде, где только можно. Я постараюсь уберечь вас от этого.
Поймите меня правильно, паттерны проектирования – прекрасная практика, вы можете использовать их, и в некоторых ситуациях от вас будут ждать именно такого подхода. Однако вы должны отчетливо понимать, для чего вы это делаете и действительно ли выбранный вами паттерн подходит под вашу проблему.
Не относитесь к паттернам проектирования как к серебряной пуле, у вас есть достаточно способов решения проблемы, и только они и ваш опыт подскажут, какое решение подойдет лучше всего. Красота и элегантность кода – это не все, что требуется от качественного продукта (чуть позже мы обсудим это в теме про оптимизацию).
Будьте рассудительны. Если перед вами гвоздь – пожалуйста, беритесь за молоток, но, если вы не уверены до конца, потратьте чуть больше времени, принесите все инструменты и проверьте, что подойдет лучше всего.
Тезисы
■ Паттерны проектирования – благо и проклятие.
■ Не используйте паттерны проектирования для решения всех на свете проблем.
■ Подходите к выбору решения прагматично, хладнокровно и осознанно.
Задание
Ознакомьтесь с паттернами проектирования и проанализируйте код вашего проекта: используются ли на нем какие-то из описанных паттернов? Выясните, есть ли в вашем проекте места, которые идеально подходят под описание проблемы одного из паттернов проектирования. Сделайте рефакторинг, реализовав выбранный вами код в рамках выбранного паттерна. Насколько новый код представляется вам лучше старого? Стал ли код более читаемым, лучше расширяемым или интуитивно понятным?
История из жизни
Мое первое знакомство с паттернами программирования было шапочным, и не могу сказать, что я был впечатлен. На сколько-то лет я забыл об их существовании, пока не понял, что многие из написанных мной решений принимают определенную, повторяющуюся форму. После чего я решил освежить свои знания и при повторном знакомстве с паттернами хихикал, отмечая в голове те, к которым пришел с опытом. Мог бы я сберечь себе время, если бы уделил паттернам должное внимание при первом знакомстве? Безусловно. Получил бы я столько опыта, если бы не забыл их и не дошел до них практическим путем? Боюсь, что нет, не получил бы.
Переабстракции
Большинство языков программирования дает обширный набор конструкций, позволяющих при работе над кодом создавать сложнейшие абстракции. Их может быть так много, что сам анализ задачи, возможно, превратится в нескончаемый процесс подбора комбинаций из интерфейсов, поздних связываний, абстрактных классов и виртуальных функций. Ведьмин круг, из которого вы не сможете выбраться.
Идентичность языка определяется, помимо прочего, его подходом к предоставлению свободы разработчику. Некоторые языки программирования дадут вам десяток способов по-разному совершить одно и то же действие (C++, как здорово, что ты зашел). От других вы дождетесь в лучшем случае двух (Go, заходи, присаживайся). Какой подход предпочтительнее, покажет опыт, но если вы уже работаете с проектом на конкретном языке программирования, то вам остается одно: следовать принятым соглашениям о способах использования возможностей языка. В худшем случае ваши коллеги никак не обсуждают этот вопрос и каждый из них пишет код так, как считает правильным (о, эта дивная кроличья нора!).
Однако у вас есть возможность помочь себе и коллегам: абстрагируйте код ровно до той степени, пока он не начнет делать то, что указано в требованиях к нему. Ваша работа – не соревнование «кто напишет самый абстрактный, гибкий (и неподдерживаемый) кусок кода на всем проекте». Этот код будут поддерживать ваши коллеги – пожалейте их, не всем нравится продираться через хрустальные замки интерфейсов и дюжины классов с множественным наследованием.
Если вы ожидаете, что ваш код будет часто и значительно меняться в ближайшем будущем, дайте себе чуть больше свободы в абстракциях, но не бросайтесь в омут с головой. В случае необходимости будет проще переписать этот код с нуля, чем тратить время и нервы на попытки понять, как же он должен работать. Во всех остальных случаях – keep it simple[2]! Если вы чувствуете непреодолимую жажду сотворить нечто невероятно сложное из всех конструкций языка, до которых сможете дотянуться, – создайте свой самый запутанный и понятный только вам pet project, он точно вас не разочарует.
Тезисы
■ Разные языки программирования предоставляют различный уровень абстракций.
■ Используйте ровно тот уровень абстракций, который работает для вашей задачи.
■ Пишите просто – этот код придется поддерживать вам и вашим коллегам (а они могут знать, где вы живете).
Задание
Узнайте, какой уровень абстракций предлагает язык программирования вашего проекта. Проанализируйте код проекта: есть ли негласные правила использования тех или иных возможностей языка разработчиками? Попробуйте решения, которые можно выполнить с меньшим уровнем абстракций, сделав код более интуитивным и простым.
История из жизни
Однажды при найме нового разработчика я получил от него тестовое задание, которое включало в себя довольно простую задачу: в ней требовалось реализовать веб-приложение, позволяющее редактировать текстовые заметки. Обычно кандидаты ограничиваются минимальным набором необходимых классов и компонентов, но на сей раз это оказалась целая заготовка большой системы, состоящей из интерфейсов, трейтов, абстрактных классов, фабрики заметок и прочего. При личной встрече я первым делом задал вопрос: «Почему вы решили так усложнить задание?» На что получил более чем достойный и ожидаемый (в душе) ответ: «Я просто готовился к тому, что эту систему придется в дальнейшем расширять».
Оптимизация
Оптимизация – это способ сделать уже написанный код более быстрым, менее требовательным к ресурсам и более отвечающим нуждам задачи, которую он выполняет. Оптимизация возможна почти для любого написанного кода, но в большинстве случаев она нужна только в конкретных местах проекта.
Задачи оптимизации кода, его быстродействия крайне важны, и отчасти вы уже оптимизируете код, даже не осознавая этого. Многие языки программирования включают механизмы оптимизации в свои инструменты:
