Оценка риска для выбора структуры

Question

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

При выборе веб-фреймворка, на что следует обращать внимание при решении, что делать?

Вот что я заметил в рамках, на которую смотрю:

• Небольшое сообщество. В списке пользователей каждый день только несколько сообщений
• Нет новостей на странице "Новости" со времени предыдущего выпуска, более 6 месяцев назад
• За последние 30 дней svn не фиксировалось
• Хорошая документация, но вики не обновляется с предыдущего выпуска
• Самая последняя версия до сих пор отсутствует в репозитории maven

Это не официально санкционированная среда Java EE, но я видел, как несколько человек упоминали ее как хорошее решение в ответах на различные вопросы о переполнении стека.

Я не собираюсь говорить, на какую основу я смотрю, потому что я не хочу, чтобы это вступило в войну рамок. Я хочу знать, какие другие аспекты проекта мне следует учитывать при оценке риска. Это должно относиться и к другим областям, кроме Java Web, например, ORM и т. Д.

Answer 1

Я скажу, что так называемые «мертвые» проекты не представляют особой опасности, если сам проект надежен и вам нравится.Дело в том, что если библиотека или фреймворк уже делает все, что вы можете думать, то это не такая уж большая проблема.Если у вас есть стабильный проект, запущенный и работающий, вам следует подумать о фреймворке (готово!) И сосредоточиться только на вашем веб-приложении.От вас не требуется обновлять сам фреймворк до последней версии каждый месяц.

Лично я считаю, что наиболее важным моментом является то, что вы найдете тот, который интуитивно понятен для вашего проекта. Что имеет больше смысла?MVC?Должен ли каждый элемент в URL быть отдельным объектом?Как будет работать интерактивность (AJAX)?Нет смысла выбирать что-то просто потому, что это «отраслевой стандарт» или потому, что оно используется многими известными сайтами.Может быть, они выбрали его для нужд, совершенно отличных от ваших. Прочтите учебные пособия для каждой структуры и будьте критически настроены. Если это не соответствует вашему образу мышления или вы видели, как это делается более элегантно, тогда двигайтесь дальше.Здесь вы рассматриваете дизайн , и хороший дизайн равносилен гибкости и масштабируемости.Существуют сотни веб-фреймворков, старых и новых, на каждом языке.Вы обязательно найдете полдюжины, которые работают именно так, как вы хотите думать в своем проекте.

Точки, которые я считаю обязательными:

• Расширяемость с помощью плагинов: проверьте, есть ли уже подключаемые модули для различных задач промежуточного программного обеспечения, таких как memcache, gzip, OpenID, AJAX goodness и т. Д.
• Простота и модульность : чем сложнее, тем кручекривая обучения и тем меньше вы можете доверять его стабильности;чем больше «привязан» к конкретным технологиям, тем выше вероятность того, что у вас будет цепь вокруг лодыжки.
  • Независимость от базы данных : можете ли вы использовать sqlite3 для разработки, а затем переключиться на производственную базу данных, изменив одну строку кода или конфигурации?
  • Независимость от платформы : вы можете запустить его на Apache, lighttpd и т. Д.?Не могли бы вы перенести его для работы в облаке?
  • Независимость от шаблона : можете ли вы отключить систему шаблонов?Допустим, вы нанимаете преданных дизайнеров, и они действительно хотят заняться чем-то другим.
• Документация : Я не настолько строг, если это с открытым исходным кодом, но там будетмне должно быть достаточно официальной документации, чтобы я мог полностью понять, как писать собственные плагины, например.Также посмотрите, есть ли исходный код рабочих сайтов, использующих ту же платформу.
• Лицензия и исходный код : есть ли у вас доступ к исходному коду и разрешено ли его изменять?Подумайте, можете ли вы использовать его в коммерческих целях!(Даже если у вас нет текущих планов сделать это в настоящее время.)

Всего: гибкость .Если я удовлетворен всеми четырьмя пунктами, я почти готов.Заметьте, как у меня там не было ничего о "мертвости"?Если основной дизайн хорош, и есть легко устанавливаемые плагины для выполнения каждого модного слова web-dev 3.0-beta, которое вы хотите сделать, то мне все равно, был ли последний SVN коммит в 2006 году.

Answer 2

Вот что я ищу в структуре, прежде чем решу использовать ее для проекта производственной среды:

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

• Приличное сообщество, чтобы вы могли задавать вопросы и т. Д. Веселый и активный канал IRC - большой плюс.

• Постоянная итерация произведения. Ошибки закрываются или открываются ежедневно / еженедельно? Вероятно, хороший знак.

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

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

Я могу продолжать, но это некоторые основные из моих голов.

Answer 3

Помимо рассмотрения структуры, вам также нужно учитывать множество вещей о себе (и любых других членах команды) при оценке рисков:

• Если фреймворк - это новый, незрелый, «передовой» фреймворк, будете ли вы готовы и способны отлаживать его, исправлять или обходить любые возникающие проблемы?

• Еслиесть небольшое сообщество, вам придется самостоятельно выполнять большую часть отладки и диагностики.У вас будет время, чтобы сделать это и при этом уложиться в сроки, которые у вас могут быть?

• Вы сами смотрели на рамки, чтобы определить, насколько они хороши, или вы готовы полагаться на то, что?другие говорят об этом?Почему вы доверяете их мнению?

• Почему вы хотите использовать это, а не "официально санкционированную среду Java EE"?Это прагматическая причина или просто желание попробовать что-то новое?

• Если из-за проблем с платформой вы пропускаете сроки или поставляете некачественный продукт, как вы об этом будете говорить?Ваш начальник или клиент?

Answer 4

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

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

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

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