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

Question

Я нахожусь в моей карьере фрилансера, где разработал несколько веб-приложений для предприятий малого и среднего бизнеса, которые поддерживают такие функции, как управление проектами, бронирование/резервирование и управление электронной почтой.

Мне нравится работа, но я обнаружил, что в конечном итоге мои приложения попадают в точку, где подслушивание для обслуживания очень велико. Я оглядываюсь назад на код, который я написал 6 месяцев назад, и обнаружил, что мне нужно потратить некоторое время, просто переучивая то, как я изначально закодировал его, прежде чем я смогу внести исправления или дополнения к функциям. Я стараюсь практиковать с использованием фреймворков (раньше я использовал Zend Framework и рассматриваю Django для своего следующего проекта)

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

Answer 1

Хотя есть, конечно, хорошие статьи по этой теме, ни один из них не является заменой реального опыта.

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

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

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

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

Начните очищать свой код сегодня. Не откладывайте это на свои будущие проекты.

---

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

Answer 2

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

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

Answer 3

Я бы честно рекомендовал посмотреть на Martin Fowlers Patterns of Enterprise Application Architecture. В нем обсуждается множество способов сделать ваше приложение более организованным и поддерживаемым. Кроме того, я бы рекомендовал использовать модульное тестирование, чтобы лучше понять ваш код. Книга Кента Бекка по адресу Test Driven Development - отличный ресурс для изучения способов изменения кода на основе модульных тестов.

Answer 4

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

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

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

Answer 5

Для улучшения ремонтопригодности :

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

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

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

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

• Низкое сцепление и высокая когерентность. Удостоверьтесь, что вы в курсе последних достижений в этой области: дизайн по контракту, инъекция зависимостей, аспекты, шаблоны проектирования и т. Д.

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

• Использование системы управления версиями, если вы этого не сделаете, что уже

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

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

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

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

Рекомендуемая литература:

• "Code Complete" by Steve Mcconnell

• Все на design patterns включены в список рекомендуемой литературы.

Answer 6

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

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

3. Я бы рекомендовал использовать систему управления источником, такую ​​как Subversion, если вы еще этого не сделали.