Почему выгодно/не выгодно использовать готовые решения

Вот ведь как бывает – универсальные решения не оптимальны – вполне логичное утверждение. Зато утверждение что, популярное решение «для всех» может быть оптимальным тоже вроде не противоречит здравому смыслу. В данной статье я построюсь объяснить, как я вижу эти противоречия вместе.

Парадокс в том, что изначально при переводе некоторых статей «авторитетных» зарубежных авторов наши переводчики не уловили очень тонкую (для Российской действительности) грань. Практически все статьи в зарубежном Интернете опираются на два понятия «стоимость» и «цена». На первый взгляд это синонимы (хотя для людей хотя бы знакомых с экономикой это не так). И из-за этих неточностей у многих сформировалось неверное представление об использовании различных решений.

В чем же разница и как эти, казалось бы, экономические термины, относятся к web-разработке и в частности к PHP? На самом деле все достаточно просто.

Начнем с разницы между стоимостью и ценой. Стоимость, в экономике, это количество ресурсов (денег, времени и т.д.), которые необходимо что бы приобрести (создать, выкупить и т.п.) что-либо. Ну а цена это то кол-во ресурсов, за которые вы хотите продать это самое что-либо.

К web-разработке, как ни странно, все вышеописанное относится прямым образом. Каждый раз, разрабатывая какое либо решение для поставленной задачи каждый сталкиваются со стоимостью реализации и ценой, за которою каждый готов продать свою работу. Притом под словом «продать» я не имею ввиду именно получение денежных знаков. Хотя конечно такой расклад тоже устроил бы многих. Но тем не менее.

Даже выбор технологии играет свою не последнюю роль в стоимости готового решения. Т.е. используя PHP в качестве языка программирования для создания CMS можно значительно выиграть во времени (тут и огромное кол-во примеров, готового кода, отличная интеграция с web-сервисами). Хотя, например, для других более ресурсоемких задач скриптовый язык становится не пригодным из-за больших накладных расходов при выполнении кода. Становится очень важно определить цели и выбрать нужные инструменты для их достижения.

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

Пример первый – выгода индивидуального решения. Возьмем все ту же web-разработку. Для CMS использование готовых решений в подавляющем большинстве случаев является не оправданным. Это объясняется тем, что уж больно это расплывчатое понятие «система контроля содержания». Ведь содержание у всех разное и контроль нужен этому содержанию соответствующий. Например. Для газеты необходимо создать сайт, где будет публиковаться копия печатного издания и плюс ко всему существовать какие либо другие мелкие сервисы (голосования, комментарии…).

Итак, CMS по определению необходима для контроля содержания, а этот самый контроль нужен для упрощения поиска и доступа к информации. Так, например, для упрощения доступа к информации в нашем примере не выгодно использовать рубрики. Лучшим будет временная шкала (или простой календарь) выхода номеров издания. А ведь именно доступ в виде рубрик используется в подавляющем большинстве готовых CMS.

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

Можно кончено сказать, что многие CMS реализуют все необходимые возможности для конкретной задачи, но не стоит забывать и о накладных расходах. Т.е. допустим в популярных CMS реализовано очень много функционала. Каждый может выбрать те функции, которые ему нужны и использовать только их. Но, как известно чем меньше кода, тем меньше проблем. Т.е. лежащий мертвым грузом код (неиспользуемый функционал) может быть потенциально опасен. Более того, чем больше такого кода, тем больше ресурсоемким становится проект, а как говорилось выше скриптовый язык не приспособлен для ресурсоемких проектов.

Источник: http://phpwars.net