Wybierz wysiłek związany z projektowaniem kodu lub lenistwo w świecie Banku

23

Przez dwa lata pracowałem w wielkim banku inwestycyjnym.

Zrobiłem kilka projektów technicznych z myślą o stworzeniu kodu najbardziej zoptymalizowanego, z poszanowaniem dostosowanych dobrych wzorców projektowych, zasady SOLID, prawa demeter i unikając wszelkiego rodzaju duplikatów kodów ...

Kiedy dostawa w produkcji => zero błędów, wszystko stało się zgodnie z oczekiwaniami.

Ale większość programistów przyszła do mnie, aby sprecyzować, że cały mój kod jest zbyt skomplikowany, by czytać ze zrozumieniem. Słuchałem na przykład: „zrób trochę if i instanceof, zapomnij o polimorfizmie, aby bardzo łatwo było naprawić błędy związane z produkcją awaryjną”. Nie wolałem odpowiadać ......

Wiedząc, że ci programiści wcale nie są ciekawi, odmawiają wysiłków na rzecz zrozumienia dobrego projektu (na przykład 90% programistów nie wie, co to jest wzorzec strategii i tworzy kod proceduralny, a nigdy nie projektuje, ponieważ chcą, jak mówili, prostoty ), moi kierownicy projektów powiedzieli mi, że naprawdę jestem w niewłaściwy sposób i zbyt idealistyczny dla świata Banku.

Co byś mi doradził? Czy powinienem nadal pragnąć naprawdę dobrego kodu lub przystosować mnie do większości programistów, którzy, powtarzam, naprawdę nie interesują się kodem projektowym, który według mnie stanowi całe piękno naszej pracy programistycznej.

Czy wręcz przeciwnie, czy powinni nauczyć się podstawowych zasad i najlepszych praktyk OO, aby dostosować się do mojego kodu?

Mik378
źródło
19
Trudno jest szybować jak orzeł, gdy pracujesz z indykami ;-)
JonnyBoats
8
Zmień organizację lub zmień organizację. - Martin Fowler
Don Roby
9
@ Mik378 Możesz mieć problem z komunikacją. Jeśli dokumentujesz swój kod tak niechlujnie, jak napisałeś to pytanie (a im więcej „cruft” OO, tym więcej potrzebujesz dokumentacji, aby ludzie wiedzieli, co ITradeSettlementVisitorpowinien zrobić ten interfejs), twoi rówieśnicy mają prawo narzekać. Jedną rzeczą jest napisanie pięknego kodu, który ci się podoba, a drugą strukturą i udokumentowaniem go w taki sposób, aby był dostępny i użyteczny dla innych.
quant_dev
2
@quant_dev: Myślę, że zakładasz trochę za dużo na temat Mik378. Jego pytanie nie wydaje mi się źle sformułowane; on po prostu nie jest native speakerem. Nie lubię gadatliwości i nadindywidualizowanego projektowania w OO tak bardzo, jak się wydaje, ale sytuacja opisana przez Mik378 również dzwoni: pracowałem ze zbyt dużą liczbą programistów, którzy nie mogliby zrozumieć prostych rzeczy, takich jak wyrażenia boolowskie (więc mogliby napisz „jeśli (exp) to True else False”) ... Jest prawdopodobne, że tego rodzaju ludzie byliby przerażeni wzorami projektowymi, polimorfizmem i dlatego powróciliby do zwykłego starego kodu proceduralnego.
Andres F.,
2
Zdecydowanie nie zgadzam się z tym, że utrzymywanie prostego i łatwego w utrzymaniu kodu dla współpracowników jest leniwe, jak podano w tytule.

Odpowiedzi:

20

moi kierownicy projektów powiedzieli mi, że naprawdę jestem w niewłaściwy sposób i zbyt idealistyczny dla świata Banku.

GTFO!

Czas odejść i współczuć im. Dlaczego warto się pieprzyć? Wiesz, że na dłuższą metę będzie ich kosztować ich niekompetentny personel. To nie jest gra dyskusji technicznych. Chodzi o politykę. Niech szkolą innych programistów lub GTFO! Jeśli nie masz wystarczającej siły politycznej, to GTFO! Wyszukaj firmę z lepszymi praktykami.

Jedynym powodem do pozostania tam jest odpowiednia rekompensata za bóle głowy. Więc lepiej zapłacić znacznie powyżej średniej lub GTFO! Wątpię, czy możesz się tam również rozwijać jako programista. Wzrost w naszym zawodzie osiągany jest głównie dzięki pracy z ludźmi lepszymi od ciebie i zachęcającymi do najlepszych praktyk. Im lepszy jesteś, tym wyższa jest twoja wartość rynkowa dla firm, którym zależy.

