Zaskakująca liczba problemów z jakością, skalowalnością i obciążeniem pojawiła się w aplikacji, którą obecnie obsługuję, której pierwotnie nie napisałem. Na szczęście mam nowe projekty, które realizowałem od podstaw, aby zachować pozory mojego zdrowego rozsądku.
Pierwotny zespół składał się z 20 programistów (większość z nieaktualnymi zestawami umiejętności), bez dokumentów wymagań biznesowych lub testerów zapewniania jakości i od samego początku źle zarządzanych w sposób wodospadowy. Wczesne dni produkcji były krępującym koszmarem, który wymagał łatania kruchego kodu proceduralnego za pomocą jeszcze większej liczby kruchych poprawek. Później dodano funkcje, które zostały wpuszczone w model danych, który nigdy nie miał ich obsługiwać i często zdarza się, że ten sam kod jest powielany 10 razy, a zasoby nie są bezpiecznie zamykane, a zapytania ORM, które pobierają dziesiątki tysięcy jednostek, wyrzucić wszystko oprócz garstki.
Teraz jestem tylko ja i za każdym razem, gdy pojawia się nowy problem, przepisuję moduł na lepsze standardy i sprawiam, że DUŻO jest on bardziej stabilny, ale Zarząd potrzebuje odpowiedniego wyjaśnienia, dlaczego to wszystko się dzieje.
Wydają się zszokowani i zakłopotani myślą, że ta aplikacja jest niskiej jakości i tonie w długach technicznych. Na szczęście rozumieją koncepcję długu technicznego i wspierają mnie w dążeniu do jego zlikwidowania, a także bardzo mnie wspierają i doceniają, ale czuję się tak, jakbym wciąż obwiniał oryginalny zespół (który zszedł, by zrujnować inny projekt w innym podział).
Najważniejsze jest to, że nie chcę być „tym facetem”, który zawsze narzeka na deweloperów projektu przed nim. Widziałem już wcześniej taką postawę od ludzi w mojej karierze, którzy osobiście uważałem, że byli ignorantami i nie brali pod uwagę okoliczności i wpływów projektowych, które zachęcały do bycia takimi, jakie były.
Zazwyczaj widzę to podejście polegające na obwinianiu poprzedniego zespołu za kiepski projekt i wdrożenie od idealistycznych młodszych programistów, którzy nie mieli doświadczeń życiowych, z których korzystało więcej starszych członków.
Czy uważasz, że istnieje lepszy, być może łagodniejszy sposób zgłaszania tego rodzaju problemów kierownictwu, bez narażania reputacji osoby / zespołu przed tobą?
bad-codeponieważ kod rzeczywiście powoduje błędy i problemy. Oznaczyłem to, bad-programmerponieważ obawiam się, że staję się jednym, obwiniając poprzedni zespół, zmęczoną i oklepaną wymówkę, o której wszyscy wcześniej słyszeliśmy. Jeśli chodzi o pierwsze trzy akapity, być może nie musiałem być tak opisowy, ale chciałem namalować dokładny obraz mojej bezpośredniej sytuacji i podać historię tego, co do tej pory zebrałem.