Адаптируемость

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

Однако, меня удивляет, что мы работаем в индустрии, в которой изменения не только нормальны но и ожидаемы. Скорость изменений постоянно растет и не собирается снижаться. Это странно, потому что разработчики, кажется, неохотно идут на смену привычных инструментов.

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

Вот перечень сред, в которых я работал с тех пор, как начал писать код:

30 лет назад (1983)

• Командная строка Apple; написание BASIC и ассемблерного кода.
• Мало функций редактирования, но чем меньше знаешь, тем лучше спишь.
• Через год в университете на мейнфрейме, использующем FORTRAN, был установлен Sed или похожий редактор.

25 лет назад

• xedit на мейнфрейме IBM с языком REXX.
• Это был приличный полноэкранный редактор, который можно было автоматизировать для обеспечения полноэкранного интерфейса пользователя для приложений мейнфрейма.
• Я также использовал vi для некоторых целей, который по сравнению с xedit кажется громоздким и отсталым.

20 лет назад

• Я использовал редактор для, не удивительно, языка C и ряда других.
• Редактор был удобным в использовании и я достаточно хорошо с ним ознакомился.

15 лет назад

• Я работал в интегрированных средах разработки Powerbuilder, Visual C++ и Visual Basic.
• Редактировать вне этих инструментов было неэффективно и рискованно.
• Я наловчился с ними работать.
• Редакторы IDE хорошо подходят для выполнения работ.
• Также использовал vi, запуская удаленные командные строки (remote shells) на Unix-системах.

10 лет назад

• Различные Java IDE: PowerJ, JBuilder, Eclipse в зависимости от стандарта организации клиента.
• Выполнял тесты в IDE.
• Использовал Textpad для редактирования текста вне IDE.
• В режиме терминала на удаленном хосте использовал vi.

5 лет назад

• Использовал Eclipse и NetBeans для Java, Visual Studio для C\#.
• Выполнял тесты из IDE.
• Использовал Textpad для редактирования текста.
• В режиме терминала на удаленном хосте использовал vi.

Сейчас (2013)

• Sublime Text 2 для редактирования текста и кода.
• Выполняю тесты из командной строки.
• В режиме терминала на удаленном хосте использую vi.

Sublime Text действительно быстро выполняет индексирование и текстовый поиск среди тысячи файлов, но это цветочки по сравнению с умением находить определение метода на Eclipse или обходить иерархию классов. Я умею писать макросы в Sublime, способные автоматизировать повторяющиеся операции, что мне нравилось в Textpad и катастрофически не хватало в IDE. Однако, у меня нет автоматического рефакторинга, доступного в Eclipse и NetBeans.

Когда я наблюдаю за разработчиками, работающими в Vim и Emacs, мне кажется, что я смотрю на виртуозное выступление пианиста -- весь процесс выглядит таким непринужденным! Меня поражает, что данные инструменты больше оптимизированы для написания кода, чем для анализа и рефакторинга.

Одно только предложение использовать другие -- отличные от Vim and Emacs -- инструменты вызовет нешуточные волнения. Но по своему опыту скажу, что не так трудно приспособиться к новым инструментам. Конечно, потребуется время, придется получить одни навыки, забыть другие, но гибкость того стоит.

Все-таки, выживают не самые быстрые или умные, а наиболее приспосабливаемые к изменениям. 

источник