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

12

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

Makane Elhay
źródło
1
Krótkie wyjaśnienie zamknięcia: Chociaż jest to doskonałe pytanie, jest to również pytanie, na które po prostu nie można odpowiedzieć, tylko omówione (obszernie). Jest zbyt wiele czynników, które należy wziąć pod uwagę, jakość i styl kodu, umiejętności uczenia się czytelnika oraz znajomość projektu i języka, wielkość projektu i tak dalej. Jeśli jesteś zainteresowany dalszymi dyskusjami na temat zamknięcia, jest już pytanie na ten temat na naszej stronie Meta.
yannis
Książka „Wzory praktyk” opowiada o podróży od nowicjusza do mistrza rzemieślnika. Odpowiada na wiele pytań początkujących, praktykantów i programistów na poziomie czeladników. Wykorzystanie wielu wzorów zajmuje trochę czasu, ale jest to część podróży. Jednym ze wzorów jest napisanie „Broken Toys” lub „Prototypes”, które pomagają ustalić i porównać z systemami produkcyjnymi. Istnieje wiele innych przydatnych wzorów.
GuruM

Odpowiedzi:

41

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.

Aaron Kurtzhals
źródło
Wiele innych rzeczy może prowadzić do „złego kodu” - braku wewnętrznej spójności, ujednolicenia wizji lub planowania. Ogólny brak planowania lub właściwej modularyzacji kodu. Widziałem dobry kod, który był bezcelowy, ponieważ nie korzystał z wbudowanych funkcji językowych, które działałyby równie dobrze.
Ben DeMott,
Jak napisać dobry kod: cdn.thenextweb.com/files/2011/01/65987_700b.jpg
CurtisHx
2
W mojej skali czytanie złego kodu pozostaje łatwiejsze niż pisanie dobrego kodu. W najgorszym przypadku możesz uruchomić debugger na złym kodzie, który próbujesz odczytać, lub edytować go za pomocą narzędzia refaktoryzującego.
mouviciel
2
Pisanie złego kodu jest łatwe tylko do momentu, w którym musi zostać zintegrowany i działać lub zmienić w zależności od zmieniających się wymagań. Jeśli „zaprogramujesz się w kącie”, nie będzie to już łatwe.
Kaz
@mouviciel Odczytywanie złego kodu napisanego przez bardzo sprytnych programistów, którzy nie powinni pisać złego kodu, może być trudne. Czytanie złego kodu napisanego przez naiwnych programistów jest łatwe. Wystarczy założyć „naiwny kapelusz” i staje się oczywiste, czego nie udaje się osiągnąć kod. :)
Kaz
13

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.

mawcsco
źródło
1
Z pewnością zadawanie pytań i pozyskiwanie opinii jest znacznie lepsze niż zwykłe wierzenie, że ta (lub jakakolwiek inna) hipoteza jest automatycznie poprawna. Rozpoznanie, w jaki sposób różne osoby podchodzą do tego samego problemu, może często mieć pozytywny wpływ na wyniki zespołów oraz usprawnić interakcje społeczne.
Robbie Dee,
7
Masz absolutną rację. Pytanie to początek. I zrozumienie, że istnieje fałszywy konsensus, jest korzystne dla zrozumienia. Dlatego „odpowiedziałem” na pytanie, zamiast go zignorować.
mawcsco,
7

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

Caleb
źródło
Zrozumienie „kontekstowego” zakresu / głębokości systemu i bazowego API z doświadczeniem. Jakie są logiczne elementy systemu? Jak te komponenty współdziałają ze sobą? Jakie mechanizmy wykorzystują bazowe bloki konstrukcyjne? Jak zachowują się podstawowe bloki konstrukcyjne na różnych ścieżkach? Jakie są ograniczenia / cele systemu? Dlaczego wybrano pewne ścieżki w stosunku do innych kandydatów? Jeśli chcesz dodać nowy komponent, co możesz użyć ponownie i co musisz dodać ponownie? Czy widzisz z „wewnątrz systemu”? Super książka, aby zobaczyć pragmatyczne myślenie i uczenie się.
GuruM
Zbudowanie „prototypu” lub „zepsutej zabawki” (ze znanymi brakami i jedynie w celu poszukiwania alternatyw) pomogłoby „zmusić” się do przemyślenia powyższych pytań. Dodanie komponentów i dodanie funkcji, a następnie Refaktoryzacja pomogłyby w „wyczuciu” bieżących problemów i potencjalnych rozwiązań (być może poprzez wyszukiwanie na forum).
GuruM
4

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.

JohnP
źródło
2

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.

Karl Bielefeldt
źródło
Czy umiesz pisać kod i go nie rozumiesz? Skopiuj może.
JeffO
@JeffO Cały czas - lol ...
Robbie Dee
1

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

StMotorSpark
źródło
1

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 .

Robbie Dee
źródło
1

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.
JoseTeixeira
źródło
1
Bardzo dobre punkty; argumentowałbym jednak, że jest to bardziej zależne od osoby. Na przykład, nawet jeśli istnieje kod, który prawie nie ma dokumentacji, może nadal zapewniać wgląd w postaci „To dziwne, zastanawiam się, co to jest”. Jeśli ktoś naprawdę chce się uczyć, znajdzie coś pomocnego bez względu na rozmiar programu lub dokumentacji. Mając to na uwadze, dobra dokumentacja i kod, który nie jest zbyt duży, znacznie pomaga.
StMotorSpark
1
W pełni się zgadzam, zależy to również bardzo od osoby. Zauważ tylko, że ze względu na wymagania dotyczące owr, niektórzy z nas robią wiele prac od zera, podczas gdy inni robią wiele prac konserwacyjnych. To nieuchronnie doprowadzi do perfekcji dwie różne ekspertyzy, bez względu na to, czy obie zaczną od tego samego, dobrze zorganizowanego sposobu myślenia, tego samego poziomu logiki i rozumienia specyfiki języka, ...
JoseTeixeira