Jak radzisz sobie z celowo złym kodem?

Istnieje wiele historii o celowo złym kodzie, nie tylko na TheDailyWTF, ale także na SO. Typowe przypadki obejmują:

• Posiadanie bezużytecznej, marnującej czas konstrukcji (np. Pusta pętla licząca się do ogromnej wartości), dzięki której programiści mogą łatwo „przyspieszyć” aplikację, usuwając ją, gdy jest to wymagane.
• Dostarczanie celowo wprowadzającej w błąd, błędnej lub żadnej dokumentacji w celu generowania drogich próśb o wsparcie.
• Łatwe generowanie błędów lub, co gorsza, generowanie, nawet jeśli wszystko działało dobrze, blokowanie aplikacji, więc do odblokowania wymagane jest kosztowne wezwanie pomocy technicznej.

Punkty te wykazują mniej lub bardziej złośliwe nastawienie (choć czasami przypadkowo), szczególnie pierwszy punkt występuje dość często.

Jak należy radzić sobie z takimi konstrukcjami? Zignorować problem lub po prostu usunąć niepoprawny kod? Powiadomić swojego kierownika lub porozmawiać z osobą, która wprowadziła „funkcję”?

Większość złego kodu wynika z braku zrozumienia, a rozwiązaniem jest edukacja.

Celowo zły kod jest zupełnie inny, z powodu czegoś zupełnie niezwiązanego z doświadczeniem programisty lub resztą projektu. W związku z tym musisz dowiedzieć się, dlaczego celowo sabotują kod i rozwiązać ten problem. Oznacza to, częściej niż nie, politykę biurową i rzadko jest to przyjemna sytuacja dla każdego.

To, jak poradzę sobie ze stroną polityczną, zależy od wielu (niepotwierdzonych powyżej) okoliczności. Jak poradziłbym sobie z kodem, najpierw upewniłem się , że nie jestem jedynym nieporozumieniem - że to naprawdę zły kod - a następnie naprawę oczywistych braków. Jeśli to możliwe, napisz testy, że zły kod zawiedzie. Podwójne sprawdzenie, które poprawnie zrozumiałem, oznaczałoby rozmowę z osobą, która napisała kod. Należy to zrobić w bardzo miły, uprzejmy sposób, bez zakładania intencji, i może pomóc w znalezieniu podstawowego (politycznego) powodu potrzebnego później.

Wysyłka jest ważniejsza niż perfekcja wieży z kości słoniowej, ale należy zwrócić uwagę na dwa punkty. Naprawienie oczywistych braków daje 80% wyników przy 20% wysiłku, a tego rodzaju nisko wiszące owoce rzadko warto ignorować. Co ważniejsze, jeśli nie odniesiesz się do podstawowego (politycznego) powodu, prawdopodobnie celowo zostanie napisany zły kod i spowoduje dalsze problemy - i prawdopodobnie uniemożliwi wysyłkę.

Nigdy (przez 20 lat) nie spotkałem celowo złego kodu, ale przytaczane przez ciebie przykłady wydają mi się (przynajmniej dla mnie, ale IANAL) próbami oszukania pracodawcy lub klienta, więc prawdopodobnie masz legalny obowiązek wskazania tego swojemu przełożonemu.

Zależy od kultury firmy. Częściej niż nie, po prostu nie jest twoim zadaniem naprawianie i usuwanie całego złego kodu.

Z Coders at Work , myśl Jamiego Zawińskiego o nadinżynierii, którą można zastosować również w tej sytuacji:

Pod koniec dnia wyślij kurwa! Wspaniale jest przepisać kod i uczynić go czystszym, a po raz trzeci będzie naprawdę ładny. Ale nie o to chodzi - nie ma cię tutaj, aby pisać kod; jesteś tutaj, aby wysyłać produkty.

Istnieje wiele złych koderów i kodu, a po prostu próba ich naprawienia, gdy się z nim spotkasz, kosztem bieżącego projektu / zadania, może po prostu nie być tego warta, jeśli produkt „działa”. Zbyt często wszyscy jesteśmy programistami taśm klejących.

Zobacz także post Joela Spolsky'ego: The Duct Tape Programmer

Takie podejście jest objawem czegoś gorszego.

• Czy zarząd zachęca do konkurencji deweloperów?

• Gdzie jest duch zespołu?

• Czy zadania są przydzielane przez kogoś innego niż sam zespół?

• ...

W każdym razie usunięcie szkodliwego kodu nie wystarczy. Skarga do swojego menedżera z pewnością nie pomoże poprawić ducha zespołu.

Spróbowałbym porozmawiać z osobą bezpośrednio i spróbować zrozumieć, zadając wiele pytań bez osądzania go. Cały zespół musi to zrobić bez agresji.

W większości przypadków to konstruktywne zachowanie ujawnia prawdziwy problem (najgorszy), a następnie możesz nad nim popracować.

Jeśli to naprawdę nie działa. Usuń tego programistę z zespołu.

Gdybym myślał, że to celowe, prawdopodobnie zwolniłbym faceta! Jeśli jest to wynikiem tego, że ktoś nie jest wystarczająco dobrym programistą, pracowałbym nad jego umiejętnościami. Gdyby został zepchnięty z góry, prawdopodobnie zacząłbym szukać nowej pracy.

Jak należy radzić sobie z takimi konstrukcjami? Zignorować problem lub po prostu usunąć niepoprawny kod? Powiadomić swojego kierownika lub porozmawiać z osobą, która wprowadziła „funkcję”?

W zależności od kontekstu dowolny z nich może być najbardziej odpowiedni. Inne możliwości obejmują prośbę o przeniesienie do innego projektu, znalezienie nowej pracy oraz różne akty wątpliwej moralności i / lub legalności.

Biorąc jednak pod uwagę fakt, że nie znamy prawdziwych faktów i prawdziwych zaangażowanych osób, nie ma mowy, aby ktoś w pozycji, którą opisujesz, zwracał dużą uwagę na nasze porady / warte 2 centy.

Jeśli jest to prawdziwa sytuacja, o której mówisz, warto porozmawiać ze swoim menedżerem i zapytać go, co należy zrobić. Jeśli to możliwe, spróbuj rozmawiać o tym , co możesz / powinieneś zrobić, a nie o wskazywaniu palcem. Jeśli to możliwe, nie wymieniaj nazwisk. Istnieje spora szansa, że ​​Twój menedżer już rozumie problem.

Ale drugą stroną jest to, że możesz wydmuchać to z proporcji. Zastanów się długo, zanim cokolwiek zrobisz. Pomyśl o konsekwencjach, w tym o możliwości, że jakiekolwiek kroki, które podejmiesz, mogą cię odbić ... źle.