Tak, wiem, że to nie jest jedna z moich zwykłych odpowiedzi, ale naprawdę, jeśli nie możesz grać w grę polityczną w tej firmie, GTFO.

Co byś mi doradził? Czy powinienem nadal pragnąć naprawdę dobrego kodu lub przystosować mnie do większości programistów, którzy, powtarzam, naprawdę nie interesują się kodem projektowym, który według mnie stanowi całe piękno naszej pracy programistycznej.

Nie pracowałbym dla firmy, która chce, żebym zapewniał nieoptymalne rozwiązania. Chcę wyryć moje imię w oprogramowaniu. Chcę być z tego dumny. Nie piszę aplikacji proceduralnych w językach opartych na paradygmacie OO. Wierzę w oprogramowanie wysokiej jakości, a jeśli firma tego nie zrobi, GTFO! Mam nadzieję, że masz dość „pieprzyć cię z pieniędzy”.

Sokół
źródło
4
+1 - Kiedyś przyszło mi do głowy, czym jest GTFO ... ( urbandictionary.com/define.php?term=gtfo )
Reddog
2
@ Falcon Całkowicie się z tobą zgadzam i z przyjemnością znajduję ludzi, którzy podzielają mój pomysł; a zwłaszcza, gdy mówisz: „Wzrost w naszym zawodzie osiągany jest głównie dzięki pracy z ludźmi lepszymi od ciebie i zachęcającymi do najlepszych praktyk”. Najbardziej niesamowite i naprawdę frustrujące jest to, że jestem młodszym programistą i tak naprawdę nie nauczyłem się od starszych. Dzięki za odpowiedź :)
Mik378,
+1, całkowicie się zgadzam. Ten bank po prostu nie wydaje się dobrym środowiskiem pracy, a jego problemy wydają się nie do pokonania: zli programiści, złe zarządzanie. GTFO rzeczywiście!
Andres F.,
2
@ Mik378: Twój obecny pracodawca nie jest w stanie w pełni wykorzystać twoich umiejętności, w związku z czym nie będzie w stanie zapłacić ci tego, co jesteś wart. Lepsza organizacja będzie w stanie uzyskać od ciebie większą wartość i może zapłacić więcej.
kevin cline
+1, jeśli mógłbym dać ci więcej głosów pozytywnych, dostałbyś ode mnie 1000. Pracując sam w banku inwestycyjnym, wiem dokładnie, z czym ma do czynienia Mik378. Jest to wylęgarnia toksycznych zachowań, osób reagujących na polaryzację i egomanii. Nie jest to środowisko pomysłów do promowania doskonałości technicznej.
Desolate Planet
18

Twarde miejsce. Myślę, że możesz iść na dwa sposoby równolegle, utrzymując swój punkt widzenia i wykazując wolę kompromisu:

  • Chodzi o pieniądze. Jak każda praca deweloperska, ale skoro kładziesz nacisk na środowisko bankowe, powinno to działać jeszcze lepiej;). Pokaż im, że Twój styl oszczędza pieniądze. Znajdź przykład, w jaki sposób zmiana wymagań może być dokonana naprawdę łatwo dzięki Twojemu projektowi. Spróbuj znaleźć kawałek innego kodu (musisz upewnić się, że nie jesteś tu zbyt agresywny, ale hej, chodzi o porównanie stylów kodu), który jest podatny na złamanie, i pokaż im, jak nie musisz dbaj o takie problemy, ponieważ Twój kod ma lepszą jakość na początek.

  • Chodzi o pieniądze. Co jeśli twój styl kodowania faktycznie kosztuje? Może się to przydać, jeśli inni ludzie spędzą więcej czasu próbując zrozumieć Twój kod, niż to, co jest zapisywane przez odpowiedni projekt. Być może postępujesz właściwie technicznie i nadal nie przyczyniasz się pozytywnie do wysiłku zespołu. Możliwe jest również przesadzenie projektowania OOP. Jestem z tobą po stronie „dobry design jest piękny”, ale staram się cię tutaj uświadomić o ich punkcie widzenia i tym, jak mogą być właściwie z ich perspektywy. Równolegle do poprzedniego punktu spróbuj znaleźć miejsce, w którym go przesadziłeś. To daje ci pole manewru: możesz powiedzieć, ok, mogę być bardziej pragmatyczny tu i tam, ale spójrz, są też miejsca, w których ten kod jest naprawdę lepszy.

