Выбор языка программирования
Возможно, ваша команда разработчиков или другое агентство по созданию сайтов имеют некий опыт в языке разработки. Он-то и определит базовый язык сайта, пока вам ужасно не захочется чего-то новенького. У хороших разработчиков всегда под рукой не один заранее заготовленный кусок кода и способы решения характерных задач на этом языке.
Но для того чтобы изменить язык на более "крутой", им потребуется серьезная переподготовка и много времени, потому что придется создавать новые библиотеки для базовых вещей. Это оправдает себя в том случае, если существующий язык мешает продвижению сайта (или из-за того, что мало кто из разработчиков знает его, или из-за того, что его развитие застопорилось). Предположим, ваша система создана на классическом ASP, и команда, которая поддерживает ее годами, знает этот язык. Однако он уже вытеснен ASP.NET (и не развивается настолько активно), поэтому строить на нем новую систему не имеет смысла. Кроме всего прочего, найти разработчиков, которые знают Classic ASP не так-то просто. Да и язык устарел настолько, что он не подходит для модернизации сайта.
Если вам придется столкнуться с подобной ситуацией, вашей команде нужно будет освоить новый язык для переделки сайта. Если агентства со стороны предлагают вам преобразование в Classic ASP, спросите их напрямую, почему они проталкивают эту технологию. Объясните им, наконец, что вы хотите сайт, который будет жить долго, а устаревшие приемы вряд ли продлят его дни.
Если вы сами создаете сайт, и вас тянет изучить определенный язык, тогда придется утрясти вопросы с отсрочкой сдачи проекта насколько это возможно. Все в ваших руках.
Постигать что-то новое всегда интересно, но не кидайтесь от одного к другому, только потому, что это модно. Лучше знать один язык, но досконально, чем несколько, но поверхностно.
Если проект готовится для заказчика, скорее всего, он станет ограничивать вас во времени и бюджете. Ограничения могут иметь под собой как техническую подоплеку (например, требование создать и разместить сайт под определенную серверную архитектуру), так и политическую (например, требование использовать ПО с открытым кодом).
Технические ограничения
Если компания держит свои сайты на собственных серверах, скорее всего, у нее есть своя серверная архитектура. В этом случае нужно точно знать, что вы будете устанавливать.
Например, сервер работает на Windows, а компания могла бы установить PHP; это спасло бы вас от головной боли при инсталляции, потому что есть некоторые различия между PHP на Linux и PHP на Windows (в основном если сервер работает на IIS, а не Apache).
Если организация управляет собственными серверами, тогда выясните, будет ли у вас доступ к тестированию и развертыванию приложений. В некоторых проектах у меня его не было вообще, мне приходилось паковать код и данные и отсылать их IT специалистам организации для установки. Если это ваш случай, тогда скопируйте ПО хостинга для тестирования у себя. Этим вы сэкономите себе время, потому что тестирование и изменение на рабочем сервере – процесс не из легких.
Интеграция с другой системой – своего рода ограничение. И определенные сторонние приложения могут быть исключены, если вы не можете написать плагины для их интеграции.
Политические ограничения
Вы можете столкнуться с ограничениями, которые продиктованы внутренней организационной политикой и предпочтениями клиента. К примеру, любое стороннее ПО должно быть с открытым кодом или использоваться должны только технологии Майкрософт.
Термин "открытый/исходный код" часто непонятен. Когда люди решают, что программное обеспечение должно быть открытым, обычно они не имеют в виду лицензию на него или бесплатное пользование. Все, что они хотят, это иметь возможность модифицировать (изменять) код, если нужно. Это позволит обезопасить себя в том случае, если разработчик стороннего продукта по каким-то причинам пропал или откажется от развития и поддержки продукта. Если от вас требуют использования ПО с открытым кодом, проясните для себя, что под этим подразумевается. Многие коммерческие продукты имеют незашифрованных и доступный для модифицирования код, но при то не имеют лицензии открытого исходного кода.
Иногда вы можете преодолеть политические ограничения, если приведете аргументы, почему какое-то решение лучше, чем то, которого от вас требуют.
Но они должны быть достаточно вескими. Ведь если клиент непоколебимо верит в какую-то технологию, то скептицизм с его стороны вам обеспечен.
Писать новый код или улучшать старый?
Решить, начинать ли преобразование сайта с полным обновлением серверного кода всегда непросто. Даже если существующая система имеет много проблем, может показаться, что вы выбросите на ветер кучу денег и приложите массу усилий, если будете заменять ее. В этой части мы разберем причины, по которым мы либо должны поддерживать уже существующую платформу, либо создать абсолютно новую.
Разработчик всегда подвержен искушению торжественно шагнуть вперед и создать что-то новое. Кому, в конце концов, понравится ковыряться в чужом коде? У всех нас свои методы работы; свои стандарты написания кода. Есть стандарты и системы, которые мы хорошо знаем и которым доверяем абсолютно. Но если мы выметем все подчистую из существующей системы и начнем все с нуля, мы рискуем потерять много полезного, что было в ней. И еще полбеды, если сайт предназначен просто для продвинутого управления контентом. А если вы решили переписать код сложной системы электронной коммерции, в которую в течение долгого времени вносили кучу различных доработок функционала?
Спросите себя, действительно ли существующая система не отвечает вашим требованиям настолько, что вы готовы полностью заменить ее, или же вам просто непривычно с ней работать.
Также не пренебрегайте опытом тех, кто пользуется системой. Если люди добавляют контент, обновляют продукцию или выполняют другие задачи в программе каждый день, то их нужно будет переобучать. Перенастройка и усовершенствование того, что есть, может быть даже поэтапное, избавит вас от этой необходимости.
Нельзя забывать и об ограничениях в сроках и бюджете. Начинать проект заново встанет заказчику в копеечку, да и времени на развитие будет затрачено больше. Внесение изменений в существующий код (рефакторинг) позволит вам распределить затраты, выкатывая обновления постепенно, по мере их готовности.
Но есть случаи, когда создание с нуля имеет смысл. Как мы уже говорили, программисты-новички будут рады заменить систему сайта на ту, которую они знают отлично.
Если вы нанимаете собственного разработчика или команду либо начинаете работать с третьим лицом и хотите долго и плодотворно сотрудничать с ними, то тогда резонно перейти на платформу, в которой они асы.
Мы уже сказали вам, что язык программирования может устареть, или сайт был основан на более не поддерживаемом ПО, или функции, которые вы хотите добавить, перегружают существующую структуру. Не выбрасывайте деньги на ветер!
Еще одна причина, по которой надо бы избавиться от существующей платформы, – это то, что она может ограничивать вас в выборе дизайна или изменении ее структуры.
Например, сторонняя платформа систем электронной коммерции устанавливает шаблонные дизайн и процесс оформления покупки, и вы не можете внести изменения, которые повысят продажи. Трата времени на поиск проблем и решений, для того чтобы не допускать подобного, выбивает из рабочей колеи всех, кто этим занимается.
В конце концов, прежде чем принять решение установить новую платформу или перенастроить старую, досконально изучите существующую систему и посмотрите, как она уживается с настоящими и будущими требованиями.
Собственная разработка или коробочное ПО?
Предположим, вы захотите заменить сервер частично или полностью. Тогда подумайте, разработать ли вам персональное решение, или положиться коробочное ПО, или, может быть, применить их комбинацию. В этом разделе мы оценим преимущества каждого варианта.
Зачем разрабатывать свое?
Если у вас специфичные и редкие требования, то продвижение собственной разработки может стать лучшим вариантом. Стороннее ПО должно привлекать широкий рынок, чтобы разработчики не тратили свое время зря. К тому же так заманчиво добавлять множество характеристик, чтобы платформой заинтересовалось больше народу. Вся проблема в том, что разработка системы может закончиться тем, что в ней будет сотни ненужных вам вещей.
И если движок не довести до ума, его функциональные свойства будут замедлять скорость вашего сайта, болтаться как бесполезные элементы и увеличат накладные расходы.
Если у вашего сайта большой трафик и вы с самого начала в курсе, что должны оптимизировать каждую строку серверного кода и внешнего интерфейса, то создание собственного решения позволит учесть весь список требований. Моя личная проблема в том, что я недостаточно использую язык SQL. Некоторые приложения делают сотни ненужных запросов базы данных, которые существенно повышают нагрузку на сайт.
Может случиться, что лицензия на стороннюю программу не подойдет к приложению, которое вы разрабатываете. Может быть, и так, что в системе есть все, что нужно, но какие-то 10 % функций, которые вы добавляете, требуют довольно глубокого проникновения в ядро программы, проще говоря, ее взлома. Вряд ли кто-то из разработчиков софта даст вам добро на это. Вот она и проблема! Сложность будет еще и в том, чтобы усовершенствовать программу.
Лучше делайте свои изменения через официальный API. Если не сможете, все равно не взламывайте программу. Потому что то, что у вас получится, вы едва ли сможете поддерживать.
Плюсы в разработке и развитии собственной системы в том, что вы точно сможете подогнать ее под свои требования. Стандартная программа может быть написана великолепно, и так же великолепно удовлетворять требования заказчика. Но при этом утечка конфиденциальной информации все равно возможна. А теперь ваша задача – оценить, что лучше: использование готовых программ или создание своей, точно ориентированной на ваши задачи?
Выбираем коробочную платформу?
Коробочное ПО имеет явные преимущества. Вам не надо начинать с чистого листа. Вы получаете то, что уже находится в боевой готовности. Если вы ищете легкий способ управления контентом или ведения онлайн-магазина, а ваши требования достаточно просты, то наверняка одно из многих существующих в программе решений удовлетворит вас.
Есть бесплатные сторонние программы, а есть лицензионные, за которые приходится платить. У некоторых бесплатный только основной продукт, а дополнения – платные. Они добавляются быстро, поэтому заранее подумайте о том, что вам нужно для проекта. В одной системе может быть все включено в лицензионную оплату. Она, несомненно, обойдется вам дешевле, чем бесплатная альтернатива, для которой нужно будет приобрести несколько коммерческих дополнений.
Не забудьте узнать, на какую поддержку вы можете рассчитывать. У многих бесплатных программ официальная поддержка стоит денег или вовсе не существует. Еще не помешает зайти на форум, где пользователи отвечают друг другу на вопросы. Посмотрите, сколько людей участвует в нем и как быстро приходят ответы.
Рисунок 2.5. На WordPress оживленные форумы. Они для людей, которым нужно помочь в выборе правильного ПО
Если поддержка включена в стоимость, узнайте, в каком виде она предоставляется. Есть ли на нее ограничения или нет? Придется ли ждать? Существует ли общественная площадка поддержки и сразу ли персонал отвечает на вопросы? Twitter, кстати, тоже неплохой способ узнать о поддержке и общественном мнении о продукте. Просто спросите о нем и посмотрите, какие отзывы вы получите. Если поддержка хорошая, платный продукт может быть более стоящим, чем бесплатный вариант.
Облачные решения
Третий способ решения, который нам нужно обсудить, – это программное обеспечение как услуга (SaaS), известные также как облачное ПО. Есть системы управления контентом (CMS), которые, к примеру, используются в электронной коммерции. В них реализован различный функционал, начиная от простого "положить в корзину" и страницы оплаты и заканчивая полноценным интернет-магазином. Такое решение привлекательно тем, что вам не нужно ничего устанавливать, чтобы запустить и поддерживать сайт. Может лишь возникнуть необходимость настроить некоторые опции и выбрать шаблон.
Использование внешнего размещения – быстрый способ запустить в работу ваш сайт. Вообще, в проектах электронной коммерции, такое решение перекладывает проблемы безопасности и сложных функций на компанию, которая специализируется на этом. Но есть кое-что, над чем нужно подумать.
Возможно, заказчик должен платить за пользование сервером ежемесячно и, естественно, это нужно внести в бюджет. Проверьте, изменится ли цена в зависимости от вашего трафика и количества заказов.
Вы также не можете изменять работу такого ПО. Если разработчик вносит изменения, которые влияют на ваш бизнес, придется с этим смириться. Вы не сможете переписать какую-то часть так, как вы это делаете с программой, находящейся на вашем сервере. Это и понятно. К ее исходному коду вы имеете доступ.
Ваш сайт будет зависеть от деятельности разработчиков облачного ПО, которые крутятся в бизнесе и не перестают предлагать услуги заказчикам по доступным для них ценам. Программа, установленная на вашем сервере, даже если провайдер отойдет от дел, все равно остается у вас. Правда, вы потеряете поддержку, но по крайней мере сможете перейти на что-то свое абсолютно бесплатно. Если вы будете полагаться на внешний сервер, тщательно исследуйте его, чтобы убедиться, что он надежный, а компания – стабильная.
Бойтесь "евангелистов"!
Пользователи определенных продуктов порой проявляют свои странности. Вы это можете наблюдать на форуме, куда они заходят и наивно спрашивают: "А какая CMS лучше?"
По большому счету это бессмысленный вопрос. Он не прольет света на проблему, которую вы стараетесь решить. Читатель понятия не имеет, какой у вас сайт: крошечный с несколькими кусочками редактируемого текста или огромный трехъязычный, вмещающий в себя тысячи документов.
И все равно кто-нибудь да расскажет вам о своей любимой CMS и в восторге станет доказывать, почему она лучшая из лучших. Этих людей мы называем "евангелистами": они так любят софт, которым пользуются, что и представить себе не могут, что у кого-то может быть что-то другое. Я сам являюсь поставщиком CMS. Именно поэтому я иногда имею свою выгоду от "евангелистов" в среде наших пользователей. Но я и первый, кто в случае, если наше решение не вписывается в проект, скажет об этом прямо.
Бойтесь "евангелистов", когда вы изучаете стороннее ПО. Неважно, что это будет: целая платформа или простой скрипт. Задавайте специфические вопросы с учетом ваших требований. Тогда, скорее всего, в ответ вы получите более квалифицированное мнение.
Хостинг
Нас часто просят порекомендовать хороших хостинг-провайдеров и помочь с выбором хоста. Хостеров тысячи, но все они предлагают в конечном итоге серверы, которые могут мало отличаться друг от друга внешне, но по стоимости – в разы. Так что же выбрать? Может быть, просто хостера подешевле, у которого есть все, что вам нужно?
Дешевый хостинг – дорогой хостинг, или Скупой платит дважды
Многим хостинг-провайдерам удается сбывать свой продукт на рынке чисто из-за низкой стоимости. Можно достать хостинг за $10 в год. Но то, что есть такой дешевый хостинг, еще не говорит о том, что надо пользоваться им. Он может в результате обойтись вам гораздо дороже, чем качественный хостинг с разумной, обоснованной ценой. Хороший хост стоит денег. А если заказчик толкает вас к дешевому провайдеру, то, надеюсь, что, прочитав этот раздел, вы вооружитесь неплохими контраргументами.
Веб-хост с оплатой $10 в год, чтобы "сколотить" хоть какие-то деньги, должен разместить сотни сайтов на каждый физический сервер. Соответственно, это может привести к перегрузке, и какой-нибудь сайт с тяжелым трафиком застопорит остальные или даже выведет их в офлайн.
Google сейчас использует показатель скорости загрузки сайта для ранжирования выдачи, таким образом, медленный сайт не только раздражает пользователей, но и ухудшает позицию выдачи.
Рассчитывать на техническую поддержку за $10 в год было бы глупо. Ни один провайдер не сможет этого сделать за такие деньги. Если ваш сайт стал хуже работать и проблема коснулась пользователей, знайте, что вы можете быстро связаться со специалистом в приоритетном порядке. Услуги клиентам стоят денег. Так что низкая цена хостинга окупается за счет платы за поддержку.
Как выбрать хост
Ваш сайт имеет определенные требования. Например, чтобы запустить сайт на WordPress, вам нужен следующий набор:
• PHP версии 5.2.4 или выше,
• MySQL версии 5.0.15 или выше,
• модуль Apachemod_rewrite.