Jak ludzie potrafią pisać i utrzymywać niezwykle złożony i trudny do odczytania kod? [Zamknięte]

27

Czytanie kodu źródłowego SQLite jest niemożliwe. Jest to jednak użyteczny kawałek dość złożonego oprogramowania (w końcu jest to w pełni rozbudowana wbudowana baza danych), który można pobrać, skompilować i wykorzystać z kodu innego użytkownika i jest on stale aktualizowany.

Jak ludzie potrafią pisać i utrzymywać tak niezwykle złożony i trudny do odczytania kod?

sharptooth
źródło
1
Myślę, że nie :-D
Pawka
2
@Pawka: Gdzie „oni” nie obejmują osób SQLite.
Frank Shearar,
11
Nawet jeśli kod jest złożony i trudny do odczytania, może być stosunkowo dobrym kodem, biorąc pod uwagę złożoność problemu, który rozwiązuje. Pisanie prostego i łatwego kodu, który rozwiązuje trudne problemy, jest często po prostu niemożliwe, bez względu na to, jak ściśle przestrzegasz „najlepszych praktyk”. Jeszcze ważniejsze jest, aby kod był tak prosty i przejrzysty, jak to tylko możliwe .
Joonas Pulakka
1
Czy ktoś widział kiedyś ogromny projekt, który był łatwy do odczytania?
Jeff Davis,
2
Zatrudnianie stażystów, postdoków itp. I zmuszanie ich do robienia tego ...
DarenW

Odpowiedzi:

19

Istnieje duża różnica między złożonym a skomplikowanym. Poniższy link o podsumowuje. :)

http://codebetter.com/blogs/dru.sellers/archive/2009/09/25/complex-vs-complicated.aspx

Mówiąc bardziej osobiście, pracuję na bazie kodu złożonej z ponad 1 miliona linii kodu. Byłem w nim od linii 1 do jego obecnego stanu. Im bardziej jesteś farmilarny (czytaj dłużej, że jesteś w kodzie), tym łatwiej się staje. Nie mogę powiedzieć, co robi każda linia, ale mogę powiedzieć, że zacząłeś szukać danego zadania lub błędu. Po prostu przychodzi naturalnie.

Morał tej historii jest taki, że jak każda rzecz w świecie programowania wymaga czasu. Jeśli spodziewasz się spojrzeć na SQLite i po prostu go poznać i zrozumieć, żartujesz sobie. Potrzeba czasu, aby dowiedzieć się, jak wszystko działa razem. Różnica między dobrym a złym kodem polega na tym, jak długo trwa ten proces.

Wreszcie, niektórzy programiści nie mają możliwości wskoczyć do bazy kodu i zacząć ją rozgryzać. Wielu poczuje się przytłoczonych czystym rozmiarem lub architekturą bazy kodu. Inni nie będą mieli problemu po prostu wskoczyć w to. Wszystko zależy od mocnych stron programistów.

Tony
źródło
31

W konkretnym przypadku SQLite głównym narzędziem, które wybrali do programowania i konserwacji, jest automatyczne testowanie. Są dumni ze 100% zasięgu (zasięgu oddziału, a nie pokrycia wyciągów) w swoim zestawie testów. Według nich jest to jeden z najlepiej przetestowanych programów na świecie. Wiedzą więc od razu, że coś, co dodali lub zmienili, powoduje regres i mogą w wyniku tego rozwinąć się bez strachu.

http://sqlite.org/testing.html

Dość oszałamiające liczby - mają około 640 razy więcej wierszy kodu testowego niż kodu produkcyjnego.

EDYCJA: Wygląda na to, że pytanie powstało z martwych! A nieco ponad rok później ta sama strona informuje, że ma 1177 razy więcej linii kodu testowego niż produkcyjnego!

