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

Коли я придумав проект, я не знаю, як мені почати працювати над ним. Багато разів я просто ігнорую це. Однак я не хочу більше ігнорувати свої ідеї проекту.

Тепер я запитую всіх вас, чи може хтось поділитися своїм досвідом? Як мені почати проект, коли у мене є лише ідея?

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

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

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

Ось як я починаю всі нетривіальні проекти зараз. Це допомагає мені зберігати фокус, а також допомагає утримувати сферу та мету від «еволюціонування» під час розвитку.

Я думаю, що Лінус це вважав найкращим

Ніхто не повинен починати робити великий проект. Ви починаєте з невеликого тривіального проекту, і ніколи не слід очікувати, що він стане масштабним. Якщо ви це зробите, ви просто переосмислите і взагалі вважаєте, що це важливіше, ніж це можливо на цьому етапі. Або ще гірше, можливо, вас налякає чистий розмір твору, який ви передбачаєте. Тому почніть з малого, і подумайте про деталі. Не думайте про якусь велику картину та вигадливий дизайн. Якщо це не вирішує якусь досить негайну потребу, це майже напевно розроблено. І не сподівайтесь, що люди заскочать і допоможуть вам. Це не так, як працюють ці речі. Вам потрібно спочатку отримати щось корисне на півшляху, а потім інші скажуть «ей, це майже працює для мене», і вони втягнуться в проект. - Лінус Торвальдс

Що має бути моїм першим кроком для досягнення поставленої мети більш ефективним та ефективним способом?

Я припускаю, що ви раніше робили проекти, і ви перебуваєте в коледжі / університеті, який не вчить контролю версій / джерел. Якщо ви хочете побачити деякі проекти, ви завжди можете перейти до сховищ з відкритим кодом, таких як Github (використовує Git), Bitbucket (використовує Mercurial), Google Code (використовує Mercurial, Git і Subversion), CodePlex (Mercurial і Subversion / TFS), SourceForge (багато) тощо, і ознайомтеся з їхньою базою коду. Їх спільним є те, що вони використовують програмне забезпечення для управління джерелами.

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

• http://betterexplained.com/articles/a-visual-guide-to-version-control/
• http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

Ви знаєте, коли мені прийшов один проект, я не знаю, що мені робити. Багато разів я це ігнорую.

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

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

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

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

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

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

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

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

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

Але не починайте, поки ви насправді не відчуєте , що саме час!

Великі проекти формуються з багатьох менших проектів чи творів. У вас може бути одна велика ідея або вимога проекту - скажімо, програма, яка керує контактами.

Розбити його; запитайте себе: "які менші шматочки мені потрібні для цього?"

Після того, як ви визначили свої менші частини, повторіть; Ви можете виявити, що деякі деталі потребують подальшого розбиття. Ідея полягає в тому, щоб ви визначили найбільш керовані цілі для кожної з менших деталей. Навчіться використовувати дисципліновані принципи в розробці та розробці (наприклад, Agile-TDD), і менші, більш керовані цілі будуть виконані.

Створіть контур

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

Сплануйте свої кроки

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

Знайдіть інструменти для роботи

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

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

Отримати допомогу

Великі проекти зазвичай не роблять поодинці. Зверніться до однокурсників, людей у ​​вашій громаді, які можуть програмувати, та будь-якого іншого, хто вважає, може допомогти вам перед початком роботи. Не бійтеся питати.

Почати!

Не гуляйте, не чекайте, коли хтось інший розпочне ваш проект, а потім скажіть: «У мене була така ідея!». Це назавжди переслідує вас ...

Можливо, це повно кліше, але ... я підкажу.

Щоб мати можливість впоратися з великим проектом, потрібно головне одне: досвід. Досвід дає вам все необхідне:

• Знання: чим більше часу ви витрачаєте на проекти, тим більше загальних та конкретних знань ви отримаєте
• Впевненість: управління великими проектами потребує впевненості, впевненість виходить із знань і взагалі того, що кожен твір - це те, що ви робили раніше, або ви бачили, як це роблять люди
• Професійна мережа: якщо проект дійсно великий, вам доведеться усвідомити, що ви не можете його здійснити самостійно, тому будьте готові до того, що дізнаєтесь, кого можна запитати або де ви зможете знайти ключову інформацію, яку ви шукаєте

