Skąd programiści i programiści wiedzą, że mają rację?

Jeśli zapytasz programistów, dlaczego powinni pisać czysty kod, odpowiedzią numer jeden, którą otrzymasz, jest łatwość konserwacji. Chociaż jest to na mojej liście, mój główny powód jest bardziej bezpośredni i mniej altruistyczny: nie mogę powiedzieć, czy mój nowy kod jest poprawny, jeśli jest zbyt brudny. Przekonałem się, że tak bardzo skupiłem się na poszczególnych funkcjach i liniach kodu, że kiedy kończę mój pierwszy szkic i cofam się, aby ponownie spojrzeć na duży obraz, czasami nie pasuje do siebie. Spędzenie godziny lub dwóch refaktoryzacji dla czystości często odkrywa błędy kopiowania / wklejania lub warunki brzegowe, które były bardzo trudne do wykrycia w szorstkim ciągu.

Jednak niektórzy uważają, że czasami celowe jest wpisywanie brudnego kodu w celu wysyłki oprogramowania, z planem „wyczyszczenia go później”. Czy istnieje jakaś praktyczna technika, która daje im pewność co do poprawności kodu, gdy czytelność jest mniejsza niż idealna? Czy to umiejętność, którą warto rozwijać? A może brak zaufania do kodu jest dla niektórych osób łatwiejszy do zaakceptowania?

Kod prawdopodobnie nie jest poprawny.

Może to jednak nie mieć znaczenia.

Szybka i brudna może być właściwą drogą w sytuacjach, gdy:

• Kod ma krótki czas życia . Na przykład przekształcasz wiele danych w standardowy format za pomocą programu ad-hoc.
• Negatywny wpływ awarii jest niewielki :
  • Dane, które transformujesz, nie są krytyczne, a błędy w nich można łatwo poprawić
  • Użytkownik końcowy jest sympatycznym programistą, który będzie rozumował komunikaty o błędach i omijał je, powiedzmy, masując dane wejściowe.

Czasami nie jest ważne, aby kod był solidny i obsługiwał wszystkie możliwe dane wejściowe. Czasami musi po prostu obsługiwać znane dane, które masz pod ręką.

W takiej sytuacji, jeśli testy jednostkowe pomogą ci szybciej napisać kod (tak jest w moim przypadku), użyj ich. W przeciwnym razie, kod szybki i brudny, załatw sprawę. Błędy, które się nie uruchamiają, nie mają znaczenia. Błędy, które naprawiasz lub pracujesz w locie, nie mają znaczenia.

To, co absolutnie niezbędne, to to, że nie błędnie zdiagnozujesz te sytuacje. Jeśli kodujesz szybko i nieczysto, ponieważ kod zostanie użyty tylko raz, wówczas ktoś decyduje się na ponowne użycie kodu w jakimś projekcie, który zasługuje na lepszy kod, ten kod zasługuje na większą ostrożność.

Oni nie. Obecnie pracuję nad bazą kodu stworzoną przez „szybkich i brudnych” programistów, którzy „wyczyściliby ją później”. Dawno minęły, a kod żyje dalej, trzeszcząc w stronę zapomnienia. Kowbojscy koderzy po prostu nie rozumieją wszystkich potencjalnych trybów awarii, jakie może mieć ich oprogramowanie i nie rozumieją ryzyka, na jakie narażają firmę (i klientów).

Okej, ryzykując całkowitą przynętą, zamierzam „diabłów popierać” pogląd przeciwny.

Proponuję, abyśmy jako programiści nadmiernie martwili się takimi rzeczami, jak właściwa praktyka i czystość kodu. Sugeruję, że chociaż te rzeczy są ważne, nic nie ma znaczenia, jeśli nigdy nie wyślesz .

Każdy, kto był w tym biznesie przez pewien czas, prawdopodobnie zgodziłby się, że można będzie bawić się oprogramowaniem w nieskończoność. Duke Nukem Forever, moi przyjaciele. Nadchodzi czas, kiedy ta przyjemna w obsłudze funkcja lub tak pilna praca refaktoryzacyjna powinny zostać odłożone na bok, a rzecz powinna się nazywać GOTOWA.

