Czyli patrzysz tylko na część techniczną pracy? A co z innymi aspektami? Trafiasz na projekt i tak ruszasz od zera i jedziesz we jakimś kierunku? Czy jednak potrzebujesz jakiegoś wprowadzenia o co w tym chodzi, jakie są standardy pracy, gdzie repozytoria kodu, jak budować releasy, jak wygląda struktura zespołu i sposób pracy? I czego się od Ciebie wymaga?
ale pisałeś o idealnym projekcie od zera, nie wspominałeś nic o projektach, do których się dołącza i mają być idealne. "Idealny" albo wg mnie dobry projekt solo to całkiem coś innego niż zespołowy. Co więcej uważam, że nie istnieje zespołowy projekt, który będzie "idealny" dla kogokolwiek z jego twórców. Bierze się to z prostego faktu, że "idealność" to pojęcie względne i mocno związane z konkretnym osobnikiem. Jeśli mamy dwie osoby to już są dwa różne poglądy na "idealność" a jak tych osób jest 10 to ... Z drugiej strony choćby nie wiem jak dokładne i restrykcyjne były reguły i standardy to każdy pisze kod indywidualny, który jednak mieści się w narzuconych ramach.
Takie cechy dobrego projektu wg mnie to przede wszystkim (pewnie dużo zapomnę):
- NIEZMIENNOŚĆ założeń projektu (w granicach rozsądku)
- nieskąpienie na narzędzia
- jasne wytyczne co do sposobu pisania kodu
- porządek
Ad. 1. najbardziej nie lubię jak w trakcie implementacji projektu ktoś wpada na genialny pomysł, że to małe coś to można zrobić inaczej. Nieważne, że ta zmiana przekreśli praktycznie cały kod, który jest już napisany i sprowadza się do tego, że cały projekt trzeba zacząć od nowa - przecież to tylko taka mała zmiana. Nieważne, że tak miało nigdy nie być i to nigdy nie będzie potrzebna - akurat teraz jest. Niestety w biznesie tak jest często, szczególnie przy niezdecydowanym kliencie. Po takim info mam ochotę wykasować cały katalog danego projektu i nigdy do niego nie wracać. Zresztą wiem, że nie tylko ja bo reszta zespołu ma podobnie. Zazwyczaj kończy się tym, że projekt leci do konta na tydzień, dwa, wszyscy zajmują się czymś innym i jak już wszyscy ochłoną to zaczyna się od nowa. Ta przerwa ma też tą zaletę, że można pozbyć się z głowy rozwiązań dobrych dla starego projektu ale niekoniecznie dobrych dla nowego.
Ad. 2. drugim demotywatorem jest dla mnie przypadek, kiedy muszę wymyślać koło na nowo - wiem, że na rynku jest idealne narzędzie, które rozwiąże dany problem i tak na prawdę to jego koszt będzie znacznie mniejszy niż mój czas, który spędzę na napisaniu tego od zera, a na pewno nie będzie tak dobre jak to co już jest. Ale nie bo moja pensja jest w budżecie a kasy na dodatkowe wydatki w tym roku brak - zgłaszać to trzeba przed zamknięciem budżetu. Miałem tak raz i po ostrej wymianie zdań jednak kasa się znalazła
Ad. 3. jeśli ktoś pisze camelCase inny CamelCase a jeszcze ktoś inny sanke_case to można cholery dostać. Do tego nawias {
na końcu linii albo jako samotny w linii, dodatkowo na równi z poprzednią lub następną linią. No obłęd po prostu :) Następnie mamy typa od zmiennych lokalnych nazywających się a
, b
, i
, x
, xx
itd. a z drugiej strony ZmiennaIteracyjnaPetliGlownej
oraz ZmiennaIteracyjnaPetliPomocniczej
. Do tego w RADach dochodzą nazwy komponentów typu Edit1
, Edit2
, Edit964
itd. Patrzysz w kod a tam Edit324.Text := s
i ni chuchu nie wiadomo co ten nieszczęsny edit pokazuje ani co jest w tej zasranej zmiennej s
... Niestety mam jeden odziedziczony taki projekt. Szczęście w nieszczęściu, że jest on mały a jakichś zmian/poprawek wymaga może raz na rok.
Ad. 4. Porządek - co to może być? - choćby to, że zawsze na koniec dnia pracy kod każdego gościa z zespołu jest zatwierdzany do głównego repo. Projekt można zawsze zbudować bez błędów, główna baza testowa jest sprawna i działająca. Generalnie chodzi o to, żeby nie robić sobie nawzajem roboty. Jak piszesz sam to wiesz co gdzie dałeś, ale jak jest np. 10 osób i każdy robi po swojemu to się prędzej czy później zaczyna robić bałagan.