Тож ви можете зробити дві речі:

• Занурись і подивись, як це йде. Ймовірно, ви зробите багато помилок, але головне - навчитися на них.
• Отримайте роботу, де ви зможете спеціально спостерігати за людьми, які займаються великими проектами

Я сподіваюся, що це допомагає.

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

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

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

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

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

Розділіть великі речі на більш дрібні.

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

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

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

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

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

Як [X]
я хочу [Y],
щоб [Z]

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

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

Я думаю, що це буде найшвидший і організований спосіб перейти від ідеї до коду.

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

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

Відкриття файлу, Збереження файлу, Збереження файлу як, Друк тощо та наклейте їх на дошку під головним меню.

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

Жовті наліпки чудові, їх можна досить швидко переміщати.

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

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

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

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

Наступне, що я роблю, - це створити папку і поставити її під контроль джерела . Це так просто, як git init .сьогодні.

Далі я працюю "привіт світ" . Це дозволяє мені знати, що моє середовище розробки налаштовано належним чином.

Далі я отримую "привіт світ" для сторонніх бібліотек, що працюють . Це мінімальний необхідний мінімум, щоб показати, що я посилаюся на бібліотеку і правильно користуюся нею. Наприклад, для бібліотеки баз даних це з'єднання та запуск простого запиту. Для інструментарію GUI він відображає вікно.

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

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

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

Якщо все, що у вас є, - «велика ідея», вам знадобиться багато речей (які дуже добре описані в інших відповідях), і особливо ці 2: час та мотивація .

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

Отже, як уже було сказано, робіть невеликі кроки , ось і ключ.

Але це ще не все, вам потрібно робити невеликі та корисні кроки ! Тобто кроки, які принесуть вам найбільшу цінність та продемонструють ключові концепції вашої великої ідеї.

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

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

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

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

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

Захист коду, як правило, становить близько 20% (+ -10%) бюджету проекту. Орієнтуватися на правильне отримання коду безглуздо, це 80% зусиль, на які ви не зверталися, тому отримання ідеального управління кодом все ще залишає вам лише 20 виконаних робіт.

Що робити, якщо у вашому проекті немає користувачів? Що робити, якщо це ідеально, але опубліковано через тиждень після "Acme Patent Trolls" для патенту на ідею, і це виявиться наступним Facebook?

Подивіться на наступні стандартні проблеми життєвого циклу проекту Вимоги, дизайн, код, тест, інтеграція, розгортання, відстеження та виправлення дефектів, управління зміною вимог (запити на вдосконалення). Плани випуску, розподіл ресурсів (скільки годин на день ви плануєте, і чи будете ви реально робити проект), юридичні (Freedon для роботи) тощо.

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

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

Тож, щоб відповісти на ваше запитання, відкладіть програмні засоби та витягніть свої інструменти "бізнес-планування". Опрацюйте, ЧОМУ ви це робите, бо ЧОМУ тоді, ЧОМУ і КОГО вони цього хочуть? (Ви можете бути власним клієнтом, але все-таки робіть вправу). Запишіть це у «Бізнес-план» та побудуйте з їх.

1. як виглядає успіх?
2. які невідомі у проекті?
3. які знання у проекті?
4. що ви можете зробити, щоб усунути / виявити невідомі, перетворити їх у знання?
5. що ти можеш зробити, щоб зібрати знання, щоб досягти успіху?
6. який наступний конкретний крок зробити, що рухає проект вперед?

повторюйте останній крок, поки проект не буде виконаний; прийміть, що це може зайняти роки , і продовжуйте рухатися вперед

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

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

Перелік дій, які потрібно зробити при запуску нового проекту:

1. створити новий каталог
2. створити makefile, скопіювавши деякий існуючий шаблон makefile
3. створити кілька заголовків та файлів реалізації
4. переконайтеся, що вона компілюється
5. почати використовувати управління версіями
6. приймати рішення про іменування класів, функцій, членів даних, змінних
7. напишіть свій перший клас
8. переконайтесь, що ваш клас незалежний, і кожен член-член не залежить від інших функцій-членів
9. створити кілька об'єктів, створивши такі функції, як main ()
10. повторіть кроки 7-10, поки ваша програма не буде готова
11. складіть його
12. доставити його кінцевим споживачам