Idealny projekt

1

Ludzie generalnie potrafią powiedzieć, że coś nie spełnia ich oczekiwań, że "to nie to", coś jest słabe, antywzorzec, kiepski kod, brak dokumentacji, "tak się nie robi" itd.
Dużo trudniej mówić o tym jak powinno być.

Czy macie swoje wymarzone/skonkretyzowane wizje jak powinna wyglądać "Misja: projekt X od jutra", tak żeby było "idealnie" i co to jest "idealnie" dla Was?
Sposób pracy, narzędzia, komunikacja?

1

wg mnie nie ma idealnego bo nawet 5 linijek kodu, które napisałem 30 minut temu teraz bym napisał "ładniej". Jest kod dobry i przyjemny i wg mnie to taki, który po pierwsze działa poprawnie a po drugie sam się opisuje i jeśli się go otworzy po roku przerwy, żeby dodać jakąś funkcjonalność to liczba WTF na godzinę wynosi 0

2
yarel napisał(a):

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ę):

  1. NIEZMIENNOŚĆ założeń projektu (w granicach rozsądku)
  2. nieskąpienie na narzędzia
  3. jasne wytyczne co do sposobu pisania kodu
  4. 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.

0

Miałem na myśli projekt z perspektywy jednostki, która do niego dołącza, zaś sam projekt może być na różnym etapie realizacji.
Ot, takie rzucenie na głęboką wodę. Niekoniecznie musi to być "część implementacyjna", czy projekt startujący "od 0".
Zgadzam się, że "ideał" to tylko etykietka i każdy może inaczej postrzegać. Wydaje mi się, że jakieś cechy wspólne powinny się jednak przewijać :)

Jak dla mnie "idealne" elementy:

  1. Zaangażowanie w przedsprzedaż. Nawet na zasadzie informacji/konsultacji, tak żeby być świadomym, że co się dzieje i hamować wodze fantazji sprzedawców odnośnie tego co się da, a czego się nie da.

  2. Ciągłość między kolejnymi fazami projektu (tak, żeby po fazie sprzedaży nie było pytań co w zasadzie trzeba dostarczyć)

  3. Wymagania projektowe - udokumentowane, tak by uniknąć tego o czym pisałeś, tj. "niezmienność założeń projektu". Wydaje mi się, że to stan naturalny, że ludzie dostrzegają z czasem różne detale, zależności, trudności i przekłada się to na zmianę założeń.

  4. Sposób pracy - Jak pracujemy między sobą, a jak z klientem. Do kogo zwrócić się z pytaniami dotyczącymi tematu X, tematu Y, ...
    Tak by nie stukać od drzwi do drzwi i może ktoś coś wie w temacie, albo jest w stanie udzielić wiążącej odpowiedzi, i tu kolejny punkt:

  5. Decyzyjność - decyzje podejmowane racjonalnie w oparciu o fakty i argumenty, a nie ad-hoc i motywowane aktualną sytuacją polityczną.
    Te dotyczące inwestycji w narzędzia, szkolenia jak i rozwiązanie.

  6. Co do organizacji procesu wytwórczego, to tu można dyskutować o wyższości jednego podejścia nad innym (czyt. metodyki bardziej sformalizowane i te "zwinne").
    Niezależnie od wyboru oczekiwałbym konsekwencji w podejściu.

3

Idealny projekt właśnie powstał:
https://github.com/kelseyhightower/nocode

1 użytkowników online, w tym zalogowanych: 0, gości: 1