Najdziwniejsze zasady programowania, o których nigdy nie słyszałeś

Reklama

Przeprowadziliśmy Cię już przez najważniejsze zasady programowania 10 podstawowych zasad programowania Każdy programista musi przestrzegaćZawsze pisz kod, który może obsługiwać każdy, kto może skończyć z oprogramowaniem. W tym celu podajemy kilka zasad programowania, które pomogą ci oczyścić swoje działania. Czytaj więcej musisz o tym wiedzieć, ale istnieje inna klasa zasad programowania, która może się okazać jeszcze bardziej korzystne niż tamte.

Podczas gdy wyżej wymienione zasady uczą cię, jak być mądry z twoim kodem, następujące zasady nauczą cię być mądry z twoim kodem. Niektóre z nich są dziwne, a wiele z nich jest humorystycznych, ale wszystkie są równie praktyczne i ważne. Uważajcie!

1. Zasada wzdęcia

Ten ma tak wiele odmian, że trudno wybrać jedną jako główną. Być może najbardziej „oficjalną” wersją jest Prawo Otaczania Oprogramowania, popularniej nazywane Prawo Zawińskiego, nazwany na cześć Jamiego Zawińskiego i wspomniany w Sztuka programowania w systemie UNIX:

„Każdy program próbuje się rozwinąć, dopóki nie będzie mógł odczytać poczty. Te programy, które nie mogą się tak rozwinąć, zostaną zastąpione tymi, które potrafią. ”

instagram viewer

Mówi o tendencji programów do przyciągania coraz większej liczby funkcji w czasie i nieuchronnie dryfuje w kierunku coraz większej złożoności. Możesz to wiedzieć jako pełzanie funkcji, czyli ciągłe dodawanie nowych funkcji, które nie mają nic wspólnego z głównym celem programu. Pełzanie funkcji prowadzi do wzdęć, a wzdęcia są często niepożądane.

Może to również dotyczyć wydajności oprogramowania:

„Oprogramowanie rozszerza się, aby zużywać wszystkie dostępne zasoby.”

W latach 90. dyski twarde, procesory i pamięć RAM były znacznie bardziej restrykcyjne niż obecnie, a programiści ciężko pracowali, aby zmieścić się w jak największym zakresie. Jednak teraz, gdy mamy większe dyski, szybsze procesory i więcej pamięci RAM, nadal staramy się przestrzegać limitów. Z czasem wszystko się wzdęcia. Twoim zadaniem jest mieć to pod kontrolą.

2. Mentalność „Gorzej jest lepiej”

Prawie tak, jakby w odpowiedzi na zasadę wzdęcia, mamy Gorzej jest lepsza mentalność, po raz pierwszy wymyślony przez Richarda P. Gabriel w eseju napisał o jakości oprogramowania:

„Oprogramowanie, które jest ograniczone, ale proste w użyciu, może być bardziej atrakcyjne dla użytkownika i rynku niż na odwrót”.

Innymi słowy, mądrze jest dowiedzieć się jeden problem twoje oprogramowanie ma się rozwiązać, a następnie być bardzo dobrze w tej jednej rzeczy. Nie komplikuj. Im bardziej się rozproszysz, tym projekt będzie trudniejszy do zarządzania i tym bardziej będzie niepożądany dla użytkowników.

Co się stanie, gdy to zignorujesz? Skończysz z Software Peter Principle:

„Zbyt skomplikowany projekt stanie się w końcu zbyt skomplikowany, aby go zrozumieć nawet jego twórcy.”

Wywodzi się z szerszej Zasady Piotra, która stwierdza, że ​​kiedy pracownicy są awansowani na podstawie ich obecnych kompetencje, a nie ich oczekiwane kompetencje na następnym stanowisku, wszyscy pracownicy ostatecznie kończą na stanowisku niekompetencja. Zastosuj tę zasadę i zastosuj ją do oprogramowania, a zobaczysz, dlaczego gorsze oprogramowanie może być często lepsze.

3. Prawo Eaglesona

„Twój własny kod, którego nie przeglądałeś przez co najmniej sześć miesięcy, równie dobrze mógł zostać napisany przez kogoś innego”.

To pozornie demotywacyjne powiedzenie jest w rzeczywistości czymś do przyjęcia. Faktem jest, że nikt nie jest idealny. Możesz myśleć, że jesteś genialnym programistą, ale jest zawsze czegoś więcej możesz się nauczyć, zawsze więcej miejsca do uprawy. Jeśli kiedykolwiek spojrzysz wstecz na stary kod i błąd, prawdopodobnie oznacza to od tego czasu nauczyłeś się czegoś nowego.

Innymi słowy: jeśli spojrzysz wstecz na stary projekt i nie widzisz niczego, co można by poprawić lub następnym razem zrobiłbyś inaczej, prawdopodobnie utknąłeś jako programista.