Wiele razy o to walczyłem. ZAWSZE jest jeszcze jedna poprawka, coś innego, co „należy” zrobić, aby było „właściwe”. ZAWSZE możesz to znaleźć. W pewnym momencie, w prawdziwym świecie, wystarczająco dobry musi być wystarczająco dobry. Żadne rzeczywiste oprogramowanie wysyłkowe nie jest idealne. Żaden. W najlepszym razie jest wystarczająco dobry.

Tacy programiści prawie nigdy nie wiedzą, że dobrze to zrobili, tylko w to wierzą . Różnica może nie być łatwa do zauważenia.

Pamiętam, jak programowałem, zanim dowiedziałem się o testach jednostkowych. I pamiętam to poczucie pewności siebie na zupełnie innym poziomie po przeprowadzeniu pierwszego przyzwoitego zestawu testów jednostkowych. Nie wiedziałem, że taki poziom zaufania do mojego kodu istnieje wcześniej.

Dla kogoś, kto nie ma tego doświadczenia, nie można wyjaśnić różnicy. Dlatego mogą nawet rozwijać się w trybie kodowania i modlitwy przez całe życie, życzliwie (i nieświadomie) wierząc, że robią, co w ich mocy, biorąc pod uwagę okoliczności.

To powiedziawszy, naprawdę mogą istnieć wspaniali programiści i wyjątkowe przypadki, kiedy naprawdę uda się utrzymać całą przestrzeń problemową w jego umyśle, w stanie pełnego przepływu. Doświadczyłem takich rzadkich chwil, kiedy doskonale wiedziałem, co napisać, kod po prostu wyleciał ze mnie bez wysiłku, mogłem przewidzieć wszystkie specjalne przypadki i warunki brzegowe, a wynikowy kod po prostu działał . Nie mam wątpliwości, że istnieją geniusze programowania, którzy mogą pozostać w takim stanie przepływu przez dłuższy czas lub nawet przez większość swojego czasu, a to, co tworzą, to piękny kod, pozornie bez wysiłku. Sądzę, że takie osoby mogą nie mieć potrzeby pisania drobnych testów jednostkowych, aby zweryfikować to, co już wiedzą. A jeśli naprawdę jesteś geniuszem, może być OK (chociaż nawet wtedy nie będziesz w pobliżu tego projektu na zawsze i powinieneś pomyśleć o swoich następcach ...). Ale jeśli nie ...

I spójrzmy prawdzie w oczy, prawdopodobnie nie jesteś. Ja sam wiem, że nie jestem. Miałem rzadkie chwile spływu - i niezliczone godziny żalu i smutku, zwykle spowodowane własnymi błędami. Lepiej bądź szczery i realistyczny. W rzeczywistości uważam, że najwięksi programiści są w pełni świadomi własnej omyłki i błędów z przeszłości, więc świadomie rozwinęli nawyk podwójnego sprawdzania swoich założeń i pisania tych małych testów jednostkowych, aby zachować bezpieczeństwo. ( „Nie jestem świetnym programistą - po prostu dobrym programistą o wielkich nawykach.” - Kent Beck.)

Testy jednostkowe . To jedyny sposób, aby mieć zaufanie do dowolnego kodu (brudnego lub nie).

Na marginesie;

skróty powodują duże opóźnienia (Pippin)

Dobrze jest nauczyć się akceptować fakt, że żaden system oprogramowania o rozsądnej złożoności nie będzie idealny bez względu na to, ile testów jednostkowych i poprawek kodu jest wykonywanych. Pewien stopień chaosu i wrażliwość na nieoczekiwane zawsze czają się w kodzie. Nie oznacza to, że nie należy próbować tworzyć dobrego kodu ani przeprowadzać testów jednostkowych. Są to oczywiście ważne. Należy znaleźć równowagę, która będzie się różnić w zależności od projektu.

Umiejętność, którą należy rozwinąć, to zrozumienie, jaki poziom „doskonałości” należy zastosować w przypadku konkretnego projektu. Na przykład, jeśli piszesz aplikację do elektronicznej dokumentacji medycznej z 12-miesięczną osią czasu projektu, będziesz chciał poświęcić znacznie więcej czasu na testowanie i upewnienie się, że twój kod jest łatwy do utrzymania, niż w przypadku jednorazowej aplikacji internetowej do rejestracji konferencji które należy wdrożyć do piątku. Problemy pojawiają się, gdy ktoś robiący aplikację EMR staje się niechlujny lub aplikacja rejestracyjna nie jest wdrażana na czas, ponieważ programista jest zbyt zajęty poprawianiem kodu.

