Что на самом деле спрашивают
Вопрос «какие программы используют разработчики» редко задают из чистого любопытства. Обычно за ним стоит практическое: человек собирается попробовать сам и не знает, что ставить; или родитель прикидывает, что понадобится ребёнку, который объявил, что будет программистом. Общее у них одно — ожидание списка названий, который можно скачать и установить.
Мы ответим, но не так. Честный ответ удивляет: набор программ у разработчика небольшой, скучный, и почти ни одна из них не пишет код сама. Польза сидит не в названиях, а в ролях, которые эти программы играют в рабочем дне. Поэтому начнём с ролей, а к названиям вернёмся в конце — вместе со способом их искать, который не устаревает.
Пять ролей вместо списка названий
Редактор кода — то, что открыто на экране почти весь день. Внешне он похож на привычную программу для документов, но устроен наоборот: никакой заботы о красоте, зато можно держать открытым сколько угодно файлов, сломанные места подсвечиваются сами, недописанные строки договариваются за вас, а прыжок от одного куска программы к любому другому занимает мгновение. Аскетичность не случайна. Программа с точки зрения компьютера — просто текст, много небольших текстовых файлов, а раз так, то главный инструмент ремесла — очень умный блокнот. Обычная программа для документов здесь не годится: она прячет текст внутрь оформления, а нужно ровно наоборот — чистый текст, который поймёт любой инструмент. Отсюда следствие, к которому мы ещё вернёмся: текст открывается чем угодно, поэтому редактор взаимозаменяем. И он не думает за разработчика — это хорошо оборудованная кухня, а не повар.
Терминал — окно, в котором компьютеру отдают команды словами, а не кликами по меню. Со стороны похоже на кино про хакеров, по сути — второй способ управления, и в умелых руках он бережёт силы. Про терминал у нас есть отдельный материал, поэтому здесь — коротко.
Браузер. Незаметная со стороны часть ремесла — поиск. Никто не держит в голове всё: разработчик постоянно смотрит, как устроена нужная штука и что означает ошибка, которую он видит впервые. Главный навык, который не пишут в вакансиях, — умение сформулировать вопрос так, чтобы ответ нашёлся: не «у меня ничего не работает», а дословный текст ошибки плюс пара слов о том, что делали перед этим. Документацию при этом читают не как роман, а как словарь: открыли, нашли слово, закрыли. А для тех, кто делает сайты, браузер ещё и мастерская: в нём есть встроенная «лупа», через которую видно, из чего собрана любая страница. Страница, которую вы сейчас читаете, для веб-разработчика одновременно и результат работы, и рабочий стол.
Хранилище версий — самый непонятный постороннему взгляду пункт и самый важный для совместной работы. Представьте архив, в котором сохранён каждый шаг: вот программа вчера, вот она до сегодняшних правок, а вот момент прямо перед тем, как всё сломалось. К любому сохранению можно вернуться, как в игре, и спросить у архива, что изменилось с утра и кто это сделал. Но главное — он позволяет многим людям править одни и те же файлы и не затирать чужую работу: архив сверяет правки и не даёт им бесшумно исчезнуть. Без этой штуки всё, что больше одной страницы, превращается в переписку из серии «у меня работает, а у тебя?».
Место договорённостей — список задач и переписка. Здесь живёт всё, что вокруг кода: что делать, в каком порядке, что имел в виду заказчик, кто уже во всём разобрался. Проза жизни, но именно она превращает отдельные правки в общий результат.
И — всё. Никакой экзотики и никакой единой «программы для программирования», в которой вертится ремесло. Если вы ждали её — вот первое расхождение между представлением и реальностью.
Второе расхождение важнее. Набор ролей у новичка и у человека, который проектирует большие системы, почти одинаков, и объяснение простое: инструмент здесь выбирают по принципу «не мешай». Интерес разработчика — в программе, которую он строит, а не в инструментах, поэтому инструменты берут скучные и надёжные. Отсюда практический вывод: узнав, какими программами пользуется человек, вы почти ничего о нём не узнаете. Спрашивайте лучше, как он ищет ответы и что делает, когда всё сломалось.
Тупик: поиск «той самой» программы
Что пробуют первым? Ищут «профессиональную» программу — ту, которой пользуются «настоящие разработчики», — ставят её и ждут, что за инструментом придёт умение. Вторая версия того же тупика — вечный подбор: человек месяцами сравнивает редакторы, читает споры про них и настраивает выбранное. Занятие приятное, даёт ощущение прогресса и почти ничего не меняет в результате. Спрашивать, какой программой пользуется разработчик, — всё равно что спрашивать, какой ручкой пишет писатель: ручка не держит роман.
Почему так — посчитайте сами, на своих цифрах. Возьмите любой час своей работы и разложите его: сколько времени заняло само движение пальцев — набор, клики, — а сколько решение о том, что именно набрать и по чему кликнуть. У разработчика деление такое же, только вместо набора текста там чтение чужого текста и размышление. Вывод из этой арифметики: редактор ускоряет первую часть, ту, что с пальцами. Если пальцы занимают малую часть часа, то даже идеальный редактор ускоряет малую часть. Ускорять надо другое — то, как ищут, как хранят, как сверяют, как договариваются. Это роли из списка выше, а не названия.
Третья разновидность — скопировать чужой набор целиком. У автора красивой настройки всё летает, значит, беру как есть. Но настройки — это память рук: привычки нажатий, выстроенные под конкретного человека, его задачи и его порядок дня. Чужая настройка — чужая память, и работает она в основном у того, кто её строил. А строивший когда-то начинал с почти пустого редактора.
Бывает и обратная крайность — аскеза напоказ: работать в самом простом блокноте и презирать тех, кто настроил себе удобства. Это тот же тупик, только с другой стороны: инструмент снова занимает место работы.
Хорошая новость: тупик безвреден, если выйти из него вовремя. Признак, что пора, простой — вы замечаете, что настраиваете инструмент чаще, чем им пользуетесь.
Позиция редакции
Мы считаем, что на вопрос «какие программы используют разработчики» правильно отвечать списком ролей, а не списком названий. Названия устаревают, роли — нет: «куда писать», «где искать», «как хранить», «где договариваться» останется, какие бы программы ни победили завтра. И ещё одно, без чего первая часть позиции не работает: привычка важнее программы. Один и тот же редактор у человека, который записывает свои шаги и всегда может ответить на вопрос «что я делал вчера», и у человека, который этого не делает, — два разных инструмента. Поэтому в наших материалах про инструменты мы сначала описываем роль и привычки вокруг неё и лишь потом — конкретные программы, если их вообще стоит называть.
Условие, при котором мы неправы. Пока программа — это текстовые файлы, редактор взаимозаменяем и «какой именно» — вопрос вкуса. Но если разработка однажды уйдёт в замкнутые среды, где проект целиком живёт внутри одной программы и не выносится наружу, выбор инструмента станет выбором ремесла — и тогда список названий окажется полезнее списка ролей, а эту статью придётся переписать. Есть и ближний случай, где наша позиция не работает уже сейчас: если вам завтра нужно сесть за чужой компьютер и продолжить чужую работу, вам нужен именно список названий. Тут мы честно бесполезны.
Как найти названия и с чего начать
Сами названия мы не приводим не из скрытности, а потому, что они устаревают быстрее, чем статья успевает надоесть. Найти их просто: наберите в поиске роль — «редактор кода», «система контроля версий» (то самое хранилище), «терминал». Первые же результаты дадут имена; проверяйте их по роли, а не по хвале в описании.
Если хочется попробовать самому: поставьте редактор и хранилище версий — это скелет, на который позже ляжет всё остальное. А если терпения больше, чем страха, начните с терминала: у нас о нём есть отдельный материал, и это редкий случай, когда один инструмент действительно экономит часы, а не минуты.