Цикл, который вы описываете, нормальный. Способ улучшить ситуацию - не избежать этого цикла, а упростить его. Первый шаг - принять это:
- Почти невозможно узнать все в первый день проекта.
- Даже если вы как-то все знаете, к тому времени, когда вы закончите проект, что-то (требования клиента, рынок, на котором вы работаете, технологии, с которыми вы работаете, пожелания их клиентов) изменится и будет сделано в Наименьшая часть того, что вы знали неверно или неправильно.
Поэтому невозможно все спланировать заранее, и даже если бы вы могли, следование этому плану привело бы вас к созданию чего-то несовершенного или устаревшего. Зная это, мы интегрируем изменения в наше планирование. Давайте посмотрим на ваши шаги:
- Начните с нескольких вариантов использования
- Начать кодирование
- Осознайте несколько вещей, с которыми я не справился хорошо, и не очень хорошо вписывается в текущую кодовую базу.
- Переписать большую часть кода
Это действительно отличная отправная точка. Вот как я подхожу к этому:
1. Начните с нескольких вариантов использования
Хороший. Говоря «прецедентов», вы фокусируетесь на том, что программное обеспечение для . Говоря «несколько», вы не пытаетесь открыть все; Вы придерживаетесь контролируемого объема работы. Все, что я бы добавил здесь, это расставить приоритеты. С вашим клиентом или конечным пользователем выработайте ответ на этот вопрос:
Какое самое маленькое и простое программное обеспечение, которое я могу вам дать, улучшит вашу ситуацию?
Это ваш минимальный жизнеспособный продукт - все, что меньше, чем это, не полезно для вашего пользователя, но все, что больше, рискует планировать слишком рано. Получить достаточно информации, чтобы построить это, а затем двигаться дальше. Имейте в виду, что вы не будете знать все на этом этапе.
2. Начните кодировать.
Отлично. Вы работаете как можно скорее. Пока вы не написали код, ваши клиенты получали нулевую выгоду. Чем больше времени вы тратите на планирование, тем дольше клиент проводит в ожидании без окупаемости.
Здесь я бы добавил напоминание, чтобы написать хороший код. Запомните и следуйте принципам SOLID , пишите достойные модульные тесты вокруг чего-то хрупкого или сложного, делайте заметки о том, что вы, вероятно, забудете или что позже может вызвать проблемы. Вы хотите структурировать свой код так, чтобы изменения не вызывали проблем. Чтобы сделать это, каждый раз , когда вы принимаете решение , чтобы построить что - то в этом путь вместо того , чтобы что путь, вы структурировать свой код так , что , как мало кода , насколько это возможно зависит от этого решения. В общем, хороший способ сделать это - отделить ваш код:
- используйте простые дискретные компоненты (в зависимости от вашего языка и ситуации этот компонент может быть функцией, классом, сборкой, модулем, службой и т. д. У вас также может быть большой компонент, построенный из более мелких, например, класс с большим количеством функций или сборка с большим количеством классов.)
- каждый компонент выполняет одну работу или работу, связанную с одной вещью
- изменения в том, как один компонент выполняет свою внутреннюю работу, не должны вызывать изменения других компонентов
- компонентам следует давать то, что они используют или от которых они зависят, а не выбирать или создавать их
- компоненты должны предоставлять информацию другим компонентам и просить их выполнять работу, а не извлекать информацию и выполнять работу самостоятельно.
- компоненты не должны иметь доступ, использовать или зависеть от внутренней работы других компонентов - использовать только их общедоступные функции
Делая это, вы изолируете последствия изменений, так что в большинстве случаев вы можете исправить проблему в одном месте, а остальная часть кода не заметит.
3. Обнаружение проблем или недостатков в дизайне.
Это случится Это неизбежно. Примите это. Когда вы столкнетесь с одной из этих проблем, решите, что это за проблема.
Некоторые проблемы - это проблемы в вашем коде или дизайне, которые затрудняют то, что должно делать программное обеспечение. Для решения этих проблем вам нужно вернуться и изменить свой дизайн, чтобы решить проблему.
Некоторые проблемы вызваны нехваткой информации или тем, о чем вы раньше не думали. Для решения этих проблем вам нужно вернуться к своему пользователю или клиенту и спросить их, как они хотели бы решить эту проблему. Когда у вас есть ответ, вы идете и обновляете свой дизайн, чтобы справиться с ним.
В обоих случаях вы должны обращать внимание на то, какие части вашего кода должны были измениться, и когда вы пишете больше кода, вы должны думать о том, какие части могут измениться в будущем. Это облегчает определение того, какие части могут быть слишком взаимосвязаны, а какие части должны быть более изолированными.
4. Перепишите часть кода
Как только вы определили, как вам нужно изменить код, вы можете пойти и внести изменения. Если вы хорошо структурировали свой код, то это обычно включает изменение только одного компонента, но в некоторых случаях это может также включать добавление некоторых компонентов. Если вы обнаружите, что вам нужно многое изменить во многих местах, подумайте, почему это так. Не могли бы вы добавить компонент, который хранит весь этот код внутри себя, а затем все эти места просто использовать этот компонент? Если вы можете, сделайте это, и в следующий раз, когда вам придется изменить эту функцию, вы сможете сделать это в одном месте.
5. Тест
Распространенной причиной проблем в программном обеспечении является недостаточное знание требований. Часто это не ошибка разработчиков - часто пользователь не уверен, что ему нужно. Самый простой способ решить эту проблему - это полностью изменить вопрос. Вместо того, чтобы спрашивать «что вам нужно для программного обеспечения?», Каждый раз, когда вы проходите через эти шаги, дайте пользователю то, что вы создали до сих пор, и спросите его: «Я построил это - он делает то, что вам нужно?». Если они говорят «да», то вы создали что-то, что решает их проблему, и вы можете перестать работать! Если они скажут «нет», они смогут более конкретно рассказать вам, что не так с вашим программным обеспечением, и вы сможете улучшить эту конкретную вещь и вернуться за дополнительной информацией.
6. Узнайте
Проходя этот цикл, обращайте внимание на проблемы, которые вы обнаруживаете, и изменения, которые вы делаете. Есть ли шаблоны? Вы можете улучшить?
Некоторые примеры:
- Если вы продолжаете обнаруживать, что упустили из виду точку зрения определенного пользователя, можете ли вы привлечь этого пользователя к участию в этапе проектирования?
- Если вам по-прежнему приходится что-то менять, чтобы обеспечить совместимость с технологией, можете ли вы создать что-то для взаимодействия между вашим кодом и этой технологией, чтобы вам нужно было только изменить интерфейс?
- Если пользователь по-прежнему меняет свое мнение о словах, цветах, изображениях или других вещах в пользовательском интерфейсе, не могли бы вы создать компонент, который предоставляет остальной части приложения такие компоненты, чтобы они все были в одном месте?
- Если вы обнаружите, что многие ваши изменения относятся к одному и тому же компоненту, уверены ли вы, что этот компонент привязан только к одной работе? Не могли бы вы разделить его на несколько более мелких частей? Можете ли вы изменить этот компонент, не касаясь других?
Будь проворным
То, к чему вы движетесь, это стиль работы, известный как Agile. Agile - это не методология, это семейство методологий, объединяющих целый ряд вещей (Scrum, XP, Kanban, и многие другие), но их объединяет общая идея, что все меняется, и как разработчики программного обеспечения мы следует планировать адаптацию к изменениям, а не избегать или игнорировать их. Вот некоторые из его основных принципов, в частности те, которые имеют отношение к вашей ситуации:
- Не планируйте дальше, чем вы можете с уверенностью предсказать
- Делайте поправки на вещи, чтобы измениться, как вы идете
- Вместо того, чтобы строить что-то большое за один раз, создайте что-то маленькое, а затем постепенно улучшайте это
- Держите конечного пользователя вовлеченным в процесс и получайте быструю, регулярную обратную связь
- Изучите свою собственную работу и прогресс, и учитесь на своих ошибках