Лучший способ спланировать задачу?

Ответ 1

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

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

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

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

Часто, со сложным дизайном, я преобразую этот эскиз дизайна в комментарии, чтобы вести меня как код, который быстрее и точнее, чем иметь возможность проконсультироваться со своими заметками каждые две секунды:

// open file
// read header line
// check header is right (watch for int problem)
// select right config object
// loop over lines, read each line into config object

И я конвертирую каждый комментарий в код.

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

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

Ответ 2

Я поклонник CRC-карты.

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

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

Ответ 3

Я использую что-то вроде "reallife" CRC Cards - я просто беру несколько кусочков бумаги и ручку и начинаю рисовать классы, их методы и все их зависимости. Другие документы используются для более подробной информации о функциональности.

Ответ 4

Если вы новичок в программировании, начните с основ: Обучение программированию. Напишите небольшую "hello world" программы и расширьте свои знания на веб-сайтах или приложениях Windows. Научитесь писать программы, соответствующие вашим требованиям. Если у вас нет каких-либо требований, запишите их перед началом работы, иначе ваша программа не будет иметь финишной линии.

Когда вы чувствуете себя готовым к выполнению больших проектов, вы можете взять дизайн классов и объектов, используя UML и узнать тестовая разработка, чтобы написать более надежный код. Узнайте больше о различных методах разработки, таких как Agile и Scrum. Большие проекты требуют планирования и хороших дизайнов, поэтому вы должны знать свои теории.

Ответ 5

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

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

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

Ответ 6

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

"Создание диаграмм классов и всех подобных материалов" - это на самом деле просто способ записать на бумаге то, о чем вы уже думаете: какие классы вам нужны, какие данные они будут хранить и как классы относятся к каждому Другие. Вам не нужно следовать никакому формальному процессу - я считаю, что сырые коробки и стрелки работают отлично, чтобы организовать мои мысли.

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

Ответ 7

Две точки с планированием и подготовкой:

• Чтобы убедиться, что вы и клиент поделились одним и тем же видом проблемы.
• Чтобы выявить потенциальные проблемы с вашей идеей о том, как решить проблему.

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