Czy należy zawsze stosować najlepsze praktyki kodowania [zamknięte]

Czy podczas kodowania oprogramowania architektura powinna zawsze stanowić najlepsze praktyki lub praktyczne praktyki dotyczące budowanej aplikacji?

Jeśli tworzę dwustronicową aplikację internetową, która może funkcjonować przez 5 lat i mam 2 ulepszenia w ciągu tych 5 lat, powinienem kodować wstrzykiwanie zależności, wzorce projektowe, model-widok-kontroler z modelami widoku itp.

Należy zawsze stosować najlepsze praktyki kodowania

Zawsze? Nie, to głupie.

Najlepsze praktyki są wytycznymi. Dla większości ludzi, w większości sytuacji, jeśli zostaną wdrożone z pewną finezją, przyniosą najlepsze rezultaty. Tam właśnie zaczynasz rozważając rozwiązania. Ale będą miejsca, w których najlepsze praktyki mogą i powinny być ignorowane, ponieważ istnieją lepsze rozwiązania.

Problem polega na tym, że ludzie nie mogą patrzeć w przyszłość. A początkujący (i grupa początkujących) nieuchronnie myślą, że są w tym szczególnym scenariuszu, w którym reguły ich nie dotyczą. W razie wątpliwości skorzystaj z najlepszych praktyk. Lata debaty i doświadczenia wielu inżynierów mądrzejszych od ciebie lub mnie wykazały, że zapewniają one niezmiennie dobre wyniki. Ale żaden (lub prawie żaden) z nich nie zna twojego konkretnego problemu tak dobrze jak ty. Czasami zdarzają się wyjątkowe przypadki, w których reguły mogą być zgięte.

Tak. To oczywiste. Dlaczego nie zrobiłbyś tego, co najlepsze?

Ale nie o to chodzi. Trudność polega na ustaleniu, jaka JEST najlepsza praktyka, ponieważ aby odpowiedzieć, że musisz dokładnie wiedzieć, jakie masz wymagania i jak projekt może ewoluować na przestrzeni lat, i to jest diabelnie trudne.

Jedna dobra zasada: NIE jest jednak najlepszą praktyką, aby brać nazwy wielu wzorców projektowych i po prostu zacinać je bez zastanowienia.

Poza tym na twoje pytanie naprawdę nie można odpowiedzieć. Dokładne ustalenie, czym jest „najlepsza praktyka” w danej sytuacji, polega na tym, że jest się inżynierem oprogramowania. Musisz go zawęzić, aby uzyskać lepsze odpowiedzi.

Najlepszą praktyką jest ta, która najskuteczniej spełnia funkcjonalne i niefunkcjonalne wymagania oprogramowania dotyczące funkcji, łatwości konserwacji, wydajności itp. Jeśli taka praktyka jest zgodna z jakimś „standardem branżowym”, jest to niesamowite. Ale jeśli nie, pragmatyzm wygrywa.

Tam, gdzie obecnie pracuję, tworzymy od nowa nowy interfejs internetowy dla naszego produktu. W żaden sposób nie będzie ODPOCZYNEK; używa wyłącznie POST. Nie jest wielopoziomowy, nie używa żadnych mikrousług i nie korzysta z bazy danych NoSQL. Nie ma żadnej architektury takiej jak Enterprise Java.

Innymi słowy, wcale nie jest modny.

Zawiera jednak najnowocześniejszą platformę HTML5 , która zawiera podobne do Angulara wiązanie danych, automatyczne skalowanie do różnych typów urządzeń, takich jak urządzenia mobilne i komputery stacjonarne, integracja z interfejsem użytkownika Kendo firmy Telerik, aby wykonać wszystkie ciężkie prace, oraz w pełni zaszyfrowane i zabezpieczone kanał danych.

Co najlepsze, nastąpi to w ciągu 30 dni, a osiągnięcie tego zajęłoby armię programistów Java w architekturze Enterprise. Kod to ES6 / Typescript; to jeden z najczystszych kodów, jakie kiedykolwiek widziałem.

Nie . Najlepsze praktyki to rzeczy, które są ogólnie uważane za najlepsze w 99% przypadków, ale to nie znaczy, że zawsze mają zastosowanie w każdej sytuacji.

Jako programista Twoim zadaniem jest znać i stosować te najlepsze praktyki, ale także wiedzieć, kiedy można je bezpiecznie odrzucić.

To nie powinna być autopromocja, ale niedawno napisałem wpis na blogu związany z moją pracą na platformie Salesforce.com, który szczegółowo opisał jedną z tych okazji . Jedną ze złotych zasad jest „Nigdy nie rób zapytania w pętli”, ale ostatnio, po raz pierwszy od 7 lat pracy na platformie, miałem zupełnie uzasadniony powód, aby nie przestrzegać tej zasady.

Istotą jest to, że platforma ma ograniczenia liczby zapytań, które można wykonać w danym kontekście wykonania, ale w tym przypadku musiałem wykonać zapytanie w pętli, aby uniknąć wyczerpania miejsca na sterty, i wiedziałem, że będę dobrze w obrębie zapytania limit.

