Pomaganie komuś, kto nie jest i nigdy nie będzie profesjonalnym programistą, pisanie kodu, który jest bardziej czytelny i użyteczny w użyciu i interpretacji [zamknięty]

Jestem Elvis, bardzo się staram nauczyć się być Einsteinem. Pracuję dla Morta.

O czym do diabła mówi ten szalony idiota!?!? (Musisz tylko przeczytać kilka pierwszych akapitów)

Jeśli nie masz ochoty czytać tego linku, w zasadzie jestem profesjonalnym programistą, a mój szef ma (jest to przerażająco dokładne):

profesjonalny programista biznesowy, który nie ma dyplomu z informatyki, ale ma dużą wiedzę na temat Office i VBA, i który zazwyczaj pisze aplikacje zwiększające wydajność współużytkowane przez swoich współpracowników

Wszystko to powiedziawszy, duża część mojej pracy polega na zbieraniu kodu i przygotowaniu go do produkcji. Jednak bardzo zły styl i kult ładunków utrudniają to. Sytuację pogarsza fakt, że nie chce on czytać książek programistycznych ani pozwalać mi pomóc mu w poprawieniu kodu.

Czy istnieją jakieś inne strategie pomocy komuś, kto nie jest profesjonalnym programistą, nigdy nie będzie profesjonalnym programistą piszącym kod, który byłby bardziej czytelny i użyteczny dla mnie w użyciu i interpretacji?

Analizując twoje odpowiedzi w kilku komentarzach, nie wiem, czy zdajesz sobie sprawę, że to, czego doświadczasz, jest dość powszechne, szczególnie podczas pracy w specjalistycznych dziedzinach, w których eksperci w dziedzinie (nazwijmy ich naukowcami), aby dowiedzieć się, jak zawierać i dostosowywać algorytmy do bieżących problemów.

Zamiast narzekać na naukowca i oczekiwać, że się zmienią, po prostu zdaj sobie sprawę, że nie powinieneś oczekiwać, że naukowiec będzie troszczył się o „jakość kodu”. Często trudno jest zmusić innych programistów do dbania o „jakość kodu”, nie mówiąc już o kimś, kto zajmuje się głównie domeną, a nie programowaniem.

To, dokąd się wybierasz, zależy w dużej mierze od stopnia zaufania, jaki „naukowiec” ma w twojej zdolności do zrozumienia ich pracy. Jeśli mają pewność, że potrafisz zrozumieć ich kod i nie zepsują go podczas modyfikacji, to zwykle nie ma problemu. Będą polegać na twojej wiedzy.

Jeśli jednak naukowiec nie chce, abyś zmienił swój kod, jest wysoce prawdopodobne, że jeszcze nie „zasłużyłeś” na ich zaufanie. Jeśli tak jest, to zamiast skupiać się na naprawianiu naukowca, powinieneś skupić się na „naprawianiu” siebie. Rozumiem przez to podjęcie kroków w kierunku zdobycia ich zaufania. Prawdopodobnie najłatwiejszym sposobem na to jest:

W ramach procesu testowania:

1. Zacznij przekształcać algorytmy w coś łatwiejszego do zrozumienia (np. Diagramy, PDL, notacja matematyczna)
2. Naucz się rozumieć algorytmy.
3. Pamiętaj, aby zidentyfikować przypadki krawędzi.
4. Zapytaj naukowca, czy Twoja uproszczona „alternatywna” reprezentacja jest poprawna
5. I NAJWAŻNIEJSZE zidentyfikuj znalezione problemy; I bez brzmienia „oskarżycielski” powiedz coś w stylu „Spojrzałem na algorytm i zauważyłem, że XYZ powinien to zrobić, czy powinien?”. Nic nie zyska ich pewności siebie lepiej niż ta kula.

Gdy zaczniesz znajdować błędy ORAZ wykazać zainteresowanie ich obszarem zainteresowań, szanse stają się znacznie wyższe, że przynajmniej pozwolą Ci zacząć modyfikować kod, aby uczynić go bardziej „profesjonalnym”. Często nawet nie odczuwają potrzeby kodowania prototypu. Po prostu napiszą coś w jednym z tych „alternatywnych” zapisów, których ich nauczyłeś (nawet nie zdając sobie z tego sprawy) i będą mieć pewność, że będziesz wiedział, co mają na myśli.

