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ć?
programming-practices
quotations
beyeran
źródło
źródło
Odpowiedzi:
Warto zastanowić się nad tym, co powiedział Torvalds:
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.
źródło
Algorytmy + struktury danych = programy
Kod to tylko sposób na wyrażenie algorytmów i struktur danych.
źródło
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.
źródło
int**
. To powinno cię przekonać, że dane w rzeczywistości NIE są oczywiste; staje się tak tylko poprzez nadanie znaczenia danym. I to znaczenie jest w kodzie.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).
źródło
Code is easy, it's the logic behind the code that is complex
, co miał na myśli?”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”.
źródło
Linus oznacza to:
- Fred Brooks, „The Mythical Man Month”, rozdz. 9.
źródło
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 .
źródło
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.
źródło
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.
źródło
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.
źródło
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
W Naprawianie zachowania / wyników kodu:
źródło
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.
źródło
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
źródło
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.
źródło
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)
źródło
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.
źródło
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.
źródło