Как я планирую веб-приложение уровня предприятия?

Я честно рекомендовал бы смотреть на Martin Fowlers Patterns Архитектуры приложений для предприятия. Это обсуждает много способов подать Вашу заявку, более организованную и удобную в сопровождении. Кроме того, я рекомендовал бы использовать поблочное тестирование, чтобы дать Вам лучшее понимание Вашего кода. Книга Kent Beck по Разработке через тестирование является большим ресурсом для изучения, как обратиться к изменению в Вашем коде через модульные тесты.

Необходимо считать, возможно, использование SharePoint. Это - среда, которая уже разработана, чтобы сделать все, что Вы упомянули, и имеет много других функций, Вы, возможно, не думали о (но возможно Вам будет нужно в будущем :-))

Вот некоторая информация от официального сайта.
Существует 2 различных среды SharePoint, которые можно использовать: Windows Sharepoint Services (WSS) или Microsoft Office сервер Sharepoint (MOSS). WSS свободна и поставлется с Windows Server 2003, в то время как MOSS не свободен, но имеет намного больше функций и покрывает почти все Вы потребности предприятия.

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

1. Используйте хорошие принципы MVC и платформы для разделения слоя представления от бизнес-логики и модели данных.
2. Используйте устойчивый слой постоянства для не связи бизнес-логики с моделью данных
3. Запланируйте отсутствие гражданства и асинхронное поведение.

Вот превосходная статья о том, как eBay занимается этими проблемами http://www.infoq.com/articles/ebay-scalability-best-practices

1. Используйте платформу / система MVC. Чем более организован и централизованный Ваш код, тем лучше.

2. Попытайтесь использовать Кэш-память. PHP имеет созданный в расширении для него, требуется приблизительно десять минут для установки и еще двадцать для подачи заявления. Можно кэшировать то, что Вы хотите к нему - я кэширую все свои записи базы данных в нем - для каждого приложения. Это делает блуждания.

3. Я рекомендовал бы использовать систему управления исходным кодом, такую как Подверсия, если Вы уже не.

Для улучшения пригодности для обслуживания, Вы могли:

• Если Вы - единственный разработчик, затем принимают стиль кодирования и придерживаются его. Это вселит в Вас веру позже при навигации через собственный код о вещах, которые Вы, возможно, возможно сделали и вещи, что Вы абсолютно не будете. Быть уверенным, где посмотреть и что искать и что не искать, сохранит Вас много времени.

• Всегда занимайте время для осовременивания документации. Включайте задачу в план разработки; включайте то время в план как часть любое изменение или новая возможность.

• Сохраните документацию сбалансированной: некоторые схемы высокого уровня, значимые комментарии. Лучшие комментарии говорят, который не может быть считан из самого кода. Как бизнес-причины или "whys" позади определенных блоков кода.

• Включайте в план, усилие сохранить структуру кода, имена папок, пространства имен, объект, переменную и стандартную программу называет актуальным и отражающим из того, что они на самом деле делают. Это будет иметь большое значение в улучшающейся пригодности для обслуживания. Всегда называйте лопату "лопатой". Избегайте больших блоков кода, структурируйте его средствами, доступными в Вашем предпочтительном языке, дайте понятные имена блоков.

• Слабая связь и высокая когерентность. Удостоверьтесь Вы актуальный с методами достижения их: дизайн контракта, внедрение зависимости, аспекты, шаблоны разработки и т.д.

• С точки зрения управления задачами необходимо оценить больше времени и взимать более высокий сбор для ненепрерывных обрабатываемых деталей. Не смущайтесь делать клиента знающим, что Вам требуется дополнительное время, чтобы сделать, маленькое ненепрерывное распространение изменений со временем в противоположность большим непрерывным проектам и текущему техническому обслуживанию начиная с администрирования и анализа наверху больше (необходимо управлять и проанализировать каждое изменение включая влияние на существующую систему отдельно). Одна польза, которую Ваш клиент собирается извлечь, является большей продолжительностью жизни системы. Другой точная документация, которая сохранит их опцию искать, чужая справка должна они решать сделать так. Оба защищают клиентские инвестиции и являются сильными коммерческими аргументами.

• Используйте управление исходным кодом, если Вы уже не делаете этого

• Сохраните подробный журнал всего сделанного для клиента плюс любая важная коммуникация (простой компьютер или основанный на бумаге CMS). Обновите свою память перед каждым присвоением.

• Сохраните журнал проблем оставленным открытым, идеи, предложения на клиента; снова обновите свою память прежде, чем начать присвоение.

• Запланируйте заранее, как постподдержка внедрения будет проводимой, обсудите с клиентом. Сделайте свои системы, легки поддержать. Запланируйте параметризацию, контролируя инструменты, проверки работоспособности в сборке. Продайте постподдержку внедрения клиенту как часть первоначального контракта.

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

Рекомендуемое чтение:

• "Код, завершенный" Steve Mcconnell

• Что-либо на шаблонах разработки включено в список рекомендуемого чтения.