Z całą pewnością moją pierwszą próbą byłoby zaproponowanie sugestii, w jaki sposób naukowiec mógłby najlepiej pomóc w „lepszej komunikacji”, aby ci pomóc; ale wygląda na to, że tego próbowałeś. Zatem jedynym krokiem, nad którym masz kontrolę, jest to, co robisz. Zdobądź ich zaufanie i prawie zawsze ekspert ds. Domen odczuje ulgę, że przekaże kodowanie komuś innemu i nie będzie musiał się martwić o wszystkie drobne szczegóły związane z pisaniem kodu. Woleliby raczej skupić się na ulepszaniu algorytmów.

Czasami wszystko, co możesz zrobić, to zaproponować sugestię i zostawić to później. Nie zrobisz wrażenia na swoim szefie lub seniorze, jeśli będziesz ciągle powtarzał coś, co już odrzucił lub zdecydował, że nie chce tego robić, nawet jeśli masz 100% racji. W rzeczywistości zaszkodzi to relacjom, bez względu na to, czy jesteś sugestatorem, czy sugestią. Skoncentruj się na tym, co TY możesz zrobić, aby ułatwić sobie pracę.

Kiedy jest naprawdę „kimś, kto nie jest profesjonalnym programistą, nigdy nie będzie profesjonalnym programistą”, jak mówisz, a kiedy duża część twojej pracy naprawdę „bierze swój złożony kod i przygotowuje go do produkcji”, brzmi to jak twój dwuosobowy zespół byłby bardziej produktywny, gdyby zostawił programowanie i skoncentrował się na części menedżerskiej projektu.

Zakłada to jednak, że masz rację. My, programiści, zawsze pomijamy kod napisany przez innych ludzi jako znacznie gorszy od naszego. To przekonanie jest naprawdę trudne do pokonania i prowadzi do niedoceniania naszych kolegów. To, co uważacie za „programowanie kultu”, może być „sprawdzonymi najlepszymi praktykami” z jego perspektywy, a to, co uważacie za „eleganckie zastosowanie wzorców obiektowych”, może być dla niego „niepotrzebną nadużytecznością”. Trudno mi powiedzieć, bo znam tylko twoją stronę historii.

Pogarda dla kodu innych ludzi staje się tym silniejsza, im bardziej różne są nasze style programowania. W takim przypadku jest to instynkt pozytywny, ponieważ mieszanie różnych stylów programowania w jednym projekcie bardzo utrudnia utrzymanie.

Gdy oboje nie jesteście w stanie naśladować stylu drugiego, możecie zdefiniować jasne obowiązki. Ustaw jedną osobę odpowiedzialną za jedną część wniosku, a drugą osobę za drugą. Zdefiniuj przejrzyste interfejsy między obydwoma modułami razem, ale pozostaw wewnętrzną implementację odpowiedzialnemu. Aby uświadomić mu błędy w kodzie, możesz napisać dla niego testy jednostkowe i wskazać, kiedy jego kod oczywiście nie zachowuje się zgodnie z określoną umową interfejsu.

Poprzez ustanowienie wyraźnego prawa własności do kodu możesz osiągnąć lepsze współistnienie różnych stylów. Ponadto, gdy oboje jesteście odpowiedzialni za naprawianie błędów we własnym kodzie, nie będziecie musieli często nawigować po sobie nawzajem.

Musisz zadać sobie pytanie: jaki jest twój ostateczny cel? 1. aby pomóc szefowi? 2. pomóc firmie? 3. pomóc sobie? I zanim odpowiesz „wszystkie powyższe”, zwolnij. Twoim pierwszym zadaniem jest jasne zdefiniowanie głównego celu, ponieważ odpowiedź zależy od niego.

Jeśli Twoim celem jest:

1. Pomóc swojemu szefowi? Odpuść sobie. Nie wydaje się, żeby o to prosił. Powiedziałeś: „Wie, że jego kod jest zły, ale robi to, czego potrzebuje”. No to koniec dyskusji. Dopóki twój szef nie będzie niezadowolony z obecnej sytuacji, nie zamierza się zmienić i będzie oburzony twoimi staraniami, aby mu pomóc. Jeśli w którymś momencie w przyszłości „poczuje ból” status quo, mam nadzieję, że staniesz się godnym zaufania mentorem i będzie wiedział, gdzie szukać pomocy.

