Остерегайтесь инструментов повышения производительности

    Внимание! Статья представляет собой перевод поста из блога Марка Симэна.

    Mark Seeman — архитектор программного обеспечения, проживающий в Копенгагене. Ранее работал разработчиком и архитектором в компании Microsoft. Сейчас Mark является независимым коснультантом. Также Mark является автором небезызвестной книги Dependency Injection in .NET
    Статья представляет собой перевод поста из блога Mark Seeman.
    В комментариях, исключая, разумеется, обсуждений самого поста Марка, хотелось бы услышать мнения насчёт качества перевода и главное стоит ли в будущем при появлении интересных записей делать перевод и выкладывать сюда (а может и из его старых записей что-то перевести)?
    Далее идёт перевод поста Марка.

    Эта статья затрагивает тему использования разработчиками инструментов повышения производительности.
    Время от времени я бываю втянутым в жаркие дебаты на счёт преимуществ и недостатков ReSharper. Эти дебаты происходят обычно в Твиттере, где ограничением являются 140 символов на сообщение, что является не очень благоприятным условием для ведения детальных дискуссий. Я не хочу пустопорожней болтовни, так что начнём детальное обсуждение.
    Этот пост не будет представлять собой нападки на ReSharper. В сущности, у меня нет какого-то особого мнения насчёт ReSharper как и насчёт других «инструментов повышения производительности», однако я чаще бываю втянут в споры насчёт ReSharper, чем, например о JustCode или CodeRush. Я полагаю, что так происходит потому, что большая часть людей страстно влюблены в ReSharper.
    На самом деле я собираюсь расширить эту дискуссию до более широкого круга «инструментов производительности», таких как (но не ограниченных, представленными ниже):

    А почему мы вообще собираемся вести подобную дискуссию?

    Единственный инструмент повышения производительности, который я использую в настоящий момент – это Visual Studio 2012, но я беспокоюсь даже из-за этого. Вы могли бы сказать, что это просто мой личный выбор и в этом была бы частичка правды. Но я пишу этот пост не для того, чтобы защитить себя. Напротив, я пишу, потому что считаю, что вы должны остерегаться проблем, которые здесь представлены. Возможно, вы станете лучше как разработчик, если мне удастся привлечь вас к самостоятельному и осознанному рассмотрению выбора, который вы можете принимать сейчас за данность.
    Каким образом я вообще был втянут в эти яркие представления в Твиттере? Почему людей вообще заботит вопрос о том, какой инструмент повышения производительности я использую? Прежде всего, я не могу не признать, что изредка я занимаюсь троллингом: я просто получаю удовольствие от передёргиваний, как в приведённой по ссылке цепочке сообщений.
    Такому поведению есть причина, окромя простого желания поозорничать. Я хочу, чтобы вы поразмыслили о собственном выборе инструментов, а не занимались фанатизмом.
    Опять же, есть более рациональная и глубокая причина того, что люди интересуются тем, что я делаю: я показываю множество презентаций о коде и в течении этих презентаций я много программирую. Всякий раз, когда я выступаю и программирую вживую, я много перед этим репетирую и использую специализированные сниппеты, чтобы не докучать публике тривиальной частью программирования. Вот пример того, как в течение выступления, кто-то твитнул, пожаловавшись на то, что я не использую ReSharper. Однако, целью выступления не является написание кода за наименьшее количество времени. Целью является – научить писать код. Если я буду программировать слишком медленно, то аудитория может заснуть, но если я буду программировать очень быстро, то никто ничего не сможет понять. Я просто не убеждён в том, что конкретно в этом случае, использование «инструмента повышения производительности» будет являться более хорошим выбором.

    Как вы вообще можете жить без того или иного инструмента повышения производительности?

    Самой распространённой реакцией людей, когда они узнают, что я не использую их любимый «инструмент повышения производительности» является недоумение.


    В чём заключается моё недовольство инструментами повышения производительности? Оно значительно глубже, чем неприязнь к какому-либо конкретному инструменту. Чарльз Петцольд уже описал своё отношение к Visual Studio 2005 в отличной статье озаглавленной «Разлагает ли разум Visual Studio?». Это длинная статья, но прочитать её определённо стоит. Вы прямо сейчас должны пойти и прочитать её.
    В случае, если вы не хотите тратить время на прочтение этой статьи (с другой стороны вы ведь уже читаете эту довольно длинную статью), я изложу её основной смысл: через IntelliSense, генерацию кода, мастеров настройки и предоставление возможностей простого перетаскивания, Visual Studio нам помогает, но она также толкает нас к написанию (или не написанию) кода специфическим путём. Среда направляет нас.
    Делает ли это нас более продуктивными? Я даже не знаю как измерить продуктивность разработчика, так что я не могу дать ответ. Учимся ли мы, когда программируем таким способом? Я бы сказал – не особо.
    Несмотря на то, что Visual Studio, во многом, является впечатляющим и весьма полезным программным обеспечением, меня беспокоит то, что я очень зависим от неё. Чтобы изучить новые методики, я пытаюсь следить за тем, что происходит вне .NET\Microsoft экосистемы. 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. Но я их уважаю не благодаря этому, а, скорее, вопреки.
    Share post

    Comments 46

      +9
      Переводы нужно не отправлять в хаб «Переводы», а делать переводами:

      Насколько я знаю, на это карма не нужна
        0
        Блин, не знал. А как теперь исправить положение? После нажатия на значок редактирования поста я там не вижу такой возможности.
          0
          Уже никак.
            0
            Жаль. Косяк получился (((
              0
              Можно написать в тех.поддержку хабра, перенесут в нужный раздел — уже были прецеденты.
          +15
          На мой взгляд достаточно сомнительный позыв в статье. Resharper дополняет студию, делает многие рутинные операции за меня. Та же навигация по коду ускоряет поиск нужного фрагмента в разы. Да и рефакторинг не лишний.

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

          В принципе многое можно сделать и в простых текстовых редакторах + командная строка. Но зачем? Чтобы считать себя крутым? Я типа могу делать это и без IDE? Смешно звучит.

          Есть задача, есть инструменты, с помощью которых задачу можно решить. И чем удобнее инструмент, чем лучше им владеет программист, тем эффективнее он может решить эту задачу.
            +2
            В принципе, я тоже не совсем согласен с автором. Но в идее о том, что без инструментов мы становимся беспомощными что-то есть. В той статье Петцольда, которую рекомендовал Марк, Чарльз пишет, что почувствовал себя настоящим программистом, когда после программирования в Visual Studio он стал писать программу в блокноте на чистом С. Ещё там Чарльз пишет, что ему нравится самому писать метод Main() и, что его раздражает генерация кода в WinForms)))

            Но, вы знаете, я в разных местах обнаружил на удивление много людей, которые согласны с Марком.
              +4
              В принципе многое можно сделать и в простых текстовых редакторах + командная строка. Но зачем? Чтобы считать себя крутым? Я типа могу делать это и без IDE? Смешно звучит.

              Смешнее когда он не может этого делать. Еще смешнее когда не знает как пишутся базовые конструкции яп без автокомплита и автогенерации.

              И да IDE расхолаживают. Думаю, что главный посыл статьи, что IDE должна быть дополнением программиста, а не наоборот
                +3
                Я не понимаю, почему не упоминается момент, когда нужно анализировать существующий код проекта из тысяч классов, написанный сотней разработчиков разного уровня подготовки? Как насчет рефакторинга в таких условиях? Конечно, можно обойтись простым «Search+Replace», но на эту обезъяью работу уйдет уйма времени. И как раз нежелание делать обезъянью работу будет сдерживать девелоперов заниматься рефакторингом. Так что камень в огород Resharper-a не зачтен.
                  +3
                  Я скорее не понимаю, почему в статье не упоминается тот момент, что когда пишешь без помощи IDE, тебе приходится думать, как структурировать код проекта из тысячи классов так, чтобы можно было разобраться в нём без сторонних инструментов. И в получившейся структуре, которая прошла проверку твоим мозгом, разобраться куда легче.

                  Я согласен с автором, что ребята Ruby on Rail куда продуктивнее нас, да и что спорить — их инструменты на порядок легче в использовании. Взять к примеру тестирование — я в восторге от реализации BDD в Ruby и никак не могу удобно и просто реализовать подобный процесс в .NET.
                +7
                Автор исходного поста по крайней мере честен — признаётся что любит потроллить :)

                По поводу неудобства TDD в Visual Studio — как раз с ReSharper это происходит очень даже удобно.

                Сводить Visual Studio + ReSharper к скорости печатания — тоже тот ещё троллинг — помимо повышения скорости эта связка даёт ещё и быструю проверку ошибок, стиля кодирования, предупреждения о возможных проблемах, не говоря уже про рефакторинг.

                Про скорость печатания… Может конечно всё очень индивидуально, но лично у меня программирование идёт двумя способами, которые иногда пересекаются:

                1) Подумать как сделать, быстро написать, причесать.

                2) Подумать как сделать, понять что лучше разбить задачу на мелкие, вероятно описать архитектуру, мелкие задачи решить способами 1 и/или 2. После этого интегрировать в общее решение, выполнить тесты, сделать ревью, вероятно рефакторинг.

                И для таких вариантов VS + ReSharper тоже весьма полезны.

                P.S. Всё это не относится к математическим/алгоритмическим задачам, где собственно программирование занимает очень небольшой процент времени.
                  +1
                  Признаюсь, я уже начал теряться в догадках. Возможно, Марк преуменьшил своё желание к троллингу :) Может, он всё-таки в данном случае очень сильно потроллил, а я зря перевёл? :-D

                  Но, опять же, статья Петцольда повествует об этих же проблемах. И там, совсем не похоже, что Чарльз троллит.
                    0
                    Почему же зря — сколько людей, столько и мнений.

                    От задачи, опять же, многое зависит. Если, например, писать оптимизатор SQL-запросов — скорость набора отходит не на второй, а на какой-то запредельный план и если есть другие средства проверки корректности кода — то можно хоть в блокноте писать. Хотя, конечно, лучше в sublime/vim/notepad++ :)
                  +2
                  Хорошо, когда люди имеют разные мнения.

                  Для меня IDE — это не средство скоростного ввода, а облегчение чтения кода, облегчение отладки, ускорение понимания кода. На все это и работает и автодополнение, и быстрая навигация, и контекстные подсказки, и проч.
                    +1
                    Спасибо за этот комментарий. На самом деле, я сделал перевод именно по этой причине. В то время как все сходят с ума по R# (ну, честно говоря, я им активно пользуюсь, купил лицензию), есть люди, которые относятся к этому настороженно. Вот, например, Боб Мартин рекомендует использовать метод Extract till you drop (извлекай пока нечего будет извлекать), чтобы получать короткие методы. Однако есть и выступление Кристины Горман, которая считает это бездумной практикой и рекомендует пользоваться своей головой а не механизированными методами. Когда изучаешь различные мнения — ты начинаешь лучше понимать суть вещей.
                    +7
                    А я так и не понял, что хотел сказать автор. Увидел такой посыл: использование R# повышает скорость написания кода (только?) => повышение скорости нафиг не надо, ибо это не основное => R# нафиг не нужен.

                    Т.е. во-первых, он свёл функционал решарпера к какому-то тупому бесполезному автокомплиту, совершенно забыв про мощнейшие инструменты рефакторинга и поиска кода, умные снипплеты, стиль и прочее, а потом сделал на основании всего такой мегавывод.

                    В общем, автор на мой взгляд троллит и передёргивает.
                      0
                      Не, просто автор опытный и хорошо знает возможности VS. Знает, что там есть и поиск и сниппеты и много чего.
                        0
                        Да, там много чего интересного есть. Но реализовано это мягко говоря странно. (Как я понял, они принципиально не хотят конкурировать с Решарпером, и добавляют уж то, без чего совсем плохо жить становится).

                        Если ближе к теме, я периодически бываю на разных конференциях от Microsoft, там иногда демонстрируется код, иногда демонстрируется сама студия. И уже много лет я смотрю, как бедные докладчики мучаются без решарпера и рассказывают про новые «мегафичи», которые там уже давным-давно есть. А тебе пытаются продать худшую реализацию за большие деньги.
                          0
                          Хорошо знает возможности VS, но, судя по твитам, нифига не знает про возможности решапрера(окромя автокомплита и темплайтов).
                      • UFO just landed and posted this here
                          +2
                          Я думаю, что основное содержится в коротеньком разделе «указывание пути». Действительно, очень легко попасть в ловушку и выпустить скрытый страшный баг в продакшн, если ты не понимаешь внутренних механизмов, на которые ты неявно ложишься, через использование какого-нибудь генератора. Просто пользуешься бездумно чем-то сгенерированным и предоставляющем тебе некое API. А ты возьми и попробуй пару раз сам вручную написать всё что генерирует дизайнер linq2sql, к примеру.
                          Да что там говорить о таких инструментах, когда даже использование очень высокого уровня API без разбора его внутренних механизмов может привести к очень плохим последствиям. Мне кажется его идеи ведут к таким рассуждениям.
                            +3
                            Оффтопик.
                            А за что минусуют статью? За плохой перевод? За несогласие с автором? За то, что я просто не сделал статью в статусе «перевод»? Просто если так происходит из-за банального несогласия с тем, что излагается в статье, я так с отрицательным рейтингом скоро буду — обидно как-то.
                              –2
                              Я лично минусовал статью за категорическое несогласие с автором. А за перевод конечно же спасибо. Но не могу сказать что, объективно и аргументировано написано.
                                –1
                                Конечно из-за несогласия с автором.

                                Вот вы перевели, новички начитаются и будут говорить что они мега крутые программисты, потому что пишут в блокноте. Зачем это на хабре?

                                А карму не знаю зачем минусуют. Наверно чтобы следующий раз тщательней выбирали что переводить.
                                  +1
                                  Это для всех. Если человек во всё верит — не быть ему программистом хорошим никогда. В кодексе хабра где-то написано, что не надо минусовать статью сразу — сначала почитай комментарии (ну или что-то в этом роде). Я полагаю, что новичок должен посмотреть комментарии. А если новичок будет думать, что умение программировать в блокноте это круто — то он будет прав. Он будет не прав, если будет этим всё время заниматься.
                                    +3
                                    Да, это круто, когда автомеханик может починить сломаный в чистом поле автомобиль одной отверткой. Но это ни разу не круто если в автосервисе с кучей инструментов он чинит автомобили одной отверткой. Зачем советовать это? Я против, поэтому от меня минус статье.
                                      +1
                                      «Если вы считаете, что выигрываете от использования вашего любимого «инструмента повышения производительности» я не буду вас переубеждать.» — кусочек из статьи.

                                      Максимум, что он советует это просто попробовать свои силы без инструментов. Хотя таких призывов я тоже не видел. В остальном он высказывает своё мнение насчёт некоторых вещей.

                                      Ну а минусовать за то, что несогласен с ИМХО автора — ИМХО, мне кажется неправильно. Я перевёл потому что это явно альтернативное мнение одного из очень крутых и уважаемых западных специалистов и поэтому оно достойно внимания и того, чтобы его обсудили на Хабре. Мне вот интересны были рассуждения людей на эту тему. Ещё я вынес для себя то, что, вероятно, 15 человек, которые заминусовали статью (боже упаси, я за плюсами не сильно гонюсь) испытали личную обиду из-за альтернативного мнения автора и это меня немного пугает.
                                        +2
                                        Человек считает что статья хорошая — ставит плюс. Плохая — минус. Человек может выражать как согласие, так и несогласие безо всяких личных обид. Для этого и создан рейтинг, для этого и существуют две стрелочки, на этом и построена саморегуляция сообщества.

                                        Nothing personal. Боже упаси на каждую хреновую статью обижаться.
                                +1
                                > «Остерегайтесь инструментов повышения производительности»
                                А ведь сама студия тоже инструмент производительности. Можно заменить в статье R# на VS и будет такой же ошибочной статьей. Можно ведь писать в блокноте и компилировать код из консоли — студия только мешает так как навязывает «программирование снизу-вверх».

                                Рассматривать R# только как инструмент для быстрого набивания кода так же абсурдно как и рассматривать VS в том же ключе.
                                  0
                                  Коллективный разум уже догадался, что часть представленного в статье — троллинг. Другая часть ведёт к философской дискуссии о смехотворности программиста, который не может сделать и шага без среды разработки. Вот ссылка на соответствующий комментарий. И, да, вы правы, насчёт студии, Петцольд негодует и насчёт студии безо всяких R#.

                                  Мой личный взгляд таков: R# — годный, хороший инструмент, который позволяет не пропускать лишний раз потенциальный NullReferenceException, R# позволяет прилизывать код, делать его настолько чистым, что без него такой чистоты добиться просто невозможно, в силу ограниченности человеческих способностей. В таком ракурсе, IDE + R# выступают в качестве экзоскелета для мозга программиста. Но во всём этом кроется маленький подвох — подсаживание на иглу и ослабление собственных возможностей. Это как отрофирование мышц при их неиспользовании. Честно говоря, если выбить R# у меня сейчас из под рук — моя ментальная часть будет очень сильно страдать при попытках писать код без этой усиленной мега-оболочки, я уж молчу про студию, без которой я просто не смогу скомпилироваться (ну, про студию-то ладно — это, конечно, перебор, на мой взгляд, хотя никто не мешает писать батник для компиляции, ага :)). Хорошо ли это? Я затрудняюсь ответить на этот вопрос, хотя интуитивно мне не нравится такое положение вещей — эта зависимость о которой говорят Марк и Петцольд.
                                    0
                                    Зависимость от инструментов может не нравиться.
                                    Однако, могу предложить аналогию: ходить нужно всегда пешком, потому что автомобили и самолёты — это для слабаков, зависимых от технического прогресса и не контролирующих весь процесс целиком :)
                                      0
                                      Марк не предлагает всегда ходить пешком. Он предлагает понимать как работает автомобиль, иначе вы однажды попадёте на youtube и получите миллион просмотров и не отнюдь не потому, что вы хороший водитель-профи. Случай с самолётом я бы исключил — здесь полная делегация ответственности.
                                  +4
                                  Вся эволюция человека разумного — это эволюция инструментов. Объем мозга со времен ранних кроманьонцев не менялся. Бороться с решарпером в пользу чистой студии, все равно что бороться со студией в пользу блокнота (ну и так далее). Типичный луддизм.
                                    +1
                                    … с автомобилями в пользу лошадей. А то ишь, совсем отучились какашки с улиц убирать, а ведь это жизненно необходимый навык!
                                      0
                                      Однако до сих пор есть простые инструменты, например молоток. Можно конечно научиться управлять специальным роботом для забивания гвоздей, но это и не мешает уметь забивать гвозди молотком. Луддизм тут не причём.
                                      0
                                      В visual studio мне очень, очень не нравится парадигма решений/проектов. CMake для С++ мне кажется напорядок удобнее и гибче. Можно конечно создавать свои конфигурации помимо стандартных debug/release и переключаться между ними. Но все же гораздо удобнее просмотреть мейкфайл и что-то где то закоментировать чем создавать новую конфигурацию проекта VC++ лазить по куче вкладок смотреть где какая галка стоит. В C# решениями/проектами более меннее удобно пользоваться, но все равно например пребилд/постбилд события неудобно настраивать, приходится делать отдельный батник и его запускать уже из событий сборки/построения.
                                        +2
                                        В свое время я работал с Delphi, потом ушёл на VS.NET.

                                        Позднее через Perl ушел в RoR.

                                        И я могу только подтвердить слова автора статьи.

                                        Я лет шесть писал с помощью vim, сейчас пишу с использованием Sublime Text 2, и я сейчас более производителен, чем когда использовал Visual Studio + Resharper. Сейчас, правда, сами VS и Resharper тоже стали намного удобнее.

                                        Кстати, самое мое большое достижение за четыре месяца уложилось в 30 строк кода.

                                        Хотя, думаю, это индивидуально.
                                          +2
                                          Очень интересный комментарий. Кстати, да, почему-то никто не обратил внимание на то, что автор также говорит о том, что при изучении доп. инструментов повышается привязанность к VS, а значит к стеку технологий от Microsoft, что, в конечном счёте, приводит к сложности с освоением других технологий.

                                          Хотя, возможно, это является платой за рост в глубину в определённой технологии? Т.е., получается, что рост в глубину в данном контексте, может, и, вероятно, мешает росту в ширину.
                                          0
                                          Имхо смысл поста в том, что через решарпер может быть приятнее писать, но на продуктивность это не влияет, потому спор использовать решарпер или нет, это спор о вкусах, а не о хороших практиках.
                                            +3
                                            Я могу отказатся от решарпера. Дома у меня его нет (равно как и больших проектов).
                                            Но зачем мне запомниать нэймспесы и имена всех классов солюшаена на 100 проектов вместо ctrl+alt+tab я не знаю.
                                            Зачем мне помнить в какой папке леждит какой файл вместо shif+alt+l я тоже не знаю.
                                            Я могу на бумажке нарсовать дерево вызовов и источник какого либо значения в стеке вызово, но зачем мне это длеать вместо shif+ctrl+alt+a
                                            Зачем запонимнать мена всех классов, вместо того чтоб помнить хоть какую то его чать и сделать ctrl+n тоже не знаю.
                                            Зачем мне искать каждый класс и метод из стэк трейса, который я взял в логе, вместо shift+ctrl+e?
                                            Или может быть я стану хуже программировать если решарпер мне подскажет где вызывался определенный виртуальный метод, у переменной определенного типа?

                                            Без всего этого можно жить. И я живу дома без решарпера. Я пишу на асме в как блокноте (на само деле в AvrStudio но это как блокнот).
                                            Но я не могу понять зачем отказыватся от инструмента, когда он есть! Зачем мне забивать мозг ненужной информацией, вместо того, тчоб сосредоточится на решении проблемы?
                                              +1
                                              А мне кажется здесь вопрос нахождения золотой середины.

                                              Можно уйти в одну крайность и писать в Блокноте и компилировать каждый файл в командной строке по отдельности. Но так само можно уйти и в другую крайность с генераторами кода и визуальными редакторами, когда целые классы появляются и компилируются в продакшн без хоть какого либо ознакомления разработчика с ними.

                                              Тогда весь это спор сводится (впрочем, как и большинство споров) к нахождению золотой середины. Автор статьи утверджает, что продвинутые редакторы (Vim/Emacs/Sublime) — это и есть та самая золотая середина. Если кто-то не согласен, то он должен представить свое видение золотой середины.

                                              Утверждения вида «редактор — это деградация. точка.» как по-мне не аргументированы.
                                                0
                                                Всю свою историю человечество пользуется инструментами — мы носим одежду, обувь, ездим на машинах и метро, используем плиту для приготовления пищи. И почему то ни разу не слышал чтобы повара называли лузером если он готовит торт не на костре, а в хорошей духовке. Та же картина с врачом — если хирург к вам подступит с куском обсидина вместо скальпеля и булыжником вместо наркоза…
                                                А если серьезно — без нормальной IDE даже просто переименовать класс это целое дело, которое отнимает время и внимание. Возможность посмотреть значение переменной во время отладке экономит время, а уж возможность реально за несколько секунд увидеть все версии изменений — просто бесценно.
                                                  0
                                                  А не расскажете, что у вас со ссылками в статье?
                                                    0
                                                    А что с ними? Если что-то не открывается — пожалуйста, напишите в личку что именно.
                                                      0
                                                      Они не прямые а через какой-то редиректор. Зачем?
                                                        0
                                                        Ааа… всё может быть. Я просто ссылки скопировал из оригинала статьи и не заморачивался.

                                                  Only users with full accounts can post comments. Log in, please.