Szybkie i brudne jest idealnie w obrębie podsystemu . Jeśli masz dobrze zdefiniowany interfejs między badziewiem a resztą systemu oraz dobry zestaw testów jednostkowych, które sprawdzają, czy brzydki szybki i brudny kod działa prawidłowo, może być zupełnie w porządku.

Na przykład może masz ohydny hack wyrażeń regularnych i przesunięcia bajtów, aby przeanalizować niektóre pliki pochodzące od strony trzeciej. Załóżmy, że masz test potwierdzający, że wynik analizowania przykładowych plików jest tym, czego oczekujesz. Możesz to wyczyścić, abyś mógł ... Nie wiem, reagować szybciej, gdy strona trzecia zmieni format pliku? To po prostu nie zdarza się dość często. Bardziej prawdopodobne jest, że zmienią się one na zupełnie nowy interfejs API, a ty wyrzucisz stary parser i podłączysz nowy, który jest zgodny z tym samym interfejsem API, i voila, gotowe.

Problemem jest szybkie i brudne rozwiązanie, gdy architektura jest szybka i brudna. Twój główny obiekt domeny musi być dobrze przemyślany, a interfejsy, ale krawędzie twojego systemu mogą zwykle być nieuporządkowane bez konieczności płacenia za piper.

Oto historia szybkiego i brudnego programisty, którego znam.

Znam osobę, która uważa testy jednostkowe za stratę czasu. Po wielu kłótniach w końcu napisał jeden. Składał się z jednej długiej metody posypanej && i || i zwrócił wartość logiczną do assertTrue. Instrukcja obejmuje 20 wierszy. Z drugiej strony napisał klasę, w której każda metoda miała jedną linię, a główna ponad 1000 linii bez białych spacji. To była ściana tekstu. Kiedy przejrzałem jego kod i wstawiłem kilka nowych wierszy, zapytał „dlaczego”. Powiedziałem „Ze względu na czytelność”. Westchnął i usunął je. Na górze umieścił komentarz: „Nie dotykaj, to działa!”

Ostatnim razem, gdy z nim rozmawiałem, napisał kod dla strony internetowej dla firmy. Próbował znaleźć błąd. Ostatnie 3 dni spędził robiąc to przez 8 godzin dziennie. Nieco później rozmawiałem z nim ponownie i okazało się, że jego kolega z zespołu zmienił wartość literału i nie zaktualizował go gdzie indziej. To nie było stałe. Więc zmienił też inne literały, aby naprawić błąd. Skarżył się na kod spaghetti kolegi z drużyny. Powiedział mi: „Haha, czy nie wszyscy wiemy, jak to jest spędzać całą noc z debuggerem, nie przespać jednego paskudnego robaka”. Uważa, że ​​jest to coś, co robią naprawdę dobrzy programiści i naprawdę się z tym czuje.

Uważa też, że czytanie książek o programowaniu i blogów jest bezużyteczne. Mówi: „po prostu zacznij programować”. Robi to od 12 lat i uważa, że ​​jest doskonałym programistą. / facepalm

Oto trochę więcej.

Innym razem pisaliśmy klasę DatabaseManager dla naszej aplikacji internetowej. Umieścił w niej wszystkie wywołania bazy danych. To była klasa Boga z ponad 50 metodami dla każdej możliwej rzeczy. Zasugerowałem podzielenie go na podklasy, ponieważ nie każdy kontroler musi wiedzieć o każdej metodzie bazy danych. Nie zgodził się, ponieważ „łatwo było” mieć tylko jedną klasę dla całej bazy danych, a dodanie nowej metody było „szybkie”, gdy tylko jej potrzebowaliśmy. W końcu DatabaseManager miał ponad 100 publicznych metod od uwierzytelnienia użytkownika do sortowania lokalizacji stanowisk archeologicznych.

Moją lekcją unikania szybkich i brudnych rzeczy było to, że miałem sześć miesięcy na dostarczenie tego, co zostało oszacowane (niedoszacowane) na rok pracy. Przed rozpoczęciem pracy postanowiłem zbadać metodologię. W końcu zainwestowałem trzy miesiące badań i byłem w stanie dostarczyć wyniki w pozostałych trzech miesiącach.

