Gdy szef każe pisać wbrew naukom Wujka Boba.

Szef mówi mi, m.in. że:

1. funkcje powinienem pisać tak jak on na 50 - 100 linijek i tworzyć osobną funkcję tylko jeśli coś użyję gdzieś indziej (do innego problemu). Uważa, że zagnieżdżenia są złe i każda funkcja powinna być płaska. Jego funkcje robią 5 rzeczy np.: wyliczają coś, przekształcają coś, pobierają, zapisują, zapisują logi do bazy. Czepia się, mnie że piszę zbyt małe funkcje. Moje funkcje robią po 1 rzeczy: 1 na wyliczanie, jedna na przeksztalcenie, jedna na pobieranie, jedna na zapis, inna na zapis logów do bazy itd.

2. jak potrzebuję fragmentu kodu z jego 50 linijkowej funkcji to nie powinienem tworzyć osobnej funkcji na ten frafment i użyć w obu miejscach wywołania funkcji tylko powinienem przekopiować ten fragment kodu który chce użyć do swojego skryptu.

3. piszę za dużo funkcji np.:
   była funkcja, która robiła coś takiego:

foo <- function(myDate, daysAdd = 10) {
  fromDate <- myDate - daysAdd
  toDate <- myDate + daysAdd
  #
# odtąd leci kod
# ...
}

uznałem, że lepiej będzie mi tym sterować jak zrobię funkcję taką o:

fooNew <- function(fromDate, toDate) {
  #
# odtąd leci kod
# ...
}

a żeby działało to jego poprzednie dorobiłem:

foo <- function(fromDate, toDate) {
  fromDate <- myDate - daysAdd
  toDate <- myDate + daysAdd
  fooNew (fromDate, toDate)
}

to kazał mi wyciąć ten fooNew, bo po co tak dużo pisać.

Co byście zrobili na moim miejscu?

Pewnie bym próbował przekonać, ale koniec końców to on jednak Ci płaci i jeśli chce, abyś pisał w jakiś konkretny sposób, to trzeba się tego trzymać ;-)

Zwolnij go ;)

Już to przerabiałem na początku kariery. Uciekaj jak najszybciej - każdy dzień to dzień stracony na kopanie się z koniem.
Wyznawcy kupy - paste się nie przeskoczy.

Ostatni gasi światło.

Pamiętam żelazną logikę kupistów: jak masz kod w jednej funkcji wiele razy użytej to jak coś zmienisz (i zrobisz błąd) to potem się wywali w 100 miejscach. Jak masz błąd w copy paste to możesz zawsze tylko ten jeden fragment kodu spokojnie zmieniać - wywali się tylko jeden kawałek :)

Na ten argument miałem co prawda kontrę, że przecież nie robimy błędów, bo mamy zabronione ( projekt managier wydał taki zakaz). Ale nie przekonałem :/

Ja w poprzedniej pracy mówiłem że stosujemy nadmiar dziedziczenia (tzn. uwazam że czasami dziedziczenie jest dobre, ale bardzo rzadko) i lepiej stosowac kompozycje to jeden z najbardziej odpowiedzielnych developerów powiedział że kompozycja ogranicza tak samo jak dziedziczenie. Wspominalem o tym żeby stosowac niemutowalne DTOsy, to zaczeli mnie dla beki nazywać "Immutable Man" a ja mam to w dupie, ich strata. Będa się grzebac w jakimś gównie a ja mam czyste sumienie

Dowiedz się dlaczego każe Ci pisać w taki sposób: z racjonalnego (i.e. rzeczywiście myśli że to jego sposób sprawi że końcowy produkt będzie lepszy) czy z emocjonalnego (i.e. boi się zmian, chce uchować swój autorytet, ...) powodu?
Poza tym, co leży w obowiązkach tego 'szefa'? To liniowy? Czy on rzeczywiście koduje?

Ja w sumie też tak kiedyś miałem, że wolałem mieć kod całego procesu/algorytmu w jednym miejscu, żeby przy śledzeniu działania nie skakać po funkcjach i innych klasach. Np. mamy buble sort, to po kiego pisać jakąś tam funkcję swap itp., skoro "można" to zrobić w pętli + komentarz :D

Także, rozumiem, że ktoś bez doświadczenia takie coś robi i nikt od niego nie wymaga zmiany nawyków (bo to szef) - przecież dlatego założył własną firmę, bo nikt by go nie przyjął z takimi przekonaniami :D

