Единственная разработка приложений человека? [закрытый]

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

У меня есть два списка функций:

• Высокоуровневое представление, в котором указывается объем готового продукта
• Список функций, которые я реализую в этой итерации

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

Однако я все же попытался исследовать / составить бизнес-кейс для проекта перед началом кодирования.

Как эффективно использовать его / ее время для каждой соответствующей роли?

Я не программист, владелец продукта думал время от времени, когда мне все равно приходилось быть вдали от компьютера.

Кроме того, мой цикл:

• Реализовать больше функциональности
• Интеграция-тестирование
• [повторить, как указано выше]

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

Каким будет нормальный поток событий? что за этим последует? Начать кодирование немедленно запишите пользователя рассказы / примеры использования, а затем перейти к OOA / D?

Я начал с работы неполный рабочий день или в свободное время, чтобы убедиться, что у меня есть:

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

После этого я был готов начать разработку на полную ставку.

Каких схем / моделирования будет достаточно для этого уровня? Модель предметной области, диаграмма классов и т. Д.?

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

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

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

Если я знаю требования (здесь текущее время), я их записываю в любом случае?

Да, по тем же причинам, указанным выше.

Как мне выполнить эти требования?

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

Как эффективно ли его / ее время для каждой соответствующей роли?

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

Каким будет нормальный поток событий за чем последует?

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

Каким будет диаграмма / моделирование Достаточно для этого уровня?

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

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

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

Удачи!

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

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

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

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

Вот как я работаю, YMMV:

• Держите электронную таблицу для всего высокого уровня - список ваших проектов и некоторые элементы / задачи / напоминания верхнего уровня

• Создайте папку «проект» для каждого продукта / проекта, над которым вы работаете или над которым работаете, и создайте структуру, содержащую документацию и код для проекта.

• Держите верхний уровень " сохраните файл проекта MS (или аналогичный) и наметьте временные рамки для различных шагов в каждом проекте. Это удобно для отслеживания прогресса по каждому проекту и убедитесь, что вы ничего не забываете. В основном сохраняет честность с самим собой.

  И если вам нужно отслеживать прогресс в работе над проектом, который вы выполняете для клиентов, я понимаю, что Basecamp - хорошее решение для этого. В настоящее время я оцениваю его для своей компании. См. Www.basecamphq.com

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

  И если вам нужно отслеживать прогресс в работе над проектами, которые вы выполняете для клиентов, я понимаю, что Basecamp - хорошее решение для этого. В настоящее время я оцениваю его для своей собственной компании. См. Www.basecamphq.com

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

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

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

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

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

• VCS и инструменты для отслеживания действий пользователя / истории изменений кода - очень важно добавить хорошие сообщения о фиксации
• инструменты отображения разума для хранения связанных с проектом данные (например, XMind), доска тоже полезна :)
• инструменты отслеживания времени (например, Toggl.com)
• пишут много приемочных тестов и используют фреймворки приемочного тестирования

Конечно, эти подсказки также подходят для разработки не в одиночку :)

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

Ваш вопрос предполагает, что вы думаете в терминах довольно тяжелых инструментов и процессов, но применяется правило 80/20 - например, вы можете достаточно хорошо закрепить документацию с помощью TDD, используя doc инструменты вашей платформы для создания документации API, плюс Wiki для спецификаций, списков и т. д.

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

Конкретные инструменты, которые я бы порекомендовал:

• Распределенная система контроля версий (гораздо меньше накладных расходов, чем централизованная)
• Самая легкая платформа, которую вы можете использовать, с хорошими инструментами
• Wiki для простого захвата и поддерживать небольшие и большие фрагменты контента
• Какую бы среду тестирования вы ни использовали, с самого начала проекта
• Облегченная система списков TODO, к которой можно получить доступ из любого места

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