Czysty kod - piszecie?

1

Cześć.

Oczywiste jest, że każdy z mądrych programistów stara się pisać czysty kod, jednak... czy udaje Wam isę taki kod pisać w pracy?

U mnie w pracy jestem nowy i czasami moi współpracownicy potrafią zabłysnąć intelektem, jednak czasami... ręce mi opadają.

  • Wchodzę w istniejący już projekt i facet nakazuje mi stworzyć metody statyczne działające na atrybutach klasy, na dodatek funkcje bardzo niebezpieczne, bo obsługujące logowania itp. rzeczy.
  • Chcę stworzyć diagram UML, facet podchodzi i pyta się: "Po co to robisz?".
  • Facet podchodzi i naciska mi spacje/tabulator/enter łamiąc zasady formatowania wprowadzone w kompilatorze.
  • Masa regionów w kodzie.
  • Brak testów w kodzie. Argumentacja: "Testy są fajne, ale zabierają czas" WTF!!!

Czy u Was w pracy to także norma?
Na co możecie narzekać u siebie firmie, a co możecie chwalić?

0

A co masz do regionów? Czy one przypadkiem nie polepszają czytelności?

Cóż... sprawa jest dość kontrowersyjna według mnie.

Dobre korzystanie z regionów faktycznie poprawia czytelność kodu, jednakże stosowanie regionów może być także użyte jako "chowanie śmieci pod dywan".

Funkcje 30 linijkowe gdzie 20 linijek daje się do regionu i myśli się, że jest fajnie. Takie coś według mnie nie poprawia czytelności, a jedynie ukrywa śmieci.

0

Wchodzę w istniejący już projekt i facet nakazuje mi stworzyć metody statyczne działające na atrybutach klasy, na dodatek funkcje bardzo niebezpieczne, bo obsługujące logowania itp. rzeczy.
Może źle go zrozumiałeś?

Chcę stworzyć diagram UML, facet podchodzi i pyta się: "Po co to robisz?".
Sam jestem ciekaw - po co. Używasz do tego jakiegoś programu, czy na kartce? IMO rysowanie formalnych diagramów jest po prostu stratą czasu.

Facet podchodzi i naciska mi spacje/tabulator/enter łamiąc zasady formatowania wprowadzone w kompilatorze.
chyba w IDE. Ale co? Ty sobie siedzisz i piszesz a tu włazi jakiś gość i Ci zaczyna nawalać w klawiaturę? Bo tego nie rozumiem.

Masa regionów w kodzie.
Nie widzę w tym nic złego. Może dlatego, że sam często korzystam z regionów.

Brak testów w kodzie. Argumentacja: "Testy są fajne, ale zabierają czas" WTF!!!
Pisanie testów niesie za sobą ogromne korzyści, ale dla osoby zarządzającej bez podłoża programistycznego mogą być zwyczajną stratą kasy.

Ze swojego niewielkiego doświadczenia wiem, że osoby nowe często próbują "zawładnąć światem" jednak przynajmniej na początku radziłbym stosować się do rad osób już wdrożonych w projekt.

0

Zacznę od końca :)

Ze swojego niewielkiego doświadczenia wiem, że osoby nowe często próbują "zawładnąć światem" jednak przynajmniej na początku radziłbym stosować się do rad osób już wdrożonych w projekt.

Dokładnie tak robię. Nie ma co udawać mądrtzejszego, w końcu ja nie jestem typem osoby, która pokazuje co to nie ona. Zwyczajnie w świecie kilka rzeczy mnie irytuje, jednakowoż zaznaczam, że sporo już nauczyłem się od tego programisty.
Krótko mówiąc ogólna moja opnia o pracy nie jest taka zła.

Może źle go zrozumiałeś?

Niestety - dobrze zrozumiałem :)
Dlaczego tak się stało? Bo pisali bez wczesniejszego projektowania w UML.

Sam jestem ciekaw - po co. Używasz do tego jakiegoś programu, czy na kartce? IMO rysowanie formalnych diagramów jest po prostu stratą czasu.

