W jaki sposób utrzymywane są ogromne biblioteki open source, mając kod daleki od praktyk „czystego kodu”?


80

Nadal nie mam doświadczenia w pisaniu kodu o wysokiej jakości, dlatego czytam książki poświęcone temu zagadnieniu, takie jak Clean Code autorstwa Roberta C. Martina, i ciągle sprawdzam kod znanych bibliotek, aby poprawić swoje umiejętności.

Chociaż wiele bibliotek open source jest utrzymywanych od lat, co oznacza, że ​​jest bardzo mało prawdopodobne, że nie są one na właściwej ścieżce, w wielu z nich zauważyłem, że kod jest daleki od zasad adresowanych do pisania czystego kodu - np. Metody zawierające setki linii kodu.

Więc moje pytanie brzmi: czy zasady czystego kodu są zbyt ograniczone i możemy sobie bez nich poradzić w wielu bibliotekach takich jak te? Jeśli nie, w jaki sposób utrzymywane są ogromne biblioteki bez uwzględnienia wielu z tych zasad?

Będę wdzięczny za krótkie wyjaśnienie. Przepraszam, jeśli pytanie wydaje się głupie od początkującego faceta.

EDYTOWAĆ

Sprawdź ten przykład w bibliotece Butterknife - jednej z najbardziej znanych bibliotek w społeczności Androida.


71
Cierpisz na uprzedzoną próbkę. Mówisz, że sprawdzasz kod „dobrze znanych” bibliotek. Biblioteki, które upadły pod własnym ciężarem, ponieważ nie stosowały najlepszych praktyk, nie są „dobrze znane”, zniknęły w zapomnieniu.
Jörg W Mittag,

3
Czy sprawdziłeś np. Źródła Linuksa?
Martin Schröder

55
Podstawową miarą wartości oprogramowania nie jest to, jak „czysty” jest kod, ale to, jak dobrze spełnia określone zadanie. Podczas gdy niektórzy ludzie lubią pisać oprogramowanie tylko po to, aby coś napisać, dla większości ludzi kod jest tylko środkiem do celu.
whatsisname

3
Nikt się z tobą nie zgadza. Pytanie brzmi, jak utrzymać słaby kod przez lata? Dlaczego nie zostało wyczyszczone przez wiele kolejnych etapów ewolucji?
Islam Salah

13
Przesłanka pytania (że długo utrzymywane projekty open source muszą z natury rzeczy być zgodne z koncepcją najlepszych praktyk autora jednej książki) jest całkowicie fałszywa i nie wiem, skąd je masz. Czy mógłbyś rozwinąć przesłankę swojego pytania?
Wyścigi lekkości na orbicie

Odpowiedzi:


84

Dobra odpowiedź już tutaj, ale pozwólcie, że powiem kilka słów o waszym przykładzie maślanego noża : chociaż nie mam pojęcia, co robi kod, na pierwszy rzut oka nie wydaje mi się on niemożliwy do utrzymania. Zmienne i nazwy metod wydają się być wybierane celowo, kod jest odpowiednio wcięty i sformatowany, ma pewne komentarze, a długie metody przynajmniej wykazują pewną strukturę bloków.

Tak, w żaden sposób nie przestrzega reguł „czystego kodu” wuja Boba, a niektóre metody są z pewnością zbyt długie (prawdopodobnie cała klasa). Ale patrząc na kod wciąż widzę wystarczającą strukturę, aby można je było łatwo „wyczyścić” poprzez samodzielne wyodrębnienie tych bloków w metody (przy niskim ryzyku wprowadzenia błędów przy użyciu narzędzi do refaktoryzacji).

Prawdziwym problemem z takim kodem jest dodanie jednego bloku i drugiego bloku, a inny blok działa do pewnego stopnia, czasem przez lata. Ale każdego dnia kod staje się coraz trudniejszy do ewolucji, a jego modyfikacja i testowanie zajmuje trochę więcej czasu. A kiedy naprawdę musisz zmienić coś, czego nie można rozwiązać przez „dodanie kolejnego bloku”, ale wymaga restrukturyzacji, będziesz żałował, że ktoś nie zaczął wcześniej czyścić kodu.


Komentarze nie są przeznaczone do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu .
yannis

158

