Как много вы планируете, прежде чем начать писать код?

Question

Когда вы начинаете новый проект, как вы планируете его или сколько времени это займет?

псевдокод? Блок-схема?

Вы пытаетесь продумать все классы заранее?

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

Answer 1

После опыта ЛОТА незавершенных проектов , я склонен внедрять упрощенную версию моих бизнес-процессов в мою методологию личного развития.

Они обычно имеют следующую структуру:

1. Создайте бриф, чтобы я имел в виду цель.
2. Реализуйте диаграмму классов , чтобы понять данные, с которыми я буду иметь дело.
3. Реализовать все классы.
4. Составьте диаграмму прецедентов , чтобы обозначить действия.
5. Поместить дизаграмму варианта использования (в HTML для веб-приложений)
6. Подключите эшафот, выполнив модульные тесты и собрав их для прохождения.
7. Решите выпустить продукт для коммерческого успеха, а затем забудьте о нем все.

Answer 2

много меньше, чем я должен

Я всегда ныряю, пачкаюсь и потом понимаю, что напутал. Затем вернитесь и спланируйте и сделайте все правильно.

но фаза беспорядочных ошибок дает мне прекрасные идеи, которые я не смог бы реализовать в процессе формального проектирования.

Редактировать В основном я получаю такие удары по клавиатуре путается при игре с большим / сложным. Интересно посмотреть, как далеко продвинулись дела, прежде чем ты поймешь, что твой «это у меня в голове, так что все в порядке» дизайн на 100% ошибочен.

Answer 3

Наверное, не самая лучшая техника ... но ... Я планирую в коде .

Я часто открываю класс / методы / и т. Д. что мне нужно, просто делая это таким образом. С учетом сказанного я всегда предполагаю, что мой код планирования не будет окончательным решением.

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

Answer 4

Когда я занимался «водопадным» способом, я писал несколько сотен страниц документов, показывающих все детали, которые могли быть раскрыты во время исследования. Чтобы добраться до этого огромного тома документации, я бы вообще

1. встретиться и поприветствовать всех участников проекта
2. делать обильные заметки относительно предполагаемых требований
3. создавать длинные маркированные списки требований высокого уровня
4. начало разбивать требования высокого уровня на четко определенные детали
5. начать заполнять шаблон слов спецификации требований к программному обеспечению: SRS
6. создание каркасов в фотошопе, Excel или (мой любимый) Balsamiq
7. перечислить данные, которые должны быть получены, и начать строить приблизительную схему
8. перечислить структуры классов в UML
9. определить сроки проекта
10. бла-бла-бла
11. написать код
12. надеюсь, что то, что было запрошено, является тем, что все еще требуется, когда код будет завершен!

В течение последних нескольких лет я следовал вместе с Agile (SCRUM) и придерживался совершенно другого подхода.

1. встретиться с владельцем продукта, чтобы узнать о задачах, которые предстоит построить
2. разбить историю на задачи (базовое планирование)
3. назначить время для задач
4. сделать более детальное планирование
5. -> написать тест, написать код для прохождения теста, рефакторинг -> проверить в танце
6. демонстрация рабочего продукта / функции
7. начать процесс с

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

Имейте в виду, что есть время и место для обоих способов развития. Я не хотел бы создавать программное обеспечение Jet, используя Agile!

Answer 5

Все зависит от того, насколько велик проект. Иногда могут потребоваться месяцы, чтобы просто собрать все требования и точно знать, что для этого нужно.

Когда дело доходит до кодирования, все зависит от того, насколько это сложно. Если это будет чрезвычайно сложно, я начну с того, что просто вытяну то, что хочу. Затем я напишу свой псевдокод в комментариях. Тогда я буду кодировать вокруг этих комментариев.

Однако, если это простое кодирование. Обычно я просто пишу то, что у меня на уме, и проверяю это.

Мы используем очень гибкий подход, в котором мы будем работать над основными частями, и, конечно, всегда появляются требования Так что мы будем приспосабливаться к тем, кто придет. Вы никогда не будете полностью знать, что именно вы хотите создать в начале цикла создания.

Это мое мнение.

Answer 6

IMO 5 минут планирования вперед = 1 час кодирования ....

Так много раз нам приходится возвращаться и переосмысливать всю ситуацию, потому что мы ничего не планировали.

Самая важная часть должна быть FLOWCHART.

О других деталях иногда можно позаботиться на лету.

Answer 7

Я завариваю кофе и делаю пару бутербродов.

На самом деле это зависит от проекта. Я работал над некоторыми проектами в оборонной промышленности, для которых потребовалось 2 года детального планирования, прежде чем написать одну строчку кода, и я сел и набросал несколько небольших утилит из нескольких запросов в электронном письме из 3D или Художник-текстурщик за один присест с сумкой кренделя и чашкой Джо.

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

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

Answer 8

Лично это зависит от масштаба и сложности проекта, от количества людей, с которыми я работаю над ним, и от общих ожиданий по доставке.

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

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

Answer 9

В зависимости от сложности проекта я обычно начинаю с блокнота и бумаги и пишу спецификацию и некоторый псевдокод потока управления. Тогда я всегда могу вернуться к этому, пока я пишу код. Это облегчает задачу и требует меньшего количества рефакторинга, потому что вы не продумали проблему до конца.

Answer 10

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

По сути, попробуйте взглянуть с высоты птичьего полета на проблемы, которые нужно решить. Посмотрите, достаточно ли малая из этих проблем, чтобы вы могли их решить, и выясните, что может понадобиться для связи с остальным решением. Думайте об этом как о чёрном ящике с API для внешнего мира.

После того, как вы разберетесь со всеми вашими блоками, посмотрите, нужно ли вам разбить проблему на более мелкие подзадачи или у вас есть достаточно подробное представление всего проекта, чтобы вы могли начать с кода.

По моему опыту, планирование помогает вам предотвратить проблемы в будущем, заставит вас больше думать о том, как должен расти код в будущем, если вам нужно что-то добавить и т. Д.

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