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

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?

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”.

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.

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.

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.

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.

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)

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.

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”

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.

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)

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.