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.