Szef mówi mi, m.in. że:

Kim jest "szef"? Jeśli przez szefa masz na myśli jakiegoś PMa, czy kogoś innego, bardziej biznesowego, to nie rozumiem, czemu ingeruje w to, co piszesz, i że w ogóle ma czas na to.

Chyba, że "szef" to lead developer, senior, czy po prostu programista z zespołu, który lubi się rządzić i szefować, to jeszcze rozumiem, że próbuje coś narzucić. Ale z drugiej strony czy to faktycznie twój oficjalny przełożony? Czy odpowiadasz przed nim i czy musisz się go faktycznie słuchać? Niektórzy ludzie się rzucają i szefują, nawet jeśli nie mają realnego wpływu.

Jego funkcje robią 5 rzeczy np.: wyliczają coś, przekształcają coś, pobierają, zapisują, zapisują logi do bazy.
Czepia się, mnie że piszę zbyt małe funkcje.

Dobra, doczytałem tutaj i widzę już, że dałem się wkręcić. Przecież to brzmi jak jakaś pasta z Wykopu o programistach...
Coś jak "Mój szef jest wielbicielem dużych funkcji".

Nie ma tam innych programistów? Jeśli są, to też piszą po "szefowemu"?

somekind napisał(a):

Nie ma tam innych programistów? Jeśli są, to też piszą po "szefowemu"?

piszą tak jak szef, z tą różnicą, że szef przynajmniej pisze przejrzyście - patrzysz i widzisz o co chodzi, a reszta gmatwa i zagnieżdża ify.

No, ale i tak jest lepiej niż w poprzedniej pracy, gdzie kod pisali doktoranci matematyki. Funkcje mające po kilka tysięcy linijek i nieużywanie pakietów tylko odkrywanie koła na nowo.

A jak wyglądają unit testy do tych funkcji co robią pięć rzeczy na raz? Możesz szefowi powiedzieć że małe funkcje się łatwiej testuje ;)

@Julian_: ja bym tam wstal wyprostowal sie, strzelil kosciami i powiedzial ze ma prawo miec inne zdanie, jest juz dorosly i moze popelniac bledy kiedy chce, ale niech mi nie kaze tego robic skoro moje rozwiazanie dziala (u mnie w projekcie pare osob tak pisze - tyle ze ich kod dziala i robia to szybko wiec moge z tym zyc (jedyny problem jak sa na urlopie i mam jakis blad w ich kodzie znalezc :))). Zreszta nie masz tak zle - metoda do 100 linijek jest jeszcze do ogarniecia.

@Julian_: dobrze myślisz z tą funkcją / lambdą fooNew (R?).
To co opisałeś to najprostszy refaktoring typu proceduralnego. Nawet człowiek który zna tylko C lub Pascala powinien go zrozumieć.

Ja myślę, że tu nie kod jest problemem tylko ten człowiek - Twój szef.
Jest masa ludzi którym się wydaje że już wszystko umieją po 5 latach pracy (sam byłem w tym miejscu). I nie przetłumaczysz im niczego "nowego".
Jeśli to osoba która ma ponad 40 lat to nie liczyłbym na jego (pozytywną) zmianę.
Daj sobie rok na oddolną poprawę sytuacji w firmie i w tym czasie się rozwijaj. A jak nic się nie poprawi to zmiataj stamtąd.

"Pisałbym po swojemu" - można próbować, ale może się skończyć tym że Ciebie wywalą, na Twoim kodzie zrobią refucktoring a potem będą sobie jeszcze robić jaja między sobą że mieli w zespole gościa który chciał pisać po książkowemu.

Znacie jakieś książki/dobre artykuły o tym jak ma wyglądać paradygmat programowania funkcyjnego?

żeby przesłać szefowi jak znów coś wymyśli dziwnego. (poza clean code)

moja rada, po prostu zmień pracę :)

Ja w pracy ostatnio trafiłem na niezły pasztet. Algorytm pewnych przeliczeń dla różnych grup użytkowników i wielu parametrów rozwleczony na ifowisku o rozpietości ponad 1k linii + odwołania do innych metod. I weź coś zmieniaj w algorytmie jak dochodzi do określanie zmiennych jako "w" lub inne skróty...

Edit : powoli szukam nowej pracy bo większość kolegów w pracy nie widzi w takim postępowaniu nic złego. A mają po ok. 8 lat doświadczenia. ;-)

