Czy istnieje studium przypadku, które w przekonujący sposób pokazuje, że czysty kod usprawnił rozwój? [Zamknięte]

Pracuję jako programista i widzę tylko kod „Big Ball of Mud” (bez przydatnych komentarzy), ale lubię robić czysty kod i bardzo trudno jest mi napisać gorzej sposób.

Szukam jakiegoś studium przypadku, w którym użycie czystego kodu (widzę tutaj różne definicje czystego kodu) poprawiło rozwój i łatwość konserwacji.

Szybkim (ale w żaden sposób wyczerpujący) szukaj z Google Scholar Okazuje się wiele artykułów, które odnoszą się do Boba Martina czystego kodu , ale ja osobiście nie widziałem żadnych dokumentów, które obejmują korelację pomiędzy „czystego kodu” i ulepszonego rozwoju.

Pomyśl jednak przez chwilę o swoim pytaniu. Pytasz o ulepszony rozwój, który sam w sobie jest bardzo szerokim obszarem tematycznym, obejmującym nie tylko pisanie lepszego kodu, ale także wiele innych czynników, takich jak komunikacja, zarządzanie oczekiwaniami, metodologia i usprawnianie procesów, testowanie, ciągła integracja i naprawdę całe pudełko i kostka, gdy weźmie się pod uwagę, ile rzeczy ma wpływ na powodzenie projektu tworzenia oprogramowania, nie mówiąc już o ulepszaniu go.

Pytanie powinno zatem brzmieć: czy pisanie czystego kodu przyczynia się do lepszego rozwoju oprogramowania? Aby odpowiedzieć na to pytanie, jedyny „dowód”, który mógłbym przedstawić, byłby całkowicie anegdotyczny i dlatego uważam, że książka Czysty kod byłaby doskonałym odniesieniem, ponieważ została napisana nie tylko przez samego Boba Martina, ale także z wieloma rozdziałami przez niektórych z najmądrzejszych twórców oprogramowania. Jeśli to nie pomoże, być może zastosuje się trochę twardej logiki.

Jeśli zrobisz bałagan w domu i nigdy nie zabierzesz się do czyszczenia go, wtedy życie w domu stanie się obowiązkiem. Trudniej jest znaleźć rzeczy, trudniej się poruszać i nikt przy zdrowych zmysłach nie będzie chciał cię odwiedzić, jeśli żyjesz w brudnym środowisku. To samo dotyczy kodu. Jeśli Twój kod to bałagan, trudniej jest zlokalizować problemy, a co dopiero je naprawić. Łatwiej jest usprawiedliwić obejście, które może nie zadziałać, ale hej, na pewno bije to, że trzeba przedzierać się przez cały ten stary szlam, prawda? W końcu, tak jak nigdy nie sprzątaj domu, pozwolenie, aby Twój kod stał się nieporządny, będzie cię kosztować czas i wysiłek, a także spowoduje trudności na dłuższą metę. Utrzymanie kodu w czystości zapewni jednak lepszą platformę do pracy, dzięki czemu refaktoryzacja i debugowanie będą mniej uciążliwe,

Nie, nie mam bezpośrednich dowodów do przekazania, a są to tylko myśli kogoś, kto robił to od bardzo dawna i, miejmy nadzieję, że zdobył trochę mądrości przy tworzeniu oprogramowania . :-)

Musisz zrozumieć, że żadna firma nie zamierza pisać miernego kodu. Problem polega na tym, że 50% kodu, który daje lub bierze, jest napisane przez programistów poniżej średniej w Twojej firmie. Głosisz do chóru, kiedy objaśniasz zalety czystego kodu. Sztuka polega na tym, jak to zrobić. Przeprowadź badania dotyczące takich narzędzi, jak narzędzia do wzajemnej oceny, analizy statyczne, automatyczne testy, ciągła integracja, TDD, scrum, programowanie ekstremalne itp. I przedstaw potencjalne rozwiązania zamiast wyjaśniać, dlaczego problem jest zły.

Wiem, że będzie to sprzeczne z rzeczywistością, ale czas na wprowadzenie na rynek, odpowiednie spełnienie wymagań, odpowiednie finansowanie, dobry marketing, odpowiednią cenę i zwykłe szczęście mają znacznie większy wpływ na sukces oprogramowania niż jakość kodu.

To nie znaczy jakość kodu powinny być ignorowane, ale trzeba przyznać, że jest tylko jednym z wielu czynników.

Istnieje wiele przykładów po prostu okropnego kodu w bardzo udanych produktach (np. Oryginalny system operacyjny Apple, który pozostawił zarządzanie wątkami aplikacjom).

Nie mogę wymyślić żadnych przykładów pięknego kodu pokonującego źle pomyślany lub zawyżony produkt.

Więc jeśli jego czas na marketing kontra ładny kod, czas na rynek powinien mieć priorytet!

Musisz oddzielić czysty kod od prawdziwych celów: obniżenie kosztów naprawy usterek po wdrożeniu i ograniczenie niepotrzebnych przeróbek. Kiedy mówisz o „pisaniu czystego kodu, aby miał mniej błędów”, mówisz o religii. Kiedy mówisz o „zmniejszeniu wskaźnika wad o 10%, oszczędzając 2 miesiące pracy nad projektem”, mówisz o zarządzaniu. Czysty kod jest narzędziem poprawiającym początkową jakość bazy kodu, a tym samym obniżającym całkowity koszt, ale jest jednym z wielu.

Poniższy artykuł wyjaśnia, dlaczego poprawne działanie za pierwszym razem ma znaczenie z punktu widzenia kosztów: http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf

Nie znam żadnego konkretnego badania, ale sprawdź pracę Steve'a McConnella .

Jeśli ktoś to ma, to zrobi to. Na przykład skanowanie dwóch minut znalazł to (16 lat, ale nadal aktualne).

Aby dodać do odpowiedzi Mattnza, jeśli jeszcze tego nie zrobiłeś, powiedziałbym, że szczególnie sprawdź Code Complete: Praktyczny podręcznik budowy oprogramowania Steve'a McConnella. Oprócz faktu, że prawdopodobnie poprawi to kodowanie, cytuje on liczne badania w książce na temat tego, jak różne praktyki kodowania wpływają na jakość programów.

Jako przykład (z książki):

Inne badanie różnych 450 procedur (co jest po prostu niezwykłym zbiegiem okoliczności) wykazało, że procedury o najwyższych stosunkach sprzężenia do kohezji miały 7 razy więcej błędów niż te z najniższymi stosunkami kohezji i były 20 razy droższe naprawić (Selby i Basili 1991).

Była to również odpowiedź numer jeden na pytanie. Jaka jest najbardziej wpływowa książka, którą powinien przeczytać każdy programista? (chociaż widzę, że odpowiedzi na to pytanie zostały niedawno reorganizowane w kiepski sposób)