Эта статья является частью серии из шести статей:

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

Методология проектирования

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

  • Неформальная спецификация: начните с описания того, что должна делать программа: каковы входные и выходные данные и как они соотносятся. Эта спецификация должна быть точной.
  • Примеры. Чтобы ваша спецификация была ясной, всегда полезно представлять примеры того, что программа делает в конкретных случаях. Примеры должны «напрягать» программу, т. е. использовать граничные условия и самые неожиданные способы, какие только можно вообразить.
  • Исследование. Хороший способ выяснить, какие приемы программирования работают лучше всего, – это использовать интерактивный интерфейс для экспериментов с фрагментами программы. Идея состоит в том, чтобы написать небольшие операции, которые, по нашему мнению, могут понадобиться для программы, и мы используем операцию, которую система уже предоставляет в качестве основы. Этот шаг дает нам лучшее представление о том, какой должна быть структура программы.
  • Структура: мы делаем приблизительный план операций, необходимых для вычисления выходных данных из входных данных, и того, как они сочетаются друг с другом.
  • Кодирование: мы реализуем структуру и группируем связанные операции в модули.
  • Тестирование. Наконец, мы должны убедиться, что наша программа работает правильно. Существуют разные подходы к тестированию относительно того, когда тестировать, что тестировать и как тестировать.

Методология разработки

Существует множество способов организации разработки программного обеспечения, от «сверху вниз» к «снизу вверх». Их часто объединяет то, что вы должны начать с достаточно полного набора требований. Практика показала, что почти невозможно правильно предвидеть большинство функциональных и нефункциональных требований, и поэтому часто выгодно начинать с небольшого набора требований. CTM называет это подходом «от тонкого к толстому», и вы можете использовать этот подход как основной драйвер гибкой разработки.

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

Я знаю, что это сложно, но:

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

Ресурсы: СТМ