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

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?

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.

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!

• 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ę.

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.

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.

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.

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 :)

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

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.

• 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.

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.

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.