4. Zasada najmniejszego zdziwienia

„Jeśli niezbędna funkcja ma wysoki współczynnik zdziwienia, może być konieczne jej przeprojektowanie.”

Po raz pierwszy opublikowany w IBM Systems Journal jeszcze w 1984 roku ta zasada jest nadal zaskakująco aktualna - być może bardziej niż kiedykolwiek wcześniej.

Zasadniczo dotyczy delikatnej równowagi między innowacją a znajomością: jeśli jest to oprogramowanie zbyt różne od innych tego rodzaju i nie jest więc zgodny z oczekiwaniami użytkowników prawdopodobnie nie przyjmą tego. Lepiej jest dążyć do stopniowych ulepszeń, które są wystarczająco duże, aby imponować, ale wystarczająco małe, aby pozostać zaznajomionym.

5. Prawo entomologii cybernetycznej

„Zawsze jest jeszcze jeden błąd”.

Często nazywany Prawo Lubarskiego z Entomologii Cybernetycznej, nie jest jasne, kim tak naprawdę jest Lubarsky. Jednak jego zasada jest prawdziwa dla wszystkich programistów: bez względu na to, jak czysto piszesz kod, bez względu na to, jak solidnie testujesz swoje moduły, bez względu na to, jak często refaktoryzujesz swoje klasy, zawsze będzie kolejny błąd.

W pewnym sensie jest to zasada uwalniania. Chociaż zdecydowanie powinniśmy starać się w przypadku kodu wolnego od błędów ważne jest również, aby pamiętać, że perfekcjonizm jest wrogiem dobra. Poszukaj błędów, napraw je, gdy się pojawią, a następnie przejdź dalej.

6. Prawo Kernighana

„Debugowanie jest dwa razy trudniejsze niż pisanie kodu. Dlatego, jeśli piszesz kod tak sprytnie, jak to możliwe, z definicji nie jesteś wystarczająco inteligentny, aby go debugować. ”

Brian Kernighan, ten sam, który jest współautorem Biblia języka programowania C. Dlaczego warto programować w C?C nie jest martwym językiem. W rzeczywistości magazyn IEEE Spectrum uznał go za najlepszy język nr 2 w 2017 r. Oto pięć powodów. Czytaj więcej , słynie z tego wnikliwego prawa. Sedno tego jest takie: pisz dobry kod, napisz czytelny kod, napisz prosty kod, wszystko, o ile nie jest sprytny kod.

Próba napinania mięśni programujących za pomocą złożoności wieży z kości słoniowej jest dokładnym przeciwieństwem tego, co to oznacza napisz czysty i lepszy kod 10 porad dotyczących pisania Cleaner & Better CodePisanie czystego kodu wygląda łatwiej niż jest w rzeczywistości, ale korzyści są tego warte. Oto, jak możesz zacząć pisać czystszy kod już dziś. Czytaj więcej . Im trudniej zrozumieć kod, tym trudniej będzie go debugować, gdy nieuchronnie się zepsuje.

I jak Robert C. Martin wyjaśnia, że ​​nie chodzi tylko o debugowanie:

„Rzeczywiście stosunek czasu spędzonego na czytaniu do pisania wynosi znacznie ponad 10 do 1. Cały czas czytamy stary kod w ramach pisania nowego kodu... [Dlatego też] ułatwienie czytania ułatwia pisanie. ”

7. Debugowanie gumowej kaczki

Ten nie jest tak bardzo zasadą, jak techniką, ale jest tak pomocny i dziwny, że pominięcie go byłoby niedopuszczalne.

Po raz pierwszy powiedział Pragmatyczny programista, debugowanie gumowej kaczki ma miejsce, gdy debugujesz zepsute oprogramowanie, tłumacząc kod nieożywionemu obiektowi (np. gumowej kaczce) po jednej linii na raz. Działa, ponieważ akt wyjaśniający uruchamia różne części mózgu, a Ty częściej dostrzegasz niespójności i odkrywasz, gdzie popełniłeś błąd.

Z tego powodu gumową kaczką może być zaskakująco fajny prezent dla programistów Najlepsze upominki dla programistów: 20 pomysłów na koderów i frajerówSzukasz prezentu dla programisty? Oto najlepsze prezenty dla maniaków, od mechanicznych klawiatur po stojące biurka i wiele innych. Czytaj więcej , niezależnie od tego, czy kupujesz go dla siebie, czy dla swojego programisty.

8. Reguła dziewięćdziesiąt dziewięćdziesiąt

„Pierwsze 90 procent kodu stanowi pierwsze 90 procent czasu programowania. Pozostałe 10 procent kodu stanowi pozostałe 90 procent czasu programowania. ”

