Время — деньги. Создание команды разработчиков программного обеспечения.
Типичные проблемы и их решение.
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Не торопитесь.
Как уже не раз было сказано, разработчики часто пытаются работать с новыми технологиями, основываясь лишь на допущениях. Эти допущения превращают проект скорее в азартную игру, чем в серьёзную техническую работу. Не торопите события: хотя некоторые проблемы можно и должно решать с ходу, всё же следует определить ключевые потребности и убедиться, что новые технологии в состоянии удовлетворить их. В этом случае вы сможете предвидеть проблемы и лучше подготовитесь к их решению, а также отреагировать на возникшие проблемы на более ранних этапах цикла разработки проекта.
Не увлекайтесь моделированием отдельных функций.
Часто возникает искушение создать прототип какого-либо компонента без учёта контекста, не принимая во внимание характер его применения. Хотя сосредоточиться на узкой задаче много проще, в этом таится большая опасность. Моделирование не должно концентрироваться на отработке какого-то одного компонента, важно отработать совместную работу всех критически важных компонентов. Я очень рекомендую создавать общесистемные прототипы, в которых собраны воедино все критически важные фрагменты системы, даже если при этом приходится использовать искусственные данные, жёстко прошивать вызовы API или подменять их заглушками. Тем не менее в этом случае удастся составить хорошее представление о проблемах с интеграцией компонентов и убедиться в проектных решений на уровне системы.
Не оставляйте анализ производительности напоследок.
Большинство считает, что производительность — это что-то, что «добавляется» к программе в конце цикла работы над проектом. Хотя настройка разного рода параметров, несомненно, может и должна выполняться после сборки всех частей проекта, также верно и то, что на этом этапе объём возможных изменений весьма ограничен. Неуместно вносить фундаментальные изменения в архитектуру или внутреннюю структуру продукта в последние недели работы над проектом.
Необходимо заранее проанализировать производительность на макроуровне: сначала на прототипе, а затем после сборки всех основных фрагментов программы.
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.