Идеально! Как создать и переделать свой сайт. Правильный подход и передовые техники разработки. Аарон Уолтер

Чтение книги онлайн.

СКАЧАТЬ если сервер работает на IIS, а не Apache).

      Если организация управляет собственными серверами, тогда выясните, будет ли у вас доступ к тестированию и развертыванию приложений. В некоторых проектах у меня его не было вообще, мне приходилось паковать код и данные и отсылать их IT специалистам организации для установки. Если это ваш случай, тогда скопируйте ПО хостинга для тестирования у себя. Этим вы сэкономите себе время, потому что тестирование и изменение на рабочем сервере – процесс не из легких.

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

      Политические ограничения

      Вы можете столкнуться с ограничениями, которые продиктованы внутренней организационной политикой и предпочтениями клиента. К примеру, любое стороннее ПО должно быть с открытым кодом или использоваться должны только технологии Майкрософт.

      Термин «открытый/исходный код» часто непонятен. Когда люди решают, что программное обеспечение должно быть открытым, обычно они не имеют в виду лицензию на него или бесплатное пользование. Все, что они хотят, это иметь возможность модифицировать (изменять) код, если нужно. Это позволит обезопасить себя в том случае, если разработчик стороннего продукта по каким-то причинам пропал или откажется от развития и поддержки продукта. Если от вас требуют использования ПО с открытым кодом, проясните для себя, что под этим подразумевается. Многие коммерческие продукты имеют незашифрованных и доступный для модифицирования код, но при то не имеют лицензии открытого исходного кода.

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

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

      Писать новый код или улучшать старый?

      Решить, начинать ли преобразование сайта с полным обновлением серверного кода всегда непросто. Даже если существующая система имеет много проблем, может показаться, что вы выбросите на ветер кучу денег и приложите массу усилий, если будете заменять ее. В этой части мы разберем причины, по которым мы либо должны поддерживать уже существующую платформу, либо создать абсолютно новую.

      Разработчик всегда подвержен искушению торжественно шагнуть вперед и создать что-то новое. Кому, в конце концов, понравится ковыряться в чужом коде? У всех нас свои методы работы; свои стандарты написания кода. Есть стандарты и системы, которые мы хорошо знаем и которым доверяем абсолютно. Но если мы выметем все подчистую из существующей системы и начнем все с нуля, мы рискуем потерять много полезного, что было в ней. И еще полбеды, если сайт предназначен просто для продвинутого управления контентом. А если вы решили переписать код сложной системы электронной коммерции, в которую в течение долгого СКАЧАТЬ