Bycie pod presją GOTO ciemnej strony

GOTOs nie robią dobrego kodu spaghetti, jest wiele innych czynników. ta dyskusja na linuksowej liście dyskusyjnej może pomóc spojrzeć na kilka rzeczy z perspektywy (komentarze Linusa Torvaldsa na temat szerszego obrazu korzystania z gotos).

Próba wprowadzenia "polityki bez goto" tylko po to, aby nie mieć gotos, nie przyniesie niczego na dłuższą metę i nie sprawi, że Twój kod będzie łatwiejszy do utrzymania. Zmiany będą musiały być bardziej subtelne i skupić się na zwiększeniu ogólna jakość kodu, myśl zgodnie z zasadami korzystania z najlepszych praktyk dla platformy / języka, pokrycia testów jednostkowych, analizy statycznej itp.

Rzeczywistość rozwoju jest taka, że pomimo wszystkich kwiecistych słów o robieniu tego we właściwy sposób, większość klientów jest bardziej zainteresowana robieniem tego w szybki sposób. Koncepcja bazy kodu szybko poruszająca się w kierunku implodacji i wynikającego z niej opadu na ich biznesie jest czymś, czego nie mogą pojąć, ponieważ oznaczałoby to konieczność myślenia poza dniem dzisiejszym.

To, co masz, to tylko jeden przykład. To, jak się na tym staniesz, będzie dyktować, jak robisz rozwój w przyszłości. I chyba masz 4 opcje:

1. Zaakceptuj prośbę i zaakceptuj, że zawsze będziesz to robić.

2. Zaakceptuj wniosek i natychmiast zacznij szukać nowej pracy.

3. Odmawiaj i bądź przygotowany do walki, aby naprawić bałagan.

4. Zrezygnuj.

To, którą opcję wybierzesz, będzie zależeć od tego, jak bardzo cenisz swoją pracę i poczucie własnej wartości.

Może możesz użyć boyscout-pattern: zostawić miejsce trochę bardziej czyste niż znalazłeś. Więc dla każdego featurerequest: nie wprowadzaj nowych Goto, ale usuń jeden.

To nie poświęci zbyt wiele czasu na ulepszenia, da więcej czasu na znalezienie nowo wprowadzonych błędów. Może nie kosztowałoby to dużo dodatkowego czasu, jeśli usuniesz goto z części, która chociaż musiała poświęcić czas na zrozumienie i wprowadzenie nowej funkcji.

Argumentować, że refaktoryzacja 2 godzin pozwoli zaoszczędzić 20 razy 15 minut w przyszłości i pozwoli na szybsze i głębsze ulepszenia.

Powrót do zasad:

• czy jest czytelny?
Czy to działa? Czy można go utrzymać?

To klasyczny konflikt "management" vs. "techies".

Pomimo bycia w zespole "techie", przez lata mocno ugruntowałem stronę "zarządzania" tej debaty.

Istnieje wiele powodów tego:

1. Jest całkiem możliwe, aby mieć dobrze napisane łatwe do odczytania prawidłowo zorganizowane programy z gotos! Zapytaj dowolnego programistę asemblera; warunkowa gałąź i prymitywna pętla do to wszystko, z czym muszą pracować. Tylko dlatego, że "styl" nie jest aktualne i nie znaczy, że nie jest dobrze napisane.

2. Jeśli jest to bałagan, to będzie to prawdziwy ból, aby wyodrębnić zasady pracy, których będziesz potrzebować, jeśli zamierzasz całkowicie napisać od nowa, lub jeśli robisz techniczną refaktoryzację programu, nigdy nie będziesz pewien, że zachowanie refaktorowanego programu jest "poprawne", tzn. robi dokładnie to, co robi stary program.

3. Zwrot z inwestycji-trzymanie się oryginalnego stylu programowania i minimalizowanie zmiany będą wymagały minimalnego wysiłku i szybko spełnią oczekiwania klientów. Spędzanie dużo czasu i wysiłku refaktoryzacja będzie droższa i potrwa dłużej.

4. Ryzyko-przeróbki i refaktoryzacja są trudne do poprawienia, wymagane jest obszerne testowanie kodu refactored i rzeczy, które wyglądają jak "błędy", mogą być" funkcjami", jeśli chodzi o klienta. Szczególny problem z "ulepszaniem" starszego kodu polega na tym, że użytkownicy biznesowi mogą mieć dobrze ugruntowaną pracę arounds, które zależą od błędu jest tam, lub, wykorzystać existense błędów do zmiany procedur biznesowych bez informowania działu IT.

Więc w sumie kierownictwo stoi przed decyzją -- "dodaj jednego małego goto" przetestować zmianę i wprowadzić ją do produkcji w podwójnym szybkim czasie z niewielkim ryzykiem -- lub -- przejść do dużego wysiłku programistycznego i mieć biznes krzyczeć na nich, gdy nowy zestaw błędów pojawia się.

