LINUX.ORG.RU

История изменений

Исправление Deleted, (текущая версия) :

если учебный тогда:

1) открываешь текстовый редактор и хреначишь туда неформализованные хотелки и варианты использования (юзкейсы, причем не обязательно в умл)

2) из 1 формируешь: четкое ТЗ (можно даже по ГОСТУ, благо такой есть), высокоуровневую архитектуру (модулей, подсистем смотря какя толщина проекта)

3) из 2 создаешь задачи верхнего уровня, типа «создать модуль конфигурации», затем берешь одну задачу и детализируешь: «создать парсер и writer конфигов», «создать модифицируемое хранилище конфигурации с конкуррентным доступом и поддержкой событий» - при этом описывая там требования из тз и требования вытекающие из взаимодествия с другими модулями (последнии и есть «контакты», оне частично представлены API)

4) из 3 пишешь код, затем тест или наоборот, смотря какую методологию предпочитаешь, в любом случае требования API и поведения у тебя должны быть в 3

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

Исходная версия Deleted, :

если учебный тогда:

1) открываешь текстовый редактор и хреначишь туда неформализованные хотелки и варианты использования (юзкейсы, причем не обязательно в умл)

2) из 1 формируешь: четкое ТЗ (можно даже по ГОСТУ, благо такой есть), высокоуровневую архитектуру (модулей, подсистем смотря какя толщина проекта)

3) из 2 создаешь задачи верхнего уровня, типа «создать модуль конфигурации», затем берешь одну задачу и детализируешь: «создать парсер и writer конфигов», «создать модифицируемое хранилище конфигурации с конкуррентным доступом и поддержкой событий» - при этом описывая там требования из тз и требования вытекающие из взаимодествия с другими модулями (последнии и есть «контакты», оне частично представлены API)

4) из 3 пишешь код, затем тест или наоборот, смотря какую методологию предпочитаешь, в любом случае требования API и поведения у тебя должны быть в 3

и так для всех кусков