Как мне спланировать и начать проект?

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

Существует ли какой-то стандарт при запуске проекта, такой как сопоставление классов и начало модульных тестов? Что такое хорошее соглашение при планировании и запуске среднего проекта.

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

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

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

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

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

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

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

Хорошие опытные программисты обычно не понимают это правильно на первом проекте. Что приходит с опытом, так это способность быстрее распознавать плохой дизайн и способность переписывать быстрее.

По моему опыту, эта проблема исчезнет, ​​когда у вас будет больше опыта - вы почувствуете, что работает, а что нет. Кроме того, хорошая инкапсуляция может снизить затраты на изменение дизайна. Чем более плотно инкапсулированы ваши модули, тем дешевле будет их изменить позже. Считайте, что это отличная мотивация для того, чтобы держать ваши уроки отдельно

http://nathanmarz.com/blog/suffering-oriented-programming.html

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

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

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

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

Например, начните со списка Todo. Сделайте это просто ... даже не беспокойтесь о хранении базы данных. Просто заставь это работать. Теперь начните строить на этом фундаменте. Может быть, вы хотите изучить MVVM и WPF ... вы уже знаете, как реализовать список задач в памяти, поэтому вам нужно решить еще одну проблему. Теперь вы хотите сделать так, чтобы несколько пользователей могли загружать свои списки задач из базы данных. Вы решили в памяти и отдельной презентации, так что вы можете сосредоточиться на доступ к данным обучения. Оттуда вы можете расширить приложение, чтобы оно имело более сложную модель домена (например, переход от списка Todo к решению для управления проектами), веб-интерфейс или даже заставить его работать на мобильном устройстве. Ключом к выполнению этой работы является выбор того, что вам выполнимо, против чего вы можете отметить прогресс и которое со временем может расти.

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

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

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

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

Другими словами, когда вы начинаете, не проектируйте НИЧЕГО !!! ,

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

Итак, список пожеланий + основные приоритеты = требования .

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

Т.е.: СЕЙЧАС вы можете потакать своим дизайнерским убеждениям .

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

Плачь хаос, пусть проскользнут собаки ... Код !!

Затем реализуйте свои тесты в соответствии со своими спецификациями, затем для каждого теста напишите свой код. Постройте, «отпустите», затем повторите со следующей функцией, пока вы не решите, что проект достаточно завершен.

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

После того, как вы выполнили такие основы, как установление целей проекта, получение списка требований и блокирование любых интерфейсов с внешними системами.

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

• краткий простой английский текст.
• "Goal Driven" работает лучше всего, т.е. "Обезьяна получает виноград" лучше, чем "Красная кнопка Monkey Pushes".
• Запретить техническую терминологию. Никаких «выпадающих», «текстовых полей». Хороший вариант использования должен быть независимым от любой технологии интерфейса. Вы должны иметь возможность использовать вариант использования для системы на основе HTML и использовать его для голосовой активации без каких-либо изменений в самом сценарии использования. (это очень сложно сделать, но оно того стоит!).
• Стремитесь уменьшить количество слов вашего первого черновика на 50%, избавьтесь от лишних шагов и словесных выражений.

Чем вы готовы указать свои основные классы:

UML - универсальный язык моделирования. Является стандартным инструментом для проектирования классов. Вы указываете открытые члены и методы каждого класса и связываете их вместе в четкой и четкой графической модели.

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

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

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

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

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