Автор сегодняшней нашей статьи Майкл О'Чёрч хоть и утверждает, что исповедует либертарианский подход к разработке, тем не менее достаточно горячо выступил против использования IDE в работе, поскольку, с его точки зрения, они противоречат «философии Unix». А также он попытался проанализировать, почему же эти инструменты настолько распространены в корпоративной среде.
Интерактивные среды разработки (IDE) вызывают среди айтишников еще более жаркие споры, чем те или иные языки программирования. Я не отношусь к числу фанатов IDE. Считаю, что эти инструменты имеют право на существование. Вообще, в программировании я придерживаюсь либертарианских взглядов: делайте что хотите, только не мешайте мне делать мое дело. Тем не менее, в этой статье я хотел рассказать о некоторых порочных явлениях, которые характерны именно для таких компаний, где IDE становятся общепринятыми или обязательными инструментами разработки:
- проблема «полноприводного двигателя». Это явление связано с тем, что если неопытный водитель попытается проехать по бездорожью на полноприводном автомобиле, то рано или поздно застрянет. Сев за руль такого автомобиля, новичок просто успеет подальше забраться в глушь, прежде чем машина откажет. IDE оправдывают себя, когда с их помощью вам удается поддерживать чей-то страшно некачественный код, который без IDE был бы совершенно неуправляемым комом противоречий. Благодаря IDE даже самый отвратительный код может показаться сносным. Думаю, с этим согласятся все. Проблема в другом: наделяя вас такими возможностями, IDE подталкивают к довольно сомнительной практике. Мы начинаем постоянно гнать разработку вперед, мирясь даже с вопиюще некачественным кодом, когда необходимость исправить или полностью переписать плохой код становится очевидна всем. IDE позволяют отсрочить возникновение проблем с качеством кода и оттянуть масштабные бизнес-последствия. И это устраивает менеджезавров, обожающих жесткие дедлайны, но только усугубляет проблему в итоге.
- IDE-зависимость. Практики программирования, развивающие у разработчика зависимость от конкретной рабочей среды, просто непростительны. Причем неважно, о какой именно среде идет речь — Emacs, vi или Eclipse. Серьезная проблема IDE заключается в том, что они развивают у вас привычку работать таким образом, что переход в новую среду разработки крайне осложняется. Один из наиболее одиозных примеров такого рода находим в культуре Java: извращение принципа работы в командной строке, заключающееся в применении каталогов-синглтонов «src» и «com», но многие проблемы лежат гораздо глубже. Хуже того, из-за распространения IDE работу могут получить и такие «программисты», которые не знают, что такое система сборки и даже контроль версий. Им кажется, что о таких вещах уже позаботились «какие-то умники», а ширпотребному программисту достаточно уметь штамповать классы по требованию начальника.
- Спагеттификация. Я убежден, что хорошая IDE должна быть доступна только для чтения. Желательно, чтобы она могла обслуживаться через Веб. Считаю, что навигация по коду помогает любому, кому приходится читать код, независимо от его качества. Когда вы видите имя, у вас должна быть возможность щелкнуть по нему и посмотреть, где это имя определено. С другой стороны, для меня не менее очевидно, что автоматический рефакторинг — порочная вещь. IDE позволяет с легкостью «внедрять» в программу любые абстракции, из-за чего со временем она превращается в спагетти-код, где все делается повсюду. Без IDE есть только один способ выполнить подобную работу — написать скрипт. Это оказывает на процесс разработки два эффекта. Во-первых, на внесение любых изменений требуется время, может быть, полчаса. И это хорошо: ведь если скрипт приведет к изменениям, которые отразятся на работе каждого, об этих изменениях придется поговорить, и такая беседа продлится явно дольше, чем полчаса. Во-вторых, такую работу смогут выполнить только настоящие программисты — по крайней мере, понимающие, что такое «скрипт» и «командная строка».
- Время, затрачиваемое на поддержку среды разработки. Как только компания решает использовать для работы «вот эту среду» — обычно речь идет об IDE с различными корпоративными надстройками — IDE начинает обрастать разнообразными плагинами, порой довольно некачественными. Ее приходится поддерживать, появляется масса постылой работы, которой никто не хочет заниматься.
И это только верхушка той груды проблем, которые порождает «культура IDE». Хуже всего, что IDE приучает вас писать плохой код. Поэтому еще раз подчеркну, что я не отвергаю IDE в принципе. IDE — это просто инструмент, который порой бывает полезен. Если вы работаете с IDE и при этом умеете писать качественный код, я только рад за вас. Тем не менее, я не переношу культ IDE, так как люто ненавижу тот отвратительный код, который они плодят.
По моему опыту, именно в таких средах разработки, которые значительно зависят от IDE, получается наиболее дремучий спагетти-код, объектно-ориентированная сумятица и прочие монструозности, которые просто не мог написать полный идиот. Ему помогли. Автоматический рефакторинг, из-за которого код переполнился бессмысленными абстракциями? Зависимость от инъекций? Корявые паттерны? Да, в них все дело.
Кстати, в последнее время я стал глубже изучать язык C, так как все плотнее занимаюсь машинным обучением и понимаю, насколько важно уметь судить о производительности и какие исчерпывающие знания вычислений для этого требуются. Как минимум необходимо свободно изъясняться на языке C. Я прорабатываю книгу Зеда Шоу «Learn C the Hard Way», где автор высказывает ряд блестящих мыслей о программировании как таковом. Во вступительной главе он предупреждает, что при обучении не следует пользоваться IDE, а также поясняет свою точку зрения:
IDE или “интегрированная среда разработки” просто отупляет вас. Если вы хотите стать хорошим программистом, такие инструменты вам противопоказаны, так как они скрывают от вас суть процесса, а вы должны совершенно четко представлять, что делаете. Они полезны, если нужно срочно решить какую-то задачу, а платформа построена на базе определенной IDE. Но если вы учитесь писать код на C (а также на многих других языках), IDE просто бессмысленны. [...]
Да, вы пишете код довольно быстро, но можете программировать только на этом языке и только на этой платформе. Неудивительно, что некоторые компании столь охотно продают вам эти IDE. Они знают, что вы ленивы. Обзаведясь IDE, вы оказываетесь заключены на ее платформе — только потому, что вы ленивы. Чтобы разорвать этот порочный круг, нужно сжать зубы и наконец-то научиться программировать без IDE. Вы по-настоящему освоите работу с кодом в простейшем текстовом редакторе или в программерском редакторе — например Vim или Emacs. Да, поначалу это не так просто, но в итоге вы научитесь работать с любым кодом, на любом компьютере, на любом языке, так как будете понимать, что делаете (выделено мною — авт.)».
Не могу согласиться с пассажем «IDE отупляет вас». Опираясь на нее, кодер в принципе не умнеет, но я не думаю, что такой инструмент действительно вызывает деградацию способностей программиста. Программирование в больших корпорациях (масса работы по техподдержке, низкая продуктивность, полдня теряется на митинги, сложности с выбиванием разрешения на занятия интересными задачами, плохие исходники) действительно со временем разрушает личностные навыки, но дело здесь не только в IDE. Тем не менее, в целом я с ним согласен. Большинство ярых сторонников IDE — это посредственные программисты, знающие всего один язык и одну среду. К тому же такие люди не развиваются, так как не понимают, что именно происходит в коде. Подобные кадры губительны для софтверной индустрии. Программист обязан развиваться, если он этого не делает — его следует уволить.
Проблема с IDE заключается в том, что каждая корпоративная культура разработки подстраивает IDE под себя. При этом среда программирования становится настолько необременительной и простенькой, что дома, без любимой IDE, вы фактически ничего не можете написать. Для людей вроде меня, которые в принципе не любят такую среду, это не представляет проблемы, так как я вполне сносно программирую и без этих прибамбасов. Но если кто-то скатился в ритуальное программирование, так как сразу начал работать неправильно и уверен, что любая разработка должна протекать только в IDE (а больше-то он ничего и не видел), то он перестает быть программистом в 18:01 каждый будний день. У новичков зачастую даже не хватает навыков, чтобы самостоятельно настроить знакомую им среду разработки. Базовые навыки нужно приобретать там же, где ими овладели все великие программисты — в командной строке. И человек останавливается в развитии не потому, что хочет этого, а из-за простого непонимания, что же такое «программирование» на самом деле.
Самое большое бедствие, свойственное этим на первый взгляд насыщенным корпоративным средам, — это отсутствие документации. При работе с Unix и инструментами командной строки вы всегда найдете в Интернете man-справку и практические руководства. Такие ресурсы стимулируют иную культуру, где каждый умеет решать стоящие перед ним проблемы. Имея достаточно времени, вы сможете найти ответы на любые ваши вопросы. Именно на таком материале вы и растете: не знаете, как что-либо работает, гуглите полученное сообщение об ошибке, получаете результат. Подобные знания приобретаются не за один день, зато они получаются глубокими. Этот процесс не работает в чрезмерно усложненной корпоративной среде. Чтобы немного продвинуться в решении проблемы, приходится отвлекать от работы знающего человека. А трата рабочего времени на реальное самообразование кажется многим менеджерам неприемлемой.
Здесь я снова хотел бы процитировать Зеда Шоу («Learn C the Hard Way», глава 3):
В разделе "Дополнительное задание" к каждому упражнению я иногда ставлю перед вами задачу самостоятельно найти информацию и разобраться в проблеме. Это важное умение самодостаточного программиста. Если вы постоянно обращаетесь к кому-то с вопросами, а не пытаетесь разрешить их своими силами, то никогда не научитесь решать проблемы независимо. Следовательно, вы никогда не будете уверены в собственных навыках и всегда будете нуждаться в ком-то, кто возьмет на себя часть вашей работы. Чтобы избавиться от такой вредной привычки, первым делом постарайтесь самостоятельно ответить на вопрос, а также проверить, правилен ли ваш ответ. Для этого придется докапываться до сути, экспериментировать с возможными вариантами ответа и проводить собственные исследования (выделено мною — авт.)».
Читатель уже понимает, что я выступаю против феномена «посредственного разработчика». В апреле прошлого года я писал статью «Java Shop Politics», касающуюся той же темы. Теперь я считаю, что зря выделил только язык Java, противопоставляя его C#, VB или даже С++. Я считаю, что любая компания, подчеркивающая свою приверженность любому языку X, работает неправильно. Корень зла не в самом языке Java, каким бы ограниченным он ни казался, а в культуре Большой Софтверной Компании. Именно в таких условиях множатся посредственные разработчики и вырождается сама идея объектно-ориентированного программирования, которое в настоящее время ушло уже достаточно далеко от идей Алана Кея.
В хорошо управляемых софтверных компаниях программы пишутся для решения проблем. Если проблема решена, это означает, что программа ГОТОВА. В будущем эта программа может потребовать адаптации или технической поддержки, но изначально это не предполагается. Не ведется разговоров о том, сколько штатных работников потребуется задействовать на текущую поддержку программы после завершения ее разработки. Если когда-нибудь потребуется изменить программу, это будет сделано. Программа решает четко поставленную проблему, после чего ее авторы переходят к решению новых задач. Боже упаси от программ, постоянно обрастающих требованиями. Отношение «программист-программа» должно строиться по принципу «один ко многим». Именно в такой ситуации начинается написание программ «по мере необходимости». Единственная проблема такого подхода в том, что он требует микроуправления небольшими программами, которые могут быть достаточно важными. Это и не устраивает «менеджезавров», привыкшим отслеживать выработку. Не нравится это и нерадивым сотрудникам, которым сложнее понять, к кому обратиться за помощью и когда именно дела пойдут плохо. Такая ситуация не возникает лишь в случае, когда работа каждого отдельного программиста отслеживается лишь его непосредственным клиентом, и человек может тихо делать очень важную работу (например, понемногу оптимизировать алгоритмы ядра, снижающие нагрузку на сервер). Но ведь можно выстроить и противоположную систему: множество разработчиков трудится над огромной программой, Которая Делает Сразу Все. Это порочный путь программирования, но именно к нему нас подталкивает активное использование IDE. Дело в том, что для настройки огромной общекорпоративной IDE требуется проделать немалый объем работы, поэтому такая настройка выполняется всерьез и надолго. Это и привлекает менеджеров, желающих руководить Огромными Проектами, на которых легко поддерживать однородность кадрового состава. В этом коренится политика использования одного языка. Хотя менеджеры ее и обожают, она зачастую оказывается бессмысленной.
Полагаю, что правильная организация труда такова: инженер должен заниматься разработкой нескольких небольших самодостаточных программ. В этом и есть суть так называемой «философии Unix». Напротив, Большие Программы неизбежно обрастают недокументированными протоколами связи и требованиями к согласованности, нарушение которых чревато не только появлением ошибок, но и случаями удручающего непонимания. Из-за этого размывается исходная концептуальная целостность системы, появляется спагетти-код и «комья грязи». Чтобы этого не происходило, отдельные программы должны быть небольшими, а крупные проблемы должны решаться на уровне систем, состоящих из таких программ. Система, в свою очередь, должна обладать такими качествами, как отказоустойчивость.
Существуют ли успешные исключения из философии Unix? Да, но они встречаются редко. Классический пример работоспособной большой программы — это база данных, к подсистемам которой зачастую предъявляются очень жесткие требования (транзакции, производительность, параллелизм, выносливость, отказоустойчивость). Базу данных просто невозможно собрать из небольших программ, так сказать, органически вырастить. Чтобы создать работоспособную базу данных, требуется определенная высокоуровневая координация. Ведь в случае с базой данных бизнес-требованиями нельзя пренебрегать, они критически важны. Postgres — на мой взгляд, наилучшая из существующих SQL-баз, совсем не проста. Кстати, в базах данных нарушается один из основных принципов философии Unix — хранение данных в виде обычного текста. На то есть веские причины (рациональное использование носителей информации).
Кроме того, работа с базами данных требует, чтобы их можно было эксплуатировать, не вникая в сложный процесс эволюции такой системы и высокооптимизированные внутренние детали. Поэтому в данном случае отделение реализации от интерфейса (одна из сильных сторон объектно-ориентированного программирования) оказывается необходимым благом. Связующие конструкции, применяемые в базах данных, — например, указатели на файлы — должны быть объектами (под «объектом» в данном случае понимается сущность, которую можно использовать, не вполне представляя себе ее внутреннюю организацию). Также необходимо отметить, что множеству очень умных людей понадобились десятилетия, чтобы как следует наладить работу баз данных. Итак, большие проекты побеждают, когда поставленная задача невыполнима при помощи небольших проектов или «свободной федерации» таковых.
Я считаю, что очень многие айтишные менеджеры ошибаются, думая, что руководят разработкой какого-то исключительного продукта. Вот-вот их Большая Система (подобная Postgres) вырастет и станет настолько важной, что люди смирятся с ее сложностью и начнут ею пользоваться, так как эта Система станет чем-то более масштабным, чем Postgres или ядро Linux. Практически всегда они ошибаются. История корпоративной разработки напоминает слоновье кладбище, усеянное останками таких огромных систем. Исключения из философии Unix встречаются крайне редко. Можете быть уверены, что ваш корпоративный суперпродукт таким исключением не является. Если вдобавок большинство ваших посредственных разработчиков не могут писать код вне вашей IDE, то вам не позавидуешь.
Майкл О’Чёрч
Источник
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.