Какой подход/методология вы используете для разработки программного обеспечения для одного человека

Question

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

В частности, меня интересуют следующие вопросы:
_ Вы используете структурированный подход, даже если вы разрабатываете самостоятельно или вообще нет?
_Какие этапы вы используете?
_Какие документы вы пишете до и после кодирования?

И если у вас есть «ваш» стандартизованный подход, можете ли вы использовать шаблоны, которыми вы пользуетесь?

Спасибо заранее, веселит Gerry

Answer 1

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

• Всегда записывайте, что вы собираетесь сделать, и то, что вы не собираетесь делать (определить область) - Подумайте о функциональных требований (Functional Design)
• (OO only) Создайте диаграмму классов, которая отображает отношения между классами. (Технический дизайн - диаграммы последовательности, в то время как полезно, занимают огромное количество времени)
• Напишите свою программу в соответствии с тем, что вы только что записали (или ее частью).
• Рефакторинг и редизайн вашего приложения (один раз в каждые X часов, напишите его)
• Повторите шаги с 3 по 4, пока результат не будет тем, что вы написали в функциональном дизайне.
• Пройдитесь по всем углам приложения, чтобы найти каждый путь и записать это в тестовом документе. Определите возможные проблемы на путях и проверьте их.

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