×
Фото Программист на Drupal против программиста на ЯП. История одного программиста

Программист на Drupal против программиста на ЯП. История одного программиста

Недавно меня нашёл один программист и спросил, не хочу ли я писать с ним сайты. Мол есть заказчики (забугорные), есть наработки, нужны программисты.

Первая часть текста написана до 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».

Будь первым – оставь комментарий!

Фото Первичная настройка FreeBSD
Предыдущая запись:
Первичная настройка FreeBSD
Фото Micro men — фильм о начале эпохи PC
Следующая запись:
Micro men — фильм о начале эпохи PC

Интересное на «Цифре»

Фото 5 причин не исправлять "ошибки"
5 причин не исправлять "ошибки"
Сразу оговорюсь, речь пойдёт не о критических ошибках. Если ваш сервис лежит бездыханный, то конечно — ноги в руки и фиксить.
"Чайка-менеджмент". Опасности и злоумышленники
Не так давно мы рассмотрели анти-паттерн “Чайка-менеджмент”, однако, совсем забыли рассмотреть опасности для такого менеджера
Фото «Методологическое безумие» и «Scrum»
«Методологическое безумие» и «Scrum»
Пока в Москве повальное увлечение методологией “скрам” меняется на “бирюзу”, в регионах так и продолжают внедрять “скрам”. Оба эти увлечения обычно не приводят ни к чему хорошему. В конце концов всё приходит к “у нас скрам, но не совсем” или “скрам — говно”
Противление методологиям как методология
Забавное нынче время. Попы освящают дата-центры, детям преподаётся креационизм, а в командах разработки появилось новое обзывательство: “теоретик”