Rozwój sieci 10 przeciwstawnych kodowań, których musisz unikać

Projektowanie architektury strony internetowej lub aplikacji lub konfigurowanie efektywnego procesu kodowania często sprawiają, że mamy do czynienia z powtarzającymi się problemami. Nie musimy koniecznie rozwiązywać tych problemów związanych z projektowaniem oprogramowania od podstaw rozwiązania na poziomie architektonicznym mogą być ponownie wykorzystane w taki sam sposób jak fragmenty kodu na poziomie mikro.

Wzorce projektowe są generalnie rozwiązania wielokrotnego użytku w niektórych scenariuszach to może przydaje się do rozwiązywania często występujących problemów, i może bardzo pomóc nam zoptymalizować nasz kod.

Podczas gdy wzorce projektowe są świetnym sposobem na ulepszenie naszego procesu rozwoju dzięki zastosowaniu sprawdzonych formuł, czasami możemy się z nimi pomylić. Nazywa się to antypatiami.

Czym są Antyporosty?

Termin “antipattern” został ukuty w książce AntiPatterns w 1998 roku ponownie wykorzystane rozwiązania, które początkowo wydają się przydatne, ale później okazuje się zrobić więcej szkody niż pożytku.

Może się to zdarzyć z różnych powodów, na przykład, jeśli nie korzystamy z wzorców we właściwym kontekście, otoczeniu lub czasie (rozwiązania, które były skuteczne w przeszłości, nie zawsze działają w obecnych czasach) lub w innych przypadkach cały paradygmat od samego początku było po prostu źle.

Antyporosty są również często nazywane wzory awarii. Dobra wiadomość jest taka, że ​​jest możliwe do ich rozpoznania i uniknięcia.

W tym poście zajmiemy się 10 powszechnymi kodowaniami kodowania w tworzeniu stron internetowych, które mogą nas oszukać i myśleć, że mamy dobrze zoptymalizowany kod. (Zauważ, że antypatry wymienione w tym poście niekoniecznie są takie same jak te, które można znaleźć w książce wspomnianej powyżej).

1. Optymalizacja przedwczesna

Dobry czas jest kluczowym czynnikiem w optymalizacji kodu. Możemy łatwo odtworzyć antypatię “przedwczesna optymalizacja”, jeśli zwrócimy uwagę na małe wydajności i zoptymalizujemy dla nich zbyt wcześnie w procesie rozwoju, zanim dokładnie wiemy, co chcemy zrobić.

Według słynnego cytatu Donalda Knutha “przedwczesna optymalizacja jest źródłem wszelkiego zła“, co może być przesadą, ale nadal pokazuje, jak poważne problemy mogą spowodować przedwczesna optymalizacja.

Jeśli zoptymalizujemy wydajność, zanim stworzymy efektywną architekturę, możemy niższa czytelność kodu, robić trudniejsze debugowanie i konserwacja, i dodaj zbędne części do naszego kodu.