Jest to więc rzadkie, ale są chwile, w których najlepsze praktyki nie są odpowiednie dla scenariusza, więc jeśli nie pasują, nie zmuszaj ich.

Zakładam, że przez „najlepsze praktyki” masz na myśli listę zasad, które ktoś napisał w książce. Oczywiście, jeśli masz na myśli frazę dosłownie, to oczywiście powinieneś zawsze pisać najlepszy kod, jaki możesz.

Czy muszę wskazać, że nie istnieje jeden, powszechnie akceptowany zestaw „najlepszych praktyk”? W przypadku każdej zasady promowanej przez jednego eksperta prawie zawsze można znaleźć innego eksperta z jednakowymi kwalifikacjami, który mówi coś innego.

Ale do rzeczy: krótka odpowiedź: zwykle, ale nie zawsze.

Każda dziedzina ma swoje „najlepsze praktyki” i „podręczniki”. Reprezentują one zgromadzone doświadczenie i mądrość wielu, wielu ludzi przez wiele, wiele lat i nie należy ich ignorować. ALE! Zawsze są wyjątkowe okoliczności, przypadki skrajne itp. Osoba naprawdę zdolna w każdej dziedzinie wie, kiedy stosować się do zasad, a kiedy je łamać.

Powiedziałbym ogólnie: zacznij od przestrzegania zasad zawartych w podręczniku. Przestrzeganie zasad zawartych w podręczniku prowadzi do kłopotów - niepotrzebnej złożoności, niskiej wydajności itp. - to zastanów się, czy złamanie tej jednej reguły tym razem może nie być lepszym pomysłem.

Jeśli zignorujesz zasady i pójdziesz tam, gdzie prowadzi cię kaprys chwili, Twój kod prawdopodobnie będzie pomieszanym bałaganem. Nie ważne jak mądry jesteś, nie jesteś pierwszym programistą na świecie. Uczenie się na podstawie doświadczeń innych ma sens. Dlatego w naszym codziennym życiu mamy rodziców, nauczycieli i kaznodziejów: nie musimy więc sami powtarzać każdego głupiego błędu, aby dowiedzieć się, że to głupi błąd.

Ale jeśli niewolniczo przestrzegasz listy reguł w jakiejś książce w 100% przypadków, często będziesz wbijał kwadratowy kołek w okrągły otwór. Ludzie, którzy napisali zbiór przepisów, mogli nie spotkać się z przypadkiem podobnym do twojego. A nawet jeśli tak, to jeśli jest to dość rzadkie, mogą to zignorować. Reguła, która działa w 80% przypadków, jest doskonałą regułą - pod warunkiem, że rozumiesz, że działa ona w 80% przypadków, a nie w 100% przypadków.

Napisałem książkę o projektowaniu baz danych, która zawiera wiele zasad, których odradzam projektantom baz danych. (Powstrzymam się od nadawania tytułu, żeby nie wyglądać, jakbym bezwstydnie angażował się w autopromocję). Z pewnością zachęcam każdego, kto chce zaprojektować bazę danych, do przeczytania książki takiej jak moja i do nauczenia się z niej wszystkiego, co mogą. . Ale OCZYWIŚCIE zdarzają się sytuacje, w których powinieneś łamać zasady, które wymieniam.

Kiedyś napisałem dokument standardów programowych dla zespołu programistów, którym wtedy kierowałem. I ostatnia reguła brzmiała mniej więcej tak: „Jeśli masz dobry powód, aby złamać jedną z powyższych zasad, to śmiało, ALE musisz dołączyć komentarz do kodu wyjaśniający, dlaczego złamałeś regułę. Jeśli nie możesz przyjść z uzasadnionego powodu, a następnie postępuj zgodnie z regułą. Jeśli napisanie komentarza sprawia więcej kłopotów niż przestrzeganie reguły, postępuj zgodnie z nią. ” Mieliśmy zaledwie kilka razy, kiedy ktoś uznał, że złamanie reguły jest warte kłopotów z koniecznością wyjaśnienia, dlaczego.

Przez najlepsze praktyki zakładam, że masz na myśli „nieformalne zasady, których społeczność programistów nauczyła się w miarę upływu czasu, które mogą pomóc poprawić jakość oprogramowania”, a nie jakiś dosłownie najlepszy sposób wykonywania określonego zadania.

Tak, dopóki nie masz powodu, aby tego nie robić. Powinien to być dobry powód, dla którego poważnie się zastanowiłeś i zastosowałeś do okoliczności i ograniczeń danego zadania. Oznacza to, że w pełni rozumiesz praktykę i jesteś w stanie ją zastosować. Nie wchodźmy w to przekonanie, że jeśli go nie rozumiesz, nie może to być najlepszy sposób myślenia. Zobacz definicję.

