Преждевременная оптимизация

 "Преждевременная оптимизация — корень всех зол". 

Дональд Кнут

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

Убрать при помощи awk ведущий пробельный символ строки

cat filename | awk '{$1=$1}1'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

разговоре.

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

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

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

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

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

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