Zasady określone w „Czystym kodzie” nie zawsze są ogólnie uzgodnione. Większość z nich to zdrowy rozsądek, ale niektóre opinie autora są raczej kontrowersyjne i nie są podzielane przez wszystkich.

W szczególności preferencje dla krótkich metod nie są uzgodnione przez wszystkich. Jeśli kod w dłuższej metodzie nie jest powtarzany w innym miejscu, wyodrębnienie jej części do osobnej metody (aby uzyskać wiele krótszych metod) zwiększa ogólną złożoność, ponieważ metody te są teraz widoczne dla innych metod, które nie powinny się nimi przejmować. Jest to więc kompromis, a nie obiektywna poprawa.

Porady zawarte w książce są również (jak wszystkie porady) ukierunkowane na określony rodzaj oprogramowania: aplikacje dla przedsiębiorstw. Inne rodzaje oprogramowania, takie jak gry lub systemy operacyjne, mają inne ograniczenia niż oprogramowanie dla przedsiębiorstw, dlatego obowiązują inne wzorce i zasady projektowania.

Język jest również czynnikiem: Clean Code zakłada Javę lub podobny język - jeśli używasz C lub Lisp, wiele porad nie ma zastosowania.

Krótko mówiąc, książka jest opiniami jednej osoby na temat określonej klasy oprogramowania. Nie będzie miało zastosowania wszędzie.

Jeśli chodzi o projekty typu open source, jakość kodu waha się od bezwzględnej do doskonałej. W końcu każdy może opublikować swój kod jako open source. Ale jeśli spojrzysz na dojrzały i udany projekt open source z wieloma współautorami, możesz być całkiem pewien, że świadomie zdecydowali się na styl, który im odpowiada. Jeśli ten styl jest sprzeczny z niektórymi opiniami lub wytycznymi, to (mówiąc wprost) to wytyczne są złe lub nieistotne, ponieważ działający kod przebija opinie.


18
+1 za „ukierunkowane na określony rodzaj oprogramowania”. Można to rozszerzyć na większość książek na ten i podobne tematy. Weź wszystko, co czytasz, z odrobiną soli, może to być stronnicze od czasu, gdy jest napisane, środowiska docelowego, metodologii rozwoju i wszelkiego rodzaju innych czynników.
Reginald Blue,

16
Przestrzeganie tej książki ściśle tworzy coś, co wielu nazywa „śmieciowym kodem”.
Frank Hileman,

16
@FrankHileman: jeszcze bardziej nie przestrzegam żadnych zaleceń tej książki.
Doc Brown

5
@ jpmc26 - Twoja linkowana odpowiedź dotyczy dziedziny, którą dobrze znam, programowania naukowego. Niedawno otrzymałem przedmiot z listy życzeń, który miał sprawić, że model grawitacyjny zastosowany w kilku symulacjach Centrum Kosmicznego Johnson będzie relatywistycznie poprawny. Licząc komentarze i puste linie, napisany przeze mnie kod, który oblicza relatywistyczne zaburzenie grawitacji Newtona, ma 145 linii długości i wszystko to w jednej funkcji. Normalnie skuliłbym się, widząc, że sam napisałem funkcję o długości 45 linii, a co dopiero 145. Ale nie w tym przypadku. ...
David Hammen,

12
... Ta funkcja implementuje jedno równanie, równanie X w dzienniku Y, więc zdecydowanie przestrzega reguły jednego celu. (To, że równanie obejmuje jedną czwartą strony, jest w szczegółach.) Nie ma sensownego miejsca na podzielenie tej funkcji na części ani żadnego sensownego powodu, aby to zrobić. Komentarze, których wujek Bob gardzi? W tym przypadku są absolutnie konieczne i jest to typowe w programowaniu naukowym. Chociaż dobrze jest zobaczyć odpowiednie odniesienia do czasopism w dokumentacji modelu TeX, dobrze jest również zobaczyć je w implementacji.
David Hammen

34

Podsumowanie

Jak pisze JacquesB, nie wszyscy zgadzają się z „Czystym kodem” Roberta C. Martina.

Projekty open source, które według ciebie „naruszają” zasady, których się spodziewałeś, mogą po prostu mieć inne zasady.

Moja perspektywa