Osiągnęliśmy duże korzyści, identyfikując wspólną funkcjonalność i budując biblioteki wymagane do obsługi tych wymagań. Nadal widzę programistów piszących własny kod, gdy są dostępne procedury biblioteczne. Ci koderzy często przepisują lub co najwyżej wycinają i wklejają ten sam kod, gdy muszą później rozwiązać ten sam problem. Poprawki błędów niezmiennie wychwytują tylko niektóre kopie kodu.

Jeden programista udzielił wymownej odpowiedzi, gdy poprosiłem go o użycie kodu bibliotecznego: „Czy to nie oszustwo? Musiałem napisać cały swój własny kod w szkole”.

W niektórych przypadkach wydaje mi się, że może istnieć duży zestaw testów regresji, które znajdą „wszystkie” błędy i zweryfikują zachowanie, umożliwiając w ten sposób szybką i brudną technikę kodowania. Ale przede wszystkim jest to kwestia złego planowania projektu i menedżera, który uważa, że ​​ważniejsze jest, aby to zrobić, niż zrobić to dobrze.

I zapomnij o „posprzątaj później”, to się nigdy nie zdarza. W rzadkich przypadkach zdarza się, że programista zapomina większość kodu, dzięki czemu zadanie jest znacznie droższe, niż gdyby zrobił to dobrze za pierwszym razem.

Produkt jest wysyłany.

Kod nie istnieje w próżni. Cierpiałem nieopisany żal gaszący ogień w następstwie szybkiego i brudnego i kowbojskiego kodowania. Ale czasami ukończenie produktu jest priorytetem, nie zastanawianie się, jak napisać najlepszy kod. Ostatecznie, jeśli produkt zostanie dostarczony i będzie działał wystarczająco dobrze, użytkownicy i klienci nie będą wiedzieli ani obchodzić się z tym, jak „zły” jest kod w środku, i przyznam, że były chwile, kiedy w ogóle mnie to nie obchodziło tak długo, jak wyszedłem przez drzwi.

Tak, dotyczy to kwestii organizacyjnych i „nigdy nie powinno się zdarzyć”. Ale jeśli zdarzy ci się pisać kod w organizacji, która jest źle zarządzana i ściśle związana z terminami, na poziomie indywidualnego programisty masz ograniczone możliwości.

Nie sądzę, że mogą szczerze powiedzieć, że dobrze to zrobili, jeśli nie jest to łatwe do utrzymania. Jeśli przyznają, że muszą „później to posprzątać”, prawdopodobnie istnieje coś, czego nie przemyśleli wystarczająco. Dokładne przetestowanie pozwoli naprawdę odkryć wszelkie problemy z brudnym kodem.

Ja osobiście nie chciałbym rozwijać umiejętności „pisania brudnego kodu” i być pewnym jego poprawności. Wolę napisać poprawny kod za pierwszym razem.

Skąd oni wiedzą, że dobrze to zrobili? Testowanie to prosta odpowiedź.

Jeśli ich kod został dokładnie przetestowany przez dobry zespół ds. Kontroli jakości i przejdzie pomyślnie, powiedziałbym, że dobrze go zrozumieli.

Pisanie szybkiego i brudnego kodu nie jest czymś, co powinno być nawykiem, ale jednocześnie zdarzają się sytuacje, w których możesz spędzić 20 minut na pisaniu kodu, który może być sklasyfikowany jako brudny lub 4 godziny refaktoryzacji dużej ilości kodu, aby zrobić to dobrze. W świecie biznesu czasami wystarczy 20 minut na wykonanie zadania, a gdy dotrzymasz terminów, szybka i brudna może być jedyną opcją.

Sam byłem po obu stronach tego, musiałem naprawić brudny kod i musiałem napisać własny, aby obejść ograniczenia systemu, w którym się rozwijałem. Powiedziałbym, że mam zaufanie do kodu, który ja napisałem, ponieważ chociaż był brudny i trochę włamany, czasami upewniłem się, że został dokładnie przetestowany i miał dużo wbudowanej obsługi błędów, więc jeśli coś pójdzie nie tak, nie zniszczy to reszty systemu.

