Cytat Torvaldsa na temat dobrego programisty [zamknięty]

Przypadkowo natknąłem się na następujący cytat Linusa Torvaldsa:

„Źli programiści martwią się o kod. Dobrzy programiści martwią się strukturami danych i ich relacjami”.

Myślałem o tym przez kilka ostatnich dni i nadal jestem zdezorientowany (co prawdopodobnie nie jest dobrym znakiem), dlatego chciałem omówić następujące kwestie:

• Jaka interpretacja tego jest możliwa / ma sens?
• Czego można się z tego nauczyć?

Warto zastanowić się nad tym, co powiedział Torvalds:

git ma prostą konstrukcję, ze stabilnymi i dość dobrze udokumentowanymi strukturami danych. W rzeczywistości jestem wielkim zwolennikiem projektowania kodu wokół danych, a nie na odwrót, i myślę, że jest to jeden z powodów, dla których git odnosi sukcesy […] W rzeczywistości twierdzę, że różnica pomiędzy złym programistą a dobrym jest to, czy uważa, że ​​jego kod lub struktury danych są ważniejsze.

Mówi on, że dobre struktury danych sprawiają, że kod jest bardzo łatwy do zaprojektowania i utrzymania, podczas gdy najlepszy kod nie może nadrobić złych struktur danych.

Jeśli zastanawiasz się nad przykładem git, wiele systemów kontroli wersji stosunkowo regularnie zmienia format danych w celu obsługi nowych funkcji. Po uaktualnieniu, aby uzyskać nową funkcję, często musisz uruchomić jakieś narzędzie do konwersji bazy danych.

Na przykład, kiedy DVCS stał się popularny, wiele osób nie było w stanie dowiedzieć się, co w modelu rozproszonym sprawiło, że scalenia były o wiele czystsze niż scentralizowana kontrola wersji. Odpowiedź jest absolutnie niczym, poza tym, że rozproszone struktury danych musiały być znacznie lepsze, aby mieć nadzieję na pracę w ogóle. Uważam, że od tego czasu nadrobiły to scentralizowane algorytmy scalania, ale zajęło to dość dużo czasu, ponieważ ich stare struktury danych ograniczały rodzaje algorytmów, których mogliby użyć, a nowe struktury danych złamały wiele istniejących kodów.

Natomiast pomimo eksplozji funkcji w git, podstawowe struktury danych prawie się nie zmieniły. Martw się najpierw o struktury danych, a Twój kod będzie naturalnie czystszy.

Algorytmy + struktury danych = programy

Kod to tylko sposób na wyrażenie algorytmów i struktur danych.

Ten cytat dobrze zna jedną z zasad zawartych w „The Art of Unix Programming”, która jest mocną stroną Torvaldsa jako twórcy Linuksa. Książka znajduje się tutaj online

Z książki pochodzi następujący cytat, który wyjaśnia, co mówi Torvalds.

Reguła reprezentacji: Podziel wiedzę na dane, aby logika programu była głupia i niezawodna.

Nawet najprostsza logika proceduralna jest trudna do zweryfikowania przez ludzi, ale dość skomplikowane struktury danych są dość łatwe do modelowania i uzasadnienia. Aby to zobaczyć, porównaj ekspresyjność i moc wyjaśniającą diagramu (powiedzmy) drzewa wskaźników pięćdziesięciu węzłów ze schematem blokowym programu pięćdziesięciu linii. Lub porównaj inicjalizator tablicy wyrażający tablicę konwersji z równoważną instrukcją switch. Różnica w przejrzystości i jasności jest dramatyczna. Zobacz zasadę 5 Roba Pike'a.

Dane są bardziej podatne na przetwarzanie niż logika programu. Wynika z tego, że tam, gdzie widzisz wybór między złożonością struktur danych a złożonością kodu, wybierz to pierwsze. Więcej: rozwijając projekt, powinieneś aktywnie poszukiwać sposobów na przeniesienie złożoności z kodu na dane.

Społeczność uniksowa nie zapoczątkowała tego wglądu, ale wiele kodów uniksowych wykazuje jej wpływ. Zwłaszcza funkcja języka C do manipulowania wskaźnikami zachęca do korzystania z dynamicznie modyfikowanych struktur referencyjnych na wszystkich poziomach kodowania od jądra w górę. Proste pościgi wskaźnikowe w takich strukturach często wykonują obowiązki, które implementacje w innych językach musiałyby zamiast tego zawierać bardziej skomplikowane procedury.

Kod jest łatwy, jego logika jest złożona.

Jeśli martwisz się kodem, oznacza to, że nie znasz jeszcze podstaw i prawdopodobnie straciłeś kompleks (tzn. Struktury danych i ich relacje).

