проектирование

Фаулер о добавлении новой функциональности

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

Мартин Фаулер

О преждевременной оптимизации

«Преждевременная оптимизация — корень всех зол»
Дональд Кнут

статья «Structured Programming with go to Statements» в сборнике «Computing Surveys» (Vol. 6, № 4, декабрь 1974, стр. 268)

PMBOK 9 Knowledge Areas to 5 Process Group Mapping

	Project Management Process Groups
Knowledge Areas	Initiating Process Group	Planning Process Group	Executing Process Group	Monitoring & Controlling Process Group	Closing Process Group
4. Project Integration Management	4.1 Develop Project Charter	4.2 Develop Project Management Plan	4.3 Direct and Manage Project Execution	4.4 Monitor and Control Project Work 4.5 Perform Integrated Change Control	4.6 Close Project or Phase
5. Project Scope Management		5.1 Collect Requirements 5.2 Define Scope 5.3 Define WBS		5.4 Verify Scope 5.5 Control Scope
6. Project Time Management		6.1 Define Activities 6.2 Sequence Activities 6.3 Estimate Activity Resources 6.4 Estimate Activity Durations 6.5 Develop Schedule		6.6 Control Schedule
7. Project Cost Management		7.1 Estimate costs 7.2 Determine Budget		7.3 Control Costs
8. Project Quality Management		8.1 Plan Quality	8.2 Perform Quality Assurance	8.3 Perform Quality Control
9. Project Human Resource Management		9.1 Develop Human Resource Plan	9.2 Acquire Project Team 9.3 Develop Project team 9.4 Manage Project team
10. Project Communications Management	10.1 Identify Stakeholders	10.2 Plan Communications	10.3 Distribute Information 10.4 Manage Stakeholder Expectations	10.5 Report Performance
11. Project Risk Management		11.1 Plan Risk Management 11.2 Identify Risks 11.3 Perform Qualitative Risk Analysis 11.4 Perform Quantitative Risk Analysis 11.5 Plan Risk Responses		11.6 Monitor and Control Risks
12. Project Procurement Management		12.1 Plan Procurements	12.2 Conduct Procurements	12.3 Administer Procurements	12.4 Close Procurements

Read more from PMBOK, Process Groups PMBOK

Эрик Эванс о едином языке команды разработки

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

Эрик Эванс о разнице диалектов

Проект сталкивается с серьезными проблемами, когда в нем отсутствует единый

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

собственный язык, приспособленный для описания предметной области в терминах

программной архитектуры.

Терминология повседневных дискуссий оторвана от терминологии, внедренной код

(а это, в конце концов, главный продукт, создаваемый в проекте) . Даже один и тот же

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

критические положения предметной области часто выражаются в промежуточной

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

Необходимость в переводе затрудняет коммуникацию и ослабляет интенсивность

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

Эрик Эванс о правилах предметной области

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

Эрик Эванс о связи модели и языка обсуждения проекта

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

разговоре.

Устраняйте трудности путем экспериментирования с альтернативными выражениями, отражающими альтернативные модели. Затем выполняйте рефакторинг кода,

переименовывайте классы, методы и модули, чтобы добиться соответствия новой модели. Ликвидируйте путаницу в терминологии путем устных обсуждений — таким же

образом, как мы приходим к согласию о значении обычных слов.

Осознайте, что изменения в ЕДИНОМ ЯЗЫКЕ — суть изменения в модели.

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

что из-за них пострадает архитектура программы.

Эрик Эванс, определение термина «модель»

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

Эрик Эванс о последствиях унификации модели в больших системах

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

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

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

обеспечение в рамках одного проекта под эгидой единой модели. Я знаю этот грех и за

собой.

Но рассмотрим же, чем это чревато.

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

Эрик Эванс о проблеме работы с несколькими моделями

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