Jak zorganizować jednoosobowy projekt? [Zamknięte]

Co jakiś czas (czytaj: o każdym dniu) wpadam na nowy pomysł, zaczynam nowy projekt w moim ulubionym edytorze / IDE, zaczynam kodować, a następnego dnia go usuwam i zaczynam coś nowego. Programuję od około sześciu lat iw ciągu tych sześciu lat naprawdę ukończyłem tylko jeden bardzo mały projekt (widget Dashboard dla Pastebin.com). Chociaż może to być świetne do nauki kodowania, naprawdę chcę coś ukończyć.

Co powinienem zrobić przed, podczas i po właściwym kodowaniu? Jakie są dobre zasoby, które uczą mnie, jak organizować takie jednoosobowe projekty?

Jeśli to ważne, chcę zająć się tworzeniem stron internetowych lub komputerów Mac.

Myślę, że prawdziwym problemem długoterminowym jest raczej motywacja niż organizacja.

1. Znajdź użytkowników i porozmawiaj z nimi. Zobacz swój projekt jako rodzaj prezentu (lub produktu, który można sprzedać) tym osobom. (Ktoś, kto odrzuca pomysły, jest również świetny, nawet jeśli tak naprawdę nie tworzy z tobą kodu).

   Posiadanie takiej motywacji społecznej będzie znacznie silniejsze w utrzymaniu interesującego projektu na dłuższą metę niż zwykła osobista ciekawość.

2. Twoim celem powinny być małe kęsy wielkości użytecznych funkcji. Postaw to na SourceForge lub GitHub i traktuj projekt jako coś, co potrzebuje szansy na przetrwanie, nawet jeśli nagle uderzy cię meteor.

   Prowadzi to do większej liczby wydań (co oznacza więcej opinii i entuzjazmu użytkowników), a także większe prawdopodobieństwo, że inna osoba może zdecydować się wnieść wkład w projekt.

3. Wybierz konkretny cel uczenia się dla siebie. Jakiej technologii lub techniki pomaga projekt się nauczyć? Jeśli okaże się, że technika nie jest odpowiednia dla obszaru problemowego, czy będziesz wystarczająco zainteresowany, aby przynajmniej ukończyć wersję 1.0 przed odłożeniem jej na bok?

   Przykłady takich celów obejmują pisanie parserów, protokołów sieciowych, aspektów sztucznej inteligencji w grach, platform uczenia się lub zestawów narzędzi, nowego języka itp.

Najgorszy scenariusz oznacza pominięcie wszystkich trzech, w których wielokrotnie wykonuje się „masową przeróbkę” nigdy nie wydanego narzędzia obejmującego kod, który nie jest interesujący dla osób, dla których nie ma pewności.

Gdy podczas pracy nad projektem wpadniesz na pomysł nowego projektu, po prostu zanotuj go na liście pomysłów na projekt. Następnie wróć do bieżącego projektu. Jeśli projekt jest wart zachodu, nie daj się rozproszyć nowemu projektowi. Wykonaj następujące kroki tylko, jeśli jest to wyjątkowy pomysł.

Zanim zaczniesz nasz projekt, zaplanuj go. Co to zrobi Jak ciężko będzie to zrobić? Jakie są znane i nieznane? Co może pójść nie tak? Jak długo to zajmie? [Teraz możesz zdecydować, czy iść dalej, czy przestać.] Zachowaj swój plan. [Jeśli pracujesz nad projektem, odłóż na bok nowy projekt i przejdź do drugiego oryginalnego projektu.]

Po uruchomieniu projektu skonfiguruj go jako oddzielny projekt w swoim IDE. (Więc nie musisz go usuwać, aby rozpocząć następny projekt.) Sprawdź to w nowym oprogramowaniu do kontroli wersji jako nowy projekt. (Teraz możesz go usunąć, jeśli okaże się, że przeszkadza to innemu projektowi.) Sprawdzaj swój projekt, ilekroć robi to poprawnie. (Teraz możesz wrócić, jeśli zejdziesz z toru).

Śledź problemy pojawiające się w twoim projekcie. Można to zrobić za pomocą kilku plików tekstowych w projekcie. Pliki takie jak TODO, Dziennik zmian, README (mogą zawierać znane błędy i problemy) mogą być odpowiednie.

Gdy kod działa, oznacz go w kontroli wersji. Jeśli warto to zrobić, zrób to.

Wróć do swojego planu i sprawdź, jak dobrze ci poszło. Zrób sam dokument z lekcjami. Czego się nauczyłeś, jak dobrze oceniłeś? Jakie problemy przegapiłeś? Jakie problemy przeceniłeś? Wszystko, co uznasz za ważne.

Porzuciwszy projekt, wykonaj proces wyciągniętych wniosków. Dodaj notatkę o tym, dlaczego porzuciłeś projekt.

Raz na miesiąc sprawdzaj swoje wnioski. Z biegiem czasu możesz zwiększać odstępy między recenzjami.

Oto link do „ Doing Agile w jednym zespole ”. To ciekawa lektura!

