Czy pisanie oprogramowania jest łatwiejsze niż czytanie i rozumienie go od zera? [Zamknięte]

Ja i mój przyjaciel rozmawialiśmy wczoraj o różnicach między pisaniem dużego oprogramowania C ++ a rozumieniem go jako nowego rekruta.

Czy to możliwe, że skoro oprogramowanie wykonuje się jedna linia na raz, a proces ten przypomina, jak my (ludzie) uczymy się i budujemy coś na innym, pisanie dużego oprogramowania jest w rzeczywistości łatwiejsze niż czytanie i rozumienie, co robi (przechodzenie przez kod pomaga, ale musisz pamiętać o wielu klasach / plikach źródłowych razem, nawet nie wiesz, dla czego zostały napisane, kod wielowątkowy dodaje punkty malus).

Z początku brzmi to dziwnie, ale po pewnym czasie wydawało się to rozsądne

Bazując na moim doświadczeniu, uszeregowałem następujące działania w kolejności od najłatwiejszej do najtrudniejszej.

1. Czytanie dobrego kodu
2. Pisanie złego kodu
3. Pisanie dobrego kodu
4. Odczytywanie złego kodu

Powyższy ranking prowadzi do 2 wniosków

1. Chociaż łatwiej jest pisać kod niż czytać zły kod, łatwiej jest czytać dobry kod niż pisać własny kod
2. Pisanie złego kodu jest łatwiejsze niż pisanie dobrego kodu, ale pisanie złego kodu pozwala na odczytanie złego kodu, co jest najtrudniejsze ze wszystkich. Zwłaszcza, że ​​zły kod jest czytany więcej niż jest zapisywany.

Oczywiście dobry kod i zły kod to szerokie uogólnienia. Polecam Code Complete i Clean Code, aby uzyskać więcej informacji na temat dobrego kodu.

To pytanie odwołuje się do fałszywego konsensusu. http://en.wikipedia.org/wiki/False-consensus_effect

Różni ludzie inaczej uczą się i przyswajają informacje. Jest podobny do słuchaczy, uczniów wizualnych i uczniów kinestetycznych. Dla niektórych czytanie kodu jest łatwiejsze, dla innych tworzenie kodu jest łatwiejsze. Dla mnie to jest to drugie. Dla innych w moim zespole jest to pierwszy. Nie sądzę, aby znalezienie jakiegoś konsensusu lub większości było przydatne. Lepiej jest zrozumieć, w jaki sposób twój mózg absorbuje i uczy się informacji, i wykorzystuj tę wiedzę, aby stać się lepszym i nauczyć się akceptować innych, którzy są inni.

różnice między pisaniem dużego oprogramowania C ++ a rozumieniem go jako nowego rekruta

To nie to samo, co różnica między oprogramowaniem do czytania i pisania. Kiedy jesteś nowy w projekcie (a zwłaszcza gdy jesteś nowy w firmie), musisz dowiedzieć się o wiele więcej niż tylko kod. Zrozumienie, dlaczego kod robi to, co robi, często wymaga zrozumienia, w jaki sposób działa firma i jak projekt odnosi się do reszty organizacji. Krótko mówiąc, czytanie kodu bez wiedzy w tle jest wolniejszym, trudniejszym zadaniem niż czytanie kodu, gdy w pełni rozumiesz kontekst, w którym działa kod.

Jest to różnica między pisząc nowy kod na przedsięwzięcia typu greenfield i czytania i modyfikowania istniejącego kodu, ale nie powiedziałbym, że jest zawsze łatwiej niż inne, po prostu inna. Kiedy tworzysz coś nowego, nie musisz się martwić, jak sprawić, by Twój kod działał z tym, co już istnieje, ale musisz się martwić, czy twój projekt będzie wystarczająco rozszerzalny i dostosowalny, aby był przydatny w przyszłości . Kiedy pracujesz nad istniejącym projektem, często możesz wykorzystać to, co już istnieje, jako przewodnik, ale najpierw musisz zrozumieć, co tam jest.

Jako „nowy rekrut” zwykle lepiej jest pracować nad istniejącym projektem, ponieważ pomaga on nauczyć się wszystkiego, czego nie wiesz: jak działa firma, jak współpracują różne projekty, kodować standardy i praktyki, a nawet (szczególnie) co można poprawić.

To interesujące pytanie, ale skłaniam się ku stronie, która jest łatwiejsza do odczytania i zrozumienia niż do stworzenia.

Jeśli jesteś doświadczonym programistą, możesz przeczytać kod i powiedzieć: „Tak, dobry wybór, sprawdź, och, mogłem zrobić X zamiast Y” itp. Możesz zmodyfikować lub dostosować, ale to by zaoszczędź mnóstwo czasu na pisaniu od zera (chyba że istnieją ku temu powody).