To bezczelne przysłowie Toma Cargilla przekonuje, dlaczego programowanie może być tak frustrujące: bez względu na to, jak blisko myślisz o ukończeniu, jesteś znacznie dalej niż nawet twoje najlepsze szacunki. Kiedy myślisz, że skończyłeś, jesteś tylko w połowie drogi.

Jest to zgodne z prawem Hofstadtera:

„Zawsze trwa dłużej, niż się spodziewasz, nawet biorąc pod uwagę prawo Hofstadtera”.

9. Prawo Parkinsona

„Praca rozszerza się, aby wypełnić czas dostępny na jej ukończenie.”

Ta jedna zasada, stworzona przez Cyrila Northcote Parkinsona, jest szerszą zasadą, która absolutnie dotyczy programowania i idzie ręka w rękę z powyższą regułą dziewięćdziesiąt dziewięćdziesiąt: ile czasu trzeba do ukończenia projektu, to dokładnie ile czasu to zajmie brać. W rozwoju oprogramowania „wczesne ukończenie” to właściwie mit.

Prawo Parkinsona jest powodem, dla którego właściwe terminy są kluczowe, jeśli chcesz zakończyć i wysłać oprogramowanie. Dlatego często profesjonalni programiści często polecają zwinne zasady zarządzania projektami Jak stosować zwinne zasady zarządzania projektami do organizowania swojego życiaZwinne, najlepiej znane jako metoda zarządzania projektami, to świetne ramy do zarządzania życiem osobistym. Pokażemy Ci zasady, które możesz pożyczyć - w zestawie bezpłatne pobieranie arkusza roboczego! Czytaj więcej i narzędzia do zarządzania projektami, takie jak Asana Trello vs. Asana: Najlepsze bezpłatne narzędzie do zarządzania projektami to ...Wybór między Trello i Asaną jest trudny. Tutaj porównujemy bezpłatne plany i pomagamy zdecydować, które narzędzie zarządzania projektami jest najlepsze dla Twojego zespołu. Czytaj więcej .

10. Prawo Brooka

„Dodanie siły roboczej do późnego projektu oprogramowania sprawia, że ​​później”.

Następnym razem, gdy spóźnisz się na projekt, co jest prawdopodobne, ponieważ większość projektów programistycznych potrzebuje więcej czasu niż przydzielono, pamiętaj, że dodanie koderów nie rozwiąże go szybciej.

W rzeczywistości to zajmie dłuższy ukończyć. Musisz nie tylko przyspieszyć działanie nowego kodera, ale prawdopodobnie będą one kolidować z istniejącymi koderami. Więcej rzeczy będzie wymagało udokumentowania, potrzebna będzie większa biurokracja, aby wszyscy byli na tej samej stronie, a więcej tarcia wyjdzie z całego doświadczenia w czasie kryzysu.

Idąc naprzód jako programista

Teraz, gdy znasz te zasady, jesteś w rzeczywistości lepiej przystosowany do prawdziwy świat programowania, nie tylko tego, co spotkałeś w szkole, na kursie internetowym lub w obozie dla początkujących. Zasady te wynikają z wieloletniego doświadczenia i niepowodzeń.

Dzięki tej nowo odkrytej mądrości możesz teraz przystąpić do kariera programistyczna o wysokim popycie 10 prac programistycznych, które są w tej chwili na żądaniePonieważ lądowanie na stanowisku programistycznym może być trudne w obecnym krajobrazie, rozważ skupienie się na jednej z poniższych koncentracji, aby zwiększyć swoje szanse na sukces. Czytaj więcej z bardziej realistycznymi oczekiwaniami. W tym celu dowiedz się, jak to zrobić zmaksymalizuj swoje możliwości kariery programistycznej Jak poprawić swoje możliwości kariery programistycznejJeśli chcesz rozpocząć, zrestartować lub w inny sposób poprawić swoją karierę programistyczną, nie jest to łatwe. Jeśli jesteś na studiach, czas jest teraz. Oto kilka wskazówek, które mogą zaprowadzić Cię daleko. Czytaj więcej . A jeśli zdecydujesz, że programowanie nie jest dla Ciebie, nie martw się - zastanów się nad jednym z nich zamiast tego niekodujące zadania techniczne Kodowanie nie jest dla wszystkich: 9 zadań technicznych, które można uzyskać bez niegoNie zniechęcaj się, jeśli chcesz być częścią dziedziny techniki. Istnieje wiele miejsc pracy dla osób bez umiejętności kodowania! Czytaj więcej .

Które z tych zasad są dla ciebie najbardziej prawdziwe? Znasz jakieś inne dziwne zasady programowania, które przeoczyliśmy? Daj nam znać w komentarzach poniżej!