Kiedy patrzymy z góry na tych szybkich i brudnych programistów, musimy pamiętać o jednej rzeczy, klient zasadniczo nie płaci, dopóki nie ma produktu, jeśli zostanie wysłany i przejdzie testy UAT i znajdzie błędy z szybkiego i brudnego kodu, to jest o wiele mniej prawdopodobne, że wycofają się, gdy będą mieli prawie działający produkt przed nimi, ale jeśli nie mają nic, a ty im mówisz: „wkrótce to zrobimy, my tylko naprawiamy x” lub „to było opóźnione, ponieważ musieliśmy dostać y działa idealnie ”, są bardziej skłonni do poddania się i pójścia z konkurentem.

Oczywiście, ponieważ ten obraz pokazuje, że nikt nie powinien lekceważyć niebezpieczeństwa szybkiego i brudnego kodu!

Nie sądzę, że powinieneś zacząć iść tą drogą. Szybki i brudny może dać czasową korzyść szybszego ukończenia, ale zawsze płacisz dziesięciokrotnie za zrobienie tego w końcu.

Moim zdaniem nauka oceniania poprawności kodu Q&D nie jest umiejętnością wartą rozwijania, ponieważ jest to po prostu zła praktyka. Dlatego:

Nie sądzę, by „szybkie i brudne” i „najlepsze praktyki” były w ogóle zgodne. Wielu programistów (łącznie ze mną) wypaliło szybki i brudny kod w wyniku przekrzywienia potrójnych ograniczeń . Kiedy musiałem to zrobić, był to zwykle efekt pełzania zakresu i zbliżającego się terminu. Wiedziałem, że kod, który sprawdzam, jest zasysany, ale wypluł właściwe dane wyjściowe, biorąc pod uwagę zestaw danych wejściowych. Bardzo ważne dla naszych interesariuszy, wysyłamy na czas.

Spojrzenie na oryginalny raport CHAOS wyraźnie pokazuje, że Q&D nie jest dobrym pomysłem i zabije budżet później (w trakcie konserwacji lub w trakcie rozbudowy). Nauczenie się, jak oceniać poprawność kodu Q&D, to strata czasu. Jak powiedział Peter Drucker: „Nie ma nic tak bezużytecznego, jak robienie skutecznie tego, czego w ogóle nie należy robić”.

Nie wiem, czy mój nowy kod jest poprawny, jeśli jest zbyt brudny.

„Brudny” oznacza różne rzeczy dla różnych ludzi. Dla mnie oznacza to przede wszystkim poleganie na rzeczach, o których wiesz, że prawdopodobnie nie powinieneś polegać, ale o których wiesz, że możesz spodziewać się pracy w najbliższym czasie. Przykłady: zakładając, że przycisk ma wysokość 20 pikseli zamiast obliczać wysokość; twarde kodowanie adresu IP zamiast rozpoznawania nazwy; liczenie na tablicę do posortowania, ponieważ wiesz, że tak jest, mimo że metoda, która zapewnia tablicę, nie gwarantuje jej.

Brudny kod jest delikatny - możesz go przetestować i wiedzieć, że teraz działa , ale całkiem niezły zakład, że w pewnym momencie w przyszłości się złamie (albo zmusi wszystkich do chodzenia po skorupkach jaj w obawie przed jego złamaniem).

Ryzykując, że zabrzmi to trochę kontrowersyjnie, twierdzę, że nikt tak naprawdę NIE WIE, że ich kod jest w 100% poprawny i w 100% bez błędów. Nawet jeśli masz naprawdę dobry zasięg testu i rygorystycznie stosujesz dobre praktyki BDD / TDD, nadal możesz opracować kod zawierający błędy i tak, który może nawet zawierać skutki uboczne!

Samo pisanie kodu i zakładanie, że działa, oznacza nadmierną pewność ze strony programisty, że wyczuwa on własne umiejętności tego programisty, a gdy pojawią się problemy (które nieuchronnie będą), wysiłek debugowania i utrzymania kodu będzie kosztowny, szczególnie jeśli inny programista potrzebuje aby zachować kod później. Prawdziwa różnica polega na zastosowaniu dobrych praktyk inżynierii oprogramowania, które zapewniają prawdziwą pewność, że Twój kod prawdopodobnie będzie działał przez większość czasu, a jeśli wystąpi błąd, łatwiej jest debugować i znacznie mniej kosztowne w zmianie i utrzymaniu, niezależnie od osoby, która później pracuje nad tym kodem.

