О готовых решениях и ужасных программистах « Блог Голубева Евгения

О готовых решениях и ужасных программистах

Написано 09.06.2008 // Профессиональное.

FreewareПостоянно по роду деятельности я сталкиваюсь с необходимостью интегрировать готовое решение. Это может быть Class на PHP или JS плагин, не имеет значения. Эти готовые решения делятся на разные группы качества, об этом и о причинах этого и хочется написать.

Большинство готовых решений можно распределить на 3-и группы. Группы двухсторонние, с одной стороны описывающие качество решения, с другой возможности интеграции.

И так по порядку:

1. Качественные, беспроблемно интегрируемые.
Самая малораспространенная группа. В большинстве случаев, это решения имеющие большой “фан клуб”. Такие решения развиваются, поддерживаются и дополняются. В них уже мало багов с которыми можно столкнутся. Они имеют большое колличество всевозможных мануалов и т.д.

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

2. Среднего качества, несложно интегрируемые.
Эти решения вторая по распространённости группа. Обычно созданное каким-либо умельцем и выложенное в блоге, на личном сайте. Может иметь “фан клуб”. Но либо не поддерживается автором, либо слабо развивается. Часто имеет какие-либо подводные камни, например поддержку только определённой версии библиотеки или языка. После доработки напильником они беспроблемно интегрируются.

Таких решений много, их можно встретить где угодно. Им часто не хватает “душевности” чтоли. Не без изъянов, но они работают и это радует.

3. Низкого качества, не интегрируемые.
Это самая распространённая группа. Иногда думаешь глядя на такое творение, зачем его выкладывали, неужели его кто-то прикрутил. Оно же не работает отродясь. Таким решением не помогает даже напильник. Проще и быстрее написать с нуля.

Таких решений ОЧЕНЬ много. Их колличество постоянно растёт. Зачем их выкладывают на суд общественности? Ведь все мы когда-то начинали, становились умнее и опытнее, развивались. Но зачем показывать очередное “произведение” и выкладывать его на phpclasses и иже с ними?

Причины.
Знаете, недавно у меня спросили “проблемы PHP”. Я знаю точно одну, основную проблему PHP. Безграмотность и непрофессионализм разработчиков! Ведь язык действительно гибкий, на нём можно сделать любое решение для сайта, сервиса и т.д. Все мифы и реальности с “глюченностью и карявостью” языка связаны лишь с “проблемными” разработчиками.

Нахватавшись азов, прочитав учебник по PHP и сделав себе страничку, они штурмуют биржи труда. Выставляя рейты в 1$-8$ за час, работая на пиво и сигареты, подрывая доверие к фрилансу, и искуственно снижая цену.

Начинаешь замечать, что выставляя свой рейт, который значительно больше “школьного” ты получаешь всё больше заказов. Теперь “качество разработчика”, это его высокий рейт. И страшно то, что “школьники”, осознав это, подымают свои рейты. Со страшными проектами в портфолио они заряжают 12$-15$ за час. Таких пока единицы, и их быстро отсеивают, но прецеденты перерастают в постоянство.

Начал за здравие, закончил за упокой…. Ну пусть будет так…. Статья “О готовых решениях и ужасных программистах”…



5 комментариев

  1. Артём Курапов

    Проблема интеграции зачастую состоит и в том, что нет общей парадигмы построения сайта. Одни следуют MVC с контроллерам по switch-case и xml, другие по объектам и smarty, одни пишут напрямую mysql_query, другие используют PEAR DB, Котерова или свои модели. Даже фреймворков полно - хочешь codeigniter, хочешь zend или cakephp…

    В общем случае надо очень расписывать как плагин работает, описывать функции, как устанавливать.. В любом случае установка такого Неизвестно Ли-работающего Объекта занимает от 3 часов и больше.

    Я вот сейчас с сервисами мучаюсь, там уже за 40 часов перевалило, хотя документация есть, просто её слишком много, без элементарного способа употребления :)


  2. m0nah

    Да Артём, вы правы. Это одна из проблем интеграции. Но часто приходится интегрировать не глобальное решение, класс или их совокупность.

    Отсутствие документации - это проблема номер один, запутанная и сложная документация - проблема номер два :-)

    Хотя к примеру качественные описание методов класса - идеальная документация.

    А сервисы да, разные бывают. Бывает ещё “весёлая” документация. Написано одно, а на деле совсем другое.


  3. Рома Ш.

    Это элементарно издержки Open Source’а. Хочется хорошего, выверенного и оттестированного кода, мануал по быстрой интеграции и документец по-толще для более тщательного изучения? Такое не грех и купить. А раз есть покупатели, то и продавцы найдутся :)
    Конечно, личную доблесть, портфолио и фан-клубы никто не отменяет, но только самые упорные способны за эту идею вылизывать и документировать свой код.
    … эммм, правда я и с автором спорить не собираюсь - плохой программист не станет вдруг хорошим, если его стимулировать деньгами.
    Так что надеемся на гениев, способных СНАЧАЛА сделать что-то достойное, а потом уже заявлять об этом (в том числе и рейтом).


  4. m0nah

    Рома, на самом деле я в большинстве случае даже на документации и мануалов хочу.
    Хочется, чтобы этот код просто работал для начала.
    И просто методы у класса назывались логично.
    Большего мне не надо, как интегрировать нужный функционал я найду.
    А стимуляция деньгами помогает очень редко, это точно.


Обсуждение закрыто.