Kłamstwo 2: Kod powinien być zaprojektowany wokół modelu świata? [Zamknięte]

23

Niedawno przeczytałem post na blogu Three Big Lies i trudno mi uzasadnić drugie kłamstwo, które jest cytowane tutaj:

(LIE # 2) KOD MUSI BYĆ ZAPROJEKTOWANY WOKÓŁ MODELU ŚWIATA

Nie ma żadnej wartości w kodzie będącym jakimś modelem lub mapą wyimaginowanego świata. Nie wiem, dlaczego jest tak atrakcyjny dla niektórych programistów, ale jest niezwykle popularny. Jeśli w grze jest rakieta, możesz mieć pewność, że istnieje klasa „Rakieta” (zakładając, że kod to C ++), która zawiera dane dokładnie dla jednej rakiety i wykonuje rakietowe rzeczy. Bez względu na to, jaka transformacja danych jest rzeczywiście wykonywana, ani na układ danych. Lub, jeśli o to chodzi, bez podstawowego zrozumienia, że ​​tam, gdzie jest jedna rzecz, prawdopodobnie jest więcej niż jedna.

Chociaż za tego rodzaju projekty istnieje wiele kar za wydajność, najbardziej znaczące jest to, że nie skaluje się. W ogóle. Sto rakiet kosztuje sto razy więcej niż jedna rakieta. I jest bardzo prawdopodobne, że kosztuje to jeszcze więcej! Nawet nie-programistom nie powinno to mieć żadnego sensu. Ekonomia skali. Jeśli masz coś więcej, powinno stać się tańsze, a nie droższe. Sposobem na to jest odpowiednie zaprojektowanie danych i pogrupowanie rzeczy według podobnych przekształceń.

Oto moje problemy z tym kłamstwem.

  1. Kod ma wartość modelu / mapy wyobrażonego świata, ponieważ modelowanie wyobrażonego świata pomaga (przynajmniej ja, osobiście) wizualizować i organizować kod.

  2. Posiadanie klasy „Rakieta” jest dla mnie idealnie uzasadnionym wyborem na klasę. Być może „rakiety” można podzielić na typy rakiet, takie jak AGM-114 Hellfire itp., Które zawierają siłę nośną, maksymalną prędkość, maksymalny promień skrętu, typ celowania itd., Ale nadal każda wystrzelona rakieta musi mieć pozycję i prędkość.

  3. Oczywiście posiadanie 100 rakiet kosztuje więcej niż 1 rakietę. Jeśli na ekranie jest 100 Rakiet, musi być 100 różnych obliczeń, aby zaktualizować ich pozycję. Drugi akapit brzmi, jakby twierdził, że jeśli jest 100 rakiet, aktualizacja stanu powinna kosztować mniej niż 100 obliczeń?

Mój problem polega na tym, że autor przedstawia „wadliwy” model programowania, ale nie przedstawia sposobu na jego „poprawienie”. Być może podchodzę do analogii z klasą rakiet, ale naprawdę chciałbym zrozumieć powód tego kłamstwa. Jaka jest alternatywa?

thndrwrks
źródło
9
@gnat: To pytanie jest całkowicie w gestii projektowania oprogramowania, więc jestem skłonny dać mu trochę swobody.
Robert Harvey,
12
Ten post na blogu jest dość słabo napisany i nie broni zbyt dobrze i nie wspiera swoich roszczeń. Nie zastanawiałbym się nad tym.
whatsisname
21
Ktokolwiek napisał ten cytat, jest idiotą, który nie rozumie pojęć OO ani tego, jak są one implementowane w oprogramowaniu. Po pierwsze, nie odwzorowujemy świata wyobrażonego, lecz odwzorowujemy świat rzeczywisty. A jeśli masz 100 rakiet, tylko stan dodatkowych rakiet zużywa dodatkowe zasoby, a nie model lub zachowanie. Wydaje się, że ma różne pomysły na ten temat i sugeruje rozwiązanie problemu, który nie istnieje. „Grupowanie podobnych rzeczy” jako optymalizacja może czasami mieć sens, ale jest całkowicie niezależne od korzystania z klas lub nie. Jeśli chcesz się uczyć, unikaj tego szarlatana.
Martin Maat,
3
Biorąc pod uwagę, że autor nie zadał sobie trudu napisania łącznie więcej niż 5 akapitów wyjaśniających „3 wielkie kłamstwa”, prawdopodobnie spędziłeś więcej czasu na myśleniu o tym artykule niż on. Jeśli nie będzie się starał, nie powinieneś.
Caleb,
9
Myślę, że to, o co mu chodzi, to czy naprawdę potrzebujesz 100 [prawdopodobnie dynamicznie przydzielanych również metodami wirtualnymi] „obiektów rakietowych”, w przeciwieństwie do listy pozycji, listy prędkości itp. (Posiadającej listę wszystkich pozycji i lista prędkości oznacza, że ​​możesz użyć instrukcji wektorowych, aby dodać prędkość do pozycji przy każdej aktualizacji tiku zamiast pisać naiwną pętlę przez listę obiektów)
Random832

Odpowiedzi:

63

Po pierwsze, spójrzmy na jakiś kontekst: jest to projektant gry piszący na blogu, którego tematem jest wyliczanie ostatniej spadku wydajności z procesora Cell BE. Innymi słowy: chodzi o programowanie gier konsolowych, a dokładniej programowanie gier konsolowych na PlayStation 3.

Teraz programiści gier to ciekawa gromada, jeszcze bardziej programiści gier konsolowych, a Cell BE to dość dziwny procesor. (Jest powód, dla którego Sony zdecydowało się na bardziej konwencjonalny projekt na PlayStation 4!)

Musimy więc spojrzeć na te stwierdzenia w tym kontekście.

Istnieje również kilka uproszczeń w tym poście na blogu. W szczególności ten kłamstwo nr 2 jest źle przedstawiony.

Twierdziłbym, że wszystko , co abstrahuje od realnego świata, jest w pewnym sensie modelem. A ponieważ oprogramowanie nie jest rzeczywiste, ale wirtualne, zawsze jest abstrakcją, a zatem zawsze modelem. Ale! Model nie musi mieć czystego mapowania 1: 1 na prawdziwy świat. To w końcu sprawia, że ​​jest to model.

W pewnym sensie autor jest w błędzie: oprogramowanie jest modelem. Kropka. W pewnym sensie ma rację: ten model wcale nie musi przypominać prawdziwego świata.

Podam przykład, który już dawno podałem w innych odpowiedziach, (nie) słynny przykład Wprowadzenie do rachunku bankowego OO 101. Oto jak wygląda konto bankowe w prawie każdej klasie OO w historii:

class Account {
  var balance: Decimal
  def transfer(amount: Decimal, target: Account) = {
    balance -= amount
    target.balance += amount
  }
}

A więc: balancejest to dane i transferjest operacją .

Ale! Oto jak wygląda konto bankowe w prawie każdym oprogramowaniu bankowym:

class TransactionSlip {
  val transfer(amount: Decimal, from: Account, to: Account)
}

class Account {
  def balance = 
    TransactionLog.filter(t => t.to == this).map(_.amount).sum - 
    TransactionLog.filter(t => t.from == this).map(_.amount).sum
}

Tak, teraz transferjest dane i balancejest operacja (w lewo zagiąć dziennika transakcji). (Zauważysz również, że TransactionSlipjest niezmienna, balancejest czystą funkcją, TransactionLogmoże być jedynie „prawie” niezmienną strukturą danych tylko z dopiskiem… Jestem pewien, że wielu z was zauważyło rażące błędy współbieżności w pierwszej implementacji, które teraz magicznie znikają .)

Zauważ, że oba są modelami. Oba są równie ważne. Oba są poprawne. Oba modele modelują to samo. A jednak są one dokładnie dualne : wszystko, co jest danymi w jednym modelu, jest operacją w drugim modelu, a wszystko, co jest operacją w jednym modelu, to dane w drugim modelu.

Zatem pytanie nie dotyczy tego , czy modelujesz „prawdziwy świat” w swoim kodzie, ale jak go modelujesz.

Jak się okazuje, drugi model jest tak naprawdę działaniem bankowości w prawdziwym świecie. Jak już wspomniałem powyżej, ten drugi model jest w większości niezmienny i czysty oraz odporny na błędy współbieżności, co w rzeczywistości jest bardzo ważne, jeśli weźmie się pod uwagę, że nie było tak dawno temu, gdzie TransactionSlipbyły faktyczne kartki papieru, które zostały wysłane konno i powóz.

Jednak fakt, że ten drugi model faktycznie pasuje zarówno do tego, jak działa bankowość w świecie rzeczywistym, jak i do tego, jak działa oprogramowanie do bankowości w świecie rzeczywistym, nie powoduje, że staje się ona w jakiś sposób bardziej „odpowiednia”. Ponieważ tak naprawdę pierwszy („zły”) model dość dokładnie przybliża sposób, w jaki klienci bankowości postrzegają swój bank. Do nich , transferto operacja (mają do wypełnienia formularza), a balanceto kawałek danych na dnie ich wyciągu z rachunku.

Może więc być prawdą, że w podstawowym kodzie silnika gry wysokowydajnej strzelanki PS3 nie będzie żadnego Rockettypu, ale nadal będzie istniało pewne modelowanie świata, nawet jeśli model wygląda dziwnie dla kogoś, kto nie jest ekspertem w dziedzinie programowania silnika fizyki gier konsolowych.

Jörg W Mittag
źródło
1
Czy nie oznacza to, że dobry kod modeluje rzeczywisty świat i że w rzeczywistości jest to tylko nieporozumienie prawdziwego świata, które powoduje zły model, a zatem zły kod?
yitzih
14
Wolę sformułować to jako „czasami prawdziwy świat nie jest tym, za kogo się wydaje”, lub „to, co„ rzeczywisty świat ”zależy od kontekstu”. (Ponownie, dla właściciela konta bankowego, dane na dole wyciągu są bardzo prawdziwe, podczas gdy dla pracownika banku są ulotne.) Myślę, że oświadczenie w blogu jest głównie spowodowane tym, że autor nie rozumie, że „modelowanie prawdziwy świat „nie oznacza” robienia zdjęcia i uczynienia z klasy wszystkiego, co się tam widzi.
Jörg W Mittag,
Interfejs aplikacji bankowości internetowej prawdopodobnie będzie traktował balancedane i transakcje jako więcej danych, a przelewy jako operacje, ponieważ to właśnie widzi użytkownik, nawet jeśli zaplecze może traktować je inaczej.
user253751,
@yitzih: każdy model jest abstrakcją i uproszczeniem, więc możesz oskarżyć każdy model o niepoprawność, ale to nie jest konstruktywne. Każdy model musi spełniać swój cel i musi być na to wystarczająco dobry, nie marnując zasobów na niepotrzebne rzeczy. W przypadku oprogramowania rządowego człowiekiem może być ktoś, kto może brać udział w wyborach, musi płacić podatki lub może być żonaty z innym człowiekiem, w przypadku naszego oprogramowania CRM człowiek to ktoś, kto jest związany z zamówieniami i ma adres dostawy (i żadne modeluje, jak je (je)…
Holger,
2
Jeśli człowiek wie coś o bankowości , będzie mu łatwiej, a ponieważ techniki bankowe, o których wiedzą, zostały wymyślone, aby bankowość działała, mogą sprawić, że oprogramowanie bankowe będzie działać. Nie dlatego, że drugi model jest „bardziej podobny do prawdziwego świata”, ale dlatego, że opisuje lepszy bank. Pierwszy model może być równie dokładną reprezentacją dysfunkcyjnego banku w prawdziwym świecie! Zgadnij, co: jeśli chcesz dobrego oprogramowania bankowego, programiści muszą nauczyć się dobrze robić bankowość, choćby z dokumentów wymagań.
Steve Jessop,
19

Nie zgadzam się z każdym „kłamstwem”, które proponuje.

TL; DR Autor tego artykułu starał się być kontrowersyjny, aby uczynić ich artykuł bardziej interesującym, ale tak zwane „kłamstwa” są akceptowane przez twórców oprogramowania z dobrych powodów.

Kłamstwo 1 - Duże O ma znaczenie dla celów skalowania. Nikt nie dba o to, czy mała aplikacja zajmuje więcej czasu, co jest jedyną stałą czasową, ważne, że gdy podwoją rozmiar wejściowy, nie zwielokrotni czasu wykonania przez współczynnik 10.

Kłamstwo 2 - Modelowanie programów po rzeczywistym świecie pozwala programiście spojrzeć na twój kod 3 lata później, aby łatwo zrozumieć, co robi. Kod musi być łatwy do utrzymania, w przeciwnym razie musisz poświęcić wiele godzin, próbując zrozumieć, co program robi. Inna odpowiedź sugeruje, że możesz mieć bardziej ogólne klasy, takie jak LaunchPadi MassiveDeviceMover. Niekoniecznie są to złe klasy, ale nadal będziesz ich potrzebować Rocket. Skąd ktokolwiek powinien wiedzieć, co MassiveDeviceMoverrobi lub co się porusza? Czy porusza się po górach, statkach kosmicznych czy planetach? Zasadniczo oznacza to, że dodawanie takich klas jakMassiveDeviceMover czyni program mniej wydajnym (ale być może znacznie bardziej czytelnym i zrozumiałym).

Dodatkowo koszt czasu programisty już dawno zaczął przewyższać koszt sprzętu. To okropny pomysł, aby zacząć od optymalizacji z przodu swoich myśli. Programujesz go w łatwy i zrozumiały sposób, a następnie poprawiasz program po ustaleniu, które części programów zajmują dużo czasu. Nie zapomnij: 80% czasu wykonania jest wykorzystywane przez 20% programu.

Kłamstwo 3 - Kod jest niezwykle ważny. Dobrze napisany (i modułowy) kod pozwala na ponowne wykorzystanie (oszczędzając niezliczoną liczbę roboczogodzin). Pozwala także na przesiewanie i rozpoznawanie złych danych, aby można było je obsłużyć. Dane są cudowne, ale bez kodu nie byłoby możliwe ich przeanalizowanie i uzyskanie przydatnych informacji.

yitzih
źródło
5
Myślę, że jestem bardziej sympatyczny do # 3. W ciągu 30 lat programowania ogromną większość błędów, problemów z wydajnością i innych problemów, które widziałem, udało się rozwiązać, naprawiając reprezentację danych. Jeśli dane są prawidłowe, kod praktycznie sam się pisze.
Lee Daniel Crocker,
6
Prawdziwy problem z numerem 3 polega na tym, że porównuje jabłka z pomarańczami, a nie, że kod jest ważniejszy niż dane i odwrotnie.
Doc Brown,
3
Dane wejściowe nie są w twoich rękach, ale sposób reprezentowania danych w twoim oprogramowaniu jest całkowicie w ich obrębie. Być może nazywasz tę część „kodowaniem”, ale myślę, że tak nie jest: na przykład często jest ona niezależna od języka i często jest wykonywana przed rozpoczęciem jakiegokolwiek kodowania. Zgadzam się jednak, że kod, który czyści brzydkie dane wejściowe, jest często dobrą rzeczą; ale nie możesz tego zrobić, dopóki nie zdefiniujesz pojęcia „czysty”.
Lee Daniel Crocker,
3
Właściwie nie sądzę, by Kłamstwo 3 było Kłamstwem. Fred Brooks napisał już kilkadziesiąt lat temu: „Pokaż mi swoje schematy blokowe i ukryj swoje tabele, a ja nadal będę mistyfikowany. Pokaż mi swoje tabele i zwykle nie będę potrzebować twoich schematów blokowych; będą oczywiste”. (W dzisiejszych czasach prawdopodobnie rozmawialibyśmy raczej o „algorytmach” i „typach danych” lub „schematach”). Tak więc znaczenie danych jest znane od dawna.
Jörg W Mittag,
1
@djechlin Nie miałem na myśli tego, że dane nie są ważne lub że kod jest ważniejszy. Po prostu dane nie są ważniejsze niż kod. Oba są bardzo ważne i bardzo na sobie polegają.
yitzih
6

W systemie e-commerce nie zajmujesz się „rakietami” na poziomie klasowym, lecz „produktami”. To zależy od tego, co próbujesz osiągnąć i od pożądanego poziomu abstrakcji.

W grze można argumentować, że rakiety są tylko jednym z wielu rodzajów „ruchomych obiektów”. Dotyczy to tej samej fizyki, co wszystkich innych ruchomych obiektów. Przynajmniej „rakieta” odziedziczy po jakiejś bardziej ogólnej klasie bazowej „ruchomych obiektów”.

W każdym razie autor cytowanego przez ciebie fragmentu nieco zawyżał swoją sprawę. Rakiety mogą nadal mieć unikalne cechy, takie jak „pozostała ilość paliwa” i „ciąg”, i nie potrzebujesz stu klas, aby reprezentować to dla stu rakiet, potrzebujesz tylko jednej. Tworzenie obiektów jest dość tanie w większości przyzwoitych języków programowania, więc jeśli chcesz śledzić rzeczy podobne do rakiet, pomysł, że nie powinieneś tworzyć obiektów rakietowych, ponieważ może być zbyt drogi, nie ma większego sensu.

Robert Harvey
źródło
5

Problemem w prawdziwym świecie jest cała ta przeklęta fizyka. W prawdziwym świecie dzielimy rzeczy na obiekty fizyczne, ponieważ łatwiej je przemieszczać niż pojedyncze atomy lub gigantyczny stopiony żużel czegoś, co potencjalnie może być rakietą.

Podobnie rzeczywisty świat zapewnia wiele przydatnych funkcji, na których polegamy. Naprawdę łatwo jest zrobić wyjątek od pingwina - „wszystkie ptaki latają, z wyjątkiem…”. I naprawdę łatwo jest nazwać rzeczy rakietami, to znaczy, jeśli nazywam tego pingwina rakietą i zapalam ... to po prostu nie działa.

Tak więc, jak rozdzielamy rzeczy w świecie rzeczywistym, koncepcyjnie działa pod tymi ograniczeniami. Kiedy robimy rzeczy w kodzie, powinniśmy rozdzielić rzeczy, aby działały dobrze w tych ograniczeniach, które są zdecydowanie różne.

Jaka jest alternatywa?

Pomyśl o sieciach. Nie modelujemy portów, przewodów i routerów w kodzie. Zamiast tego dzielimy komunikację sieciową na połączenia i protokoły. Robimy to, ponieważ jest to użyteczna abstrakcja niezależnie od implementacji w prawdziwym świecie. I nakłada użyteczne ograniczenia (np .: nie można się komunikować, dopóki połączenie nie zostanie otwarte), które mają znaczenie tylko w kodzie .

Tak, czasami modelowanie kodu po rzeczywistym świecie działa, ale to zbieg okoliczności . Kiedy ludzie mówią o OOP, obiekty nie są obiektami ze świata rzeczywistego. To, że szkoły i samouczki mówią inaczej, jest tragiczną dekadą.

Telastyn
źródło
1
+1: Protokoły są w dużej mierze abstrakcją „prawdziwego świata”. Nawet w dzisiejszym świecie funkcjonariusze protokołu są jednymi z najważniejszych pracowników na przykład podczas wizyty państwowej. Kto idzie pierwszy na czerwonym dywanie na spotkaniu G8, Obamie lub Putinie? Czy ściskają lub podają sobie ręce? Jak przywitać się z Arabem a Hindusem? I tak dalej. Mamy wiele „rzeczy” w „prawdziwym świecie”, które nie są „rzeczami” w „świecie fizycznym”. Modelowanie świata rzeczywistego nie oznacza modelowania świata fizycznego. Nawet jeśli Rocketw kodzie tego faceta nie ma żadnego typu, jestem gotów się założyć, że istnieje jednak jakiś model…
Jörg W Mittag
… Prawdziwy świat, nawet jeśli nie odpowiada on żadnemu „fizycznemu” (w znaczeniu „dotykalnym”). Nie zdziwiłbym się, gdybym znalazł tam rzeczywiste „fizyczne” obiekty (w sensie „rzeczy, które fizyk mógłby rozpoznać”), takie jak ćwiartki, tensory, pola itp., Które oczywiście są również „ rzeczy realne ”i„ modele realnego świata ”.
Jörg W Mittag,
Alan Kay wyobrażał sobie Dynabook jako komputer, który byłby przekazywany dzieciom od urodzenia i który stałby się przedłużeniem ich mózgu. Wzorzec MVC miałby zatem umożliwić widokowi i kontrolerowi wypełnienie luki między mózgiem a modelem w celu wsparcia metafory bezpośredniej manipulacji, tj. Złudzenia, że ​​komputer jest tylko przedłużeniem mózgu i że można bezpośrednio manipuluj obiektami modelowymi własnymi myślami. I to właśnie mamy na myśli, gdy mówimy, że model domeny modeluje „prawdziwy świat”. Powinien implementować abstrakcje w naszych mózgach.
Jörg W Mittag,
A kiedy myślę o silniku fizyki gier konsolowych, prawdopodobnie prawdopodobnie nie myślę o rakietach, dlatego w moim kodzie nie powinno być modelu rakiety. Ale ja prawdopodobnie myśli jakieś inne „myśli prawdziwy świat”, i nie powinny być modele te w kodzie.
Jörg W Mittag,
2

Alternatywą jest modelowanie rzeczy, o które dbają twoje programy. Nawet jeśli twój program zajmuje się rakietami, być może nie będziesz potrzebować bytu o nazwie Rocket. Na przykład możesz mieć LaunchPadencję oraz LaunchScheduleencję i MassiveDeviceMoverencję. Fakt, że wszystko to pomaga w wystrzeliwaniu rakiet, nie oznacza, że ​​sam radzisz sobie z rakietami.

BobDalgleish
źródło
0

Mój problem polega na tym, że autor przedstawia „wadliwy” model programowania, ale nie przedstawia sposobu na jego „poprawienie”. Być może podchodzę do analogii z klasą rakiet, ale naprawdę chciałbym zrozumieć powód tego kłamstwa. Jaka jest alternatywa?

To jest prawdziwy problem, ale dam ci moją opinię jako programisty, może to pomoże.

Po pierwsze, nie nazwałbym tego kłamstwem, jako powszechne nieporozumienia. Nazywanie tego kłamstwem to tylko szum.

Jeden On ma rację pod pewnymi względami. Nie zamierzam poświęcać na to dużo czasu, ponieważ nie jest to częścią pytania. Ale w gruncie rzeczy ma rację. Mógłbym to powtórzyć jako „To, co działa w laboratorium, może nie działać w prawdziwym życiu”. Zbyt wiele razy programiści trzymają się projektu, który działa w „laboratorium”, ale zawodzi w rzeczywistych aplikacjach.

Three Brzmi dla mnie trochę jak mydło, ale w gruncie rzeczy znowu ma rację. Ale można to napisać od nowa: „pisz kod wokół swoich potrzeb, nie próbuj dopasowywać potrzeb do swojego kodu”.

Dwa Znowu, tutaj ma rację. Widziałem, jak programiści spędzili tygodnie lub dłużej, rozwijając klasę „rakietową”, kiedy działałaby prosta klasa „pojazdu” lub nawet prostsza, „ruchoma” klasa. Jeśli wszystko, co musisz zrobić, to przesunąć się z lewej strony ekranu na prawą i wydać dźwięk, możesz użyć tej samej klasy co dla samochodów, pociągów, łodzi i much. Argument 100 powinien kosztować mniej niż 1 * 100, wydaje się, że jest to czas poświęcony na rozwój, a nie tyle na koszty obliczeń. Chociaż trzymanie się mniejszej liczby klas ogólnych, że ponowne użycie jest „tańsze”, to wiele konkretnych klas, których nie można ponownie wykorzystać. Można to prawdopodobnie przepisać, ponieważ „klasy ogólne są lepsze niż określone klasy,

Zasadniczo cały artykuł mógłby zostać przepisany, z mniejszą liczbą modnych słów, a w najlepszym razie byłby to tylko akapit. To powiedziawszy, jest to blog poświęcony wąskiemu obszarowi programowania. Zrobiłem trochę programowania wbudowanego i mogę się zgodzić z ogólną ideą tych oświadczeń, chociaż wokół nich jest sporo „puchu”, aby nadać się do prezentacji na GDC.

Ostatnia uwaga, artykuł został napisany w 2008 roku (najlepiej, co mogłem powiedzieć). Rzeczy zmieniają się szybko. Stwierdzenia są dziś prawdziwe, ale systemy osadzone są dziś znacznie bardziej powszechne i zmieniają się wzorce programistyczne. Być może nawet w odpowiedzi na ten artykuł / wykład.

Coteyr
źródło
-1

Uważam za interesujące, że leżą one wokół problemów akademickich: platformy, wydajności wykorzystania pamięci i danych. Ale całkowicie ignoruje element ludzki.

Oprogramowanie polega na zaspokajaniu potrzeb ludzi. Zazwyczaj jest to wyrażone ilościowo w kategoriach biznesowych - są klienci, którzy czegoś chcą, i sponsorzy, którzy są gotowi zapłacić, aby tak się stało. Jeśli oprogramowanie jest pisane w taki sposób, aby spełniało potrzeby obu stron równania, to jest to dobre oprogramowanie, jeśli nie, to jest złe.

Jeśli platforma nie jest ważna dla klienta, to platforma nie jest ważna. Jeśli wydajność pamięci nie jest ważna dla klienta, to nie jest ważna. Jeśli dane nie są ważne dla klienta, dane nie są ważne. Jeśli kod działa, ale nie można go odczytać ani zachować, a klient chce szybkich i niezawodnych zmian za przyzwoitą cenę, źle napisany kod jest złą rzeczą. Jeśli kod działa, ale nie można go odczytać ani zachować, a klient nie dba o to lub jest gotów zapłacić za drogie programy refaktorskie, to źle napisany kod jest dobrą rzeczą.

Wielkim kłamstwem jest to, że wszystko oprócz ludzkiego elementu ma znaczenie. Dlaczego dane są ważne? Ponieważ jest jakiś klient lub interesariusz, który tego potrzebuje. To jest „wielka prawda”.

Price Jones
źródło
4
Niestety klienci oczekują szybkiego i brudnego kodu, który jest łatwy do odczytania i konserwacji, tani, bez wysiłku testowania i bez błędów.
Gonen I
@ user889742 Ha! Prawdziwe. Dokładnie powiedziałeś, że inżynierowie próbowali rozwiązać problem przez cały czas, a to sprawia, że ​​przemysł jest tak interesującą przestrzenią do pracy.
Price Jones
Ignoruje element ludzki, ponieważ jest twórcą gier, a okres konserwacji gry jest stosunkowo krótki, choć dziś jest dłuższy niż w 2008 roku. Łaty w 1. dniu wydają się być normą w grach już od kilku dni. W 2008 roku łatki do gier były wciąż stosunkowo rzadkie.
RubberDuck
-1

IMHO Jeśli kod jest „zaprojektowany wokół modelu świata”, łatwiej jest go zrozumieć zarówno dla projektantów i programistów, jak i dla opiekunów. Ale myślę, że to nie tylko ja, a nie tylko oprogramowanie. Z Wikipedii: Modelowanie naukowe to działalność naukowa, której celem jest ułatwienie zrozumienia, zdefiniowania, kwantyfikacji, wizualizacji lub symulacji określonej części lub cechy świata poprzez odniesienie do istniejącej i zwykle powszechnie akceptowanej wiedzy

Gonen I.
źródło