Zdarza mi się nadzorować kilka baz kodu, które są bardzo zgodne z zasadami Roberta C. Martina. Jednak tak naprawdę nie twierdzę, że mają rację , mogę tylko powiedzieć, że działają dobrze dla nas - i że „my” jest w rzeczywistości kombinacją przynajmniej

  • zakres i architektura naszych produktów,
  • rynek docelowy / oczekiwania klientów,
  • jak długo produkty są utrzymywane,
  • stosowana przez nas metodologia rozwoju,
  • struktura organizacyjna naszej firmy i
  • zwyczaje, opinie i doświadczenia naszych programistów.

Zasadniczo sprowadza się to do: każdy zespół (czy to firma, dział czy projekt open source) jest wyjątkowy. Będą mieli różne priorytety i różne punkty widzenia, i oczywiście dokonają różnych kompromisów. Te kompromisy i wynikający z nich styl kodu są w dużej mierze kwestią gustu i nie można udowodnić, że są „złe” lub „właściwe”. Zespoły mogą tylko powiedzieć „robimy to, ponieważ to działa dla nas” lub „powinniśmy to zmienić, ponieważ to nie działa dla nas”.

To powiedziawszy, uważam, że aby móc z powodzeniem utrzymywać duże bazy kodu przez lata, każdy zespół powinien uzgodnić zestaw konwencji kodu, które ich zdaniem są odpowiednie dla powyższych aspektów. Może to oznaczać stosowanie praktyk Roberta C. Martina przez innego autora lub wymyślanie własnych; może to oznaczać ich formalne zapisanie lub udokumentowanie „przez przykład”. Ale powinny istnieć.

Przykład

Rozważ praktykę „dzielenia kodu z długiej metody na kilka metod prywatnych”.

Robert C. Martin mówi, że ten styl pozwala na ograniczenie zawartości każdej metody na jednym poziomie abstrakcji - w uproszczonym przykładzie, sposób publiczny będzie składać się prawdopodobnie tylko do rozmów prywatnych metod, takich jak verifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...)i wreszcie sendJsonToClient(...), a metody te musiałyby szczegóły wdrożenia.

  • Niektórym się to podoba, ponieważ czytelnicy mogą uzyskać szybki przegląd kroków wysokiego poziomu i wybrać, o których szczegółach chcą przeczytać.
  • Niektórym się to nie podoba, ponieważ jeśli chcesz poznać wszystkie szczegóły, musisz przeskakiwać w klasie, aby śledzić przebieg wykonywania (o tym prawdopodobnie mówi JacquesB, gdy pisze o zwiększaniu złożoności).

Lekcja jest taka: wszystkie mają rację, ponieważ mają prawo do wyrażenia opinii.


13

Wiele bibliotek open source w rzeczywistości cierpi z powodu obiektywnie złych praktyk kodowania i jest utrzymywanych z trudnością przez niewielką grupę długoterminowych współpracowników, którzy mogą sobie poradzić ze słabą czytelnością, ponieważ są bardzo dobrze zaznajomieni z częściami kodu, które najczęściej utrzymują . Refaktoryzacja kodu w celu poprawy czytelności po fakcie jest często wysiłkiem Herculean, ponieważ wszyscy muszą znajdować się na tej samej stronie, to nie jest fajne i nie płaci, ponieważ nie są wdrażane żadne nowe funkcje.

Jak powiedzieli inni, każda książka o czystym kodzie zawierająca wszystko, co zawiera, zawiera porady, które nie są powszechnie uzgodnione. W szczególności prawie każdą zasadę można stosować z nadmierną gorliwością, zastępując problem czytelności innym.

Osobiście unikam tworzenia nazwanych funkcji, jeśli nie mam dla nich dobrego imienia. A dobre imię musi być krótkie i wiernie opisywać, jaką funkcję spełnia świat zewnętrzny. Jest to również związane z próbą uzyskania jak najmniejszej liczby argumentów funkcyjnych i braku globalnie zapisywalnych danych. Próba podzielenia bardzo złożonej funkcji na mniejsze funkcje często skutkuje bardzo długimi listami argumentów, gdy funkcja była naprawdę złożona. Tworzenie i utrzymywanie czytelnego kodu jest ćwiczeniem w równowadze między wzajemnie sprzecznymi zasadami zdrowego rozsądku. Czytanie książek jest dobre, ale tylko doświadczenie nauczy Cię, jak znaleźć fałszywą złożoność , czyli tam, gdzie osiąga się prawdziwy wzrost czytelności.


