5 słynnych cytatów programistycznych, wyjaśnionych

bycie programistą to zapisanie się na życie ciągłej nauki. Fontanna nowości-nowe funkcje, nowe języki, nowe narzędzia, nowe frameworki—nigdy nie przestaje tryskać. Ale informatyka jest również zaskakująco tradycyjną dziedziną, która opiera się na sprawdzonych zasadach. Dodaliśmy programowanie obiektowe, nowoczesny sprzęt i sztuczną inteligencję. Ale pomimo tych zmian, wiele spostrzeżeń, które zostały sformułowane po raz pierwszy pokolenie temu, nadal jest prawdziwe.

w tym artykule rozciąłem kilka moich ulubionych cytatów na temat informatyki. Jedynym warunkiem jest to, że każdy cytat musi mieć co najmniej dwadzieścia lat. Ponieważ podczas gdy stara technologia szybko staje się bezużyteczna, starożytne przykazania naszych programistycznych przodków mają o wiele większą moc.

“wszystkie problemy w informatyce mogą być rozwiązane przez inny poziom indykacji.”- David Wheeler

oto często powtarzany cytat compsci, który niewielu programistów chce wyjaśnić. Ale to jedna z moich ulubionych prawd programistycznych, ponieważ uderza w sedno tego, czym jest kodowanie.

najprostszym sposobem na rozpoczęcie myślenia o indirection jest wyobrażenie sobie warstw. Na przykład załóżmy, że masz mały projekt, który musi pasować komponent A do komponentu B:

oba elementy są znormalizowane, więc nie można ich otworzyć i zmienić sposobu ich działania. Możesz zbudować zupełnie nowy komponent (PlugTwoProngVariant), ale to dużo pracy i niepotrzebne powielanie. Lepszym podejściem jest dodanie warstwy pomiędzy dwoma elementami-adaptera, który pasuje do obu komponentów i przekłada się między nimi.

teraz, gdyby chodziło tylko o dodanie nowej warstwy, która pasowałaby do niekompatybilnych elementów, byłoby miło, ale mało użytecznie. Ale idea rozwiązywania problemów poprzez budowanie wokół nich jest koncepcją, która rozciąga się od dołu do góry informatyki. Widać to, gdy próbujesz dopasować nowy model danych do starego interfejsu użytkownika. Jest to widoczne, gdy próbujesz dopasować starszą aplikację do nowego zaplecza usługi internetowej. Widzisz to, gdy musisz korzystać z funkcji wyższego poziomu, takich jak rejestrowanie i buforowanie, lub koordynować usługi wyższego poziomu, takie jak wiadomości i transakcje. Na szczycie piramidy znajdziesz rozrzedzone tematy, takie jak uczenie maszynowe (gdy nie możesz kodować zachowania, którego potrzebujesz, napisz kolejną warstwę kodu, która Ci to wyjaśni).

Wiele osób powie Ci, że kodowanie polega na pisaniu wyraźnych instrukcji w języku, który nawet idiotyczne komputery mogą zrozumieć. Ale cytat Davida Wheelera pokazuje lepszy wgląd. Dobre programowanie polega na wspinaniu się po drabinie abstrakcji, aby dotrzeć do najbardziej ogólnych rozwiązań.

cytat związany z bonusem:

Ludzie bardzo rzadko cytują natychmiastową uwagę Wheelera na temat indirection:

“ale to zwykle tworzy kolejny problem.”- David Wheeler

ta prawda od tego czasu utrzymuje programistów w biznesie.

o prostocie

“prostota jest warunkiem niezawodności.”- Edsger Dijkstra

nie brakuje mądrych programistów ostrzegających nas, aby nie komplikować naszego kodu. Ale niewielu stawia koszt złożoności jaśniej niż Holenderski pionier informatyki Edsger Dijkstra.

oto wgląd: nie wybierasz prostoty jako prezentu dla przyszłości. Nie robisz tego, ponieważ przewidujesz szansę na ponowne użycie kodu, lub dlatego, że chcesz, aby wyglądał czystszy w recenzji kodu, lub dlatego, że chcesz ułatwić modyfikację. (Chociaż wszystkie te korzyści są cenne!) Robisz to, ponieważ prostota jest warunkiem wstępnym. Bez prostoty nigdy nie możesz mieć niezawodnego kodu, któremu możesz zaufać do prowadzenia firmy lub obsługi danych.

aby zaakceptować punkt Dijkstry, musimy na nowo zdefiniować, co oznacza “dobry kod”. To nie jest najkrótszy kod. Niekoniecznie jest to najszybszy kod. To zdecydowanie nie jest najmądrzejszy kod. To kod, któremu można zaufać.