Aby nieco rozwinąć odpowiedź Moronsa , chodzi o to, że zrozumienie szczegółów kodu (składnia oraz, w mniejszym stopniu, struktura / układ) jest na tyle łatwe, że budujemy narzędzia, które mogą to zrobić. Kompilatory mogą zrozumieć wszystko, co należy wiedzieć o kodzie, aby przekształcić go w działający program / bibliotekę. Ale kompilator nie jest w stanie rozwiązać problemów, które robią programiści.

Możesz pójść o krok dalej i powiedzieć „ale mamy programy, które generują kod”, ale generowany przez niego kod jest oparty na pewnego rodzaju danych wejściowych, które prawie zawsze są ręcznie konstruowane.

Niezależnie od tego, jaką drogą wybierzesz się do kodu: czy to przez jakąś konfigurację lub inne dane wejściowe, które następnie wytwarzają kod za pomocą narzędzia lub jeśli piszesz go od zera, nie jest to kod, który ma znaczenie. Ważne jest krytyczne myślenie o wszystkich elementach wymaganych do uzyskania dostępu do tego kodu. W świecie Linusa, który jest w dużej mierze strukturami danych i relacjami, choć w innych domenach mogą to być inne elementy. Ale w tym kontekście Linus mówi po prostu: „Nie obchodzi mnie, czy umiesz pisać kod, zależy mi, abyś zrozumiał rzeczy, które rozwiążą problemy, z którymi mam do czynienia”.

Linus oznacza to:

Pokaż mi swoje schematy blokowe [kod] i ukryj swoje tabele [schemat], a będę nadal mistyfikowany; pokaż mi swoje tabele [schemat], a zwykle nie potrzebuję twoich schematów blokowych [kod]: będą oczywiste.

- Fred Brooks, „The Mythical Man Month”, rozdz. 9.

Myślę, że mówi, że ogólny projekt wysokiego poziomu (struktury danych i ich relacje) jest znacznie ważniejszy niż szczegóły implementacji (kod). Myślę, że ceni programistów, którzy potrafią zaprojektować system, niż tych, którzy mogą skupić się tylko na jego szczegółach.

Oba są ważne, ale zgodziłbym się, że ogólnie lepiej jest uzyskać duży obraz i mieć problemy ze szczegółami niż na odwrót. Jest to ściśle związane z tym, co próbowałem wyrazić na temat podziału dużych funkcji na małe .

Cóż, nie mogę się całkowicie zgodzić, bo musisz się o to martwić. W tym przypadku jedną z rzeczy, które uwielbiam w programowaniu, są przełączanie się między różnymi poziomami abstrakcji i wielkości, które szybko przechodzą od myślenia o nanosekundach do myślenia o miesiącach iz powrotem.

Jednak wyższe rzeczy są ważniejsze.

Jeśli mam wadę w kilku liniach problemów, które powodują nieprawidłowe zachowanie, prawdopodobnie nie jest to zbyt trudne do naprawienia. Jeśli powoduje to słabą wydajność, prawdopodobnie nawet nie ma to znaczenia.

Jeśli mam wadę w wyborze struktury danych w podsystemie, co powoduje nieprawidłowe zachowanie, jest to o wiele większy problem i trudniej go naprawić. Jeśli powoduje to słabą wydajność, może być dość poważne lub, jeśli to możliwe, wciąż znacznie mniej dobre niż podejście konkurencyjne.

Jeśli mam wadę w relacji między najważniejszymi strukturami danych w aplikacji, co powoduje nieprawidłowe zachowanie, to przede wszystkim mam poważne zmiany w projekcie. Jeśli powoduje to jego słabe działanie, może być tak źle, że byłoby prawie lepiej, gdyby zachowywał się źle.

I to właśnie sprawia, że ​​znalezienie problemów na niższym poziomie jest trudne (naprawianie błędów na niskim poziomie jest zwykle łatwe, znalezienie ich może być trudne).

Rzeczy niskiego poziomu są ważne, a ich pozostałe znaczenie jest często poważnie zaniżone, ale blednie w porównaniu do dużych rzeczy.

Ktoś, kto zna kod, widzi „drzewa”. Ale ktoś, kto rozumie struktury danych, widzi „las”. Dlatego dobry programista skoncentruje się bardziej na strukturach danych niż na kodzie.

Ważna jest znajomość przepływu danych. Znajomość przepływu wymaga zaprojektowania dobrych struktur danych.

Jeśli cofniesz się o dwadzieścia lat, był to jeden z głównych argumentów za podejściem zorientowanym obiektowo za pomocą SmallTalk, C ++ lub Java. Duży skok - przynajmniej w C ++, ponieważ tego właśnie się nauczyłem - najpierw zaprojektowałem klasę i metody, a potem wszystko inne się ułoży.

Linus niewątpliwie mówił w szerszym znaczeniu, ale źle zaprojektowane struktury danych często wymagają dodatkowej przeróbki kodu, co może również prowadzić do innych problemów.