2
Dodałbym: po prostu dlatego, że coś jest „open source”, nie oznacza, że ​​tylko ktoś jest współtwórcą. Często wiele projektów o otwartym kodzie źródłowym jest utrzymywanych przez kliki, na dobre lub na złe, które izolują swój projekt od innych autorów - i, chyba że zostanie rozwidlony, nikt inny nie wnosi wkładu. Jeśli się nie rozwidli, czy to dlatego, że nikt nie musi go modyfikować, czy dlatego, że nikt nie jest w stanie tego zrozumieć, wówczas konwencjonalny styl kodu prawdopodobnie pozostanie niezmieniony.
can-ned_food

7

Większość projektów typu open source jest źle zarządzana. Istnieją oczywiście wyjątki od tego, ale w świecie open source znajdziesz wiele śmieci.

To nie jest krytyka wszystkich właścicieli / menedżerów projektów, o których projektach mówię, to po prostu kwestia wykorzystanego czasu. Ci ludzie mają lepsze rzeczy do roboty ze swoim czasem, na przykład faktyczną płatną pracę.

Na początku kod jest dziełem jednej osoby i prawdopodobnie jest niewielki. Mały kod nie musi być czysty. A raczej wysiłek potrzebny do wyczyszczenia kodu jest większy niż korzyść.

Z biegiem czasu kod jest bardziej stosem łatek wielu różnych ludzi. Autorzy łat nie czują prawa własności do kodu, chcą tylko dodania tej jednej funkcji lub naprawienia tego błędu w najprostszy możliwy sposób.

Właściciel nie ma czasu na sprzątanie i nikogo to nie obchodzi.

Kod staje się coraz większy. I brzydkie.

Ponieważ coraz trudniej jest znaleźć sposób na obejście kodu, ludzie zaczynają dodawać funkcje w niewłaściwym miejscu. I zamiast naprawiać błędy, dodają obejścia innych miejsc w kodzie.

W tym momencie nie chodzi tylko o to, że ludzie się tym nie przejmują, nie mają już odwagi posprzątać, ponieważ boją się zepsucia.

Miałem ludzi opisujących podstawy kodu jako „okrutną i niezwykłą karę”.

Moje osobiste doświadczenia nie są wcale takie złe, ale widziałem kilka bardzo dziwnych rzeczy.


23
Jeśli wyeliminujesz słowa „otwarty” i „źródło” w tej odpowiedzi, będzie ono nadal tak samo prawdziwe.
Stephen M. Webb,

Powiedziałbym, że to samo dotyczy oprogramowania zamkniętego.
Mark Rotteveel

3

Wydaje mi się, że pytasz, jak to działa, nawet jeśli nikt nie robi tego, co powinien. A jeśli to działa, to dlaczego mamy robić te rzeczy ?

Odpowiedź, IMHO, jest taka, że ​​działa ona „wystarczająco dobrze” , znana również jako filozofiagorsze jest lepsze ” . Zasadniczo, pomimo skalistej historii między open source a Billem Gatesem, obaj de facto przyjęli ten sam pomysł, że większość ludzi dba o funkcje, a nie błędy .

To oczywiście prowadzi nas również do „ normalizacji dewiacji ”, która prowadzi do sytuacji takich jak Heartbleed , gdzie dokładnie tak, jak gdyby chciał odpowiedzieć na twoje pytanie, ogromna, zarośnięta kupa spaghetti z otwartym kodem źródłowym o nazwie OpenSSL stała się „ nieoczyszczona ” przez około dziesięć lat , kończąc się ogromną luką w zabezpieczeniach dotykającą tysiące milionów ludzi .

Rozwiązanie było wymyślić zupełnie nowy system o nazwie libressl , który będzie używany kod clean-owski i oczywiście prawie nikt nie używa go .

Jak więc utrzymywane są ogromne, źle zakodowane projekty open source? Odpowiedź jest w pytaniu. Wiele z nich nie jest utrzymywanych w czystości. Są one losowo instalowane przez tysiące różnych osób, aby uwzględnić przypadki użycia na różnych dziwnych maszynach i sytuacjach, na których programiści nigdy nie będą mieli dostępu do testowania. Kod działa „wystarczająco dobrze”, dopóki nie zadziała, gdy wszyscy wpadną w panikę i postanowią rzucić pieniądze na problem .