2. Pomóc swojej firmie? Czy obecna sytuacja zagraża dolnej linii? Czy terminy są zagrożone? Czy wyższe kierownictwo zwiększa swoje ciepło? Jeśli nie, to się poddawaj. (Zasadniczo Jimmy Hoffa stwierdził w swoim komentarzu do twojego oryginalnego postu.) Jeśli jednak obecna sytuacja w rzeczywistości stanowi niedopuszczalne ryzyko dla twojego działu / firmy, wówczas zmiana procesu jest właściwa. W takim przypadku proponuję usiąść i nakreślić innyPodział pracy. Kluczem tutaj jest wyjaśnienie, że lepiej poświęcić czas na refaktoryzację kodu szefa, pisząc nowy kod. Mówisz, że nie masz czasu na pisanie wszystkiego sam, ale nie to sugeruję. Musisz dowiedzieć się, jak zmaksymalizować swoje mocne strony. Przestań myśleć o nim jak o Mortu i pomyśl o nim jako młodszym programistą z doskonałą wiedzą w dziedzinie domen. Jest to bardzo powszechne porozumienie robocze w branży i należałoby nauczyć się, jak się w nim rozwijać. Na przykład upewnij się, że wie, że wiesz, jak ważna jest jego wiedza specjalistyczna (często powtarzaj ten krok), a następniepokornie zasugeruj następującą strategię (lub coś podobnego) jako szybszą drogę do zdobycia wiedzy na rynku: (a) podziel pracę na „zwinne” sprinty, (b) współpracuj mocno z góry (w każdym sprincie), definiując ponad -wszystkie wymagania i architektura. (c) Pozwól mu odejść i zbuduj prototyp, aby wypracować wszystkie decyzje algorytmiczne, podczas gdy ty zbuduj infrastrukturę, którą uzgodniłeś w poprzednim kroku. (d) Zaimplementuj swoje algorytmy w swojej strukturze, podczas gdy on buduje testy, aby to sprawdzić. (e) Przeprowadź swoje V&V razem w środowisku programowania partnerskiego. (np. „Ten test się nie powiódł; dlaczego? błąd logiki algorytmicznej lub błąd kodowania?”; powtórz tutaj).

3. Pomóż sobie? Bądź szczery tutaj. Jeśli narzekasz na to, że nie lubisz swojej pracy, sugeruję, abyś poświęcił więcej czasu na myślenie o punkcie 2 powyżej. Jeśli nie zależy ci na firmie ORAZ nie podoba ci się praca, zacznij rozpowszechniać swoje CV. Jeśli dbasz o swoją firmę, ale nie lubisz swojej pracy, to skupienie się na # 2 powinno pomóc OBU kontom. Ale w takim przypadku jest to „wygrana-wygrana” tylko wtedy, gdy dla wszystkich jasne jest, że twoja pasja naprawdę wynika z chęci niesienia pomocy zespołowi, a nie tylko z egocentrycznej frustracji w zadaniu.

Nie jestem pewien, czy dodam coś do tej dyskusji, ale pracowałem w podobnych scenariuszach, w których naruszenie zasad dostępu uderza w linię z ShowMessage('Hello');podobnym lub podobnym, tylko po to, aby dowiedzieć się, że ta sama linia ma więcej kodu, poza ekranem do dobrze,

Uważam, że masz dwie podstawowe opcje:

1. Uruchom kod . Jeśli kod działa i działa tak, jak powinien, chyba że szef wyraźnie poprosi cię o naprawienie kodu, po prostu zostaw go tak, jak jest. Może to również doprowadzić go do zrozumienia, że ​​Twój kod wygląda ładniej i pozostawić pracę tobie (jak również wskazał Dunk w swojej odpowiedzi).
2. Jeśli jesteś bardzo zdeterminowany, aby uczynić kod profesjonalnym, zbuduj bibliotekę / platformę , z której będzie mógł korzystać. Jeśli często występują błędy / strategie, które często naprawiasz, możesz je zawinąć w kilka plików bibliotecznych i przekazać mu jako „bibliotekę podstawową dla firmy” , której możesz także użyć jako Wspólny interfejs.