Желание написать такую статью возникло у меня очень и очень давно. Но, наверное, потребовалось целое десятилетие, чтобы все частицы мозаики могли собраться воедино, и кроме самой проблемы я смог увидеть и её решение. Сегодня вместо эмоционального негодования я хочу предоставить своим читателям конструктивный обзорный материал, способный помочь им уберечь себя от «быдлокодеров».
Что же такое «быдлокод»? В первую очередь, это результат некачественной работы программиста, как правило, низкоквалифицированного. Основной проблемой такого «кода» является вовсе не его полная неработоспособность, а высокая нагрузка на сервер, вызванная выбором методов решения задачи. А также «глюки», которые может вызывать скрипт при совместной работе с остальными компонентами системы.
Впервые термин появляется пару десятилетий назад, когда крупные корпорации начали переносить свои «производственные мощности» в страны третьего мира. И кто-то из «эффективных менеджеров» предложил оплачивать труд программистов «посимвольно». Это привело к тому, что писать короткие и понятные «сценарии» стало экономически невыгодно, и программисты из развивающихся стран вынуждены были создавать сложные, неуклюжие и витиеватые конструкции, совершенно неэффективные в работе. Львиная доля таких «сдельщиков» на тот момент были жителями Индии, поэтому среди разработчиков развитых стран появился термин «индусский код». Наверное, именно «индусский код» можно считать первым проявлением «быдлокодерства».
Должен отметить, что в сообществе программистов «быдлокодерами» также презрительно называют PHP-программистов. Считается, что «быдлокодеров» в их среде несколько больше, чем среди разработчиков, работающих с другими языками программирования. Это связано с тем, что PHP изначально не использовал объектно-ориентированную модель, и за годы своего развития язык лишь частично обрел поддержку принципов ООП.
Объектно-ориентированный язык программирования – это такой язык, в котором существует некая модель данных, где каждый объект относится к определенному типу или классу и имеет свои атрибуты, которые наследуются дочерними элементами.
Если говорить простым языком для тех, «кто в танке»: есть объект, например, «Форма», в которую как бы «вложен» сценарий, который обеспечивает её работоспособность, т.е. проверяет корректность вводимых данных и при отсутствии ошибок отправляет данные в базу. И чтобы модифицировать этот сценарий вам просто нужно найти нужную форму через интерфейс среды разработки и переписать сценарий. Если говорить о программировании на PHP, то сценарий обработки формы может быть где угодно, так как все объекты, за исключением самой базы данных и графических элементов, физически не существуют. Все необходимые элементы страницы, запрашиваемой пользователем, создаются в результате работы того или иного сценария. Поэтому найти нужный сценарий бывает не так-то просто среди множества файлов системы. К тому же любой сценарий может обратиться к любому PHP-файлу, чтобы вызвать уже используемую где-то функцию. Это приводит к тому, что при необходимости модернизировать какой-то участок кода всегда требуется проверять, не используется ли этот сценарий где-то ещё и не повлияет ли его изменение на работоспособность других элементов системы. Таким образом, отсутствие жесткой структуры ведет к тому, что логика и стройность системы отдается на откуп программисту, где он выступает в качестве системного архитектора, и тут уже все зависит целиком от его профессионализма в проектировке. И то, что кажется логичным и стройным для одного, может показаться хаосом для другого. Вот почему в описаниях вакансий PHP-программистов, почти всегда можно встретить формулировку «умение читать чужой код».
Но означает ли всё вышесказанное, что среди PHP-программистов на самом деле больше «быдлокодеров», чем среди остальных представителей этой профессии? Вовсе нет, просто среди веб-разработчиков их проще выявить.
Также, отсутствие необходимости в приобретении дорогостоящей «среды разработки» привлекает в отрасль людей, не имеющих профильного образования. И пускай меня заплюют «айтишники», но основываясь на собственном опыте, могу с уверенностью сказать, что «быдлокодеров» порядка 90% среди всех программистов. И даже среди оставшихся 10% не найдется того, кто не признался бы сам себе, что написал «быдлокод» буквально… полгода назад! Я здесь не говорю об армии «школяров», которые лишь вчера покинули свои ВУЗы, я говорю об уже сложившихся профессионалах, имеющих реальный опыт серьёзной работы более 10 лет.
Почему же все так не любят быдлокод и чем он опасен? Уверен, что каждый из вас сталкивался с проблемой, когда программный продукт – будь то операционная система или сайт не только не работает так, как ожидает от него пользователь, но и попросту «зависает» или не выполняет корректно нужную операцию. Всё это проявления быдлокода, критическая «масса» которого увеличивается с каждой, даже самой несущественной, модернизацией системы. Что в один прекрасный момент способно повлечь за собой не только серьёзный сбой программного комплекса, но и полный отказ оборудования, на котором оно установлено.
Говоря о «быдлокоде», нельзя не упомянуть о проблеме непонимания между разработчиком и заказчиком, которая всегда была, есть и будет.
Кстати, с айтишниками я не мог вообще никогда вести переговоры. Мне казалось, что я говорю на русском, а они – на козьем. Надо иметь человека в компании, который переводит с козьего, а нам с этим не везло абсолютно. А переводчика с их стороны практически никогда не бывало.
(Евгений Чичваркин. Четыре комнаты. Как и с кем стоит вести переговоры. Slon.ru 10.12.2010)
Связана она в первую очередь с полным нежеланием технических специалистов понимать и вникать в задачи бизнеса. И несмотря на то, что они всегда требуют четкого формулирования задачи, какое бы подробное техническое задание вы для них не подготовили, конечный результат всегда будет не таким, каким вы его представляли.
Программисты всегда решают поставленную задачу исходя исключительно из своего собственного представления и в меру своих способностей.
Этот конфликт существует с момента появления информационных технологий, как отрасли, и нежелание и неспособность вести прямой диалог разработчиков с управленцами сегодня практически привел к их полной изоляции друг от друга. Что конечно же отражается на методах взаимодействия и ведет к усугублению проблемы «быдлокода».
Сегодня во многих крупных компаниях и веб-студиях успешно внедряются «тикетные системы» или системы совместной работы над проектами. Это что-то вроде внутрикорпоративной среды, где к каждому участнику «приходит» заявка с заданиями, которые программист должен выполнить в течение дня. Как правило, такие заявки отправляются людьми очень далекими от программирования, сложность которых румяные начальники и грудастые проджект-менеджеры, скорее всего, оценивают «на глаз» или «посимвольно», как это было с «индусским кодом». Если два предложения в задании, то оно должно выполняться за два часа, если одно – за час. Ну, это лично моё предположение. Как вы думаете, способен ли такой подход снизить уровень «быдлокода» в системе? Конечно же нет, он только приумножит его! Бесспорно, «тикетная система» позволяет управленцам не видеть в глаза «этих чертовых разработчиков», а программистам жить в их уютном тихом мирке, отгороженном перегородками от сурового внешнего мира. Вроде бы всем удобно, но не самой компании и её программному продукту.
Безусловно, «тикетная система» в определенных условиях является эффективным инструментом, но это возможно только в том случае, если задание формулируется и направляется человеком, хорошо знакомым со средой разработки и понимающим все нюансы процесса.
Теперь давайте вернемся к проблеме «быдлокода» и посмотрим, как сегодня решают подобную проблему представители крупного бизнеса. Очень просто – с одной стороны они стараются создавать «собственные школы» программистов под началом ключевых фигур компании, возглавляющих отделы разработок. Куда они привлекают молодых и увлечённых специалистов, чтобы «натаскать» их, используя опыт собственных ошибок. Так, руководители постепенно знакомят новых сотрудников с существующей системой и отрабатывают качество их кода сначала на элементарных задачах. Другими словами, «создают» новое поколение программистов «под себя».
С другой стороны, борьба с неэффективным кодом ведётся «аппаратными» средствами. Что банально сводится к количественному увеличению парка серверов или заменой имеющихся машин более мощными. Если говорить о веб-технологиях, то появление «облачных хостингов» является как раз подобной мерой. Облачный хостинг позволяет добиться более высокой скорости обработки данных и способен обеспечить более высокую отказоустойчивость системы. Я считаю, что проблему «быдлокода» необходимо решать именно с двух сторон, т.е. улучшать код с одной стороны и расширять аппаратные мощности при необходимости с другой.
К сожалению, сегодня решать проблемы «сложным путем» не модно, а выращивание толковых программистов – дело совсем непростое. Зато очень модно получать степень MBA (англ. Master of Business Administration или Магистр делового администрирования), которая так популярна в «загнивающих капитализмах». И эти новоиспеченные «магистры», как правило «создаваемые» на базе технических специалистов, занявших теплые кресла начальников, начинают «внедрять» новые технологии гордо демонстрируя свою «учёность».
Например, в настоящий момент широко известный интернет-магазин канцелярских принадлежностей «Комуc» занимается переносом своего сайта и корпоративной системы документооборота с технологии LAMP (Linux, Apache, MySQL, PHP) на платформу Java Enterprise Edition. Компания пытается заменить существующую «неэффективную» систему, написанную собственными разработчиками, команда которых, между прочим, в настоящий момент насчитывает несколько десятков человек, платформой «Hybris». Недешевое, знаете ли, решение. Но вместо того, чтобы нанять толкового руководителя и привести в порядок имеющиеся наработки, компания пытается «сменить глобус». Чтобы у демагогов не было соблазна противостоять мне в комментариях и доказывать, что «Java рулит» (да кто ж с этим спорит!), хочу представить вам цикл статей, написанных ведущими разработчиками IBM об использовании бесплатной системы управления сайтом «Drupal» в качестве платформы для внутренней корпоративной системы. Более того, с уверенностью могу сказать, что IBM достаточно долго сама использовала этот «фреймворк», хотя и сильно модифицировала его, чтобы оптимизировать систему и снизить нагрузку на сервера. А российский сайт известнейшего журнала «Forbes» с суточной посещаемостью, превышающей 200 тысяч пользователей, до сих пор использует эту платформу.
Так значит все-таки можно бороться с «быдлокодом»? Конечно, можно… и нужно!
Добавлю от себя, что система управления сайтом «Drupal» – это тот ещё продукт «быдлокодерства». Но, как говорится, любую блоху можно подковать…
Если расширение аппаратных мощностей в большом бизнесе иногда самый простой и эффективный способ, то в малом бизнесе такой подход абсурден и лишен смысла. Вот вам живой пример. Один молодой стартапер (хоть его проекты и являются «контентными», я всё равно считаю его «стартапером») создал несколько достаточно серьёзных рекламных площадок на популярной системе «Wordpress» и столкнулся с проблемами нагрузки на сервер. Он решил свою проблему и поделился её решением в статье на «Хабре». И всё там, в принципе, правильно и грамотно рассказано, кроме одного – судя по статье, в работу над оптимизацией своих проектов и новую серверную площадку он вложил больше средств, чем потребовалось бы на создание «легкого» движка, написанного исключительно под его нужды. Который мог бы раз и навсегда решить проблемы с нагрузкой. И такое решение очевидно, так как все его ресурсы имеют достаточно примитивные функциональные возможности, и разработать собственное продукт – это простейший путь решения проблемы. Лично я знаю, как минимум, полдюжины отличных разработчиков, которые могли бы с легкостью справиться с поставленной задачей по вполне разумной «цене вопроса».
Так что же делать представителям малого и среднего бизнеса, чтобы избежать проблем «быдлокода»?
В первую очередь, нужно найти «правильного» разработчика. Выбирая программиста необходимо смотреть не только на его достижения и выполненные проекты, но и на его адекватность, как человека. Помните, что избежать конфликта с программистом невозможно, поэтому сразу прикидывайте, приятен ли вам лично этот человек или нет, и насколько он может быть адекватен в конфликтной ситуации. Другими словами, удастся ли вам от него добиться нужного результата в том случае, если его представление о «правильном решении» будет серьёзно разниться с вашим.
При выборе отдавайте предпочтение тем разработчикам, которые уже решали задачи, похожие на ваши. Обязательно попросите продемонстрировать портфолио и не бойтесь расспрашивать о каждом решении или продукте, спрашивайте о поставленных задачах и методах их решения. Даже если вы в этом совершенно ничего не понимаете, рассказ от первого лица о задаче, которая была поставлена и решении, которое было выбрано, способен дать вам представление о том, насколько сам разработчик вникает в задачи работодателя и как ищет решение.
Большинство программистов люди замкнутые, и скорее всего, вам потребуется приложить немало усилий, чтобы разговорить человека и получить нужные ответы. Если же вам попался «бойкий» товарищ, который восторженно рассказывает о каждом из решений, особо подчеркивая свои заслуги в проекте – гоните его в шею. Гарантирую, что с таким человеком построить конструктивный диалог не удастся.
Помните, что ни один программист никогда не поймет задач бизнеса, просто примите этот факт, как данность! Вам каждый раз потребуется разжевывать не только суть задачи, но и методы её решения. А также описывать перспективы развития системы, чтобы ваш разработчик мог хотя бы примерно представить возможную эволюцию конечного продукта. Это необходимо для того, чтобы у человека появилось хотя бы абстрактное представление о системе в целом. Наличие такого представления может серьёзно повлиять на выбор конкретных программных решений, что, безусловно, снизит процент неэффективного кода. Помните, что в программировании есть миллион способов добиться одного и того же результата, а «быдлокод» складывается из неправильного выбора методов для решения отдельно взятых задач. Так, любой продукт с точки зрения кода представляет из себя «лоскутное одеяло». И чтобы ваша система была не только жизнеспособной, но и эффективной, швы между этими лоскутами должны быть как можно ровнее и аккуратней, чего нельзя добиться, если программист не имеет общего представления о конечном продукте.
При оценке квалификации разработчика будьте очень осторожны, так как в некоторых случаях новичок может оказаться эффективней, чем человек с некоторым опытом.
Давайте представим, что перед нами стоит задача сделать три варианта вывода анкетных данных в каталоге товаров и нам необходимо дать возможность пользователю в любой момент переключиться на каждый из этих вариантов вывода данных. Первый вид анкеты – картинка и минимальная информация о товаре, второй вид анкеты содержит более подробную информацию, а в третьем – кроме общей информации выводятся ещё и базовые характеристики товара, а также его дополнительные фотографии. В принципе, типичная задача. Как её будет решать программист-новичок? Он прибегнет к шаблонному решению из книжки – создаст три HTML-шаблона и напишет сценарий, который при переключении типа вывода будет отправлять запрос в базу и строить вывод на основе выбранного пользователем шаблона. Возможно, его код и не будет совершенным, а результаты выборки будут иногда теряться, но в принципе, это будет хоть и кривоватый, но вполне рабочий инструмент. Как поступит разработчик «с опытом» или «дока»? Такой подумает, что работа с шаблонами – это дилетантство. Круто – это когда мы можем «динамически» и «на лету» сгенерировать шаблон. Зачем нужны шаблоны, если мы можем их создать прямо из сценария – это ведь так удобно! Может быть и удобно, но только ему. Так, этот «клоун» постарается запихать в сценарий вывода данных ещё и генерацию этих трех форм, а также, каждый раз будет запрашивать все параметры записи из базы данных, а не только те, которые содержаться в выбранном шаблоне вывода, и будет доволен собой. Я думаю, что здесь не нужно объяснять, что подобное решение не только серьезно замедлит скорость загрузки страницы, но и значительно повысит нагрузку на сервер.
Вы удивитесь, но настоящий программист-профессионал поступит точно также, как и новичок – создаст три HTML-шаблона для каждого вида отображения, но, в отличие от новичка, он сможет учесть все нюансы поведения пользователя и обеспечить идеальную работу сценария, при которой выборка бы не терялась ни при переключении типа формы, ни при изменении количества записей на странице и т.д. и т.п. Вы, наверное, бывали на страницах интернет-магазинов, где, пролистав несколько страниц вы понимали, что вывод по 25 товаров – это мало и вы хотите видеть сразу 100 записей на странице. Но изменив количество отображаемых на странице объектов, вы либо оставались на странице, имеющей тот же порядковый номер, и чтобы найти то место, где вы остановились, вам требовалось вернуться на несколько страниц назад, либо вас просто выбрасывало на первую страницу выборки и хорошо, если критерии отбора не терялись. Это типичный пример работы первых двух программистов и откровенное «быдлокодерство». Но, если вы меня поняли, «косяки» новичка достаточно невинны и легко поправимы, если есть кому «подчистить хвосты».
Если же вы стартапер и вам необходима группа разработчиков, чтобы создать уникальный продукт, то вам необходимо знать, что чем меньше людей стоят во главе отдела разработки – тем лучше. В идеале, нужно, чтобы проектировкой системы и разработкой её «модели возможностей» занималось не более двух человек.
И есть только один способ создать качественный продукт – самому контролировать весь процесс разработки.
Такой подход использовали на заре своей славы Билл Гейтс и Стивен Джобс, так был разработан «Фейсбук» Марком Цукербергом. И единственный способ получить отличный результат от программистов – это изолировать их в одном замкнутом пространстве и добиться коллективного обсуждения каждой части проекта. Если проект большой, то необходимо разделить разработчиков на группы, в каждой группе должен быть свой лидер, все такие лидеры должны участвовать в совместном обсуждении проекта и четко знать назначение той части кода, над которым они работают. В некоторых случаях, можно внести нотку соревнования в работу разработчиков и переизбирать лидеров команд после завершения определенного этапа работ или цикла. Это способно не только повысить эффективность команды в целом, но и добиться глубокого погружения в проект каждого из участников. Но возможность использования такого метода стимулирования в первую очередь зависит не от самого проекта, а от сложившегося коллектива. Некоторые программисты плохо реагируют на стрессовую ситуацию, и такой подход может существенно снизить эффективность их работы. Поэтому при внедрении подобных методов будьте предельно осторожны, внедряйте их постепенно и обязательно отслеживайте реакцию вашего коллектива. Так как серьёзная негативная реакция может привести к расколу коллектива, что сразу же отразится на качестве работы и её эффективности.
(голосов - 58, средний балл: 7,00 из 7)Поделиться