Nicolas78
źródło
Dziękuję za rozwiniętą odpowiedź.
Zanotowałem
Dodam do tego prosty problem FizzBuzz. Napisz to w Javie, a następnie zrób to ponownie w sposób TDD, nagle stanie się nieczytelny, prawda ;-).
Martijn Verburg
@Martijn Verburg - Czy uważasz, że TDD prowadzi do nieczytelnego kodu?
Don Roby
@Don Roby - czasami tak, szczególnie gdy ma się do czynienia z czymś takim jak FizzBuzz w języku OO
Martijn Verburg,
+1 @ Nicolas78 „Możliwe jest również przesadzanie projektowania OOP” - np. Tworzenie prymitywnych typów danych Obiekty takie jak na przykład int.
therobyouknow
16

Ale większość programistów przyszła do mnie, aby sprecyzować, że cały mój kod jest zbyt skomplikowany, by czytać ze zrozumieniem

Czy w ogóle przyszło ci do głowy, że mogą mieć rację?

Pracowałem z kimś, kto włożył wiele wysiłku w pisanie kodu, który opisał jako elegancki. Spędził dużo czasu, potępiając pracę innych ludzi jako nie elegancką. Jeśli konieczne jest utrzymanie kodu, jego kod nie jest kodem, który chciałbym zmodyfikować. Jest tak precyzyjny i wymagający, że jego zmiana jest głęboko obarczona niebezpieczeństwem.

Interesujące słowo, o którym tu wspominasz, to „złożone”. Kod, który można określić jako złożony, rzadko można również opisać jako szczególnie dobry.

kuszenie
źródło
1
+1000 Zgadzam się. Kod jest dla ludzi. Zastrzeżeniem jest oczywiście to, że inni koderzy powinni być w stanie odczytać to, co pisze większość koderów. Każdy, kto nie rozumie podstaw, powinien zostać ulepszony.
Iain Holder
3
+1 @temptar za „Czy w ogóle przyszło ci do głowy, że mogą mieć rację?” oraz „Kod, który można opisać jako złożony, rzadko można też opisać jako szczególnie dobry”.
therobyouknow
2
-1: Nie sądzę, że mają rację, są trochę starsi i myślę, że bliższa lektura pytania czyni to oczywistym. Kluczową frazą PO jest „unikanie wszelkiego rodzaju zduplikowanych kodów ...” Próbuje WYSUSIĆ kod, ale wymaga to wyrafinowania, którego najwyraźniej brakuje jego kolegom. Zacytował również sugestie swoich kolegów, aby „po prostu dodać if ... instanceof”. To także mówi mi, że OP jest na dobrej drodze, a jego koledzy budują dużą WTF.
kevin cline
martwi mnie to, że OOP „Too Complex” może być dobrą rzeczą, ale może również bardzo szybko się skomplikować. Podejrzewam, że oryginalny plakat wypił fajną pomoc OOP i nie zrozumiał, że nie zawsze jest to najlepszy sposób na kodowanie i że może wprowadzać wiele dodatkowych problemów, gdy nie jest to potrzebne.
Zachary K
Wygląda na to, że ten twój współpracownik nie ma przygotowanych testów do przyszłej konserwacji. Być może będziesz chciał porozmawiać o tym z kierownikiem projektu.
10

Producenci mebli z epoki wiktoriańskiej (a przynajmniej ci, których prace wciąż widzimy do dzisiaj) byli prawdziwymi rzemieślnikami, a ich wykonanie było funkcjonalne, piękne, dobrze wykonane, zaprojektowane i zbudowane do końca życia. Jednak w ciągu ostatnich 150 lat świat się zmienił. Niewiele osób jest gotowych zapłacić za takie kunszt, gdy tańsze alternatywy są bardziej komercyjnie pragmatyczne przy zakupie stołu w jadalni.

Wielu programistów chce być rzemieślnikami dawnych lat, niestety handel dyktuje, że nie zawsze tak się dzieje. Masz wybór, dostosuj się lub odejdź. Są firmy, które chcą rzemieślników, ale są znacznie liczniejsze od tych, którzy chcą produktów, które w większości działają, są tanie i teraz.

Wskazówka dla mnie, że nie nadajesz się do tworzenia większości komercyjnych programów, brzmi „Przy dostawie w produkcji => zero błędów”. Nawet Nasa nie osiągnął tego dzięki promom kosmicznym.

