Как организовать индивидуальный проект? [закрыто]

Время от времени (читай: каждый день) я придумываю новую идею, запускаю новый проект в моем любимом редакторе / IDE, начинаю кодировать, а на следующий день я удаляю его и начинаю что-то новое. Я программирую уже около шести лет, и за эти шесть лет я действительно закончил только один очень маленький проект (виджет Dashboard для Pastebin.com). Хотя это может быть полезно для изучения кодирования, я действительно хочу кое-что завершить.

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

Если это имеет значение, я хочу заняться веб или Mac разработкой.

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

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

   Наличие такой социальной мотивации будет гораздо более мощным в сохранении проекта интересным в долгосрочной перспективе, чем просто личное любопытство.

2. Ваша цель должна быть небольшими кусочками полезного функционала. Поместите его в SourceForge или GitHub и относитесь к проекту как к чему-то, что требует шанса на выживание, даже если вы внезапно попали под метеорит.

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

3. Выберите конкретную цель обучения для себя. Какую технологию или технику поможет вам проект? Если окажется, что техника не подходит для проблемной области, будете ли вы заинтересованы в том, чтобы хотя бы закончить версию 1.0, прежде чем отложить ее в сторону?

   Примеры таких целей включают в себя написание синтаксических анализаторов, сетевых протоколов, аспекты игрового ИИ, рамки обучения или инструментарий, новый язык и т. Д.

Наихудший сценарий означает пропуск всех трех, когда вы неоднократно выполняете «массовую переписку» никогда не выпускаемого инструмента, включающего код, который вам не интересен для людей, которых вы не уверены в существовании.

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

Прежде чем начать наш проект, спланируйте его. Что это будет делать? Как тяжело это будет делать? Какие известны и неизвестны? Что может пойти не так? Как много времени это займет? [Теперь вы можете решить, идти дальше или остановиться.] Держите свой план. [Если вы работаете над проектом, отложите новый проект и приступайте к другому оригинальному проекту.]

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

Отслеживайте проблемы, которые возникают в вашем проекте. Это можно сделать с помощью нескольких текстовых файлов в рамках проекта. Такие файлы, как TODO, Changelog, README (могут содержать известные ошибки и проблемы) могут быть подходящими.

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

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

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

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

Вот ссылка на « Делать Agile в команде из одного ». Это интересное чтение!

Кроме того, вы можете подумать, почему важны дисциплины разработчика программного обеспечения, которые мы делаем «на работе». Они важны только если в команде 10 человек? Нет, они важны, потому что они помогают вам думать о вашем проекте.

Кто ваша целевая аудитория? (Если это вы, то отлично - но помните, для чего вы изначально хотели приложение)

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

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

Учитывая ваш комментарий, прекратите удалять свои проекты!

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

Если вы ищете размещенный репозиторий, посмотрите на Google Code, SourceForge, GitHub и BitBucket. Загружайте свои файлы, храните их где-нибудь, а когда у вас появится новый интерес, потяните их вниз. Хотя вы можете сделать их приватными, вы можете сделать их публичными, если вам не стыдно за них. Возможно, кому-то будет интересно возобновить вашу работу или учиться на ваших примерах (особенно если вы используете интересную библиотеку или фреймворк).

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

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

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

• что вы разрабатываете (веб-сайт / текстовый редактор / мобильное приложение / ...)
• для чего вам это нужно (заработать деньги, приобрести новые технологии / внести свой вклад в открытый исходный код / ​​...)
• когда вы это сделаете (сколько времени вы посвятите своему проекту, как долго вы планируете это делать)

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

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

Если вы застряли в написании кода (например, массово переписали свой код), вы, вероятно, недостаточно опытны, чтобы сделать это. Возьмите хорошую книгу по разработке программного обеспечения, вашей платформе (mac / web / etc), прочитайте код, написанный более опытными разработчиками, который делает подобные вещи. Есть много мест, где можно сделать это сейчас (github, google code, блоги по программированию, stackoverflow).

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

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

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