A jeśli zdecydujesz się na refakturowanie w pięciu lata Czas jakiś zasmarkany absolwent college ' u będzie jęczeć, że twój program refactored nie jest już zgodny z buzzwordem i żąda, aby mógł spędzić tygodnie na przepisywaniu go.

If it ain ' t broke dont fix it!

PS: nawet Joel uważa, że to zły pomysł: rzeczy, których nigdy nie powinieneś robić

Update!-

OK jeśli chcesz refaktorować i poprawić kod musisz to zrobić poprawnie.

Podstawowy problem polega na tym, że mówisz klientowi, że "chcę spędzić n tygodni pracując nad tym programem i, jeśli wszystko pójdzie dobrze, zrobi dokładnie to, co teraz." -- to jest trudne do powiedzenia co najmniej.

Musisz zebrać długoterminowe dane na temat liczby awarii i przestojów, czasu poświęconego na analizowanie i programowanie pozornie małych zmian, liczby żądań zmian, które nie zostały wykonane, ponieważ były zbyt trudne, operacji biznesowych utraconych, ponieważ system nie mógł zmienić wystarczająco szybko. Zbierz też trochę acedemic dane na temat kosztów utrzymania dobrze ustrukturyzowanych programów a ich zatopienia.

Jeśli nie masz wodoszczelnej sprawy do przedstawienia beancounters nie dostaniesz budżetu. Naprawdę musisz to sprzedać zarządowi, a nie swoim bezpośrednim szefom.

Ostatnio musiałem popracować nad jakimś kodem, który nie był legacy per se , ale nawyki poprzednich programistów z pewnością były i dlatego GOTO były wszędzie. Nie lubię GOTO; robią ohydny bałagan i robią z debugowania koszmar. Co gorsza, zastąpienie ich normalnym kodem nie zawsze jest proste.

Jeśli nie możesz rozluźnić swoich GOTO, zdecydowanie polecam, abyś już ich nie używał.

Niestety język, w którym to jest napisane, nie ma gotowych narzędzi do refaktoryzacji

Nie masz edytorów z możliwościami makr? Nie masz skryptów powłoki? Zrobiłem mnóstwo refaktoryzacji przez lata, bardzo mało z przeglądarek refaktoryzacji.

Podstawowym problemem wydaje się być to, że masz 'analityków', którzy opisują, prawdopodobnie konieczne, zmiany funkcjonalne pod względem dodawania goto do jakiegoś kodu. A potem masz "programistów" , których praca wydaje się ograniczać do wpisywania tej zmiany i narzekania na nią.

Aby cokolwiek się zmieniło, trzeba zmienić dysfunkcyjny podział obowiązków między tymi ludźmi. Istnieje wiele różnych sposobów podziału pracy: klasyczny, konwencjonalny jedną z nich (jest to całkiem prawdopodobne, ale ignorowane, zasady w twojej pracy) jest to, aby analitycy napisali niezależny od implementacji dokument specyfikacji, a programiści wdrożyli go tak konserwacyjnie, jak tylko mogą.

Problem z tym teoretycznym podejściem jest tak naprawdę niewykonalny w wielu typowych sytuacjach. W szczególności zrobienie tego "właściwie" wymaga od pracowników postrzeganych jako junior wygrania kłótni z kolegami, którzy są bardziej starsi, mają lepsze kontakty społeczne w biurowe i bardziej biznesowe. Jeśli argument "goto nie jest niezależny od implementacji, więc jako analityk po prostu nie możesz powiedzieć tego słowa" nie leci w twoim obszarze roboczym, to prawdopodobnie tak jest.

Znacznie lepsze w wielu okolicznościach są alternatywy takie jak:

1. analitycy piszą kod skierowany do klienta, a deweloperzy piszą infrastrukturę.
2. analitycy piszą specyfikacje wykonywalne, które są używane jako implementacje referencyjne dla testów jednostkowych.
3. deweloperzy Utwórz specyficzny dla domeny język, w którym programują analitycy.
/ Align = "left" /

Jeśli zmiana programu wymaga "tylko jednego małego goto", powiedziałbym, że kod jest bardzo łatwy do utrzymania.

Jest to częsty problem w przypadku kodu starszego. Trzymaj się stylu, w którym program został pierwotnie napisany lub "unowocześniaj" kod. Dla mnie odpowiedzią jest zazwyczaj trzymanie się oryginalnego stylu, chyba że masz naprawdę dużą zmianę, która uzasadniałaby całkowite ponowne napisanie.

Należy również pamiętać, że kilka "nowoczesnych" funkcji językowych, takich jak oświadczenie Javy "throw" , lub SQLs "Na Błąd" są naprawdę "przejdź do" S w przebraniu.