Ja zauważyłem, że z każdą zmianą pracy trafiam na gorszy kod, więc bądź ostrożny :)

Mały Ogrodnik napisał(a):

Ja zauważyłem, że z każdą zmianą pracy trafiam na gorszy kod, więc bądź ostrożny :)

Być może dlatego że czasy gdy do tej pracy zatrudniano tylko inżynierów minęły a ci co byli powoli odchodzą na dobre z IT?
Jak wytłumaczyć komuś zasady "Clean Code" jeśli nie ma za sobą co najmniej 10 tys. linii kodu?
Pomyśli sobie że jesteś ekstremistą, albo że to fajna idea i tyle.

kurde od stażysty wymaga sie clean codów,testów i innych dupereli i po co jak regularzy/ seniorzy piszą taka kaszanke.

Julian_ napisał(a):

to kazał mi wyciąć ten fooNew, bo po co tak dużo pisać.

Co byście zrobili na moim miejscu?

Oczekujesz rzeczy niemożliwych, czyli pisania czystego i wydajnego kodu w branży data science. To tak jakby oczekiwać, że byk nam sie ocieli;) Duża część analityków danych nie ukończyła informatyki, a raczej studia związane z socjologią, statystyką czy fizyką i inne STEM. Osobiście znam tylko jedną osobę, która ma background programistyczny i zajmuję się data science.

Rozwiązaniem dla ciebie może być znalezienie nowej pracy, gdzie spektrum specjalizacji jest większe i osoby w zespole pomagają sobie nawzajem dbać o kod, a nie robi tego szef (mimo, że ma dobre intencje).

Pytanie czy on faktycznie na to zwraca uwagę czy tylko Ty dopytujesz się jak to ma wyglądać. Bo jeśli on na to nie patrzy, a ty nie możesz zdecydować czy pisać tak jak on chce czy po swojemu to ja osobiście miałbym to w dupie.

Dodaj w ankiecie łączoną odpowiedź. Ja próbowałem przekonać szefa i kolegów (nie za bardzo się to udało), teraz piszę po swojemu i mam w dupie plus będę szukał nowej pracy. ;-)

Co do pisania po swojemu: It is often easier to ask for forgiveness than to ask for permission. It is often easier to ask for forgiveness than to ask for permission. Sami znajdźcie kto to powiedział i kiedy. IMO działa.

Jeśli odpada możliwość sprzeciwu to zostaje ostatni wspólny mianownik - czy rekompensata za utratę zdrowia jest wystarczająca. Ostatecznie w pracy zespołowej i tak wcześniej czy później musisz zrobić coś przeciwko sobie - a wtedy patrz wyżej ;)

Pytanie co Ciebie motywuje aby stosować SOLID.
Czy chcesz tworzyć mniej kosztowne i problematyczne oprogramowanie... czy też może kieruje Tobą ego, potrzeba udowodnia twojej wyższości nad innymi członkami zespołu?

Jeżeli zależy ci na poprawieniu jakości oprogramowania, które tworzy twoja firma, to może powinieneś zamiast tego pogadać z szefem i uzasadnić dlaczego tak robisz, co nie powinno być problemem, jeżeli naprawdę wiesz na czym polega SOLID.
Zrobić meeting na ten temat i tak dalej...

Fantazjatyk napisał(a):

Pytanie co Ciebie motywuje aby stosować SOLID.
Czy chcesz tworzyć mniej kosztowne i problematyczne oprogramowanie... czy też może kieruje Tobą ego, potrzeba udowodnia twojej wyższości nad innymi członkami zespołu?

Jeżeli zależy ci na poprawieniu jakości oprogramowania, które tworzy twoja firma, to może powinieneś zamiast tego pogadać z szefem i uzasadnić dlaczego tak robisz, co nie powinno być problemem, jeżeli naprawdę wiesz na czym polega SOLID.
Zrobić meeting na ten temat i tak dalej...

SOLID to raczej do obiektowego... ja chcę pisać zgodnie z paradygmatem funkcyjnym, bo sprawia mi przyjemność. A klepanie g.* nie sprawia mi przyjemności.

Julian_ napisał(a):

Uważa, że zagnieżdżenia są złe i każda funkcja powinna być płaska.

No to akurat pod tym względem ma sporo racji. Duża liczba zagnieżdżeń nie świadczy dobrze o kodzie (wysoka złożoność cyklomatyczna).