Як організувати проект для чоловіка? [зачинено]

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

Які ще речі я повинен робити перед тим, як і після власне кодування? Які хороші ресурси, які навчають мене організовувати такі люди-проекти?

Якщо це важливо, я хочу зайнятися розробкою веб або Mac.

Я думаю, що справжньою проблемою, довгостроковою, є мотивація, а не організація.

1. Знайдіть користувачів і поговоріть з ними. Розглядайте свій проект як своєрідний подарунок (або продаючий продукт) для цих людей. (Хтось, хто відкидає ідеї, також чудово, навіть якщо він насправді не розробляє код з вами.)

   Наявність цієї соціальної мотивації стане набагато сильнішою у підтримці проекту в довгостроковій перспективі, ніж просто особиста цікавість.

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

   Це призводить до більшої кількості випусків (що означає більше відгуків та ентузіазму від користувачів), а також більша ймовірність того, що інша людина може вирішити внести свій внесок у проект.

3. Виберіть конкретну мету навчання для себе. За якою технологією чи технікою проект допомагає вам навчитися? Якщо виявиться, що методика не підходить до проблемної області, вас зацікавить достатньо хоча б закінчити версію 1.0, перш ніж відкладати її?

   Приклади таких цілей включають написання парсерів, мережевих протоколів, аспектів ігрового інтерфейсу, навчальних рамок чи наборів інструментів, нової мови тощо.

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

Коли ви працюєте над ідеєю для нового проекту, працюючи над проектом, просто відзначте його у списку ідей проекту. Потім поверніться до поточного проекту. Якщо проект вартий, не дозволяйте собі відволікатися на новий проект. Виконайте наступні дії, лише якщо це видатна ідея.

Перш ніж розпочати наш проект, сплануйте його. Що це зробить? Як важко буде це зробити? Що таке знання та невідомі? Що, ймовірно, піде не так? Як багато часу це займе? [Тепер ви можете вирішити, продовжувати чи зупинятись зараз.] Дотримуйтесь свого плану. [Якщо ви працюєте над проектом, відкладіть новий проект і продовжуйте працювати з іншим оригінальним проектом.]

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

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

Коли ви отримаєте свій робочий код, позначте його у контролі версій. Якщо варто поділитися, зробіть так.

Поверніться до свого плану і подивіться, як добре ви зробили. Зробіть документ на уроці для себе. Що ви дізналися, як добре ви оцінили? Які проблеми ви пропустили? Які проблеми ви переоцінили? Все, що ви вважаєте важливим.

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

Перегляньте свої уроки один раз на місяць або близько того. З часом ви можете збільшувати інтервал між оглядами.

Ось посилання на " Працьовитість в команді одного ". Це цікаве прочитання!

Крім того, ви можете розглянути, чому важливі дисципліни програмного забезпечення, які ми виконуємо "на роботі". Вони важливі лише, якщо в колективі 10 людей? Ні, вони важливі, оскільки допомагають думати про ваш проект.

Хто ваша цільова аудиторія? (Якщо це ви, то чудово - але пам’ятайте, для чого ви спочатку хотіли додаток)

Якщо ви робите інтерфейс користувача, подумайте над потребами своєї аудиторії, а потім зробіть кілька макетів перед тим, як зайнятися розробкою жорсткого ядра інтерфейсу.

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

З огляду на ваш коментар, припиніть видаляти свої проекти!

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

Якщо ви шукаєте розміщений сховище, перегляньте код Google, SourceForge, GitHub та BitBucket. Завантажте свої файли, зберігайте їх десь, і коли у вас з’явиться новий інтерес, потягніть їх. Хоча ви можете зробити їх приватними, ви можете зробити їх публічними, якщо ви не соромитесь їх. Можливо, комусь буде цікаво перезапустити вашу роботу чи навчитися на ваших прикладах (особливо якщо ви використовуєте цікаву бібліотеку чи рамку).

З часом попрацюйте над мотивацією. Спробуйте зосередити увагу на одній речі. Можливо, ви не отримаєте свого коду до якості виробництва, але, можливо, ви можете навести його до прикладу якості або чогось, що інші люди можуть подивитися, щоб побачити ваш набір навичок, знання чи дізнатися про певний спосіб виконання справ.

Перш за все, це проекти та проекти. Якщо ви спробуєте якусь технологію чи бібліотеку чи щось інше, ви, ймовірно, створите проект у своєму IDE, з’ясуйте, цікава вам ця чи ні, а потім видаліть проект. Це добре, всі роблять це.

Інший тип проекту - це реальне програмне забезпечення / сайти / тощо. Це бізнес, де ті "проекти", файли, програми - лише інструменти, а розробка таких складних речей вимагає мотивації та цілей :

• що ви розробляєте (веб-сайт / текстовий редактор / мобільний додаток / ...)
• для чого це потрібно (заробляйте гроші, підбирайте нову технологію / сприяйте відкритому коду / ...)
• коли б ви робили (скільки часу присвячуєте своєму проекту, як довго ви плануєте це робити)

Те, що ви розробляєте, має бути новим . Якщо ви хочете зробити ще один текстовий редактор, оскільки ви вважаєте, що потрібна необхідна функція вам, мабуть, цього не потрібно робити. Є сотні інструментів з відкритим кодом, які сприяють одному з них.

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

Якщо ви застрягли в написанні коду (наприклад, масово переписуєте свій код), ви, мабуть, недостатньо досвідчені для цього. Візьміть хорошу книгу з інженерії програмного забезпечення, своєї платформи (mac / web / тощо), прочитайте код, написаний більш досвідченими розробниками, який робить подібні речі. Зараз існує багато місць для цього (github, google code, блоги програмування, stackoverflow).

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

Чи думали ви запитати кохану людину, що їм насправді потрібно для веб-інструменту, а потім насправді зробити це для нього чи її?

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