cytat związany z bonusem:

jednym z najlepszych sposobów, aby Kod był prosty, jest pamiętanie, że mniej znaczy więcej. Dijkstra oferuje metrykę, która pomoże nam o tym pamiętać:

“jeśli chcemy policzyć linie kodu, nie powinniśmy traktować ich jako “linie wyprodukowane”, ale jako ” linie wydane.””- Edsger Dijkstra

o czytelności i przepisywaniu

“trudniej jest odczytać kod niż go napisać.”- Joel Spolsky

na pierwszy rzut oka ten cytat legendy oprogramowania i współtwórcy StackOverflow Joela Spolsky ‘ ego wydaje się prawdziwy, ale zwodniczo płytki. Tak, kod może być gęsty, zwięzły i żmudnie długi. I to nie jest tylko Kod innych ludzi. Jeśli spojrzysz na swoją pracę sprzed roku, prawdopodobnie będziesz potrzebował trochę czasu, aby uporządkować logikę, którą kiedyś dokładnie znałeś.

ale spostrzeżenia Spolskiego są zaskakujące. Niebezpieczeństwo kodu, którego nie można odczytać, nie jest oczywiste (trudno go zmienić i poprawić). Zamiast tego, większe niebezpieczeństwo polega na tym, że złożony kod wydaje się być gorszy niż w rzeczywistości. W rzeczywistości ciężar próby zrozumienia cudzego już napisanego kodu jest tak wielki, że możesz ulec pokusie popełnienia tego, co Spolsky nazywa najgorszym możliwym błędem—decyzji o przepisaniu tego kodu od zera.

to nie tak, że przepisywanie nie może poprawić architektury systemu. Zdecydowanie mogą. Ale te ulepszenia są bardzo kosztowne. Resetują zegar na testowanie i naprawianie błędów, dwie czynności, które trwają znacznie dłużej niż zwykłe kodowanie. Przeróbki są kuszące, ponieważ opierają się na jednym z najczęstszych uprzedzeń w tworzeniu oprogramowania: nie doceniamy wysiłku, aby robić rzeczy, które są koncepcyjnie proste. Dlatego ostateczne 5% projektu zajmuje 50% czasu. Łatwe rzeczy mogą być zaskakująco czasochłonne! I nic nie wydaje się łatwiejsze niż rozwiązanie problemu, który już rozwiązałeś.

więc jeśli nie powinieneś przepisywać wszystkiego, aby było idealnie, jakie jest lepsze rozwiązanie? Odpowiedzią jest zaangażowanie każdego dewelopera w stałą refaktoryzację. Daje to małe, ciągłe ulepszanie kodu-realne korzyści przy minimalnym ryzyku. Możesz poprawić czytelność po drodze.

cytat związany z bonusem:

jeśli nadal masz wątpliwości co do znaczenia czytelności, Martin Fowler pomaga umieścić go w perspektywie:

“każdy głupiec może napisać kod, który komputer może zrozumieć. Dobrzy Programiści piszą kod, który ludzie mogą zrozumieć.”- Martin Fowler

innymi słowy, praca programisty nie polega tylko na tym, aby wszystko działało, ale aby wszystko miało sens.

na powtórzenie

“nie powtarzaj się. Każda wiedza musi mieć jedną, jednoznaczną, autorytatywną reprezentację w systemie.”- Andy Hunt i Dave Thomas

każdy szanujący się programista wie, że powtarzanie jest sercem zła. Jeśli piszesz to samo w różnych miejscach, tworzysz dodatkową pracę, pisząc, testując i debugując. Co gorsza, wprowadzasz możliwość niespójności-na przykład, jeśli jedna część kodu zostanie zaktualizowana, ale inne podobne procedury nie zostaną uzgodnione. Niespójny program to program, któremu nie można ufać, a program, któremu nie można ufać, nie jest już realnym rozwiązaniem.

jednak kod nie jest jedynym miejscem, w którym powtarzanie sieje spustoszenie. Ta wersja słynnej zasady” nie powtarzaj się ” (DRY) rozszerza zasadę braku duplikacji, aby objąć inne miejsca, w których mogą się ukrywać niespójności. Nie mówimy już o powielaniu kodu. Mówimy również o powtarzaniu w systemie-a system ma wiele różnych sposobów kodowania wiedzy. Należą do nich:

