Программное обеспечение Designing на сложных уровнях? [закрытый]
5 ответов
Разбейте ваш проект на небольшие задачи (менее одного дня работы). Организуйте их по группам. Расставьте приоритеты (возможно, вам нужно сделать функцию X, чтобы сделать Y). Начинайте кодить!
Любой проект, каким бы сложным он ни был, представляет собой последовательность небольших задач. Как только вы осознаете это, вам будет легче сосредоточиться и найти подход к проекту. Конечно, разбить все на мелкие задачи - это труд, и не тривиальный. Если у вас нет опыта в этом, попробуйте обратиться за помощью к коллегам. Но лучший способ получить опыт - это попробовать!
В зависимости от ситуации и личных предпочтений, вы можете рассмотреть возможность использования agile-методологии, такой как Scrum или Kanban. Вам также следует использовать инструмент управления проектом, чтобы следить за тем, что вы должны делать. Это может быть что угодно, от post its до pivotal tracker, просто найдите то, что подходит именно вам.
Я был только в подобных ситуациях гораздо меньшего масштаба. Однако я надеюсь, что эти подсказки могут помочь.
- проведите сессию проектирования (желательно с коллегами), чтобы выяснить приблизительную архитектуру вашего программного обеспечения
- попытайтесь разбить сложные истории на более мелкие подзадачи, которыми можно управлять одна за другой.
- напишите модульные тесты - это позволит вам смело реорганизовать код, не опасаясь что-то сломать, если вы чувствуете, что ваш существующий дизайн не совсем правильный
Попробуйте использовать SCRUM и TDD.
Запланируйте короткие итерации (1-2 недели) с четкими, короткими целями, постарайтесь как можно скорее создать какой-нибудь сквозной сценарий и создайте только необходимую инфраструктуру.
Используйте TDD - я обнаружил, что это помогает, когда возникают неясные цели - написав тест перед написанием кода, вы сосредотачиваетесь на одной цели за раз.
Похоже, вам нужно организовать свое программное обеспечение по нескольким функциям вместо того, чтобы обрабатывать его как одну спагетти-код.
Возможно, вы захотите использовать некоторый формализм для структурирования своего мышления, например, UML для статической архитектуры или MSC для динамической архитектуры.
Я полагаю, что большинство разработчиков сталкивались с тем моментом "ох, черт возьми", когда вы понимаете весь объем того, что вас просили сделать :)
Похоже, вы работаете как один -man team Итак, вот мои советы:
Поговорите с клиентом - Не могу переоценить это. Вам необходимо вести открытый и честный разговор сейчас . Если они попросили луну на палке, а вам платят туппенсы, никто не получит от этого правильного результата.
Разбейте систему на высокоуровневые функции (например, приложение будет экспортировать X в систему Y), поработайте с клиентом, чтобы определить разумные вертикальные срезы, которые могут быть реализованы постепенно, и назначить им приоритет.
В рамках функций упорядочивайте и приоритизируйте под -tasks
Как предлагает Марцгг, попробуйте разбить задачи на управляемые части, я обычно использую максимум 4 дня, если не больше, и вы недостаточно понимаете детали для точной оценки, поэтому уточняйте их дальше. Однако не всегда необходимо оценивать все до мельчайших деталей. Вполне нормально согласиться уточнить вещи позже, если и вы, и клиент понимаете, где могут возникнуть возможные временные сдвиги.
Получите приличный инструмент для отслеживания задач, такой как JIRA или что-то в этом роде. Вы хотите избавить свой мозг от манипуляций с задачами, чтобы у вас была возможность задуматься о реализации решений.
Помните, что доставка - это особенность: не пропадайте в безумной дыре в коде на полгода.Продолжайте регулярно доставлять прототипы (или, что лучше, правильные рабочие версии с растущим набором функций) и работайте с клиентом, а не только для клиента.