Jedynymi miejscami, w których zwracasz uwagę na szczegóły, a zatem i koszty początkowe, są prawdopodobnie akceptowalne, są systemy krytyczne dla życia na poziomie 1 - np. Awionika / lotnictwo, motoryzacja, wojsko i medycyna.

mattnz
źródło
1
+1 @mattnz za „Masz wybór, dostosuj się lub odejdź”
therobyouknow
2
Nie zgadzam się - to bank . Zwykle podoba im się, że w ich oprogramowaniu nie ma błędów, ponieważ błędy mogą rosnąć dość drogo. Rozwiązania mogą również działać przez lata lub dekady.
2

Problem polega na tym, że pracujesz w niewłaściwym miejscu. Wygląda na to, że jesteś bardzo naukowym programistą. Nie poradzisz sobie dobrze w środowisku, w którym się znajdujesz, i jest całkiem prawdopodobne, że wymyślą jakieś wymówki, aby pozbyć się ciebie i twojego „zbyt złożonego” kodu. Możesz otrzymywać zadania śmieciowe i / lub słabe oceny wyników i tak dalej, dopóki sam nie wyjdziesz lub nie znajdą wystarczającej ilości papieru na tylnej stronie, by cię zwolnić.

Polecam znaleźć miejsce do pracy, które będzie cenić twoje akademickie skłonności. Są tam. Znajdziesz także takie, które stoją na granicy między pragmatycznym i akademickim. Taka praca może być najlepszą opcją, ponieważ pozwoli ci zaprosić chaos do swojego podejścia, gdy pomagasz innym w opanowaniu ich.

jfrankcarr
źródło
+1 @jfrankcarr za sprytne spostrzeżenie, że „można nadać śmieciowe zadania” (forma konstruktywnego zwolnienia)
therobyouknow
2

Przed podjęciem tak drastycznych kroków, jak zmiana pracodawcy, postaram się poprawić twoją własną zdolność wyjaśniania nieprogramiści, takim jak wy, kadry kierowniczej, dlaczego twój sposób kodowania jest lepszy dla firmy, i oszczędzam im czas i pieniądze. Upewnij się także, że nie zastosowałeś wzorców projektowych tylko ze względu na wzorce projektowe - czy na pewno przestrzegałeś również zasad KISS i YAGNI? (Ok, wzorzec strategii i polimorfizm nie są naukami o rakietach, daj swoim kolegom trochę czasu na dostosowanie się i wyjaśnienie, dlaczego wybrałeś takie podejście)

