Каковы лучшие практики для извлечения фреймворка из приложения?

Question

Я работаю над приложением немногим более двух лет и разработал множество полезных помощников, утилит, функций, соглашений об установке и т. Д.

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

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

С чего мне начать? Какие-нибудь лучшие практики? Есть ли подводные камни или области, на которые стоит обратить внимание?

РЕДАКТИРОВАТЬ: Я должен немного уточнить, я делаю это не для кого-либо, кроме себя. Я разрабатываю аналогичные приложения для разных отраслей, поэтому ядро ​​на 90% одинаковое, различия в деталях.

Answer 1

Вот чему мы научились в Starling Software для QAM и QWeb.

Наш подход заключается в том, чтобы рассматривать это как работу по рефакторингу, которая распространяется на все проекты с использованием фреймворка или прото-фреймворка. Мы разделяем код фреймворка в каждом проекте на что-то, что создается отдельно, так что, например, src / myapp содержит специфичный для приложения код, а src / qam содержит сам фреймворк. Каждый проект имеет свою собственную копию кода приложения, а также есть отдельный проект, который содержит только последнюю версию самой платформы. Когда мы определяем что-то в рамках конкретного проекта, который хочет быть в рамках, мы:

1. рефакторинг в рамках проекта для обобщения кода (на основе нашего понимания как этого приложения, так и всех остальных, использующих фреймворк);
2. рефакторинг в рамках проекта для перемещения сгенерированного кода из специфичной для приложения части в часть инфраструктуры;
3. применить это обновление к проекту, который содержит «главную копию» платформы;
4. объединить изменения из этой мастер-копии с другими проектами, которые также используют платформу; а затем
5. Рефакторинг в других проектах для использования этой части платформы, а не их аналогичного кода для конкретного приложения.

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

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

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

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

Answer 2

См. Извлечение Rails из Basecamp , где Дэвид Хайнемайер Ханссон (David Heinemeier Hansson) рассказывает о том, как появились Rails, из его истоков, как фреймворка, используемого в Basecamp. Учитывая популярность Rails, вы можете узнать одну или две вещи из того, как DHH справился с этим. : -)

(Ну, может быть, не столько как, сколько как почему. Но все же интересно.: -))

Answer 3

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

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

Поэтому убедитесь, что у вас есть четкий план поддержки на будущее. Как будет поддерживаться приложение? Кто будет поддерживать это? Сколько времени потребуется для его поддержания? И самое главное ... кто будет платить за это обслуживание?

2) разработчики ненавидят, когда им говорят, что делать, или их заставляют. Фреймворк, который я написал, упрощенный Data Access Layer для разработчиков VB. Он создал хороший простой в использовании набор подпрограмм, которые будут работать независимо от того, что делает MS для изменения подпрограмм доступа к БД. Ну, некоторые разработчики не хотели, чтобы им говорили, что им нужно использовать фреймворк, чтобы они стонали и стонали. Честно говоря, мне надоело это слышать, и это вызвало недоброжелательность к сотрудникам.

Так что убедитесь, что у вас есть толстая кожа и вы можете продать ПОЧЕМУ люди должны использовать ваши рамки.

Answer 4

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