Для небольших работ я считаю очень важным, чтобы точно понять, что такое результаты. Кажется, что существует какая-то обратная корреляция между размером и предположениями о намерениях. По большей задаче люди будут более готовы признать, что существует двусмысленность, и планирование требуется, чем меньше задача, тем больше все полагают, что все остальные просто знают именно то, что должно быть построено.
То, что я обнаружил, что, как правило, доставка распадается на:
- Подробных бизнес-правила (желательно какое-то легкий вес спецификации)
- планов испытаний (как будут конечные пользователи знают, что старое и новые бизнес-правила до сих пор работают)
- заявления о методологии (будет включать в себя это развитии модульных тестов и т.д.)
следующий шаг после того как вы собрали соглашение о точности ш который вы будете строить, - это определить, как он будет построен. Это то, что я назвал бы фазой проектирования разработчика.
Это очень похоже на ваш комментарий на изучение каждого класса и метода для изменения. Расследуемые вещи должны быть вокруг текущего поведения, в частности, любых побочных эффектов каждого класса, нуждающихся в модификации.
- Как эти методы ведут себя? Существует ли поведение журнала или класс, которое методы изменяют?
- Как эти методы реагируют назад? Если возможно, проверьте код потребления. По крайней мере, ищите такие вещи, как подход к уведомлению об ошибках, если код теперь генерирует исключения, он должен продолжать делать это, поскольку вы не знаете, ожидает ли этот код.
Вышеуказанное расследование должно также сообщаться пользователям, если это необходимо. Например, они могут не знать, что существующая часть кодовых сообщений электронной почты пользователей, и может не хотеть, чтобы новый код делал это, или они могут предположить, что существующий код сохраняется в хранилище данных.
Я обычно рад начать вырезать код, как только пройду через выше. Главное - избегать сюрпризов в процессе разработки. На небольшой кусочек работы непредвиденное осложнение может сбить сроки на 100% или более довольно легко, поэтому инвестиции впереди, чтобы смягчить это, стоит того.
Одно предостережение на ответе выше, что это дело действительно только с водопадом СДЛК или с внесением изменений в существующую кодовую - более ловкие проекты связаны с understandibility и управления более малое изменение как часть их естественного процесса ,
Проверьте технику помпоро - это очень хорошо для поддержания себя на ходу, оценки прогресса. – lucas1000001
Я тоже борюсь с этим. Тем не менее, я обычно ошибаюсь на стороне чрезмерного планирования и бросания результатов. Таким образом, у меня есть поддерживаемый, хорошо документированный код и отчет о дизайнерских решениях. Даже если это немного поздние или отсутствующие функции, это обычно просто исправить или готово передать другому парню. Однако я с нетерпением жду ответа на этот вопрос. –
На самом деле запись проектных решений в документе - это еще одно. Что я делаю, это добавить коды в мою программу sode через комментарии, например. «Строка ниже - это решение № 45», и тогда это можно найти в документе. – dotnetdev