Не перестаю удивляться тому, как много вопросов вроде «Какой x лучше?» встречается на Programmers.SE и Stack Overflow. Время от времени мне приходится вступать с друзьями и коллегами в дискуссии, тема которых формулируется так: «А что вы думаете о x?». Темы двух этих разновидностей объединяются тем, что x — это какой-либо язык, фреймворк или инструмент.
Рискну высказать здесь непопулярную точку зрения и сформулирую суть статьи таким образом: если вы освоили новый инструмент, это еще не значит, что вы стали более классным разработчиком.
Вы совершенствуетесь как профессионал, осваивая новые умения, инструменты в данном случае играют вспомогательные роли.
Начну с примера из моего собственного опыта. Еще в университете я стал заниматься разработкой с ASP.NET WebForms. Вскоре я очень хорошо разобрался в этом фреймворке, научившись приспосабливать его для обработки каких угодно частных случаев, что встречались мне на практике. Я наловчился самостоятельно писать расширения и эффективно переиспользовать уже задействованные компоненты. Сам я считал себя талантливым программистом, а работодатели воспринимали меня как довольно умелого специалиста. Но после долгих раздумий я теперь понимаю, что разработчик из меня был никудышный.
Через некоторое время в общем доступе появился фреймворк ASP.NET MVC, вызвавший всеобщее ликование. Я же воспринял новинку саркастически, будучи уверенным, что любой мой сайт получится более быстрым, функциональным и стабильным, чем у другого разработчика, который попытается сделать такой же ресурс при помощи MVC. Я стал изучать MVC, но этот шаблон был для меня совершенно непривычен, я с огромным трудом усваивал его основополагающие принципы и приемы разработки с его помощью. Оказалось, что я превосходно владею ASP.NET WebForms, но остаюсь довольно посредственным программистом.
Через некоторое время поддержка WebForms прекратилась, и у меня началась черная полоса. Хуже всего пришлось из-за нерационального использования JavaScript; я просто не понимал, что вставлять код JS на страницу и выполнять его именно в момент использования элемента управления — слишком затратный и медленный метод. Конечно, код переиспользовался на машинном интерфейсе, но неидеально, поскольку многие операции были актуальны именно для той страницы, которая их вызывала, и никак не касались совместного использования той или иной методологии доступа к данным. Код пользовательского интерфейса получался раздутым и уродливым. Именно в этой ситуации я понял, что самое время переходить к использованию MVC; очевидно, с его помощью я мог бы сделать код чище, ведь до меня это уже удавалось другим коллегам. Прошло время, я стал отличным специалистом по MVC. Но при этом оставался плохим разработчиком.
Наконец, я осознал, что и фреймворк MVC не идеален. Некоторые его детали оказались угловатыми и неудобными (например, Microsoft AJAX). В MVC порой получался очень чистый код, но этого удавалось достичь не всегда [1]. На этом этапе карьеры я стал изучать NUnit и принципы разработки через тестирование. Быстро стал настоящим фанатом модульного тестирования, а качество моего кода значительно повысилось.
Примерно в тот же период, когда я осваивал разработку через тестирование (TDD), меня заинтересовали Agile-методологии, в частности, как они могут помочь мне улучшить навыки разработки. Именно этот момент можно считать поворотным. Я стал пользоваться собственной небольшой Kanban-доской для управления резервом проекта (project backlog) — и опять же добился качественного скачка в профессионализме. Теперь я четко представлял, какие задачи предстоит решить в первую очередь, гораздо более рационально группировал одни важные задачи с другими. Я стал опираться на технику, которая никак не являлась частью процесса разработки, не была специальным инструментом, но действительно улучшала результаты моего труда. Мне пришлось изучить, как именно строятся рабочие процессы, а не просто освоить новое «приспособление». И мой код становился все лучше [2].
С тех пор я стал работать гораздо вдумчивее, анализировать свои навыки и пытаться определить, на самом ли деле я понимаю, «как это работает», а не «как это вертится». Я написал собственный MVC-фреймворк на node.js. Так я хотел доказать себе, что не просто умею использовать шаблон MVC или писать код на JavaScript, но и понимаю, каким образом этот шаблон помогает мне писать более качественный код. В ходе работы я подробно познакомился со спецификацией HTTP и теперь действительно понимаю принципы работы Веба, а не просто делаю программы для него.
Все это приводит меня к исходной посылке. Оглядываясь назад, я понимаю, что вырос как разработчик, не просто изучив практику использования ASP.NET MVC, jQuery, Node.js, а заглянув несколько глубже. Я научился применять шаблон MVC в другом языке, где действуют иные принципы. Осознал, как именно базовый фреймворк WebForms взаимодействует с браузером, а не просто научился писать собственный указатель времени/даты.
Ничего не стоит увлечься новым инструментом. Иногда возможности нового фреймворка вас просто очаровывают, вы не сомневаетесь, что он позволит вам писать приложения не только быстрее, но и надежнее. Скажем, вы уверены, что на Silverlight сможете написать просто отличный насыщенный веб-клиент — так что не стоит заморачиваться и учить для этого новый язык [3]. Я сам не раз оказывался в такой ситуации. Самое важное при этом — понимать, что новые фреймворки действительно очень хороши, и следует расширять свой кругозор, насколько это возможно. Но не забывайте, что ни один фреймворк не вечен, и все инструменты рано или поздно устаревают.
Рынок труда в ИT-индустрии, похоже, этого не учитывает. За последний год я видел множество вакансий, и большинство из них озаглавлены как «Требуется разработчик на <язык>» или «Требуется разработчик со знанием <фреймворк>». Далее идет список языков и фреймворков, с которыми соискатель должен иметь опыт работы на протяжении, допустим, последних трех лет [4]. Вероятно, рекрутер или HR-менеджер может не понимать, что у любого языка, фреймворка и инструмента обязательно найдутся параллели. Возьмем, к примеру, C#. Этот язык очень сильно завязан на Microsoft, а .NET-фреймворк содержит определенный набор инструментов, которые вам наверняка пригодятся, — например, NUnit. Но в основе своей C# очень похож на Java. Да, на Java анонимная функция объявляется совершенно иначе, и для этого используется JUnit, а не NUnit, но любой умелый C#-разработчик должен полностью сориентироваться в Java за очень короткое время.
С другой стороны, вполне возможно, что средний C#-разработчик будет испытывать значительные проблемы с Ruby. Динамические и статические языки настолько отличаются на практике, что при их использовании действуют совершенно разные приемы и принципы [5]. Внедрение зависимостей? Совершенно не требуется в динамических языках. Интерфейсы? Да, но совсем не такие, к каким вы привыкли.
Как же справиться с этой проблемой? Начнем с того, что здесь мы сталкиваемся сразу с несколькими фундаментальными проблемами. Во-первых, многие программисты считают, что «если я хорошо знаю Rails, то я классный разработчик». Чтобы преодолеть это заблуждение, нужно стимулировать новых разработчиков к «многостаночному» развитию. Я совершенно уверен, что в такой широкой области как наша, разумнее всего прививать изменения «снизу». Если все новые разработчики будут начинать профессиональную карьеру, зная, что для выполнения всех стоящих перед ними задач мало одного языка или одного фреймворка, то все больше специалистов будут развиваться, изучая широкий диапазон технологий, а не просто углубляясь в любимый фреймворк (а потом — в новый любимый фреймворк).
Вторая проблема связана с организационными изменениями. Большинство айтишных компаний тяготеют к использованию каких-то определенных фреймворков, и их руководство намерено так работать и дальше. С одной стороны, это вполне разумно: зачем отказываться от того, что точно нам подходит? Недавно у меня зашел разговор с одним программистом, работающим с node.js. Он утверждал, что node.js — идеальный инструмент на все случаи жизни, а я пытался убедить его в обратном [6]. Такое отношение, при котором определенный инструмент воспринимается как «в каждую бочку затычка» довольно проблематичен, поскольку в маленькой компании разработчику приходится иметь дело с гораздо менее разнообразными технологиями, чем в крупной. В большой корпорации от вас вполне могут потребовать написать машинный интерфейс совершенно иначе — так, чтобы он соответствовал API, принятому в этой корпорации. Опять же, такие способности должны прививаться снизу. Если вы расширяете собственные горизонты, осваивая новые технологии, то лучше понимаете, какая из них будет наиболее подходящей при реализации того или иного сценария. Не увлекайтесь всем подряд, что кажется новаторским и блестящим, сохраняйте спокойствие и спрашивайте себя: «Я хочу научиться работать с этим инструментом, потому что он хорошо подходит для решения стоящих передо мной задач или потому, что он просто мне нравится?»
Наконец, существует проблема найма. Принципы приглашения новых сотрудников могут изменяться только сверху. Если кто-то из читателей может влиять на набор новых сотрудников в своей организации, то я убедительно прошу вас, господа: обращайте внимание на навыки разработчика, а не только на его резюме [7]. Не перестаю удивляться тому, что во многих ИT-компаниях по-прежнему отсутствует тест на разработку, а если он и имеется, то посвящен только основным технологиям, а не навыкам, лежащим в их основе. Как пригодилось бы такое сообщество, где посетитель может узнать не только «хорошие вопросы», которые следует задавать, но и хорошие навыки, которые стоит освоить.
Итак, я рассказал о моем профессиональном развитии. Мне помогло не столько изучение новых инструментов, сколько расширение кругозора, освоение приемов управления задачами и более глубокое понимание основополагающих принципов тех языков, с которыми я работаю. Надеюсь, что среди людей, дочитавших эту статью до конца, кто-то задумается: «Действительно, я знаю, как это делается. Но понимаю ли я, почему это делается так, а не иначе?» Коренные изменения протекают и усваиваются медленно, но наша индустрия очень молода и при этом превосходно социализирована. У нас есть потрясающие возможности меняться вместе, всем нашим цехом.
[1] Я знаю разработчиков, которые впихивают в контроллер тысячи действий — как из-за лени, так и из-за недостатка знаний. Читатели, хорошо знающие MVC, просто содрогнулись бы от такого кода.
[2] Не поймите меня неправильно — я не думаю, что достиг апогея своих профессиональных возможностей, и сомневаюсь, что когда-либо реализуюсь полностью. Никому не помешает научиться чему-то еще, и я не исключение. Поэтому я трачу немало времени как на исследование новых вещей, так и на поддержку довольно старых навыков.
[3] Однажды у меня произошел довольно сложный спор с коллегой на тему того, стоит ли использовать Silverlight. К сожалению, я оказался неправ. В настоящее время мое приложение на Silverlight уже перешло в разряд унаследованных, вызвало массу проблем. Из-за этого наша организация потеряла как минимум одного разработчика.
[4] Особенно меня умилила вакансия «Требуется CMS-разработчик». Удалил, не читая.
[5] Да, в C# есть ключевое слово dynamic. Но от этого язык не становится динамическим. В C# dynamic — это просто немного более красивая версия var.
[6] Когда я упомянул пакетную обработку, ему, наконец-то, оказалось нечем крыть. Я убежден, что любой человек, которому придется программировать на node.js пакетную обработку в масштабах большого предприятия, заработает себе тяжелую миопию.
[7] Недавно я был на собеседовании, где мне задали вопрос: «Чем отличается “visibility: hidden” от “display: none” в CSS»? Как бы кандидат ни ответил на такой вопрос, вы вряд ли узнаете о нем что-то ценное.
Эд Вудкок
Источник
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.