Istotną kwestią jest to, że dobrze przemyślany i dobrze przetestowany kod pozwoli INNYM na zaufanie do twojego kodu, co w większości przypadków jest ważniejsze niż twoje zaufanie.

Jeśli brudny kod jest dobrze przetestowany, można mu zaufać. Problem polega na tym, że testowanie brudnego kodu przez jednostkę jest zwykle bardzo trudne i kłopotliwe. Właśnie dlatego TDD jest tak dobry; odsłania i usuwa brud i zapachy. Ponadto testy jednostkowe są często pierwszą rzeczą, która cierpi na utratę czasu. Więc jeśli najczystszy facet stworzył najczystszy kod, jaki kiedykolwiek napisał, nadal nie ufałbym mu ani trochę, gdyby pominął testy jednostkowe ze względu na pewność czasu.

Dobrzy programiści (Quick & Dirty i inni) nie mają pychy, by założyć, że mają rację. Zakładają, że wszystkie duże systemy mają błędy i wady, ale w pewnym momencie mogą być wystarczająco przetestowane i sprawdzone, aby mieć wystarczająco niskie ryzyko lub wystarczająco niskie koszty awarii, które kod może wysłać.

Dlaczego więc istnieją tak zwani programiści Quick & Dirty? Moja hipoteza dotyczy selekcji darwinowskiej. Programiści, którzy wysyłają sprawny kod szybko, czasami wysyłają przed wysyłką konkurencji, budżet się kończy lub firma bankrutuje. Dlatego ich firmy wciąż działają, zatrudniając nowych programistów, aby narzekać na bałagan, który należy usunąć. Dostarczane są również tak zwane czyste kody, ale niezbyt zróżnicowane, aby doprowadzić do wyginięcia koderów Quick & Dirty.

Prawdopodobnie można by pomyśleć, że nieoptymalna część kodu może nie mieć znaczenia, ze względu na krótki czas życia, niewielki wpływ na biznes lub mało czasu na wykonanie. Prawidłowa odpowiedź jest taka, że ​​tak naprawdę nie wiesz. Za każdym razem, gdy słyszę, jak ktoś mówi, że „jest to niewielka cecha” lub „sprawmy, by było to tak szybkie i tak proste, jak to tylko możliwe” i poświęcamy mało czasu na zastanawianie się nad właściwym projektem, jedynymi dwiema rzeczami, które faktycznie występują są:

1-) Projekt staje się większy, a motywacja zespołu mniejsza, pracując na kodzie pełnym „szwów”. W takim przypadku projekt prawdopodobnie przejdzie do szybkiego pasa w kierunku chaosu.

2-) Projekt staje się znany jako rozwiązanie nieoptymalne, a jego stosowanie zaczyna być zniechęcane na korzyść nowego rozwiązania lub refaktoryzacji, która jest tak droga jak nowe rozwiązanie.

Staraj się zawsze robić najlepszy możliwy kod. Jeśli nie masz wystarczająco dużo czasu, wyjaśnij, dlaczego potrzebujesz więcej. Nie narażaj się na źle wykonaną pracę. Bądź zawsze lepszym profesjonalistą. Nikt nie może cię za to ukarać, jeśli jesteś rozsądny. Jeśli tak, to nie jest miejsce, w którym powinieneś pracować.

Porozmawiaj z seniorem i oceń wpływ ewentualnych awarii. Na przykład sytuacja, w której można naprawić zabrudzenie, zajmuje 1 dzień, a solidny kod wymaga zmiany projektu i architektury, co może zająć 4-6 miesięcy + dodatkowy czas sprawdzania poprawności, aby całkowicie zweryfikować wszystkie przepływy pracy, które zostały zmienione w wyniku zmiany projektu.

Musimy również podjąć decyzję na podstawie czasu + pojemności + priorytetów na liście. Dobra dyskusja w zespole z seniorami lub osobami z większym doświadczeniem może pomóc w podjęciu decyzji, która najlepiej pasuje do zespołu i jego rezultatów.

Czysty kod jest pierwszym i najważniejszym podejściem, w którym jako brudny kod zapisuje się eskalacje, decyzje klientów go / no go, pokazuje stopery, reputację organizacji na stawce i wiele innych, gdy brudny kod przechodzi do czystego kodu.