Какой процесс должен выполнять один разработчик? Не слишком ли формальный процесс?

Question

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

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

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

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

---

РЕДАКТИРОВАТЬ: я понимаю, что есть задачи, которые я делаю, как документация и контроль исходного кода. Тем не менее, я не уверен, как часть вопроса. Как сольный разработчик, я должен принять более гибкий подход (если так, какая «ветвь» Agile - XP? Scrum? RAD?) Или более традиционный подход (водопад или спираль?)?

Answer 1

Даже если вам не нужен процесс для продвижения хорошего общения между членами команды, процесс может помочь вам компенсировать тот факт, что вы не так уж супермен, как вы думали, когда вам было 18 лет :) Тип и количество «Делопроизводство», которое вы решите сделать, зависит от ваших собственных сильных и слабых сторон. Плохая память? Ежедневно записывайте свои замыслы и мысли. Хорошо видеть деревья, но не леса? Убедитесь, что вы очень осторожны с вашими требованиями и дизайном. Хорошо видеть леса, но не деревья? Подробные списки задач, оценки времени и частые результаты - ваш друг.

Это сводится к следующему: что вы, вероятно, испортите, и какие процессы помогут вам в вашем конкретном способе работы.

Answer 2

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

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

Answer 3

Это очень широкий вопрос, но, возможно, я могу помочь, поделившись своим опытом. Я почти 5 лет работал над проектом по программированию хобби с несколькими моими друзьями. Очень сплоченная группа разработчиков, мы обычно собирали наши машины в одну квартиру на выходные, чтобы разработать проект. Моя точка зрения заключается в том, что это можно сравнить с усилиями одного человека, так как мы все должны были принять решение о важных дизайнерских решениях и так далее. 'Процесс?' Нет, я не могу опознать, даже в ретроспективе.

Единственное, что держало источник в управлении, следовало парадигме «гибкой разработки», которую мы решили реализовать с самого начала: беспощадно рефакторинг . Мы сделали, и, черт возьми, это все время разрывало всю игру на части. Но это действительно содержало исходный код в чистоте, и когда мы решили время от времени выпускать "стабильные релизы", казалось, что все пошло вместе.

Answer 4

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

Документация по проектированию, проектным решениям, операциям и т. Д. Жизненно важна для любого значимого проекта.

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

Answer 5

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

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

Answer 6

Следуй за своим сердцем.