Разработка приложений для одного человека?

Ответ 1

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

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

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

В принципе, точка, которую я пытаюсь понять (и должен следовать за каждым проектом - не только в этом случае), имеет достаточно управления, которое имеет смысл. Остальное должно быть сосредоточено на работе и развитии продукта.

Что-то еще, что вы, возможно, захотите изучить, - это читать Agile Programming Works для разработчика соло. Есть другие, похожие, статьи. Могу дать вам хорошие мысли.

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

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

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

После этого я был готов начать полный рабочий день.

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

Ответ 4

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

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

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

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

Ответ 5

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

• Сохраняйте таблицу для высокого уровня всего - список ваших проектов и некоторые элементы верхнего уровня /todos/reminders

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

• Храните документ верхнего уровня для всех проектов в корневой папке. Сохраните идеи, исследования, заметки и т.д. В этом документе.

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

Специальные инструменты, которые я рекомендую:

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

Ответ 9

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