Dlaczego więc miałbyś zawracać sobie głowę robieniem czegoś „ we właściwy sposób ”, jeśli nikogo innego nie ma?

Odpowiedź brzmi: nie powinieneś. Albo to robisz, albo nie , a świat kręci się niezależnie, ponieważ ludzka natura nie zmienia się na skalę ludzkiego życia . Osobiście staram się pisać czysty kod, ponieważ podoba mi się sposób, w jaki to robi.


1
Tak wiele linków ... na pierwszy rzut oka myślałem, że ta odpowiedź mogła być połączona z reklamami unoszącymi się w powietrzu lub że była to strona Wikipedii.
Jonny Henly

2

To, co stanowi dobry kod, zależy od kontekstu, a klasyczne książki, którymi się kierujesz, są, jeśli nie zbyt stare, aby omawiać open source, przynajmniej część tradycji toczącej niekończącą się wojnę przeciwko złym wewnętrznym bazom kodów. Łatwo więc przeoczyć fakt, że biblioteki mają zupełnie inne cele i są odpowiednio napisane. Rozważ następujące kwestie, bez określonej kolejności:

  • Kiedy importuję bibliotekę lub bibliotekę, prawdopodobnie nie jestem wystarczającym ekspertem od jej wewnętrznej struktury, aby dokładnie wiedzieć, jakiej niewielkiej części zestawu narzędzi potrzebuję do wszystkiego, nad czym pracuję, chyba że kopiuję co Odpowiedź Stack Exchange kazała mi to zrobić. Więc zaczynam pisać from A import(jeśli, powiedzmy, w Pythonie) i sprawdzam, co się pojawi. Ale to oznacza, że ​​to, co widzę na liście, musi odzwierciedlać logiczne zadania, które muszę pożyczyć, i to właśnie musi być w bazie kodu. Niezliczone metody pomocnicze, które sprawiają, że jest krótszy, po prostu mnie zmieszają.
  • Biblioteki są dla najbardziej niedoświadczonego programisty próbującego użyć algorytmu, o którym większość ludzi ledwo słyszała. Potrzebują zewnętrznej dokumentacji, która musi dokładnie odzwierciedlać kod, czego nie można zrobić, jeśli będziemy refaktoryzować wszystko, aby zadowolić zwolenników krótkich metod i robienie jednego.
  • Każda metoda biblioteczna, którą ludzie pożyczają, może złamać kod na całym świecie z katastrofalnymi konsekwencjami, jeśli zostanie usunięta lub nawet przemianowana. Jasne, chciałbym, żeby sklearn poprawił literówkę w Kalinski-Harabasz , ale mogłoby to spowodować kolejny incydent z lewą podkładką . Z mojego doświadczenia wynika, że ​​największym problemem związanym z ewolucją bibliotek jest to, że zbyt mocno próbują zaadaptować jakąś nową „dobrą” poprawkę do struktury wszystkiego.
  • Wewnętrznie komentarze są w większości w najlepszym razie złem koniecznym, z wielu powodów nie muszę się cofać (chociaż te punkty nieco przesadzają). Dobry komentarz mówi, dlaczego kod działa, a nie jak. Ale biblioteki wiedzą, że ich czytelnicy są kompetentnymi programistami, którzy nie mogli, powiedzmy, pisać-algebry liniowej, wychodząc z papierowej torby. Innymi słowy, wszystko wymaga komentowania: dlaczego to działa! (OK, to kolejna przesada.) Dlatego właśnie widzisz linię podpisu, 100-liniowy blok komentarza, 1 linię kodu, który mógł dosłownie przejść na linię podpisu (oczywiście, jeśli pozwala na to język).
  • Załóżmy, że zaktualizujesz coś w Github i poczekaj, czy kod zostanie zaakceptowany. Musi być jasne, dlaczego zmiana kodu działa. Wiem z doświadczenia, że ​​refaktoryzacja w celu uczynienia kempingu czystszym w ramach funkcjonalnego zatwierdzenia często oznacza wiele oszczędności linii, zmiany układu i zmiany nazwy, co utrudnia pracę bez wynagrodzenia, a także powoduje inne wyżej wymienione problemy.

Jestem pewien, że ludzie z większym doświadczeniem niż ja mogą wymienić inne punkty.