Doktor Brown
źródło
Zgadzam się, problem polega na tym, że nie chcą się uczyć, nie chcą zmieniać mentalności (nie jestem geniuszem w Javie, ale kiedy nie rozumiem czegoś, co większość ludzi uważa za doskonałą rzecz do wiem, dołożę starań, aby się tego nauczyć (książki, artykuły internetowe, stackoverflow itp.) Podsumowując, nie chcą mieć bólu głowy ze wzorami (mówię wzór, ale mógłbym powiedzieć „doskonała” zasada programowania więcej ogólnie), które nie przynoszą im dużo więcej pieniędzy ... Trudno to powiedzieć, ale to prawda. Gdyby tylko aplikacja działała dobrze => Z pewnością nie napisałbym tego tematu
Mik378,
@ Mik378: dużo mówisz o tym, co „inni robią źle”. Pewność, że wszystko Ci nie miał rację?
Doc Brown
Polimorfizm @DocBrown ma wyraźną wadę polegającą na fragmentacji logiki między plikami, w których proste wystąpienie utrzymuje ją w jednej metodzie. Być może jednostki robocze są zbyt małe?
2

W mojej firmie przeprowadziliśmy serię warsztatów opartych na Clean Code Developer . Celem było stworzenie forum poza normalnym codziennym biznesem z jego gorączką, terminami i paskudnymi kompromisami, w którym programiści mogliby poznać zasady projektowania oprogramowania (jak wspomniano), techniki programowania itp. Oraz zastanowić się nad swoimi projektami i ich własna praca.

Omówiono także przykłady z rzeczywistych projektów. Informacje zwrotne od uczestników były bardzo pozytywne. Trudno jednak zmierzyć rzeczywistą korzyść.

Uczestnictwo w tych warsztatach dotyczyło częściowo czasu sponsorowanego przez firmę, a częściowo wolnego czasu uczestników. Nie dotrzesz do tych kolegów, którzy nie dbają o naukę i po prostu chcą wykonać swoją pracę i wrócić do domu, ale dla każdego, kto interesuje się własną pracą, może to być interesujące.

Robert Petermeier
źródło
Bardzo podoba mi się ten pomysł.
temptar
2

Przede wszystkim sprawdziłbym, czy twoja droga jest naprawdę lepsza. Kod zorientowany obiektowo może być bardzo fajny, ale może też być koszmarem ukrytych efektów ubocznych, a każda akcja może wymagać kilku różnych klas.

Jeszcze lepiej przejdź do InfoQ i obejrzyj wykład Richa Hickeya na temat „Simple Made Easy”

Zachary K.
źródło
1

Będziesz musiał się trochę poddać, jeśli chcesz kontynuować pracę bez ciągłych zmagań. Grupa programistów, która jest w całości proceduralna, nie zaakceptuje od razu polimorfizmu. Chociaż mogą nie być w stanie zaprojektować w sposób OO, mogą uczyć się na podstawie Twojego kodu. Mogą docenić fakt, że niektóre z was kodu są łatwiejsze w utrzymaniu.

Na marginesie, musisz zadać pytania podczas procesu wywiadu, aby zobaczyć, jaki proces rozwoju i metodologia kodowania jest stosowana, jeśli uważasz, że ważne jest dopasowanie do twoich preferencji.

JeffO
źródło
0

Zdarzają się sytuacje awaryjne. Nie jesteś doskonały i ich ręce będą zepsuć swój kod w pewnym momencie. To, chyba że nigdy nie weźmiesz wolnego, co, jak potwierdzi twój lekarz ogólny, nie jest dobre dla twojego zdrowia. I prowadzi to do większych szans na wyemitowanie złego kodu.

Twój kod może mieć wyższą jakość ((niepotwierdzony fakt), ale mają zasady . (z pewnością jak diabli)

Zostałeś ostrzeżony o przestrzeganiu zasad i będziesz odpowiedzialny za ich nieprzestrzeganie. W sytuacji awaryjnej. W aplikacji bankowej. Chodzi mi o to, że jeśli twój cel kończy się źle i w więzieniu mogę wymyślić wiele zabawniejszych i bardziej znaczących sposobów na osiągnięcie tego samego rezultatu.

Ale wy, współwięźniowie, z przyjemnością usłyszycie, jak wędrujecie po braku ciekawości swoich byłych współpracowników.

(z drugiej strony, Twoja firma prawdopodobnie nie ma wewnętrznych zasad dotyczących projektowania OO, ale niezręczny inżynier przeszkolony przez COBOL, który spróbuje naprawić Twój kod, nadrobi zaległości i, w najgorszym przypadku, „ Mam 40% szans na trafienie krytyczne)

ZJR
źródło
1
Osobiście uważam, że naprawdę bardzo dobry programista robi świetny kod tak szybko, jak ten brudny kod. Zgadzam się z tobą w sprawie sytuacji awaryjnej ... ale kiedy projekt jest planowany na 4 miesiące, a programiści nie mają nawet globalnego spojrzenia na to, co zrobią, jak i jeśli coś już istnieje w aplikacji, co będzie pomóżcie im, nie mogłem tego zaakceptować. Gdy programista mówi: „Wiem, że ten kod jest okropny, ale nigdy go nie zmienię, ponieważ mogę go złamać”, to jest śmieszne. Czy są inżynierami czy nie? Inżynier powinien zaryzykować i zrobić kilka naprawdę dobrych testów jednostkowych, aby się
upewnić
1
Zgodziłbym się, gdybyśmy nie rozmawiali tutaj o bankach. Zawsze czuję, że różnią się od innych programistów. Są też zwykle starsi. (W moim otoczeniu, przynajmniej tak jak wszędzie, wnioskuję) Ich matematyka jest prosta, ale ich dokładność nie jest.
ZJR
@ZJR Dajesz się ponieść emocjom, gdy twoje proroctwa OP robią więzienie za używanie OO. Większość kodów bankowych nie podlega takiej kontroli.
quant_dev
0

Staraj się pamiętać, że programowanie jest uważane przez niektórych za środek do celu, a nie dla samego siebie. Pomyśl o wszystkich produktach i usługach, z których korzystasz: czy spędzasz dużo czasu zastanawiając się, czy kod pod spodem jest elegancki? A może po prostu doceniasz je, ponieważ po prostu działają? Znajdź branżę lub pasję, a następnie znajdź organizację z tym, a następnie zaoferuj im rozwiązania obejmujące programowanie, ale nie tylko. Problemy można doskonale rozwiązywać na różne sposoby.

therobyouknow
źródło