Jaki jest minimalny podzbiór najlepszych / dobrze znanych praktyk w tworzeniu oprogramowania dla programisty solo? [Zamknięte]

Od dłuższego czasu jestem samotnym programistą. Zwykle czytałem artykuły i posty o

• Systemy kontroli wersji
• Ciągła integracja / dostawa
• Metodologie rozwoju: Scrum, Waterfall, V-Model, Agile, XP itp.
• Oprogramowanie do zarządzania projektami

Ale prawie wszystkie wydają się skoncentrowane na ZESPÓŁACH. Nie jestem zespołem, więc jaki byłby absolutnie minimalny zestaw praktyk dla jednego programisty? Rozważ następujące warunki:

• Nie mam konfliktów z kodem osób innych osób.
• Nie muszę utrzymywać drzew plików / katalogów, moje środowisko programistyczne dba o samą wersję (programowanie oparte na obrazie).
• Nie ma żadnych wymagań formalnych, moi użytkownicy nie wiedzą, czego chcą i nie mają nic przeciwko.
• Jedyną osobą, która mogłaby być zainteresowana dostarczeniem wersji lub dokumentacji, jestem ja, w zasadzie klient chce WYNIKÓW i nie dba o metodologie oprogramowania itp.

Uważam, że nie chcę spędzać (zbyt dużo) czasu i energii na czymkolwiek, co nie jest bezpośrednio związane z wymaganiami klienta. Jakieś rekomendacje?

Nie ma właściwej odpowiedzi na to pytanie, ponieważ zależy to od każdej osoby. Jeśli używasz iPada do wykonywania wszystkich prac programistycznych, a Twoi klienci są z Ciebie zadowoleni, nie masz żadnego powodu, aby się zmieniać.

Gdybym jednak był na twoim stanowisku, zdecydowanie egzekwowałbym następujące postanowienia:

• System kontroli wersji - choć może się wydawać, że oparty na obrazach system programistyczny wykonuje regularne kopie zapasowe i tak dalej, nie masz miejsca na eksperymentalne funkcje, w których zwykle używa się gałęzi . Nie możesz również zachować ważnej wersji projektu ( tagowanie ). Jeśli kiedykolwiek rozszerzysz się poza siebie, programiści, którzy dołączą, będą myśleć, że są w piekle.
• Zwinne - ta metoda jest wyjątkowo przydatna dla klientów, którzy nie wiedzą, czego chcą. Wcześniej czy później zdadzą sobie sprawę, że nie chcą wydawać pieniędzy na ściganie ogona - będą chcieli zobaczyć postęp.
• Narzędzie do zarządzania projektami - jest to konieczne. Bardzo trudno jest zatrzymać wszystko w swojej głowie, ale nie musisz. Zdyscyplinowanie i korzystanie z narzędzia do zarządzania projektami (np. Redmine ) pozwoli ci oddzielić swoje zadania i da ci łatwą do przeglądania historię swojej pracy. Będzie to bardzo ważne, gdy zaczniesz ładować za godzinę.

Kontrola wersji jest absolutną koniecznością dla każdego programisty, nawet samotnego. Oznacza to, że możesz łatwo i szybko odzyskać usunięte pliki i złożone zmiany, które są po prostu błędne.

Zasadniczo ratuje cię przed głupim gównem, które robisz, kiedy idziesz do pracy zawieszony.

Jak mówią inni, kontrola wersji lub zarządzanie kodami źródłowymi jest niezwykle ważne. Użyj DVCS i dowiedz się wszystkiego na ten temat. Tak naprawdę nie ma znaczenia, który to jest, ale może ci się przydać, jeśli wybierzesz popularny: git lub merkurial.

Kolejną rzeczą, o której nie wspomniałem, jest skrypt budowania w jednym kroku . To nie jest prosta ciągła integracja (moim zdaniem fraza podatna na BS), ale bardzo przydatne narzędzie. Ilekroć potrzebujesz aktualizacji awaryjnej, możesz po prostu uruchomić skrypt i gotowe. Zbliżając się do końca projektu, zdarza się również, że potrzeba kilku kompilacji dziennie. Z mojego doświadczenia wynika, że ​​bardzo się opłaca, nawet jeśli proces kompilacji nie jest zbyt skomplikowany. Możesz nawet dodawać funkcje przesyłania ftp, raporty w wiadomości e-mail, przeprowadzanie testów jednostkowych, budowanie instalatorów, podpisywanie itp. Pisanie skryptu od samego początku jest łatwe w utrzymaniu i rozszerzaniu wraz z większą liczbą kroków w miarę postępu projektu.

Odpowiem tylko na jedno, kontrola wersji jest niezwykle ważna w każdym projekcie, a nie tylko zespołowym. Używanie go zajmuje bardzo mało czasu, ale zapewnia bogatą historię, na której można polegać, nie jest to srebrna kula, ale z pewnością miło jest móc wrócić do kopii roboczej, jeśli to naprawdę funkcja eksperymentalna zepsuła większość aplikacji.

Kontrola wersji jest absolutną koniecznością. Nie tylko z powodu utrzymywania źródła w porządku, ale z powodu archeologii źródła. Rok od sprawdzenia, jak ewoluowała klasa lub procedura, może zaoszczędzić wiele bólu, jeśli spróbujesz „naprawić” jakiś dziwny kod.

W przypadku metodologii - zdecydowanie polecam manifest programistów . Zwykle daje świetne wyniki w małych zespołach ze względu na zerowy narzut i brak konieczności utrzymywania w głowie, jak działa struktura szkieletowych kontenerów aplikacji internetowych CMS obsługujących MMS opartych na portletach J2EE .