Nie zgadzam się. Projektowanie aplikacji w UML w specjalnie do tego stworzonym programie, jest nie tylko zaoszczędzeniem czasu (zaraz poiwiem czemu), ale także pozwala uniknąć błędów.
Zaoszczędzamy czas dzięki UML, gdyż aplikacja projektowana w odpowiednim oprogramowaniu, zostanie sama wygenerowana (szkielety klas itp.) plus uzyskamy ładny i możliwie bezbłędny projekt.
W rezultacie oszczędzamy pieniądze i czas (czyli też pieniądze).

Stworzyłem dużo projektów w swoim życiu i od czasu, gdy stosuję UML projekty są dużo łatwiejsze podczas modyfikacji i utrzymywaniu. Stąd moje zaskoczenie, gdy ktoś nie używa UML.

chyba w IDE. Ale co? Ty sobie siedzisz i piszesz a tu włazi jakiś gość i Ci zaczyna nawalać w klawiaturę? Bo tego nie rozumiem.

Nie. Podchodzi mówi: "Wiesz tutaj lepiej robić tak i tak". I ogólnie wcale źle nie mówi, jednakże skoro tak to nalezy ustalić takie zasady dla wszystkich i ustawić odpowiednie opcje w IDE.

Nie widzę w tym nic złego. Może dlatego, że sam często korzystam z regionów.

Opisałem wyżej w czym problem.

Pisanie testów niesie za sobą ogromne korzyści, ale dla osoby zarządzającej bez podłoża programistycznego mogą być zwyczajną stratą kasy.

Tam NIKT nie pisze testów :) A w dużej aplikacji brak testów wiadomo czym się kończy. Zresztą - mnóstwo tam jest zabugowanego kodu.

3

Brak testów w dużej aplikacji kończy się dużym zespołem testerów. Zwykle sporo większym od zespołu ludzi piszących kod. Ostatecznie nie przywiązuj się do takiego miejsca pracy bo albo ktoś Cię wyrzuci, albo samo zniknie. :)
Zdziwiłbyś się ile "poważnych firm" olewa testy, olewa refaktoryzację, a to jeszcze nic bo są znane w Polsce firmy, które olewają nawet dokumentację kodu.

1

Brak testów w dużej aplikacji kończy się dużym zespołem testerów. Zwykle sporo większym od zespołu ludzi piszących kod.
Większe projekty mają całe zespoły

  • projektantów
    – ludzi piszących nowe feature'y
    – piszących poprawki do tego co jest
    – piszących testy
  • testerów wykonujących te testy
  • piszących dokumentację
  • wymachujących batem
1

Generalnie jest różnie.

Parę razy miałem za PMa człowieka, który przywiązywał wagę do jakości kodu - było oficjalne formatowanie, raz na jakiś czas można było oberwać nawet za dziwną konstrukcję itp.
Ale zazwyczaj jest tak, że - szczególnie w korporacji - raczej nikt nie sprawdza poprawności kodu. Liczy się tylko liczba linijek wysłana do SVNa lub jakiegoś innego systemu wersjonowania. W rezultacie taki kod jest write-only, naprawa czyjegoś błędu - zwłaszcza naprawa błędu człowieka świeżo po studiach lub studenta - to koszmar. Jeśli na dodatek wchodzi się w taki projekt w środku, to rzeczywiście dobrze jest posłuchać jakiegoś lokalnego mędrca, który wie co jest źle zrobione.

0

W projekcie w którym jestem nikt wcześniej nie pisał zautomatyzowanych testów, licząc na testerów. Jakoś to się sprawdzało do momentu, gdy miałem rozbudować mechanizm synchronizacji danych z domeną. Operacja zawierała sporą ilość logiki i przetestowanie tego przez testera okazało się bardzo trudne jeśli nie niewykonalne. Aplikacja była wiele razy zwracana przez błędy. Wtedy się przekonałem do unit testów / testów integracyjnych.

Najgorzej jest jak trzeba zmienić jakieś fundamentalne mechanizmy. Przez to że aplikacja nie jest pokryta zautomatyzowanymi testami, to albo unika się panicznie takich zmian, albo gdy są już nie do uniknięcia, testerzy muszą wykonać solidne testy całości - czy z tej perspektywy niepisanie testów było oszczędnością czasu i pieniędzy ?
Testów nie należy jednak pisać tylko po to żeby były. Muszą być łatwe w utrzymaniu, czytelne i wiarygodne, ale to już osobny temat.

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