Nie zawsze będziesz robić to, co najlepsze. Kiedy szef powie ci: „Wyślij ten badziew, bo zostaniesz zwolniony!” Wyślesz go i prawdopodobnie poszukasz innej pracy, ale nadal ją wyślesz. Czasami robisz coś, co jest wystarczająco dobre. Oczywiście nie chcesz tego robić, ale czasami musisz jeździć wagonami i nie możesz się martwić, że konie będą ślepe.

Niektóre rzeczy są ważne, niektóre nie.

Powinieneś dopasować swój wybór języka i stylu do danego problemu.

Na przykład „najlepszą praktyką” dotyczącą obsługi wyjątków może być zawsze wychwytywanie wyjątków i rejestrowanie ich, ale podczas tworzenia testu jednostkowego najlepszą praktyką jest często pozwalanie na ich wyrzucenie, aby środowisko testów jednostkowych mogło je poprawnie zgłaszać.

Z drugiej strony rozważ zasadę „OSUSZANIE”. Dążenie do kodu, który się nie powtarza, jest zawsze dobre, nie tylko z oczywistych powodów, ale także dlatego, że im więcej kodujesz w ten sposób, tym lepszym koderem się stajesz - jest to świetny sposób na rozwinięcie umiejętności kodowania / myślenia zamiast umiejętności pisania i kopiowania / wklejania, a na dłuższą metę ogólnie lepiej poczujesz się ponownie przeglądając kod (nawet jeśli spodziewałeś się, że będzie to kod wyrzucany), jeśli będziesz przestrzegać rozsądnych zasad.

Podsumowując, bądź elastyczny, ale nie tylko koduj nieczytelne śmieci, ponieważ uważasz, że to kod wyrzucany.

Spróbuję patrzeć z innej perspektywy.

Dzisiejsze nowoczesne frameworki bardzo ułatwiają skonfigurowanie podstawowego projektu za pomocą mvc, wstrzykiwania zależności, architektury warstwowej itp. (Tutaj miłośnik wiosennego rozruchu). Powiedziałbym, że zacznij od wygenerowanej bazy i używaj dostarczonych narzędzi, aż wpadniesz na coś, co wymaga ręcznie wykonanego rozwiązania. Następnie możesz skrócić narożniki tych najlepszych praktyk.

Nie jest trudniej używać czegoś takiego jak Spring Boot dla 2-stronicowej aplikacji internetowej, a następnie tworzyć własne serwlety, zapytania jdbc i inne rzeczy.

Z mojego doświadczenia wynika, że ​​jest tylko jedna najlepsza praktyka, którą uważam za obowiązkową:

Keep It Simple, Stupid (KISS)

Innymi słowy: bez względu na wybrane narzędzia, interfejsy API, architektury itp. - jeśli jest to proste, łatwiej jest pracować w przyszłości, mieć mniej błędów, być szybkim, wydajnym w pamięci i wszystkim, czego możesz sobie życzyć.

Wszystkie inne rzeczy, o których mówią ludzie: zasady, wzorce, praktyki itp. - Uważam, że to paleta narzędzi, z których mogę wybierać, wybierając te, które najlepiej pasują do projektu, nad którym pracuję. Wszystkie zawierają techniki i pomysły na rozwiązywanie problemów. Sztuką jest, aby dowiedzieć się, czy masz te problemy w pierwszej kolejności.

Najlepsze „najlepsze praktyki” zawsze zawierają sekcję, w której powinieneś wykorzystać swoją inteligencję i doświadczenie, aby określić, kiedy pozycje w instrukcji są nieodpowiednie. Mogą również zawierać sekcję dotyczącą przeglądu, zatwierdzania i dokumentowania takich wyjątków oraz włączenia ich do „najlepszych” praktyk.

Czy podczas kodowania oprogramowania architektura powinna zawsze stanowić najlepsze praktyki lub praktyczne praktyki dotyczące budowanej aplikacji?

W teorii tak.

W prawdziwym świecie [wciąż] tak, o ile możesz sobie na to pozwolić.

Co oczywiście oznacza „nie”.

Będzie presja czasu i pieniędzy zawsze próbowała zepchnąć cię na drogę „szybkiego i brudnego” rozwiązania, ponieważ zapewnia ono „lepszą” wartość dla klienta. Sposób wdrożenia nie ma znaczenia dla klienta ani jego księgowych. Jeśli potrafisz wykonać pracę [źle] w ciągu dwóch dni lub idealnie w ciągu trzech miesięcy, jak myślisz, o co będą cię prosić?

Różnica między tymi dwoma - najlepszymi praktykami a tym, z czym musisz „uciec” - nazywa się „długiem technicznym”; jest to całkowicie do przyjęcia, o ile masz plan „spłacić”, to znaczy wrócić i poprawić rzeczy później. Ponownie, nie jest to coś, na co zawsze (kiedykolwiek?) Dostajesz budżet.

Jedną z taktyk jest wydanie wczesnej wersji Beta z „szybką” poprawką, ale upewnij się, że przed wprowadzeniem „pełnej” wersji priorytetowe są niezbędne ulepszenia architektoniczne. Ponownie, nie jest to coś, co zawsze (kiedykolwiek?) Robisz.