Jak sobie radzicie z "porządkiem w projekcie"?

0

tj w tytule
zastanawiam się jak sobie radzicie z porządkiem w swoich projektach?
chodzi mi np o styl pisania kodu, wcięcia, to że np wstrzykiwanie w polach piszecie inline, gdzie nawiasy, gdzie przerwy, naruszenia architektury i tak dalej..

co programista to inny styl pisania, a potem powstaje taki krzaczek który kijem strach dotknąć

pytam bo mam wrażenie, że sporo projektów na to cierpi, a stąd cierpimy my - programiści

0

U mnie w pracy bardzo na taki porządek zwracają uwagę, ale na razie nie znaleziono złotego środka. Każdy ma swoje przyzwyczajenia. My mamy ten komfort, ze zespół siedzi w 1 pokoju i jak coś na bieżąco możemy się ze sobą kontaktować.

0

o_O przeciez wystarczy programowac jakims normalnym IDE (a nie lodowka) i miec jasna konfiguracje formattera i wtedy to IDE dba o to zeby wszystko pasowalo.

0

Tak jak napisał @Shalom, plus, w miarę możliwości staram się, żeby moduły, pliki, metody, klasy były jak najmniejsze - jak coś jest za duże to rozdzielić - IDE sobie radzą z setkami plików...

3

Reguły formatowania w IDE- tak!, ale to rozwiązanie drugiego sortu :-).
Jak ma to działać to musi być sprawdzane w ramach buildu/CI(inaczej zawsze w końcu wychodzą wątpliwości). Dla javy można podpiąć np. checkstyle.
A jak to już jest - to dla wygody warto jakiś wspólny config / formattera dla IDE spreparować.

Przy okazji - jak już podepniemy Checkstyle, FindBugs, Sonar - mamy już wszystko tak porządnie sprawdzane, że prawie nie da się pisać : jest ekstra (mniej kodu -> mniej błędów).

0

Jak to robię w C++ (podobne rozwiązania można zastosować w dowolnym języku)

  • Plik .clang-format który zawiera zasady tego jak kod ma być formatowany.
  • Git hook w repo po stronie usera który weryfikuje czy kod jest dobrze sformatowany. Jeśli ktoś ma taką możliwość to taki git hook można zamontować po stronie serwera.
  • Skrypt który sformatuje kod źródłowy
  • CI (Jenkins, Travis, cokolwiek) może również weryfikować styl kodu

Co do sprawdzenia architektury jest również tool clang-tidy i również da się to oskryptować (plik .clang-tidy, git hook, dodatkowe skrypty) żeby weryfikować takie rzeczy jak nazewnictwo zmiennych, nie używanie starych konstrukcji, czy tych nieoptymalnych.

Ja bym odradził poleganie na IDE do robienia formatowania bo każdy ma swoje preferencje co edytora.

0

W JS się to rozwiązuje za pomocą linterów (np. ESLint), gdzie masz odpowiednie reguły i wszystko można sobie zautomatyzować. Ponadto ESLint pokazuje również różne błędy oraz potencjalne błędy (wszystko można skonfigurować).

Dzięki temu jak ktoś napisze nie tak jak jest ustalone w linterze, to wychodzi błąd (w zależności od systemu pracy w zespole takie błędy mogą być też podłączone pod np. git hooks przy commicie, albo pod CI na serwerze - co będzie skutkować tym, że jak spushujesz coś ze złym formatowaniem to build nie będzie przechodził)

chodzi mi np o styl pisania kodu,

jeśli chodzi o sam styl (wybrany przeze mnie), to ja się staram przyjmować modne wzorce. Np. jeszcze niedawno pisałem tak restructuring w ES6:

const {item} = props;

zobaczyłem jednak w kodach, że bardziej modnie jest tak pisać

const { item } = props; 

więc tak zacząłem pisać (dodatkowa spacja zwiększa czytelność, no i tak jest modniej z tego co widziałem w różnych projektach, a jeśli chodzi o formatowanie to moim zdaniem opłaca się być trochę konformistą, niż się trzymać kurczowo własnego stylu - pisząc podobnie jak inni zarówno ułatwiasz zrozumienie kodu przez innych, jak i sam lepiej rozumiesz kody innych, skoro piszą podobnie).

3
jarekr000000 napisał(a):

Przy okazji - jak już podepniemy Checkstyle, FindBugs, Sonar - mamy już wszystko tak porządnie sprawdzane, że prawie nie da się pisać : jest ekstra (mniej kodu -> mniej błędów).

No właśnie, a potem nie możesz sobie na chwilę zakomentować kawałka kodu albo postawić dwóch enterów pod rząd czy zadeklarować jakiejś zmiennej, bo Ci kompilacja nie pozwala.

Żadnego gówna utrudniającego kompilowanie lokalnie. Wystarczy np. Sonar, który po buildzie znajdzie nowe problemy i wyśle kompromitującego maila do całego teamu.

2

Styl stawiania klamerek czy wielkość funkcji ma mniejsze znaczenie niż to czy projekt jest sensownie przemyślany, a tego niestety żaden linter nie sprawdzi.

Z drugiej strony jeśli projekt jest porządnie przemyślany na poziomie architektonicznym, to znacznie trudniej spaprać kod. Jeśli programiści potrafią sensownie zaprojektować coś, to zwykle potrafią też to ładnie napisać. Jeśli w projekcie siedzą sensowni programiści, to nie muszą mieć niani aby pokazywała im jak układać zabawki na półce.

Zauważam wyraźną korelację między nieporządkiem na niskim poziomie (np. niekonsekwentne stawianie tych klamerek), a nieporządkiem na wysokim poziomie (np. bałaganiarski podział na moduły / pakiety, niejasne / ukryte zależności między modułami, źle przemyślany schemat bazy, brak dyscypliny na poziomie semantyki - nieostre / niejasne pojęcia, często źle nazwane).

Odpowiadając na pytanie tytułowe: po prostu dbamy o porządek. Staramy się pozostawić kod lepszym niż go zastaliśmy. Zawsze recenzujemy kod. Często poprawiamy / upraszczamy kod, nawet jeśli działa. Nie używamy jednak żadnych narzędzi automatycznych poza najbardziej przyziemnymi wymuszającymi np. obecność odpowiednich nagłówków licencji (copyright), wymaganymi przez dział prawny ;)

0

styl pisania kodu, wcięcia, to że np wstrzykiwanie w polach piszecie inline, gdzie nawiasy, gdzie przerwy,

linter

naruszenia architektury i tak dalej...

code review

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