Dan Ray
źródło
2
Nikt inny oprócz mnie nie postrzega tego jako problemu, a nie powodu do dumy ?
Stephen
1
tak naprawdę nie zakładam. Baza danych musi przede wszystkim być niezawodna.
ts01
5
@Stephen, dlaczego wiele przypadków testowych stanowiłoby problem ?
1
talia czasu? zbyt wiele testów jest tak złych, jak mało testów (IMHO)
Dainius
9
Jak test może być stratą czasu, jeśli obejmuje potencjalny przypadek, w którym kod może się nie powieść?
Ramhound,
7
  • funkcje ewoluują z czasem.
    • nowe funkcjonalności wynikają z nowych wymagań klientów.
    • Stary kod został napisany w sposób, który umożliwia dodawanie przyszłych, jeszcze nie zaimplementowanych funkcjonalności bez niszczenia starego kodu.
  • eksperci domenowi (w tym przypadku baza danych jest dobrze znaną dziedziną informatyki).
  • opinie społeczności
    • robaki
  • stroma krzywa uczenia się nie stanowiła problemu dla osób dobrze przygotowanych i wytrwałych. Może minąć 6 miesięcy, 1 rok lub nawet dłużej, a niektórzy ludzie są w stanie to znieść.
  • motywacje handlowe. bez wsparcia finansowego bardzo niewiele osób może zainwestować czas i energię w stromą krzywą uczenia się.
rwong
źródło
4

Nie musisz mieć dogłębnego zrozumienia całego projektu, aby móc go utrzymać. Zwykle dzięki dużemu, złożonemu oprogramowaniu ludzie będą mieli swoje własne „obszary”, którymi się opiekują i będą mieli jedynie „przechodzącą” wiedzę na temat reszty systemu.

SQLite jest w rzeczywistości stosunkowo niewielki w skali „dużych projektów oprogramowania”, ale jeśli spojrzysz na coś takiego jak system operacyjny Windows, będziesz mieć ludzi, którzy po prostu pracują na jądrze, ludzi, którzy po prostu pracują na powłoce, ludzi, którzy po prostu pracują w Internet Explorerze, ludzie, którzy pracują tylko w Menedżerze okien itp. Ktoś, kto pracuje w „powłoce”, nie będzie w stanie naprawić błędu w jądrze po upadku kapelusza.

Korzyści płynące z ewolucji tych projektów z czasem: nie zawsze zaczynały się tak skomplikowane. Oznacza to, że nowy programista może być zwykle „przeszkolony” przez bardziej doświadczonych programistów.

Gdy dołączysz do dużego zespołu programistów, otrzymasz szczególny aspekt projektu, nad którym chcesz pracować (być może błąd lub nową funkcję) i będziesz mieć innego programistę, który będzie „kumplem” przez kilka pierwszych iteracji. Twój kumpel dobrze rozumie obszar, w którym pracujesz i może pomóc ci znaleźć drogę.

W przypadku projektów typu open source, takich jak SQLite, jest to trochę trudniejsze, ponieważ istniejący programiści nie mają motywacji do „szkolenia” nowych programistów. Przekonasz się, że jesteś trochę bardziej samodzielny. Ale nadal możesz znaleźć pomoc na forach programistów lub listach mailowych (np. Po prostu zadając pytanie typu „Chciałbym wdrożyć taką i taką funkcję” lub „Znalazłem błąd XYZ, gdzie mam zacząć?” I prawdopodobnie otrzymasz jakaś forma pomocy.

Dean Harding
źródło
Zmień szczegóły, a to brzmi bardzo podobnie do mojej obecnej pracy! Najlepszą częścią tej odpowiedzi jest specjalizacja i potrzeba rozwoju z czasem. Dodaj też szczyptę humoru na temat tego wszystkiego.
DarenW,
4

Istnieje różnica między trudnym do odczytania a złożonym projektem. Jeśli dana osoba nie rozumie głęboko języka, w którym napisano projekt, ani domeny projektu, nie oznacza to, że kod jest źle napisany.

Moja rada:

  • Upewnij się, że rozumiesz język projektu. Nie wystarczy znać język.
  • Dowiedz się każdego szczegółu na temat domeny, zanim zaczniesz używać kodu.

Dla mnie SQLite jest zbyt skomplikowany i nic skomplikowanego. Dziedzina tego projektu wymaga głębokiego zrozumienia szerokich koncepcji.

Maniero
źródło
3

Jedną rzeczą niewymienioną w innych odpowiedziach jest: „Przychodzi im to naturalnie”. Większość ludzi chce pisać dobry kod, ale są nastawione na pisanie złego kodu. Niektórzy programiści, których spotkałem, są naturalnie myślicielami LINEAR, a czasem bardzo świadomie wymyślają złożone rozwiązania. Większość takich ludzi nie spędza czasu na czytaniu lub uczeniu się z książki, której się uczy, kiedy i kiedy wymaga tego praca.

Maniak
źródło
1
LOL, pracowałem z takim zapasem, gdyby istniało kilka sposobów na zrobienie czegoś (i zawsze istnieją), niezmiennie wybrałby najbardziej skomplikowane, skomplikowane rozwiązanie. Nie sądzę, żeby był tego świadomy.
HLGEM
3

Jak ludzie potrafią pisać i utrzymywać tak niezwykle złożony i trudny do odczytania kod?

Jeśli są oryginalnymi programistami i nadal go utrzymują, nie uważają go za „złożony i trudny do odczytania”. Prawdopodobnie uważają to za „proste i łatwe do odczytania”, ponieważ sami to napisali.

Każdy kod potrzebuje czasu, aby go zrozumieć. Tyle, że niektórzy potrzebują więcej czasu niż inni :)