Warto również zastanowić się, dlaczego dyscypliny tworzenia oprogramowania, które wykonujemy „w pracy”, są ważne. Czy są ważne tylko wtedy, gdy w zespole jest 10 osób? Nie, są ważne, ponieważ pomagają ci myśleć o twoim projekcie.

Kto jest waszym dobiorcą docelowym? (Jeśli to ty, to świetnie - ale pamiętaj, do czego pierwotnie chciałeś aplikację)

Jeśli tworzysz interfejs użytkownika, zastanów się nad potrzebami odbiorców, a następnie zrób kilka próbnych testów, zanim zaczniesz opracowywać twardy interfejs użytkownika.

Jeśli patrzysz na logikę biznesową, spróbuj TDD lub BDD. Zastanów się, jak chcesz, aby aplikacja działała, zanim ją zaatakujesz. Rozważ zawinięcie go w uprząż, taką jak Fitnesse lub podobna. Jeśli chcesz przetestować aplikację, najłatwiej jest zacząć od samego początku .

Biorąc pod uwagę swój komentarz, przestań usuwać swoje projekty!

Zwykle nie przechowuję projektów, które nie aktywnie rozwijam (lub przewiduję, że aktywnie rozwijam w najbliższej przyszłości) na moim komputerze, ale pliki źródłowe istnieją w repozytorium SVN i wszystko (w tym pliki konfiguracyjne IDE) jest archiwizowane na zewnętrzny dysk twardy. Nie odpowiada na twoje pytania i przestań usuwać swoją pracę, i skup się na motywowaniu siebie.

Jeśli szukasz hostowanego repozytorium, spójrz na Google Code, SourceForge, GitHub i BitBucket. Prześlij swoje pliki, trzymaj je gdzieś, a gdy znów się o to zainteresujesz, ściągnij je. Chociaż możesz ustawić je jako prywatne, możesz je upublicznić, jeśli się ich nie wstydzisz. Być może ktoś będzie zainteresowany wznowieniem pracy lub wyciągnie wnioski z twoich przykładów (szczególnie jeśli używasz ciekawej biblioteki lub frameworka).

Z czasem pracuj nad swoją motywacją. Staraj się skupiać na jednej rzeczy na raz. Możesz nie uzyskać kodu do jakości produkcyjnej, ale być może uda ci się uzyskać przykładową jakość lub coś, na co inni ludzie mogą spojrzeć, aby zobaczyć Twój zestaw umiejętności, wiedzę lub dowiedzieć się o konkretny sposób robienia rzeczy.

Przede wszystkim są projekty i projekty. Jeśli wypróbujesz jakąś technologię lub bibliotekę, lub coś innego, prawdopodobnie utworzysz projekt w swoim IDE, dowiesz się, czy ta sprawa jest dla ciebie interesująca, czy nie, a następnie usuniesz swój projekt. W porządku, wszyscy to robią.

Innym rodzajem projektu jest prawdziwe oprogramowanie / strony / itp., Które jest biznesem, w którym te „projekty”, pliki, programy są tylko narzędziami, a tworzenie tak złożonych rzeczy wymaga motywacji i celów :

• co tworzysz (strona internetowa / edytor tekstu / aplikacja mobilna / ...)
• do czego potrzebujesz (zarabiaj pieniądze, wybierz nową technologię / przyczyniaj się do open source / ...)
• kiedy to zrobisz (ile czasu poświęcisz swojemu projektowi, jak długo zamierzasz to robić)

To, co rozwijasz, powinno być nowe . Jeśli chcesz stworzyć tylko kolejny edytor tekstu, ponieważ uważasz, że brakuje jakiejś żądanej funkcji, prawdopodobnie nie musisz tego robić. Istnieją setki narzędzi open source, przyczyniają się do jednego z nich.

Nawet jeśli stworzysz małe narzędzie jednorazowego użytku, takie jak skrypt, powinieneś podać te rzeczy na liście, łatwiej byłoby rozwiązać sam problem.

Jeśli utkniesz w pisaniu kodu (np. Masowo przepisujesz kod), prawdopodobnie nie masz wystarczającego doświadczenia, aby to zrobić. Weź dobrą książkę na temat inżynierii oprogramowania, swojej platformy (mac / web / etc), przeczytaj kod napisany przez bardziej doświadczonych programistów, którzy robią podobne rzeczy. Teraz jest wiele miejsc do zrobienia (github, kod Google, blogi programistyczne, stackoverflow).

Nie próbuj rozwiązywać bardzo złożonego problemu (np. Napisać kompilator lub system operacyjny) od zera, najpierw rozłóż go na mniejsze zadania, najczęściej ktoś już utworzył biblioteki, które pomogą ci rozwiązać problem.

Czy zastanawiałeś się, czy nie zapytać ukochanej osoby, czego tak naprawdę potrzebuje do narzędzia internetowego, a potem zrobić to dla niego?

To powinno zapewnić motywację do faktycznego ukończenia i dostarczenia, co jest w tym trudną częścią. Ponadto zyskujesz na wsparciu i utrzymaniu aplikacji, jeśli jest ona przydatna dla ukochanej osoby. Jeśli nie jest to przydatne, możesz dowiedzieć się z doświadczenia, co może pójść nie tak.