Внимание! Статья представляет собой перевод поста из блога Марка Симэна. Для размещения статьи в хабе «Переводы» мне не хватает всего одной единички кармы((( Ну, не успел я заработать одной своей статьей 5 единичек, а перевод опубликовать очень хочется. Надеюсь, что за попытку размещения перевода не в хабе переводов модераторы меня не казнят :), напротив, я надеюсь, что читателям понравится статья и её перевод и я, получив +1 в карму, сразу уберу статью в хаб переводов.
Итак.
Mark Seeman — архитектор программного обеспечения, проживающий в Копенгагене. Ранее работал разработчиком и архитектором в компании Microsoft. Сейчас Mark является независимым коснультантом. Также Mark является автором небезызвестной книги Dependency Injection in .NET
Статья представляет собой перевод поста из блога Mark Seeman.
В комментариях, исключая, разумеется, обсуждений самого поста Марка, хотелось бы услышать мнения насчёт качества перевода и главное стоит ли в будущем при появлении интересных записей делать перевод и выкладывать сюда (а может и из его старых записей что-то перевести)?
Далее идёт перевод поста Марка.
Эта статья затрагивает тему использования разработчиками инструментов повышения производительности.
Время от времени я бываю втянутым в жаркие дебаты на счёт преимуществ и недостатков ReSharper. Эти дебаты происходят обычно в Твиттере, где ограничением являются 140 символов на сообщение, что является не очень благоприятным условием для ведения детальных дискуссий. Я не хочу пустопорожней болтовни, так что начнём детальное обсуждение.
Этот пост не будет представлять собой нападки на ReSharper. В сущности, у меня нет какого-то особого мнения насчёт ReSharper как и насчёт других «инструментов повышения производительности», однако я чаще бываю втянут в споры насчёт ReSharper, чем, например о JustCode или CodeRush. Я полагаю, что так происходит потому, что большая часть людей страстно влюблены в ReSharper.
На самом деле я собираюсь расширить эту дискуссию до более широкого круга «инструментов производительности», таких как (но не ограниченных, представленными ниже):
- ReSharper
- JustCode
- CodeRush
- Productivity Power Tools
- Visual Studio
А почему мы вообще собираемся вести подобную дискуссию?
Единственный инструмент повышения производительности, который я использую в настоящий момент – это Visual Studio 2012, но я беспокоюсь даже из-за этого. Вы могли бы сказать, что это просто мой личный выбор и в этом была бы частичка правды. Но я пишу этот пост не для того, чтобы защитить себя. Напротив, я пишу, потому что считаю, что вы должны остерегаться проблем, которые здесь представлены. Возможно, вы станете лучше как разработчик, если мне удастся привлечь вас к самостоятельному и осознанному рассмотрению выбора, который вы можете принимать сейчас за данность.
Каким образом я вообще был втянут в эти яркие представления в Твиттере? Почему людей вообще заботит вопрос о том, какой инструмент повышения производительности я использую? Прежде всего, я не могу не признать, что изредка я занимаюсь троллингом: я просто получаю удовольствие от передёргиваний, как в приведённой по ссылке цепочке сообщений.
Такому поведению есть причина, окромя простого желания поозорничать. Я хочу, чтобы вы поразмыслили о собственном выборе инструментов, а не занимались фанатизмом.
Опять же, есть более рациональная и глубокая причина того, что люди интересуются тем, что я делаю: я показываю множество презентаций о коде и в течении этих презентаций я много программирую. Всякий раз, когда я выступаю и программирую вживую, я много перед этим репетирую и использую специализированные сниппеты, чтобы не докучать публике тривиальной частью программирования. Вот пример того, как в течение выступления, кто-то твитнул, пожаловавшись на то, что я не использую ReSharper. Однако, целью выступления не является написание кода за наименьшее количество времени. Целью является – научить писать код. Если я буду программировать слишком медленно, то аудитория может заснуть, но если я буду программировать очень быстро, то никто ничего не сможет понять. Я просто не убеждён в том, что конкретно в этом случае, использование «инструмента повышения производительности» будет являться более хорошим выбором.
Как вы вообще можете жить без того или иного инструмента повышения производительности?
Самой распространённой реакцией людей, когда они узнают, что я не использую их любимый «инструмент повышения производительности» является недоумение.
- кхм, как? Как можно работать без Resharper?
- Вы серьёзно заблуждаетесь. Visual Studio абсолютно бесполезна без ReSharper, ИМХО
- но как вы тогда работаете? Голая Visual Studio ужасно бедна в сравнении с любой другой средой разработки
- Без ReSharper моя производительность падает на 50%, я удивлён, что вы можете справляться без него
- Я не понимаю почему вы избегаете использования ReSharper
- Хмм… R# очень хорош в навигации по коду. Быстрые клавиши для следования по потоку приложения вниз и вверх. Как вы это делаете это без R#?
В чём заключается моё недовольство инструментами повышения производительности? Оно значительно глубже, чем неприязнь к какому-либо конкретному инструменту. Чарльз Петцольд уже описал своё отношение к Visual Studio 2005 в отличной статье озаглавленной «Разлагает ли разум Visual Studio?». Это длинная статья, но прочитать её определённо стоит. Вы прямо сейчас должны пойти и прочитать её.
В случае, если вы не хотите тратить время на прочтение этой статьи (с другой стороны вы ведь уже читаете эту довольно длинную статью), я изложу её основной смысл: через IntelliSense, генерацию кода, мастеров настройки и предоставление возможностей простого перетаскивания, Visual Studio нам помогает, но она также толкает нас к написанию (или не написанию) кода специфическим путём. Среда направляет нас.
Делает ли это нас более продуктивными? Я даже не знаю как измерить продуктивность разработчика, так что я не могу дать ответ. Учимся ли мы, когда программируем таким способом? Я бы сказал – не особо.
Несмотря на то, что Visual Studio, во многом, является впечатляющим и весьма полезным программным обеспечением, меня беспокоит то, что я очень зависим от неё. Чтобы изучить новые методики, я пытаюсь следить за тем, что происходит вне .NETMicrosoft экосистемы. Clojure выглядит весьма интересным языком программирования. Походе, что Erlang способен решать некоторые сложные проблемы простым путём. Storm далеко впереди от всего того, что сейчас может предложить Microsoft. Уже годы программисты на языке Ruby претендуют на высокие показатели продуктивности. Git – система контроля версий, которая лучше всего того, что может предложить Microsoft.
Однако, я чувствую себя скованным из-за моей зависимости от Visual Studio. Я хочу изучать и использовать множество других технологий, как и .NET, так что я совсем не ищу инструментов, которые будут усиливать мои узы с Visual Studio. Использование простой обыкновенной Visual Studio – наименьшее, что я могу сделать для расширения своих горизонтов.
Повышение продуктивности
Основным аргументом «за» инструменты повышения производительности является то, что их использование делает вас более эффективным программистом. «Без ReSharper моя производительность падает на 50%, я удивлён, что вы можете справлять без него». Это очень интересное утверждение. А как вы вообще измеряете производительность?
Во имя аргументации, давайте на минуту сделаем вид, что производительность программиста измеряется количеством написанных строк кода. Существует довольно распространённый миф о том, что профессиональный программист пишет всего 10 строк кода в день. Возможно, это не правда, но даже если так, то какое количество строк в день вы пишете в среднем? 100? 200? Действительно ли вы собираетесь утверждать, что узкое горлышко вашей производительности определяется тем, как быстро вы можете печатать? Серьёзно? Тогда учитесь печатать быстрее.
Положим, что большую часть времени, код читают, а не пишут. Код должен быть оптимизирован для чтения, а не для написания. Таким образом, производительность, если она вообще может быть измерена, должна измеряться тем как быстро программисты смогут прочитать и понять кусок кода, а не тем, как быстро этот кусок кода может быть написан.
Более того, если вы считаете, что парное программирование это хороший и эффективный способ производства программного обеспечения, то вы также должны понимать, что при парном программировании в каждый отдельно взятый момент, как минимум один человек вообще ничего не печатает.
Как разъяснил это Мартин Фаулер: «Парное программирование сокращало бы производительность наполовину, если бы самой сложной частью программирования было печатание». По моему опыту, печатание – не самая сложная часть. Таким образом, я не убеждён в том, что «инструменты повышения производительности» делают кого-то более эффективным программистом.
Если вы хоть раз выглядывали за пределы эхокамеры Microsoft в последние 10 лет, то вы, должны быть в курсе о группе разработчиков, славящимися несравненным уровнем производительности. Речь идёт о разработчиках на Ruby on Rails. Позднее, как мне кажется, многие продвинутые гики стали тяготеть к JavaScript (и особенно Node.js). А что насчёт Python и Clojure? Как мне кажется, во всех случаях ухода от .NET самых передовых программистов в сторону других языков и технологий причиной является увеличение собственной производительности. Что вообще предлагают эти языки? Что ж, предпочитаемой средой разработки является, определённо не Visual Studio. Все эти программисты с успехом используют Vim, Emacs, Sublime Text и множество других редакторов. Становится очевидным, что можно быть «ужасающе производительным» без использования Visual Studio и инструмента повышения производительности.
Указывание пути
Чарльз Петцольд обратил в своей замечательной статьей внимание на то, что Visual Studio принуждает к стилю разработке снизу-вверх, что не очень вяжется с потребностями бизнеса. Visual Studio (с инструментом повышения производительности или без) делает сложной (но не невозможной) разработку «снаружи-внутрь».
Я полагаю, что помогая действовать нам строго определённым образом, инструмент закрывает для нас множество других возможностей. Мы можем даже не подозревать о том, что от нас остаётся скрытым, но если мы сможем отделаться от подобной руки помощи, то мы, возможно, сможем увидеть и другие возможности.
Я не против того, чтобы инструмент мне изредка помогал, но в остальное время я бы предпочёл принимать обоснованное решение, с учётом всей имеющейся информации самостоятельно. Я думаю, что, по крайней мере нужно понимать, что принятие помощи означает принятие решений за нас. Получается не беспроигрышная ситуация. Может быть я и получаю возможность завершить задание быстрее, но лишаюсь возможности учиться. Мало того, чем больше я полагаюсь на содействие инструмента, тем более зависимым от него я становлюсь. Для обозначения такой ситуации даже слово специальное есть. Оно звучит как «вендор-запирание» (vendor lock-in).
Заключительные мысли
Всё что здесь было изложено является исключительно мои личным и субъективным мнением. Мой личный подход заключается в том, чтобы быть неторопливым и спокойным. Я двигаюсь медленно, чтобы двигаться быстро.
Для того, чтобы показать то как медленно я двигаюсь, я записал получасовую TDD сессию. В ней нет ничего такого особенного. Я выбрал её не для того, чтобы кого-то впечатлить. Я не выбирал «лучшего» из множества возможных вариантов. Я просто записал то, как я работаю и закачал. Я бросаю вам вызов посмотреть эту сессию от начала до конца. Это будет скучно. Вы увидите длительные периоды простоев и то как подолгу я думаю. Это на самом деле реальная картина того как я работаю. Но до сих пор, каким-то образом, мне удаётся создавать программное обеспечение такого качества, что люди возвращаются ко мне снова, чтобы платить и предлагать новую работу.
Если вы посмотрите хотя бы пять минут из этого видео, вас станет очевидным то, что использование инструмента повышения производительности не принесёт мне никакой пользы. Единожды изучив инструмент повышения производительности, его использование, возможно, меня и не замедлит, но и более производительным не сделает, так зачем я должен заморачиваться с его использованием?
Это всего лишь моё мнение насчёт «инструментов повышения производительности». Это не решение подходящее под все случаи жизни. Если вы считаете, что выигрываете от использования вашего любимого «инструмента повышения производительности» я не буду вас переубеждать. Равно как и меня не надо судить за то, что я не пользуюсь каким-то определённым инструментом. Некоторые уважаемые мною программисты использую ReSharper. Но я их уважаю не благодаря этому, а скорее вопреки.
Автор: EngineerSpock