lamcro
źródło
2

Możesz owinąć głowę wokół dowolnej bazy kodu, jeśli masz - wytrwałość, cierpliwość i podejście metodyczne - ale przede wszystkim wytrwałość :-)

Nikhil
źródło
1

Zarządzanie staje się znacznie łatwiejsze, jeśli rzeczy są zawsze wykonywane w ten sam sposób. Nie znam kodu SQLite, ale pracuję w środowisku, w którym jest wiele projektów. Poza zrozumieniem uzasadnienia biznesowego (logika eq), ponieważ wszystko odbywa się zasadniczo w ten sam sposób wszędzie (dostęp do bazy danych itp.), Stosunkowo łatwo jest rozpocząć pracę nad innym projektem. Długi tekst krótki: Wytyczne kodowania - w odpowiedni sposób - znacznie ułatwiają życie i taki kod. Może to być jeden z pomocników programistów SQLite.

Sascha
źródło
1
  • Jeśli jesteś oryginalnym autorem oprogramowania i pracujesz z nim przez ponad 10 lat i jesteś geniuszem, być może uda się zrozumieć całość. Duże fragmenty złożonego oprogramowania (takie jak SQLite lub jądro Linuksa) rzeczywiście zwykle mają dokładnie jednego oryginalnego autora, który ma dogłębne zrozumienie, nawet jeśli wnieśli swój wkład inni ludzie.
  • Jeśli architektura oprogramowania jest rozsądna (wysoka kohezja, niskie sprzężenie), zrozumienie całości nie jest warunkiem koniecznym do wprowadzenia użytecznych dodatków i modyfikacji.
  • Zrozumienie RDBMS lub systemu operacyjnego to nieco szczególne przypadki, wymagające głębokiego zrozumienia podstawowych zasad CS. Nie jest tak w przypadku „zwykłych” aplikacji.
Joonas Pulakka
źródło
1

Próbują napisać to w prosty, ale nie uproszczony sposób.

Najprostsze, jak możesz, przyspiesza zrozumienie / czytanie, nawet jeśli może to zająć trochę czasu.

Klaim
źródło
1

Wdrażany algorytm określa dolny limit prostoty kodu dla implementacji. Jeśli abstrakcyjny opis algorytmu, który ma zostać zaimplementowany, jest niezwykle skomplikowany i wymaga połączenia wielu różnych danych, kod implementujący wspomniany algorytm nie może być prosty bez względu na to, kto go pisze.

Innymi słowy, jednym z powodów, dla których czasami piszę nieodgadniony kod, jest to, że biorąc pod uwagę algorytm, który chcę wdrożyć, nie mam wyboru.

dsimcha
źródło