Czego można się z tego nauczyć?

Jeśli mogę, moje doświadczenie z ostatnich kilku tygodni. Poprzednie dyskusje wyjaśniły odpowiedź na moje pytanie: „czego się nauczyłem?”

Przepisałem trochę kodu i zastanawiając się nad wynikami, które ciągle widziałem, i mówiąc „struktura, struktura ...”, to jest tak ogromna różnica. Teraz widzę, że to właśnie struktura danych zrobiła różnicę. I mam na myśli wszystko .

• Po przetestowaniu mojej oryginalnej dostawy analityk biznesowy powiedział mi, że nie działa. Powiedzieliśmy „dodaj 30 dni”, ale mieliśmy na myśli „dodaj miesiąc” ( dzień w wynikowej dacie nie zmienia się). Dodaj osobne lata, miesiące, dni; na przykład nie 540 dni przez 18 miesięcy.

• Poprawka: w strukturze danych zastąpiono jedną liczbą całkowitą klasą zawierającą wiele liczb całkowitych, zmiana w jej konstrukcji była ograniczona do jednej metody. Zmień rzeczywistą instrukcję arytmetyczną daty - wszystkie 2 z nich.

Wypłata

• Nowa implementacja miała większą funkcjonalność, ale kod algorytmu był krótszy i wyraźnie prostszy.

W Naprawianie zachowania / wyników kodu:

• Zmieniłem strukturę danych, a nie algorytm.
• Nigdzie w kodzie nie dotknięto żadnej logiki sterowania.
• Żadne API nie zostało zmienione.
• Klasa fabryki struktury danych w ogóle się nie zmieniła.

Lubię wyobrażać sobie bardzo sprytny zespół bibliotekarzy w pięknie wykonanej bibliotece z milionem przypadkowych i genialnych książek, to byłaby głupota.

Nie mogę się bardziej zgodzić z Linusem. Skoncentrowanie się na danych pomaga znacznie uprościć proste i elastyczne rozwiązanie danego problemu. Sam Git jest tego przykładem - dzięki tak wielu funkcjom obsługiwanym w latach rozwoju podstawowa struktura danych w dużej mierze pozostaje niezmieniona. To magia! --2c

Widziałem, że jest to wiele obszarów.

Pomyśl o analizie biznesowej ... Powiedzmy, że analizujesz najlepszy sposób wspierania marketingu w firmie produkującej produkty konsumpcyjne, takiej jak Colgate. Jeśli zaczniesz od fantazyjnych okien lub najnowszych technologii, nie pomożesz firmie tak bardzo, jakbyś najpierw przemyślał jej potrzeby w zakresie danych, a potem martwisz się prezentacją. Model danych przewyższa oprogramowanie do prezentacji.

Rozważ zrobienie strony internetowej. O wiele lepiej najpierw pomyśleć o tym, co chcesz pokazać (HTML), a potem martwić się stylem (CSS) i skryptami (wybierz narzędzie).

To nie znaczy, że kodowanie też nie jest ważne. Potrzebujesz umiejętności programowania, aby w końcu zdobyć to, czego potrzebujesz. Chodzi o to, że dane są podstawą. Zły model danych odzwierciedla zbyt skomplikowany lub nierozważny model biznesowy.

Piszę nowe funkcje i aktualizuję istniejące znacznie częściej niż dodawanie nowych kolumn lub tabel do schematu bazy danych. Prawdopodobnie dotyczy to wszystkich dobrze zaprojektowanych systemów. Jeśli musisz zmieniać schemat za każdym razem, gdy musisz zmienić kod, jest to wyraźny znak, że jesteś bardzo złym programistą.

wskaźnik jakości kodu = [zmiany kodu] / [zmiany schematu bazy danych]

„Pokaż mi swoje schematy blokowe i ukryj swoje tabele, a ja nadal będę mistyfikowany. Pokaż mi swoje tabele, a zazwyczaj nie będę potrzebować twoich schematów blokowych; będą oczywiste”. (Fred Brooks)

Wygląda na to, że ten pomysł ma różne interpretacje w różnych rodzajach programowania. Dotyczy to rozwoju systemów, a także rozwoju przedsiębiorstw. Na przykład można argumentować, że gwałtowne przesunięcie uwagi na domenę w projektowaniu opartym na domenie przypomina skupienie się na strukturach danych i relacjach.

Oto moja interpretacja tego: używasz kodu do tworzenia struktur danych, więc należy skupić się na tym drugim. To jak budowanie mostu - powinieneś zacząć projektować solidną konstrukcję, a nie taką, która wygląda atrakcyjnie. Tak się składa, że ​​dobrze napisane struktury danych i mosty wyglądają dobrze dzięki wydajnym projektom.