Когда вы работаете над личными проектами среднего размера, что вы указываете перед тем, как начать программировать?
Я указываю функциональную спецификацию:
- Я боялся, что, если я только начал программировать (то есть «как»), было бы слишком легко забыть «почему» и «что» я хотел кодировать (для «довольно сложного» программного обеспечения за месяцы или годы, которые может потребоваться разработка).
- I also wanted to understand, more or less, the "scope" of what I would be developing: in order to assess approximately (to an order of magnitude):
- How big it will be
- Смогу ли я закончить
- Стоило ли начинать
- Какое его подмножество может быть разработано в первую очередь
Ради управления рисками я добавлю, что часть того, что я хотел разработать, подразумевало использование некоторого программного обеспечения, с которым я не был знаком; чтобы свести к минимуму риск, связанный с этим, я также сделал небольшое одноразовое прототипирование.
Как?
Я набросал функциональную спецификацию, используя ручку и бумагу. Что-то из того, что я написал, было высокоуровневым (документ «видение» бизнес-уровня), а что-то было более низкоуровневым, больше похожим на дизайн (некоторые детали пользовательского интерфейса). Иногда я останавливался и ломал голову над тем, как это организовать, но затем продолжал, рассуждая о том, что каждая страница более или менее связна по каждой теме, и что я могу позже ломать голову над тем, как организовать страницы. (возможно, так же, как ваша вики).
Я заранее указал и не указал архитектуру программного обеспечения:
- Я начинаю разработку с базовой архитектуры (несколько небольших компонентов), а затем добавляю код; и, когда я добавляю код, если какой-либо компонент становится слишком большим и сложным, я разделяю его на несколько более мелких компонентов... это эволюционный процесс... как говорится в Систематике, A СЛОЖНАЯ СИСТЕМА, КОТОРАЯ РАБОТАЕТ, НЕИЗМЕННО ОБНАРУЖАЕТСЯ ИЗ ПРОСТОЙ СИСТЕМЫ, КОТОРАЯ РАБОТАЛА.
- Я не документирую архитектуру; или, скорее, единственной документацией по архитектуре является сам код: например, способ, которым исходный код организован в исходные каталоги, пространства имен и библиотеки DLL.
У меня есть теоретическое обоснование архитектуры в ее нынешнем виде, но я не задокументировал эти причины:
- я единственный разработчик
- Фактическая архитектура документируется кодом
- Причины такой архитектуры у меня в голове, и их можно [повторно] обнаружить по таким вещам, как соглашения об именах в исходном коде и зависимости различных компонентов.
Если бы (только если бы) я не был единственным разработчиком, то я мог бы подумать, что стоит задокументировать архитектуру и ее обоснование.
То, что я сказал выше об архитектуре программного обеспечения, справедливо и в отношении данных, которые оно обрабатывает.
Что касается тестирования, я немного кодирую, а затем тестирую; или напишите тест, а затем закодируйте функциональность, которая пройдет этот тест. Я не занимаюсь «интеграцией большого взрыва», то есть месяцами написания без какого-либо тестирования.
Одна из самых больших слабых сторон моего процесса (или что-то, что ему не хватает) — это оценка трудозатрат заранее, а затем отслеживание реализации по оценке… это одно из отличий этого «личного» процесса проекта. по сравнению с платным проектом, который я бы сделал для кого-то еще на коммерческой основе. Я сомневаюсь, что это хорошо: если оценка является лучшей коммерческой практикой, то, возможно, мне «следует» делать это и в личном проекте.
person
ChrisW
schedule
18.01.2009
