Быстрое прототипирование и рефакторинг

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

Итак, мой процесс разработки выглядит так:

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

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

Это часть общего развития? Как вы справляетесь с неизвестным ландшафтом в разработке программного обеспечения?

Это не имеет ничего общего с Agile, но люди как бы полагают, что это так, потому что они думают, что Agile - это; развитие курицы без головы в коммуне хиппи.

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

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

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

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

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

Это часть общего развития? Как вы справляетесь с неизвестным ландшафтом в разработке программного обеспечения?

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

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

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

Зависит от проекта. Если вы работаете в одиночку над небольшим проектом, может иметь смысл провести ваши технические исследования и исследования в рамках разработки. И хотя это не является частью Agile, конечно, Agile методология может быть использована для добавления некоторого контроля к этому. Однако это делает процесс очень трудно предсказать / или временной интервал. Может быть, все будет хорошо, даже быстрее, если вы работаете в одиночку над небольшим проектом, полностью принадлежащим вам, позвольте вашим требованиям раскрыться по мере их изучения. В процессе используйте хорошие принципы и будьте последовательны, и вам не нужно будет слишком много пересматривать.

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

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

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

Важным моментом является то, что функциональная спецификация может быть списком пунктов маркировки, а техническая спецификация, как правило, будет моделью, с некоторыми точками маркировки и технологическими ориентирами, может быть, всего 3 или 4 страницы в некоторых случаях.

Даже при запуске гибкого проекта мы создаем документацию:

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

Вы видите, что в нашем гибком процессе есть небольшой водопад.

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

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

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