Сколько планирования Вы делаете прежде, чем начать кодировать?

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

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

Самая важная часть должна быть РАСХОДОМ.

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

I brew some coffee and craft a couple sandwiches.

Really it depends on the project. I've worked on some projects in the defense industry that took 2 years of detailed planning before writing a single line of code, and I've sat down and churned out some small utilities from just a few requests in an email from a 3D or texture artist in a single sitting with a bag of pretzels and a cup of Joe.

Being able to develop flowcharts, UML diagrams, use-case dictionaries, and extensive coding standards before hand is a nice way to keep things organized, and is certainly worth doing on larger projects, larger teams, and mission-critical projects. But these things do take time, and are often overkill for smaller projects.

The only thing you really have to ensure is that you have an adequate understanding of the problem domain. If not, spending the time up front to research it until you do is always worth the time.

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

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

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

Как только я более или менее знаю, что пытаюсь сделать, я сажусь и пишу код. Именно здесь я обнаруживаю какие-либо проблемы в том, о чем я думал.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. встречался и приветствовал всех, кто участвует в проекте
2. делал подробные заметки относительно предполагаемых требований
3. , создавал длинные маркированные списки требований высокого уровня
4. начинали ломаться требования высокого уровня в четко определенные детали
5. начинают заполнять шаблон слова Спецификации требований к программному обеспечению: SRS
6. создавать каркасы в Photoshop, Excel, Владелец продукта видит результаты гораздо быстрее. Это означает, что они могут поддерживать проект в правильном направлении с течением времени - даже если это направление меняется по мере нашего развития.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Намного меньше, чем следовало бы

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

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

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

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

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