Первая часть текста написана до 2011-ого. Точную дату уже не скажу.
Недавно меня нашёл один программист и спросил, не хочу ли я писать с ним сайты. Мол есть заказчики (забугорные), есть наработки, нужны программисты.
Не знаю, почему он сам не хотел этим заниматься, возможно, решил, что стоит заняться менеджментом… В общем, не знаю. Меня устраивает моя нынешняя работа, поэтому, ни менять её, ни писать код «на два фронта» я не хотел, о чём сразу же ему сообщил. Он тут же у меня спросил, не могу ли я ему посоветовать хорошего программиста на Drupal’е. Этим вопросом я был выбит из колеи…
Drupal — это cms на php. «Программист на cms» звучит как-то бредово, не так ли? Я, признаться, считаю, что программист должен уметь писать на любом языке, в котором присутствует хоть какая-то логика, близкая к человеческой. Программист способен уже через неделю знакомства с языком, суметь написать на нём проект. Это не потому, что он такой замечательный лингвист, а потому, что написание программы, разработка проектов — задачи больше архитектурные, нежели кодерские/лингвистические.
Безусловно, архитектура языка, фреймворка накладывают свой отпечаток, нужно их учитывать, но тем и отличается опытный программист от начинающего кодера.
«Силу бойца определяют его умение, острота меча и пыл сердца» — пардон, цитата не точная из вроде бы 7-ми самураев.
Себя я предпочитаю считать программистом на императивных языках. У меня есть предпочтения, но я стараюсь не ограничивать себя предубеждениями, пробовать разные языки (это ещё и гиковский способ отдыха, но не об этом).
Поэтому мне было странно слышать, что человек ищет программиста на конкретной cms. В голову сразу приходила аналогия — автомеханик, специализирующийся на ключе на 16…
Но чем больше меня грыз этот вопрос, тем больше во мне возникали сомнения. Да ещё Валерий Павлович временами подливал масло в огонь, рассказами про виртуоза монтёра кондиционеров.
Специализация, разделение труда, всё большая дискретизация наук… Почему всё это работает? Мир не скатывается в каменный век, а развивается, не смотря на то, что главенствующим является не системный подход. Парадигмы программирования и паттерны проектирования держат программистов в узких рамках, заковывая в себя мозги на столько, что порой человек не может переключиться с ООП на что-либо другое. Или увидеть очевидное решение, которое противоречит модным паттернам.
Программисты начинают просто кодить, применяя алгоритмы как рецепты (не вникая в суть), заучивая паттерны как «отче наш». Временами выливая свой негатив на программистов на других языках, мол языки плохи, при этом забывая, что язык программирования — отнюдь не главное в разработке.
P.S. (2011-ый)
Пару месяцев назад, когда нужно было выбрать сервер стримминга видео для одного проекта, наткнулся на стенограмму доклада Максима Лапшина, где он рассказывал о своём сервере erlyvideo и преимуществах erlang в разработке подобных проектов. В ней довольно красиво описываются преимущества нестандартного подхода (архитектуры) erlang перед распространёнными языками.
Иной раз метла как оружие лучше, чем самый острый меч. Главное — понимать их особенности и не зацикливаться на чём-то одном.
P. P. S. (2017-ый)
Слишком много я видел специалистов по всему. Я сам когда-то гордился, что хоть на tasm под DOS, хоть на C под Linux, хоть на JavaScript под v8. Это полезно для общего развития. Пригождается для переквалификации.
Я искренне радуюсь, видя стажера, который увлекается C, программирует контроллеры, при этом пишет интерфейсы на React+Redux. Когда его попросили ради эксперимента сделать интерфейс на Sencha — он просто сел, разобрался и сделал. Это тот подход, который мне больше всего нравится: не гнушаться технологиями, а программировать.
Я выберу его при прочих равных, ибо я сам такой. Здесь вопрос уже не профессионализма, а взаимопонимания и комфорта.
Но при иных вариантах, когда нужен конкретный специалист на задачу (например, запрограммировать Drupal), выбор очевиден — нам нужен «программист на Drupal». И тут не важен опыт в Haskell, понимание ядра Linux. Тут важно сделать быстро то, что нужно. Если это сделает программист-универсал так, чтобы это было в рамках логики «Drupal» и прекрасно поддерживаемо любым другим — я выберу его (с отставанием не больше 20 — 30 %%).
Есть проблема. Программисты, которые могут много и на разном — товар штучный. И далеко не всегда они эффективны в узких областях. И далеко не каждый потом сможет поддерживать их код.
Когда-то давно я писал курсовую — считалка боевой части Heroes of Might and Magic 3. Для того, чтобы обучать нейросеть. Она у меня заняла 200 — 300 строк кода на Perl. И каждая строка была своеобразным развлечением — можно было разбирать её минуты. Но мой науч. рук. через пару месяцев сказал: для того, чтобы я её принял, надо добавить ещё тото и тото. И тут у меня случился провал… Я переписал с нуля всё на том же Perl, но теперь каждая строка была проста и понятна. Комментарии были ненужны — всё было в коде разжёвано до предела. Это уже было 2 тысячи строк кода, но я мог добавить туда любую сумасшедшую идею.
Чем дальше, тем меньше я программирую. Теперь мой код часто можно сравнить с кодом неуверенного новичка — никаких хитрых конструкций. Всё разбито на простые функции. Всё пресно и скучно. И никак не определить: кто это писал — никакого самовыражения. Применяются простые и дубовые подходы в архитектуре вместо изящных и эффективных.
А всё потому, что я стараюсь быть в любой сфере «программистом на Drupal». Человеком, который не сделает хуже, а просто сделает.
«Программисты на Drupal», безусловно, нужны. Они делают хорошо, быстро, дёшево. В своей области, но делают. Вместо объяснений: «Ну, понимаете, нельзя просто так взять и сделать insert в базу данных — нам нужно предварительно сделать проверку данных, открыть транзакцию, написать залочку, поднять пул соединений…» они просто делают «add_item(…)» — и верят в то, что всё пройдёт хорошо. А если там баг — в следующем обновлении они его починят.
В итоге: будь «специалистом во всём», веди себя как «программист на Drupal».