O pierwszym punkcie. Dlatego masz metody publiczne / prywatne. Udostępniasz publiczny interfejs API, który wewnętrznie wywołuje metody prywatne lub wewnętrzne. Drugi punkt jest również niedokładny. Nie widzę powodu, dla którego nie możesz mieć dokumentacji na temat krótkiej metody publicznej, a następnie wywołać wiele małych.
FCin

@FCin Jest to realne podejście, o ile opiekunowie pamiętają, aby zawsze używać poprawnego słowa kluczowego przed każdą metodą, gdy przychodzą i odchodzą. Lub mogą po prostu zrobić coś łatwiejszego i mniej podatnego na błędy.
JG

W językach takich jak C #, Java (o których zwykle mówi wujek Bob), modyfikatory dostępu są najbardziej podstawowym narzędziem używanym do pisania dowolnego kodu. Użycie poprawnego słowa kluczowego jest częścią pisania dowolnego kodu.
FCin

@FCin Rzadziej są wyrażane w innych językach, ale pracowałem nawet nad wewnętrznymi bazami kodów C #, w których ludzie niekoniecznie używali modyfikatorów, które powinni mieć.
JG

Dlatego powinni przeczytać książkę wuja Boba :)
FCin

2

Jest już wiele dobrych odpowiedzi - chcę dać perspektywę opiekuna oprogramowania typu open source.

Moja perspektywa

Jestem opiekunem wielu takich projektów z mniej niż świetnym kodem. Czasami nawet nie udaje mi się ulepszyć takiego kodu z powodu problemów związanych ze zgodnością, ponieważ biblioteki są pobierane miliony razy w tygodniu.

Utrudnia to utrzymanie - jako podstawowy członek Node.js mam część kodu, której boję się dotknąć, ale jest wiele do zrobienia niezależnie od tego i ludzie z powodzeniem korzystają z platformy i cieszą się nią. Najważniejsze, że to działa.

Na czytelnym kodzie

Kiedy powiesz:

Odkryłem, że kod w wielu z nich jest daleki od zasad adresowanych do pisania czystego kodu - np. Metody zawierające setki wierszy kodu.

Linie kodu nie są doskonałą miarą czytelności. W badaniu, które podłączyłem do jądra Linuksa, przeanalizowano, a ankieta wśród programistów wykazała, że ​​„zwykły” kod (kod, którego ludzie zasadniczo oczekują) i spójny kod jest lepszy niż „czysty” kod w zrozumiałości. Jest to również zgodne z moim osobistym doświadczeniem.

Niektóre projekty open source nie są zbyt przyjazne

Linus „słynny” powiedział, że Linux nie powinien mieć wbudowanego debuggera, ponieważ ludzie używający debuggerów nie są wystarczająco dobrzy, aby pracować na Linuksie i nie chce przyciągać ich więcej.

Osobiście absolutnie nie zgadzam się z jego stanowiskiem - ale ludzie też to robią.


1

Oprogramowanie typu open source niekoniecznie oznacza, że ​​zaangażowanych jest wielu autorów. Gdy oprogramowanie (lub jednostka oprogramowania) jest pisane przez jednego autora, często pojawiają się długie funkcje.

Wynika to z natury procesu rozwoju. Prosta metoda z czasem się wydłuża, dodaje się nowe funkcje i naprawia błędy.

Długie metody poważnie ograniczają zrozumienie funkcjonalności dla nowych autorów. Jednak w przypadku jednego autora rzadko stanowi to problem, a problem ten można przeoczyć. Inną naturą otwartego oprogramowania jest fakt, że wiele programów nie jest aktywnie rozwijanych, dlatego nie ma pracy refaktoryzacyjnej, która na przykład podzieliłaby złożone metody na wiele prostych metod.

Nie pokazałeś żadnych przykładów, ale z mojego zrozumienia jest to często związane z językiem programowania. Niektóre języki od samego początku egzekwują ścisłe reguły dotyczące szarpania i testowania ciężkich jednostek (a nawet TDD). Zarówno kłaczkowanie, jak i testy jednostkowe zwykle zapobiegają temu problemowi (trudno jest testować kompleksowo / długie metody).

Zasadniczo trudniej jest wyczyścić kod, jeśli oprogramowanie jest opracowywane przez jednego autora, a inni autorzy naprawiają tylko małe problemy.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.