Jeśli jesteś nowszym programistą, to „nie wiesz, czego nie wiesz”, więc będziesz musiał wymyślić / nauczyć się wszystkich drobiazgów, i najprawdopodobniej będziesz mieć problemy z wydajnością kod. Prawdopodobnie jednak lepiej zrozumiesz język.

Ale w obu przypadkach łatwiej będzie odczytać kod i przejść od tego miejsca niż napisać go całkowicie od zera.

Większość programistów łatwiej jest zrozumieć kod, który sami napisali, niż kod napisany przez innych ludzi. Jest to spowodowane zarówno wspomnianym przez ciebie uczeniem się linia po linii, jak i kwestią indywidualnego stylu i talentu. Dlatego dzieje się tak wiele nowych wynalazków kół.

Taki jest jednak widok drzew. Widok lasu jest taki, że znacznie łatwiej jest odczytać kod niż napisać go od zera. Na przykład, czy łatwiej jest napisać nowy edytor tekstu od zera, czy nauczyć się istniejącej bazy kodu wystarczająco dobrze, aby wprowadzić ulepszenia?

Kiedy zaczynasz czytać kod, możesz pomyśleć o bazillionowych sposobach, aby ułatwić sobie czytanie kodu. Pierwszy raz spędzasz na śledzeniu kodu, próbując dowiedzieć się, jaki jest ukształtowanie terenu, czasem w architekturze całkowicie anatemą tego, jak chcesz to zrobić. Ale nawet w naprawdę dużych bazach kodu spędzisz może 40-80 godzin na kręceniu kółkami, w porównaniu do setek tysięcy roboczogodzin zainwestowanych już w tworzenie tej aplikacji.

Osoba pisząca oprogramowanie prawie zawsze najlepiej rozumie program, po prostu znając logikę i swój proces myślenia podczas pisania.

Nie sądzę, że pisanie kodu w ogóle można porównać do czytania kodu pod względem łatwości zrozumienia. Z jednej strony po prostu oprogramowanie do pisania zapewnia lepsze zrozumienie tego konkretnego oprogramowania dzięki znajomości kontekstu związanego z każdą sekcją kodu, użytą biblioteką itp. Jednak czytanie kodu napisanego przez innych może być trudne do zrozumienia pod względem rzeczywiste oprogramowanie, ale jeśli chodzi o rozumienie języka, może zapewnić wgląd w nowe sposoby robienia rzeczy lub korzystania z biblioteki, których prawdopodobnie nie rozważałeś, co może prowadzić do ułatwienia pisania kodu.

Jeśli chodzi o wiedzę na temat kompilacji, myślę, że czytanie kodu i pisanie kodu są ze sobą bardzo powiązane i na wiele sposobów się ze sobą łączą. Doświadczenie w pisaniu kodu zapewnia łatwość zrozumienia innych kodów, a czytanie kodu pozwala na łatwiejsze pisanie kodu (dzięki nowym koncepcjom logicznym, użyciu biblioteki itp.).

Jest to coś, co osobiście uważałem za oczywiste, ale nigdy nie byłem całkowicie pewien, czy odnosi się to do populacji programistów jako całości. Na przykład znałem bardzo utalentowanych programistów, którzy zamiast czytać dokumentację, mogą z przyjemnością przeglądać kod innych ludzi i rozumieć go tak, jakby był ich własnym.

To prowadzi do pytania: czy to ma znaczenie?

Jeśli czytasz kod, prawdopodobnie dokonujesz zmiany, a nie przepisujesz go. Nawet jeśli przepisujesz go, prawdopodobnie będziesz pisać w nowym języku / wersji, więc niekoniecznie możesz stworzyć kod w ten sam sposób. Chodzi mi o to, że nie zawsze konieczne jest zrozumienie całego kodu przez cały czas.

Wszystko to jest prawdą, nowsze metodologie programowania, np. BDD , zdają sobie sprawę z tego, że logika biznesowa musi być czysta z kodu, a nie z samego kodu, który jest sposobem na sterowanie maszyną. To oczywiście nie jest nic nowego - koncepcja istnieje od czasu przełomowej pracy Donalda Knutha: Programowanie literackie .

Jestem zainteresowany odpowiedzią StMotorSpark, po prostu dodając:
To zależy od tak wielu czynników, że nie może to być pytanie tak lub nie, na przykład:

• Czy istniejący kod jest dobrze udokumentowany i dobrze napisany, czy też wygląda jak spaghetti bez sensu i komentarzy?
• Czy jest to niewielka aplikacja z bardzo rzadkimi sytuacjami, które wymagają niekończącego się czasu, aby znaleźć rozwiązanie, czy też większa, ale prosta aplikacja?
• itp.