Aby zapobiec przedwczesnej optymalizacji, dobrze jest postępować zgodnie z zasadą programowania YAGNI (You Aren't Gonna Need It), która zaleca “zawsze wdrażaj rzeczy, kiedy ich naprawdę potrzebujesz, nigdy, gdy tylko przewidujesz, że ich potrzebujesz.”

2. Ponowne odkrywanie koła

The “odkrywanie koła na nowo” antypattern jest czasami określany jako “projektowanie w próżni”. Dzieje się tak, kiedy chcemy rób wszystko sami i napisz wszystko od podstaw, bez szukania już istniejących metod, API lub bibliotek.

Ponowne odkrycie koła to nie tylko marnowanie czasu, ale niestandardowe rozwiązania, zwłaszcza dla podstawowych funkcji, rzadko są tak dobre jak standardowe które zostały już przetestowane przez wielu programistów i użytkowników.

3. Piekło zależności

Przeciwieństwo “odkrywanie koła na nowo” antipattern to kolejna powszechna nazwa przeciwnika “piekło zależności”.

Jeśli zamiast pisać wszystko od podstaw, używamy zbyt wiele bibliotek zewnętrznych, które opierają się na konkretnych wersjach innych bibliotek, możemy łatwo wpaść w trudną do opanowania sytuację, gdy chcemy zaktualizować, ponieważ te dodatkowe zależności są w wielu przypadkach niezgodne ze sobą.

Piekło zależności można rozwiązać za pomocą menedżerów pakietów, które są w stanie mądrze aktualizować współzależne zależności. Jeśli problem nas przytłacza, refaktoryzacja może być dobrym pomysłem.

4. Kod spaghetti

“Kod spaghetti” jest prawdopodobnie najsłynniejszym antypisem kodu. To opisuje aplikacja trudna do debugowania lub modyfikowania z powodu braku odpowiedniej architektury.

Efektem słabego projektu oprogramowania jest pęczek kodu, który ma podobną strukturę do miseczki spaghetti, tj. splątane i zawiłe. Czytelność kodu spaghetti jest bardzo niska i zazwyczaj jest to prawie niemożliwe, aby zrozumieć, jak to dokładnie działa.

Kod Spaghetti pochodzi zazwyczaj z kodu połączenie różnych złych praktyk kodowania, taki jak kod niezawierający właściwych bloków warunkowych, posiadający wiele instrukcji goto, wyjątków i wątków, zawierających części, które należą gdzieś indziej, ma minimalne relacje między obiektami, ma funkcje lub metody, których nie można ponownie użyć, lub nie są odpowiednio udokumentowane lub w ogóle.

5. Programowanie przez Permutation

“Programowanie przez permutację” lub “programowanie przez przypadek” zdarza się, gdy próbujemy znaleźć rozwiązanie problemu, sukcesywnie eksperymentując z małymi modyfikacjami, testując je i oceniając pojedynczo, a na końcu wdrażając ten, który na początku działa.

Programowanie przez permutację może być łatwo wprowadzaj nowe błędy do naszego kodu, Co gorsza, są to błędy, których niekoniecznie rozpoznajemy od razu. W wielu przypadkach nie można również przewidzieć, czy rozwiązanie będzie działać we wszystkich możliwych scenariuszach, czy nie.

6. Kopiuj i wklej programowanie

“Skopiuj i wklej programowanie” występuje, gdy nie stosujemy zasady kodowania DRY (Don't Repeat Yourself) i zamiast tworzyć ogólne rozwiązania, wstawiamy już istniejące fragmenty kodu do różnych miejsc, a następnie edytujemy je, aby pasowały do ​​danego kontekstu.

Ta praktyka powoduje, że kod jest bardzo powtarzalny, ponieważ wstawione części kodu zwykle różnią się tylko niewielkimi rozbieżnościami.

Programowanie kopiowania i wklejania jest wykonywane nie tylko przez początkujących programistów, ale także doświadczonych programistów, ponieważ wielu z nich jest podatnych na używaj własnych, wcześniej przetestowanych, sprawdzonych fragmentów kodu do konkretnych zadań, co może łatwo prowadzić niezamierzone powtórzenia.

7. Programowanie ładunku kultowego

Nazwa “programowanie kultowego ładunku” pochodzi ze specyficznego zjawiska etnograficznego zwanego “kult ładunku”. Kulty ładunku pojawiły się na południowym Pacyfiku po drugiej wojnie światowej, kiedy przymusowy kontakt z zaawansowanymi cywilizacjami doprowadził tubylców do przekonania, że ​​wytwarzane produkty, takie jak Coca-Cola, telewizory i lodówki przynoszone przez statki towarowe na wyspy, zostały stworzone przez nadprzyrodzone metody; i jeśli wykonają magiczne obrzędy podobne do zwyczajów ludzi Zachodu, ładunek wypełniony towarami przyjdzie ponownie.

Kiedy popełniamy antypatry programowania kultowego ładunku, robimy to samo. Używamy frameworków, bibliotek, rozwiązań, wzorców projektowych itp., Które działały dobrze dla innych, bez zrozumienia, dlaczego to robimy, lub jak dokładnie działają te technologie.

W wielu przypadkach deweloperzy po prostu rytualnie rób to, co w tym czasie jest modne, bez żadnego rzeczywistego celu. Ta praktyka jest nie tylko zła, ponieważ sprawia, że ​​nasza aplikacja jest nadmiernie nadęta, ale może również łatwo wprowadzać nowe błędy do naszego kodu.

8. Przepływ lawy

Mówimy o “lawa, strumień lawy” antypat, kiedy musimy radzić sobie z kodem, który ma nadmiarowe lub niskiej jakości części że wydają się być integralne do programu, ale nie do końca rozumiemy, co to robi lub jak wpływa na całą aplikację. To sprawia, że ​​usunięcie go jest ryzykowne.

Zwykle dzieje się z stary kod, lub kiedy kod został napisany przez kogoś innego (zazwyczaj bez odpowiedniej dokumentacji) lub gdy projekt przesunął się zbyt szybko z fazy rozwoju do fazy produkcji.

Nazwa antyporosta pochodzi z jego połączenia z lawą pochodzącą z wulkanów, to znaczy z początku porusza się szybko i płynnie bez podejmowania zbyt wielu środków ostrożności, ale później krzepnie i staje się trudna do usunięcia.

Teoretycznie możemy pozbyć się lawy obszerne testy i refaktoryzacja, ale w praktyce, wdrożenie jest często trudne lub nawet niemożliwe. Ponieważ strumienie lawy mają zwykle wysokie koszty wydajności, lepiej jest im zapobiegać, konfigurując dobrze zaprojektowaną architekturę i od samego początku przepływ pracy.

9. Twarde kodowanie

“Kodowanie” jest znanym antypiratem, przed którym większość książek na temat tworzenia stron internetowych ostrzega nas w przedmowie. Twarde kodowanie to niefortunna praktyka, w której przechowujemy dane konfiguracyjne lub wejściowe, takie jak ścieżka do pliku lub nazwa zdalnego hosta, w kodzie źródłowym zamiast uzyskiwać go z pliku konfiguracyjnego, bazy danych, danych wejściowych użytkownika lub innego źródła zewnętrznego.

Główny problem z twardym kodem polega na tym działa poprawnie tylko w określonym środowisku, i na za każdym razem, gdy zmieniają się warunki, musimy zmodyfikować kod źródłowy, zwykle w wielu oddzielnych miejscach.

10. Kodowanie miękkie

Jeśli bardzo się staramy, aby uniknąć pułapki twardego kodowania, możemy łatwo natknąć się na inny antypat, zwany “miękkie kodowanie”, co jest dokładnie odwrotne.

W miękkim kodowaniu, umieszczamy rzeczy, które powinny znajdować się w kodzie źródłowym, w zewnętrznych źródłach, na przykład przechowujemy logikę biznesową w bazie danych. Najczęstszym powodem, dla którego to robimy, jest obawa, że ​​zasady biznesowe zmienią się w przyszłości, dlatego będziemy musieli przepisać kod.

W skrajnych przypadkach program może być kodowany miękko stać się tak abstrakcyjnymi i zawiłymi, że niemal niemożliwe jest ich zrozumienie (szczególnie dla nowych członków zespołu) i niezwykle trudne do utrzymania i debugowania.