Банальности
Главным средством разработки программ является голова программиста, как бы это пафосно не звучало. Но я хочу рассказать немного о тех средствах, которые помимо собственной головы, в той или иной мере, упрощают или улучшают труд программиста - об оборудовании, специализированном ПО, руководствах, гугле и даже немного о музыке. О том как и что влияет на результативность, эффективность и качество, а так же о том, что неплохо бы подходить к вопросу не на уровне эмоций и инстинктов, а вполне рационально и осознанно.
Понимаете в чем тут дело, программист очень часто, в отличии от хирурга или столяра, предоставлен в части выбора инструментария сам себе. Разумеется, есть масса литературы посвященной всему по отдельности, есть опыт старших коллег, реже существуют принятые и прописанные корпоративные стандарты. Тем не менее, все это обычно носит рекомендательный характер. Более того, эти рекомендации слишком общие, наоборот, слишком специализированные или просто некорректные. Вследствие чего каждый программист вынужден набивать себе свои шишки и проходить, может быть, не самый сложный, но повторяющийся из раза в раз путь, который прошли до него все остальные.
С одной стороны иногда полезно прийти к чему-нибудь самостоятельно, с другой - это в целом зря потраченное время и нервы. А в иных случаях и более тяжелые последствия в виде некачественных продуктов, которые могут приводить и к реальным экономическим потерям, если не к человеческим жертвам. Никто ведь не дает молодому хирургу или стоматологу поискать свой инструмент, который будет удобен лично ему. Столяр не будет браться за табурет, не имея соответствующего для решения задачи инструмента. И хирург и столяр при этом точно знают, что и зачем им понадобится для работы. Программист же, в лучшем случае, отправляется гуглить и читать подборки топов, в худшем - берет то что установлено на рабочей станции администратором. И хорошо, если предоставленная машина хотя бы "тянет" то что там установлено.
Ноутбук vs ПК
Сразу честно признаюсь, у меня довольно однобокое субъективное представление о рабочей станции программиста - и это однозначно не ноутбук. Однако, я понимаю, что выбор рабочей станции может быть связан с разными обстоятельствами не касающимися прямо программирования. Человек может предпочитать мобильность по тем или иным соображениями. Может быть и так, что человек банально привык или ему выдали, подарили ноутбук. А на свой ПК пока нет денег или не позволяют жилищные условия. Однако, если есть выбор и он не связан с какими-то другими обстоятельствами, то желательно немного подумать, прежде чем сделать этот выбор, причем подумать не только о том как стильно это выглядит.
Отличия ноутбука и ПК в плане производительности нынче настолько невелики в части использования их в качестве рабочего инструмента, что на этом вряд ли надо акцентировать особое внимание. Если ваша работа не связана с ПО для рендеринга видео и разработкой трехмерных шутеров, то производительность не самая важная характеристика, от которой следовало бы отталкиваться. Впрочем, если вы заняты именно в этой области, то вы прекрасно и без меня знаете цену разрядности шин, задержкам памяти и водяному охлаждению. Для остальных же важнее окажутся важнее другие параметры. Дело даже не в отличии стоимости ноутбука и ПК за единицу условной производительности - на практике средний ноутбук почти всегда свежее чем ПК просто в силу того что у старого сдохла батарея.
Главное же отличие заключается в эргономике. Размер экрана и удобство клавиатуры это куда более важный аргумент в пользу ПК. Программирование как рабочий процесс это несколько одновременно работающих процессов и связанных с ними окошек - разместить которые на 15 дюймовом экране так, что бы это не сильно раздражало, мягко говоря, проблематично. Да, нынче есть всякие способы организовать пространство с помощью виртуальных рабочих столов и горячих клавиш, но к этому тоже надо отдельно привыкать. Что уж тут говорить о том, что к ПК без особых усилий можно подключить и два и три монитора. Да и, кто бы что не говорил, полноформатная клавиатура еще долго не станет пережитком прошлого.
В среднем рабочая станция должна легко удерживать в памяти какую-то одну главную среду разработки (IDE), пару второстепенных инструментов типа графического клиента базы данных, открытый браузер, как минимум с дюжиной вкладок, виртуальную машину или докер, и прочие мелкие подручные инструменты, включая почту и всякие чаты, так что бы не отвлекаться на них в телефон. Ключевое тут "легко": на машине с 4 гигабайтами оперативной памяти, может быть, удастся все это запустить одновременно, но работать она при этом будет медленнее вас. 16 гигабайт пока, наверное, избыточно, но, как бы, на вырост вполне, себе если цена не так важна.
Камень в принципе не самое узкое место рабочей станции. Да, компиляция процесс как правило тяжелый, но не постоянный и в основном параллельный. Вряд ли сейчас можно представить себе компьютер с одноядерным процессором. Если же надо что бы помимо компиляции параллельно проистекал второй тяжелый процесс, то четыре ядра надо. Частота процессора и его поколение в данном случае мало повлияет на результат - преимущество в 15% времени компиляции по сравнению с четырехкратной стоимостью, такое себе преимущество, от лукавого. Опять же, если вопрос не в деньгах - то чем свежее камень тем, понятно, приятнее.
До недавних пор велись споры о том, надо ли во что бы то ни стало устанавливать ОС и IDE на твердотельный диск. Сейчас, когда цены на SSD кусаются не так сильно, можно сказать, этот вопрос однозначно закрыт и ответ - однозначно да. Нынче ноутбук с классическим жестким диском надо еще поискать. Размер диска зависит опять же от доступных средств. Программирование как деятельность не вносит никаких дополнительных требований к объему диска. Даже если надо запускать дюжину докеров и иметь локально образы всех мыслимых операционных систем то вряд ли вы уйдете за пределы 500 гигабайт. Ставить в рейд массив двух-терабайтные PCI-E твердотельники индустрия пока не требует.
Тут могут возникнуть опровержения, мол, при желании можно обойтись и консолью с текстовым редактором, зачем же такая избыточная мощь. Подтверждаю - да, можно.
Vim vs Eclipse
Программирование, касательно рабочей станции, в сущности представляет из себя набор текста на каком-нибудь алгоритмическом языке программирования, работу с текстовыми файлами и компиляцией всего этого хозяйства в исполняемый код. Исходя из этого, теоретически, действительно, все что необходимо программисту это доступ к консоли и текстовому редактору. Причем именно к текстовой консоли и текстовому редактору в текстовой консоли. Чем, в общем, и довольствовались многие поколения программистов многие годы в бытность тонких клиентов и серверов, где эти программы в основном и выполнялись. Но это все осталось в относительно далеком прошлом. Сейчас программирование это все же чуть больше чем telnet, vim, бумажный талмуд со справочником команд, и кружка пива на нем.
Изменился подход к профессии, изменилась рабочая среда, изменились методы и цели. Нынче во главу угла ставится производительность, качество и экономическая эффективность. Появилось такое количество технологий и приемов работы, что ни один самый классный специалист не может знать все подряд. В то же время, интернет стал гораздо шире, появилась масса свободной информации ранее недоступной, а когда-то и тщательно скрываемой. Создано большое количество разнообразных инструментов, ранее отсутствовавших как класс. В последнее время, я бы даже сказал, слишком большое количество.
Хорошо это или плохо, я отношусь к тем, не побоюсь этого слова, олдскульным, ребятам, которые не гнушаются залезть иногда и в кишки сервера и подправить тот или иной скрипт в vim. Возникает ли такая необходимость нынче? Не сказать что бы часто, но время от времени куда проще не городить огород с установкой каких-то специальных клиентских программ и редакторов, а сделать все по-старинке из командной строки. Не из эстетических соображений, а как-раз ввиду развития вспомогательных инструментов и сред разработки многие молодые специалисты не в состоянии сделать какие-то простые вещи без готовой кнопочки или ползунка.
Молодым специалистам, а может и не очень молодым, я бы настоятельно порекомендовал специально потратить какое-то время на изучение приемов работы такими вот допотопными способами. Не в такой мере, что бы знать досконально как работает awk или sed, но что бы настроить какие-то параметры окружения, запустить компилятор с дополнительными аргументами - мастхев. Это не только дает дополнительный скил, но и помогает вникнуть в суть того что происходит в недрах тех же IDE пока мы этого не видим. Да и вообще, что бы лучше понять зачем надо было людям, что-то изобретать и пересаживаться с vim на emacs, а с него на Netbeans и Eclipse, и что в них такого хорошего.
Snippets'n'Autocompletion
Я, конечно, не знаток всех IDE и инструментов для программирования, но большинство распространенных так или иначе посмотреть приходилось. А главное, как олдфаг, я был свидетелем эволюции профессионального софта и имею достаточное представление о причинах и последствиях внедрения тех или иных фич в них. Надо ли с головой окунаться в использование новомодных штучек и перечитывать все 'Tip of the day' новой IDE вопрос, на первый взгляд, бессмысленный. На второй - на него не так то просто ответить, как себе, так и вопрошающему.
Начиналось ведь всё не бог весть с чего. Собственно, для удобства, в начале придумали языки программирования как таковые, но это не моя история. Лично я впервые столкнулся с таким новшеством как подсветка кода. Сейчас может показаться, что подсветка существовала всегда, но это не так. Подсветка появилась не одномоментно и непонятно когда изначально, но де-факто стандартом она стала вместе с продуктами Borland в 90-е. Визуальная помощь от среды разработки в виде обозначения цветом синтаксиса казалась тогда мегафичей и позволяла ускорить процесс если не в разы то на ощутимые десятки процентов.
Нынче набирать в IDE код нужно, ну, от силы, наполовину, остальное допечатывает среда. С одной стороны, это еще значительнее ускоряет сам ввод, а так же позволяет концентрироваться на идее, а не на грамматике и синтаксисе. Теперь не нужно держать в памяти имена всех переменных, функций, классов и методов, и даже целых языковых конструкций. Что значительно, как бы, облегчает работу. С другой стороны, такое облегчение оказывается причиной каверзных ошибок, которые потом сложно обнаружить глазом. Происходит это не только, и не столько, из-за схожести наименований методов или некорректной автоматической подгрузки зависимостей, а скорее в следствии того, что программист уже не помнит или не знает сам что и где должно было быть на самом деле.
Поэтому, как и в случае с консолью, я бы посоветовал, при изучении нового языка или фреймворка всегда начинать с менее специализированных приложений, таких как например Far Manager, Notepad++, Atom и прочих похожих, причем без соответствующих плагинов и разных помогаторов, оставив разве что подсветку. Что бы, так сказать, прочувствовать как всё должно работать в исходном виде, а потом уже позволять среде что-то частично додумывать за вас.
Затем, когда вы уже точно знаете, где приходится делать повторяющиеся действия и лучше было бы делать их как-то побыстрее, можно выбирать и более серьезный инструмент. Столяры пользуются навороченным электрическим инструментом не потому что они такие существуют, а исключительно в целях экономии времени на рутинных повторяющихся действиях, которые они прекрасно могут сделать и врукопашную. Более того, вы будете понимать, какой инструмент вам действительно подходит, не перебирая десять штук разных.
Так же следует относиться и ко всяким дополнительным облегчаторам и помогаторам - должно быть само собой очевидно зачем это нужно и как было бы еще лучше.
Javadoc + Google
Особняком среди многих такого плана фич IDE, фреймворков да и самих языков стоит онлайн помощь. Это когда среда во-первых, на лету подсказывает какие есть аргументы у метода; во-вторых, когда по клику можно переключиться на более детальную документацию. Так же в отличии тех времен, когда у программиста на столе лежали пара-тройка килограмм мануалов, нынче к услугам программиста есть интернет со своим стэковерфлоу. В данном случае я не призываю никого предварительно сходить в библиотеку или книжный магазин. Однако, пару слов о том как следует пользоваться всем этим добром сказать считаю не помешает.
Первое на что следует обратить внимание это то, что информация в интернете по качеству отличается от встроенной помощи или тех же печатных руководств не в лучшую сторону. Не нужно доверять примерам из интернета так же как родному манулу. Не только, потому что, люди часто ошибаются. Чем дальше эволюционируют языки и фреймворки тем больше накапливается устаревшей информации - той которая, могла быть, безо всяких дураков, правильной, но лет десять или пять тому назад.
В этом отношении бесспорным эталоном качества является Java и IDE построенные вокруг и для нее. Другие, менее консервативные варианты, это попытки в разной степени приблизиться к стандартам Javadoc. Особенно сильно рассинхроном доступной информации и фактического состояния дел страдают быстроразвивающиеся фреймворки и платформы. Это касается прежде всего новомодных разработок с использованием JavaScript. Страдают известным пренебрежением к обратной совместимости и целые стеки технологий, например, для Python и C# И если платформу .Net и фреймворки на базе Kotlin, Golang, Swift спасает так или иначе централизованная поддержка со стороны одной родительской корпорации, то остальные платформы и фреймфорки этим похвастаться не могут.
Опять же, это не только доставляет определенные неудобства в процессе работы, но и становится причиной снижения общего качества результата. Таким образом, если конкретно от вас зависит на чем будет разрабатываться новый проект, а соответственно и среда разработки, то это не последний критерий, о котором следует крепко подумать и аргументировать свой выбор.
Heavy metal vs Soul
Результатом всех этих нехитрых, в общем-то, размышлений должен стать рабочий процесс, который мало того что окажется эффективным, но и будет доставлять то самое эстетическое удовольствие, от которого я всячески пытался вас отговорить при выборе элементов рабочей обстановки. Можно ведь, не мороча себе и людям голову, поступить так как вам почему-то нравится. Но разве не лучше, если при этом вы можете обосновать свой выбор? Даже фоновую музыку в наушниках можно выбирать обоснованно, а не только потому, что вы от нее ловите кайф. Кайф то как-раз может оказаться здесь лишним.
Существует множество исследований на эту тему. Общей чертой таких исследований является то, что классифицируются в основном жанры и стиль музыки. По моему же личному представлению, для программирования, для погружения в алгоритм, для глубокой концентрации решающим фактором в пользу является вовсе не жанр или громкость, а ненавязчивость. В идеальном варианте это какие-то предпочитаемые вами композиции с минимумом значения в стихах (иностранную), без резких изменений физических свойств и не связанные с какими-то острыми эмоциональными переживаниями. Такая музыка функционально забивает посторонние шумы, на которые человек рефлекторно обязан отвлекаться - резкие, громкие звуки, человеческая речь, детский плач - заменяя их монотонным ритмом, который через какое-то время успешно игнорируется мозгом.
Есть люди предпочитающие полную тишину, и не зря. На самом деле, действительно, в тишине, а еще и в темноте, особенно перед сном, проще всего манипулировать абстрактными сущностями и залезать глубоко в закоулки сложных алгоритмов. Но полной тишины попросту сложнее добиться. Поэтому проблема наличия и выбора музыки, как части рабочей среды программиста, мне кажется совсем не праздная вещь. И обеспечение себя или ваших подчиненных условиями, в которых можно ее беспрепятственно выбирать и прослушивать значительно влияет на успех. Коего вам всем и желаю.
*/
End;
