Мені потрібно розпочати розробку та розробку нової основи для взаємодії з відкритим кодом 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 Manifesto", надають пріоритет:

Особи і взаємодія над процесами і інструменти
Роботою програмного забезпечення більш комплексної документація
спільно з клієнтами над контрактними переговорами
Реакцією на зміни в протягом наступного плану

Це вірно. Я сказав, що функціональність важливіша, ніж документація. Зауважте, що "Agile Manifest" зазначає, що пріоритети правого боку все ще важливі, тим не менше, ніж ліві.

Зв'язок

Хто створює рамки, повинен знати:

1. Як воно буде використовуватися: цільова програма
2. Яку проблему призначено вирішити: цільову задачу
3. Хто ним буде користуватися: цільова аудиторія

Наприклад, якщо компанія мала намір розробити остаточну програму з ASP .NET, було б нерозумно казати своїм програмістам "зробити цю рамку", не розповідаючи їм вищесказане. Якщо програмісти не знали цільової програми, вони могли б не зробити її орієнтованою на Інтернет. Якщо вони не знали проблеми, вони могли б створити рамки для іншої мети. Якщо вони не знали аудиторії, вони могли б запрограмувати рамки на C ++. Будь-яка з цих обставин зробить отримані рамки марними.

Стиль

Зайве говорити, що встановіть стиль / формат програмування та дотримуйтесь його.

Е

1. Модульність : повторно використовувати код програмно, а не буквально.
2. Ефективність : Ваш код призначений для повторного використання. Будь-які збитки для швидкості збільшуються.
3. Ремонтопридатність : Ви хочете мати можливість редагувати рамки для оновлення декількох програм, не змінюючи вказані програми.
4. Практичність : Чи можуть програми реально використовувати вашу рамку, не перестрибуючи обручі?
5. Практичність : Не винаходити колесо, якщо цього не потрібно робити. Ваша структура може залежати від інших рамок.
6. Надмірність : Ловіть винятки / помилки. Скрізь. Поводьтеся з ними. Скрізь. Ніколи не довіряйте будь-якому коду, окрім як у локальній області, для обробки помилок, навіть якщо ви знаєте, що це робить.

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

Процеси розвитку по суті однакові. Відмінності можуть зводитися до питань маркетингу та розгортання, хоча я вважаю, що найбільші відмінності, як правило, стосуються обсягу та визначення проекту. Пам'ятайте, що Додаток може включати або використовувати рамку або бібліотеку, а рамка може бути колекцією бібліотек.

У мене є певні сумніви щодо того, як впоратися з організацією та управлінням цим проектом: Чи є якісь загальні правила, яких слід дотримуватися, поради, найкраща практика або щось, що слід пам’ятати при розробці такого проекту?

Організація та управління проектами знову однакові для будь-якого проекту розвитку. Знову він зводиться до розмаху. Що стосується написання фреймворку, то він повинен мати дуже чітке бачення того, чого саме ви намагаєтеся досягти, та розміщення строгих правил дизайну на публічному інтерфейсі до рамки, щоб забезпечити узгодженість щодо презентації API. Якщо ви дозволите кожному розробнику зробити свою справу, ви закінчитеся складним безладом і дуже неелегантним дизайном API.

Я скористаюсь рекомендацією Райана Хейса, щоб прочитати Правила дизайну Framework, навіть якщо сама книга спрямована на розробку рамок на основі .NET, оскільки загальна порада застосовується незалежно від конкретних технологій впровадження, які ви можете обрати.

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