• instrukcje kodu
• komentarze do kodu
• dokumentacja programisty lub klienta
• Schematy danych (na przykład tabele bazy danych)
• inne specyfikacje, takie jak plany testowe, dokumenty przepływu pracy i reguły kompilacji

wszystkie te warstwy mogą się nakładać na siebie. A kiedy to zrobią, ryzykują wprowadzenie różnych wersji tej samej rzeczywistości. Na przykład, co się stanie, jeśli dokumentacja opisuje jeden sposób działania, a aplikacja podąża za innym? Kto jest właścicielem prawdy? Co się stanie, jeśli tabele bazy danych nie pasują do modelu danych w kodzie? Czy komentarze opisują działanie algorytmu, który nie pasuje do jego rzeczywistej implementacji? Każdy system potrzebuje jednej, autorytatywnej reprezentacji, z której wywodzi się Wszystko inne.

nawiasem mówiąc, konkurencyjne wersje prawdy nie są tylko problemem w małych projektach lub źle zaprojektowanym kodzie. Jeden z najlepszych przykładów walki pomiędzy XHTML i HTML5. Jeden z obozów twierdził, że specyfikacja była oficjalną prawdą, a przeglądarki musiały zostać poprawione, aby ją przestrzegać. Druga frakcja twierdziła, że zachowanie przeglądarki jest de facto standardem, ponieważ to właśnie projektanci mieli na myśli pisząc strony internetowe. Ostatecznie zwyciężyła przeglądarkowa wersja prawdy. Od tego momentu HTML5 był tym, co robiły przeglądarki-w tym dozwolone skróty i akceptowane błędy.

cytat związany z bonusem:

możliwość sprzeczności kodu i komentarzy otworzyła gorącą debatę na temat tego, czy komentarze wyrządzają więcej szkody niż pożytku. Zwolennicy ekstremalnego programowania traktują ich z otwartą podejrzliwością:

“Kod nigdy nie kłamie, komentarze czasem tak.”- Ron Jeffries

o trudnych problemach

“w informatyce są tylko dwie trudne rzeczy: unieważnianie pamięci podręcznej i nazywanie rzeczy.”- Phil Karlton

na pierwszy rzut oka ten cytat wydaje się zabawnym, ale zwykłym żartem programistycznym. Kontrast między czymś, co brzmi trudno (unieważnienie pamięci podręcznej) i czymś, co brzmi bezbolesnie (nazywanie rzeczy) jest natychmiast relatible. Każdy programista zainwestował wiele godzin pracy w naprawienie śmiesznie błahego problemu, takiego jak para parametrów przekazana w niewłaściwej kolejności lub niespójna zmienna pisana wielką literą (dzięki JavaScript). Tak długo, jak ludzie muszą współpracować z maszynami, aby coś zrobić, programowanie będzie mashupem wysokiego poziomu planowania systemu i banalnych literówek.

ale jeśli spojrzysz na cytat Phila Karltona, jest więcej do rozpakowania. Nazywanie rzeczy nie jest trudne tylko dlatego, że życie programisty jest regularnie rujnowane przez drobne bóle głowy. Jest tak również dlatego, że kwestia nazewnictwa jest tak naprawdę krawędzią najważniejszej pracy każdego programisty: projektowania oprogramowania. Innymi słowy, jak napisać kod, który jest jasny, czysty i spójny?

istnieje wiele sposobów na błędne nazewnictwo. Wszyscy widzieliśmy zmienne nazwane po typach danych(myString, obj), skróty (pc dla katalogu produktów), kilka banalnych szczegółów implementacji (swappable_name, formUserInput), albo nawet nic (ret_value, tempArray). Łatwo wpaść w pułapkę nazywania zmiennej w oparciu o to, co robisz z nią w danym momencie, a nie o to, co zawiera. A wartości logiczne są szczególnie trudne-czy progress ustawia się, gdy zaczyna się postęp, wskazuje, że trzeba wyświetlać informacje o postępie w interfejsie użytkownika, czy oznacza coś zupełnie innego?

ale nazwy zmiennych to dopiero początek. Nazewnictwo klas rodzi pytanie, jak podzielić kod na niezależne części. Nazewnictwo członków publicznych kształtuje sposób prezentacji interfejsu, który pozwala jednej części aplikacji na interakcję z drugą. Blokowanie tych nazw nie tylko opisuje, co może zrobić fragment kodu, ale określa, co będzie robił.

cytat związany z bonusem:

“istnieją dwie trudne rzeczy w informatyce: unieważnienie pamięci podręcznej, nazywanie rzeczy i błędy off-by-one.”- Leon Bambrick