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

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

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

Во-первых, вот мои 2 правила, чтобы избежать синдрома растраты:

• Отсутствие существующего, покрывающего 80% моих потребностей и расширяемого для соответствия последним 20%
• Почти наверняка, что я буду использовать его снова, в другом приложении

После того, как вы прошли те, проверьте это:

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

1) Функции следует добавлять в Framework только тогда, когда они извлечены из рабочего кода. Другими словами, прежде чем добавлять свою классную новую идею в новую классную среду, убедитесь, что она действительно повышает ценность и уменьшает повторяемость в работающем, реальном приложении.

2) Документация, документация, документация.

3) Документация, документация, документация.

Мучительный опыт и много потраченных впустую усилий приводят к этому совету: извлекать или реорганизовывать структуру из рабочего программного обеспечения. Создавайте это программное обеспечение, помня о том, что, как вы думаете, вы захотите извлечь фреймворк в будущем, но сначала не создавайте фреймворк.

Я бы предложил книгу Руководство по проектированию рамок . Это пара лет, но принципы остаются верными. Он содержит множество шаблонов и объясняет причины, по которым вы принимаете решения при создании фреймворка.

1) Придерживайтесь хороших соглашений с самого начала, убедитесь, что вы задокументировали очень конкретное соглашение, лучшие фреймворки - это те, которые внутренне согласованы.

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

3) Составьте краткое описание проекта для себя, с тем, что вы хотите, чтобы структура достигала, реалистичные цели и общие приоритеты.

4) Если он будет доступен для использования людьми, убедитесь, что у вас есть какая-то форма поддержки / отслеживания ошибок. Будут ошибки, это случается со всеми нами, но если вы сможете управлять ими с самого начала, это облегчит вашу жизнь.

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

Я не согласен со многим из того, что было сказано, и я чувствую, что больше было оставлено без упоминания, поэтому я начну с нуля.

Agile методологии

Примите гибкие методологии во время разработки вашей структуры, чтобы вы могли адаптироваться к изменениям, быстро реагировать на препятствия и обеспечивать функциональный, качественный конечный продукт. Agile методологии - это те, которые, согласно «Agile Manifesto», отдают приоритет:

Лица и взаимодействие над процессами и инструменты
Работой программного обеспечения более комплексной документация
совместно с клиентами над контрактными переговорами
Реакцией на изменения в течение следующего плана

Это верно. Я сказал, что функциональность важнее документации. Обратите внимание, что в «Agile Manifesto» упоминается, что приоритеты правой руки по-прежнему важны, чуть меньше, чем приоритеты слева.

связь

Кто бы ни делал структуру, должен знать:

1. Как это будет использоваться: целевое приложение
2. Какую проблему предполагается решить: целевая проблема
3. Кто будет его использовать: целевая аудитория

Например, если компания намеревается разработать окончательное приложение с ASP .NET, было бы глупо говорить своим программистам «создать эту среду», не сказав им вышеизложенного. Если программисты не знают целевого приложения, они могут не ориентировать его на веб-ориентирование. Если бы они не знали проблему, они могли бы создать основу для другой цели. Если они не знают аудиторию, они могут программировать фреймворк на C ++. Любое из этих обстоятельств сделает полученную структуру бесполезной.

Стиль

Излишне говорить, установить стиль / формат программирования и придерживаться его.

Е

1. Модульность : повторное использование кода программно, а не буквально.
2. Эффективность : Ваш код предназначен для повторного использования. Любые потери в скорости умножаются.
3. Поддерживаемость : вы хотите иметь возможность редактировать структуру для обновления нескольких программ без необходимости изменения указанных программ.
4. Удобство использования : могут ли приложения использовать ваш фреймворк без скачков?
5. Практичность : не изобретайте велосипед, если вам это не нужно. Ваша структура может зависеть от других структур.
6. Избыточность : перехват исключений / ошибок. Где угодно. Обращайся с ними. Где угодно. Никогда не доверяйте никакому коду, кроме как в локальной области для обработки ошибок, даже если вы знаете, что это так.

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

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

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

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

Я поддержу рекомендацию Райана Хейса о прочтении « Руководства по проектированию инфраструктуры», хотя сама книга направлена ​​на разработку сред на основе .NET, потому что общие рекомендации применимы независимо от конкретных технологий реализации, которые вы можете использовать.

Исходя из своего опыта, я бы посоветовал придерживаться классического принципа YAGNI, сначала реализовав самые упрощенные общедоступные интерфейсы, а затем расширяясь, чтобы потом обеспечить больший контроль и глубину, но будьте осторожны, используя полезные имена, чтобы показать, почему расширяются методы или классы. Я никогда не был фанатом добавления «Ex» или других подобных суффиксов к именам методов или добавления чисел в расширенные определения интерфейса. Различайте функциональность, и имена вашего интерфейса / метода должны стать более понятными и, надеюсь, менее запутанными и запутанными.