Jaka jest dobra metafora programowania? [Zamknięte]

Mam na myśli wyjaśnienie programistom, czym jest programowanie. Przed utworzeniem tego pytania upewniłem się, że szukam podobnych pytań, ale te, które znalazłem, wydawały się uchylać od tego pytania, a szczególnie chciałbym zobaczyć kilka metafor lub analogii. Osobiście uważam, że łatwiej jest wyjaśnić komuś coś technicznego za pomocą metafor lub analogii.

Powodem, dla którego mnie to interesuje, jest to, że wiele osób codziennie spotyka się z pracą programisty, ale jeśli zapytasz przeciętnego człowieka, czym jest lub robi programista, tak naprawdę nie wiedzą. Prowadzi to do pewnych sytuacji nieporozumień (np. „[...] ale myślałem, że jesteś dobry z komputerami!”)

Naprawdę chciałbym znaleźć najlepszą. Chciałbym móc łatwo wyjaśnić komuś, na czym polega mój wybór kariery. Oczywiście przynajmniej ogólny pomysł.

Osobiście nie mam solidnego, ale długo o tym myślałem i zwykle dążyłem do metafory „języka”, w której znamy język, który rozumieją komputery, i dlatego jesteśmy w stanie powiedzieć komputerom, co należy robić lub „uczyć” ich, aby rozwiązać nasze problemy.

Na przykład:

Wyobraź sobie, że w alternatywnej rzeczywistości istnieją humanoidalne roboty ze sztuczną inteligencją, a niektórzy ludzie są w stanie komunikować się z nimi za pomocą wspólnego języka, który jest odmianą języka angielskiego. Ci ludzie, którzy mogą komunikować się z robotami, mogą nauczyć ich, jak rozwiązywać określone problemy lub wykonywać określone zadania, takie jak wykonywanie naszych obowiązków.

Cóż, chociaż takie roboty jeszcze nie istnieją, programiści naszych czasów są jak ci ludzie, ale zamiast komunikować się z robotami, komunikują się z komputerami. Programiści „uczą” komputery, jak wykonywać określone zadania lub rozwiązywać określone problemy za pomocą oprogramowania, które tworzą za pomocą tego „wspólnego języka”.

Programiści i ten „wspólny język” dają nam takie rzeczy, jak poczta elektroniczna, strony internetowe, gry wideo, edytory tekstu, smartfony ( krótko mówiąc ) i wiele innych rzeczy, z których korzystamy na co dzień.

Nie chcę umieszczać programowania na tronie ani nic takiego, to po prostu najlepsza metafora, jaką mogłem wymyślić.

Jestem pewien, że ktoś znajdzie jakiś problem z tym, prawdopodobnie jest to trochę zmyślone, ale znowu dlatego zadaję to pytanie.

To jak pisanie szczegółowych wskazówek krok po kroku, jak prowadzić samochód. Ale zwykle trzeba dodać plany awaryjne dla takich rzeczy, jak „co się stanie, jeśli dojdzie do korka”, lub „co się stanie, jeśli ciężarówka zepsuje się na zakręcie”.

A czasem musisz zanurkować jeszcze głębiej i wyjaśnić zasady ruchu drogowego, na przykład, po której stronie jechać lub co robić na czerwonym świetle. A czasem trzeba nawet dokładnie wyjaśnić, jak działa kierownica lub pedał gazu.

I zwykle, gdy już wszystko to zostanie szczegółowo opisane, klient mówi „to jest idealne, z wyjątkiem tego, że musi pracować dla kogoś, kto prowadzi poduszkowiec”

Piszę bardzo, bardzo szczegółowe instrukcje dla bardzo, bardzo głupiej maszyny.

Używam metafory „Piszemy przepisy na drutach ”, która jest przyjazna dla babci.

Racjonalne uzasadnienie:

• Dziewiarstwo jest dość prostym procesem mechanicznym, w którym po prostu musisz dokładnie wykonać szczegółowe instrukcje, aby coś z tego wynieść.
• Większość instrukcji dziania dotyczy wielu rozmiarów. To daje ci - statystyki, ifmatematykę i pętle.
• Błąd znajdziesz w przepisie, gdy armia wściekłych babć przyjeżdża ze swymi powalonymi swetrami!

Niezbyt dobra analogia, ale kiedy ludzie każą mi naprawić swoją maszynę, mówię: „Jestem facetem, który projektuje samochody. Nie jestem mechanikiem!”

Jako dziecko czytam naprawdę dobry opis programowania: to tak, jakby powiedzieć robotowi, jak wykonać wspólne codzienne zadanie, takie jak chodzenie do szkoły. Możesz więc powiedzieć „Idź do szkoły!”, Ale nie wie jak. Mówisz więc: „wyjdź na zewnątrz, skręć w lewo, idź dalej, aż dojdziesz do szkoły, skręć w lewo, wejdź i usiądź”. Ale na drodze jest droga! Musisz więc powiedzieć mu, by „zatrzymał się na drodze, sprawdził, czy nie ma ruchu, przeszedł przez ulicę i idź dalej” gdzieś pośrodku. A co z drzwiami? Więc dodajesz „sprawdź, czy drzwi szkoły są otwarte. Jeśli nie są, otwórz je”. tam. W końcu masz program, który może powiedzieć robotowi, jak samemu dotrzeć do szkoły.

To idealnie łączy się z Logo, gdzie instruujesz żółwia w dokładnie ten sposób, aby tworzyć złożone kształty.

Programowanie jest jak pudełko czekoladek . Czasami znajdziesz to, czego szukasz od razu, ale przez większość czasu wymaga to wielu prób i błędów. Czasami dostajesz kokos.

Sygnalizacja świetlna . Samochody poruszają się lub zatrzymują. Łatwo sobie wyobrazić ustawienie jednej sygnalizacji świetlnej, ale co się stanie, jeśli dodasz inną? Co powiesz na trzecią? Co z całym miastem? System tranzytowy składa się z tysięcy świateł stopu, z których każde jest proste samo w sobie, ale jako całość staje się układem złożonym. Jeśli jedno z tych świateł sygnalizuje awarię lub gaśnie na kilka sekund, powoduje to chaos w całym systemie. Jeśli wszystko jest zsynchronizowane, po prostu czerpiesz przyjemność z jazdy.

Mówca motywacyjny znajdzie klucze do odblokowania zagadkę ludzkich motywacji, marzenia i pomysły. Każda sytuacja, każda osoba jest inna. To, co działało w przeszłości, może teraz nie być odpowiednie. Czasami klucz można wykorzystać ponownie, ale należy go dostosować do konkretnej osoby. Innym razem klucz należy wymodelować na nowo. Najbardziej satysfakcjonujące jest to, że dana osoba została odblokowana i zobaczysz, jak wychodzą i podbijają świat. Najbardziej druzgocące jest, gdy czujesz się blisko, ale po prostu nie jesteś w stanie odblokować potencjału.

Kryminał , gdzie detektyw powoli buduje swoją sprawę, szukając wskazówek i zbieranie dowodów. Metodyczny, inteligentny i dokładny wygra dzień. Niechlujny, ignorancki i leniwy skaza sprawę. Ostatecznie dzieło stanie lub upadnie przed ławą przysięgłych.

Automat . Wkładasz wszystkie monety i pociągasz dźwignię. Czasami wygrywasz duże, czasem siedzisz tam godzinami i nic się nie dzieje. Czasami ktoś inny zwyczajnie przechodzi obok, raz pociąga dźwignię i wygrywa główną wygraną.

Muzyka . Jedna nuta jest dość prosta, ale miara jest bardziej złożona. Kompletna piosenka ma wiele taktów z wieloma nutami. Jeśli jedna nuta jest wyłączona, może to zepsuć cały występ. Jeśli każda nuta zostanie idealnie dostarczona, wykonanie zniknie w tle i istnieje tylko muzyka.

Najlepszą metaforą czegokolwiek jest sama. Wszystko inne straci pewną dokładność. Dlatego wybór najlepszej metafory zależy od tego, co konkretnie chcesz uchwycić na temat programowania. Ponieważ będzie tu wiele odpowiedzi na temat kodowania metafor, odpowiem klasyczną metaforą dla całego procesu rozwoju:

Budownictwo

Najczęstszym aspektem tej metafory jest to, że architekt fizyczny jest nieco analogiczny do architekta oprogramowania. Oto kilka innych podobieństw:

• Zmiany są tańsze i tańsze, im wcześniej je wprowadzisz. Oznacza to, że możesz przenieść teraz jedną linię na papierze lub 10 ton cementu później.
• Budynek bez odpowiedniego planu będzie miał tendencję do zawalenia się
• Konstruktorzy próbują zaimplementować to, czego chce klient. Jeśli klient nie opisuje dokładnie, jak ma wyglądać budynek (lub występuje inna awaria w komunikacji), jego zmiana będzie kosztowna.
• Istnieją pewne prawa fizyki, których nie można wygiąć. Tak jak nie można zbudować drugiej kondygnacji o szerokości trzystu stóp na 1. kondygnacji o szerokości 100 stóp, nie można zbudować funkcji X bez solidnego podsystemu Y.

Oczywiście, jak każda metafora, ma swoje ograniczenia. Niektóre wady z tym:

• Budynki są użytkowane jednorazowo; gdzieś go budujecie i tam zostaje. Nie można skopiować go milion razy dla miliona różnych użytkowników o milionie różnych potrzeb przy zerowym koszcie przyrostowym.
• Budynki są znacznie bardziej niezmienne niż oprogramowanie.
• Nie ma wyraźnej analogii do kosztów materiałów budowlanych. Linia kodu nic nie kosztuje - tylko czas potrzebny do jej wytworzenia kosztuje.
• Architektura przyrostowa, która jest (w zależności od tego, kogo zapytasz) możliwa z oprogramowaniem, nie jest możliwa w przypadku konstrukcji, w której raz ją projektujesz, a następnie budujesz.

Jak każda analogia, zależy to, co próbujesz wyjaśnić. Uważaj, aby nie polegać na jednej metaforze, w przeciwnym razie klient zacznie się zastanawiać, jakie będą podatki od nieruchomości w jego nowym systemie płac.

Uwielbiam analogię Chrisa McMahona do tworzenia oprogramowania, które przypomina tworzenie muzyki, szczególnie muzyki jazzowej.

To Ella Fitzgerald i hrabia Basie wykonujący piosenkę One O'Clock Jump. Piosenka to dwunastotaktowy blues, który jest jazzowym odpowiednikiem aplikacji bazodanowej z interfejsem użytkownika. Rozumiem przez to: tak jak każdy programista zbudował aplikację bazodanową z interfejsem użytkownika, każdy amerykański muzyk grał dwunastotaktowy blues. To ramy, na których zawieszonych jest wiele piosenek, od hrabiego Basie, przez Jimiego Hendrixa po Ramones.

Ten konkretny film jest doskonałym przykładem zwinnej praktyki. Posłuchaj, jak głos i fortepian wpływają na siebie. Jest to bardzo podobne do programowania par i przypomina TDD: głos coś robi; fortepian reaguje; fortepian coś robi; głos odpowiada. I zauważ kontakt wzrokowy. Ci ludzie są bardzo świadomi tego, co dzieje się natychmiast. Nie mają nuty (BDUF). Są zaangażowani w aktywność wymagającą intensywnej koncentracji i umiejętności, podobnie jak dobre tworzenie oprogramowania. Zdają sobie również sprawę z tego, że istnieje grono odbiorców, podobnie jak dobre oprogramowanie powinno być świadome potrzeb osób płacących rachunki.

Oto link do postu na blogu, w którym go omawia: http://chrismcmahonsblog.blogspot.com/2007/05/example-of-analogy-monks-vs-music.html

Czasami odnoszę się do programowania do kontrolowania bezmyślnych zombie . Podsumowując mój post na blogu na ten temat:

• Podobnie jak zombie, komputery, z którymi pracujemy, są bardzo głupie. Trudno im poinstruować, aby cokolwiek robili, chyba że instrukcje są szczegółowe
• Zombie jest agresywny i jeśli pominiemy drobne szczegóły w instrukcjach, pozostaw to stworzenie nieobsługiwane, może zniszczyć wszystko wokół siebie. To samo dotyczy komputerów: brak szczegółów w instrukcjach może spowodować awarię programu i zniszczenie danych.
• Musisz znać magię, jeśli chcesz kontrolować zombie. To samo dotyczy programowania.
• Im więcej ludzi z mózgiem gromadzi się w jednym miejscu, tym więcej komputerów może mieć. Wygląda na to, że mózgi przyciągają komputery - tak samo jak przyciągają zombie.

Programowanie jest jak budowanie rzeczy z Lego :

• Sklejasz wiele małych kawałków, aby tworzyć większe rzeczy
• Małe kawałki mają ograniczoną liczbę kształtów i rozmiarów
• Małe rzeczy mogą pasować do siebie tylko w określony sposób
• Zabawa z tym może być świetną zabawą

Programowanie komputera jest jak wychowywanie dziecka ...

• Wszyscy nie zgadzają się na właściwy sposób, aby to zrobić
• Utrzymuje cię w nocy
• Nigdy nie robi tego, co mówisz
• Bez względu na to, ile książek przeczytałeś na ten temat, kiedy to robisz, masz wrażenie, że nie masz pojęcia, co robisz
• Po pewnym czasie stajesz się leniwy
• Oczekujesz, że w przyszłości przyniesie to wielkie zyski, ale ostatecznie musisz go utrzymać do końca życia
• Nigdy nie jest tak czysty, sprytny ani bezpieczny, jak chciałeś
• Kiedy spojrzysz na to później, zastanawiasz się, do cholery, o czym myślałeś
• Mimo całego stresu, który cię spowodował, i tak to kochasz.

Główna różnica polega na tym, że denerwujemy się, gdy ktoś kradnie nasz kod źródłowy, ale często cieszymy się, że ktoś zabiera nasze dzieci z naszych rąk.

Programowanie przypomina budowanie fabryki lub linii montażowej.

Pomyśl o oprogramowaniu jako o maszynie lub linii montażowej, która istnieje wewnątrz komputera. Niektóre surowce i komponenty są podawane do maszyny i zgodnie z zestawem procedur przetwarzane są w produkt końcowy. Procedury są ustawione tak, aby wykonywać określoną operację na pewnym surowcu lub elemencie zgodnie z określonym zestawem parametrów (np. Czas, temperatura, odległość itp.) W określonej kolejności. Jeśli szczegóły operacji, która ma zostać wykonana, są nieprawidłowe lub czujniki maszyny nie są poprawnie skalibrowane, lub jeśli jakiś surowiec lub komponent nie spełniał oczekiwanych standardów jakości, mogłoby to zmienić wynik operacji i produkt nie wyszedłby zgodnie z oczekiwaniami.

Taka maszyna jest bardzo sztywna w działaniu i dopuszczalnych wejściach. Maszyny nie kwestionują inteligencji projektantów ani obecnego środowiska operacyjnego. Będzie nadal postępować zgodnie z procedurami, o ile jest to skierowane. Nawet jeśli zmiana surowców lub komponentów mogłaby mieć drastyczny wpływ na to, co wydarzyło się w późniejszych operacjach, maszyna nadal wykonywałaby swoje procedury. Proces ten musiałby zostać poddany przeglądowi, aby zobaczyć, jakie zmiany w procedurach były konieczne do skompensowania i uzyskania pożądanego rezultatu. Zmiana projektu lub konfiguracji produktu może również wymagać znacznej zmiany w wykonywanych operacjach lub ich kolejności. Chociaż osoby odpowiedzialne za produkcję szybko nauczyły się, jak ważne jest izolowanie operacji w jak największym stopniu, aby ograniczyć niepożądane efekty między nimi, przyjmuje się wiele założeń dotyczących stanu składników podczas przetwarzania; założenia, które mogą nie zostać wykryte, dopóki produkt końcowy nie znajdzie się w rękach użytkownika w innym środowisku operacyjnym.

Pomaganie szybkiemu idioci przejść klasę matematyki, która wymaga pisemnego eseju.

Programowanie komputerowe jest jak gra w szachy, w której wielkość planszy, ilość sztuk w grze oraz zasady rządzące tymi kawałkami rosną wraz z upływem czasu.

Pisanie oprogramowania jest jak ... Pisanie! ^^

Nowi uczniowie na zajęciach CS / Programowanie są praktycznie jak użytkownicy nieprogramujący. Przykład robota jest dobry.

W latach 80-tych używanie logo, Karela (lub podobnych środowisk programistycznych), w których użytkownik uczy się programowania, oglądanie komputera jak robota zamiast telewizora z maszyną do pisania bardzo mi pomogło. Te narzędzia są powszechnie używane w gimnazjum i liceum.

To praktyczne programowanie pomogło uczniom zdobyć umiejętności rozwiązywania problemów, nawet jeśli nie były one związane z komputerem !!!

Lub nawet jeśli studenci nie zostali programistami.

Niektóre szkoły wyższe i uniwersytety stosowały te narzędzia również na kursach pierwszego roku.

Zastanawiam się, dlaczego wiele szkół średnich porzuca nauczanie Logo i Karel ...

Lubię analogię Freda Brooksa z Mythical Man-Month, że programowanie jest jak wykonywanie magii.

Konstrukcja (The) programu, w przeciwieństwie do słów poety, jest prawdziwa w tym sensie, że porusza się i działa, wytwarzając widoczne efekty oddzielne od samego konstruktu. Drukuje wyniki, rysuje obrazy, wydaje dźwięki, porusza rękami. Magia mitu i legendy sprawdziła się w naszych czasach. Jeden wpisuje prawidłową inkantację na klawiaturze, a ekran ożywa, pokazując rzeczy, które nigdy nie były ani nie mogłyby być. ...

(Jeden) musi działać poprawnie. Pod tym względem komputer przypomina także magię mitów i legend. Jeśli jedna postać, jedna pauza inkantacji nie ma ściśle właściwej formy, magia nie działa. Ludzie nie są przyzwyczajeni do bycia doskonałymi i wymaga tego niewiele obszarów ludzkiej działalności. Myślę, że dostosowanie się do wymogu perfekcji jest najtrudniejszą częścią nauki programowania.

„[...] ale myślałem, że jesteś dobry w komputerach!”

Zwykle jest to próba nakłonienia maniaka do naprawy komputera (czujesz, że musisz udowodnić, że się mylą?). Moja standardowa odpowiedź:
jestem programistą. To tak, jak inżynier samochodowy - prawdopodobnie nie będzie wiedział, jak naprawić hamulce w Trabant '72, a na pewno nie zrobiłby tego, gdyby wiedział. Mechanik by to zrobił!

Lubię koncepcję przepisu na gotowanie.

Programowanie jest jak posiadanie ogromnej ilości mocy. Możesz zmusić komputer do robienia wszystkiego, co chcesz. Ogranicza Cię jedynie wyobraźnia i ilość czasu, jaki chcesz zainwestować.

Programiści są jak twórcy domu. Możemy opowiedzieć ci wszystko o domach, które zbudowaliśmy. Jeśli jednak zapytasz nas o losowy dom, który mijamy po drodze, prawdopodobnie nie dowiemy się wiele. Ale jeśli potrzebujesz czegoś dodanego lub zmienionego w tym domu, możemy to zrobić, pod warunkiem, że pozwoli nam na to właściciel.

W jednym ze starych artykułów Chrisa Crawforda na temat programowania porównał złożony program do biurokracji, z wieloma agencjami, które komunikują się, przesyłając notatki tam iz powrotem. Odkryłem, że jest to bardzo przydatna metafora podczas wyjaśniania rozwoju oprogramowania.

Zasadniczo programowanie utożsamiam z układanką.

Do stworzenia nowego projektu - masz mnóstwo elementów, z których kilka nie należy do tego obrazu, i nie masz podglądu, jak wygląda układanka po jej ukończeniu. Ale znasz rozmiar i ogólne kolory, więc szacunki są możliwe, ale niekoniecznie dokładne.

Aby zmodyfikować już istniejący projekt - pojawił się kot i zrzucił kawałek gotowej układanki. Zajmie to trochę czasu, ale framework już istnieje, więc nie powinno być tak źle (w zależności od tego, ile trzeba zmienić).

Pomaga także w opisie postępu. Jeden z moich ostatnich projektów, w pewnym momencie zastanawiałem się, jak to opisać, aby osoba nietechniczna zrozumiała, dlaczego nie wiem, jak długo, i wymyśliłam: Pomyśl o układance, w której wszystkie elementy brzegowe są gotowe, podobnie jak nieco ponad połowa, jeśli elementy wewnętrzne. Te, które pozostały, są od siebie oddzielone, teraz muszę tylko wypełnić luki.

To smutne, ale programowanie jest pracą, którą można zrozumieć tylko poprzez naukę, jak to zrobić.

Programowanie ma kilka różnych poziomów postrzegania i różni się z różnych stron.

Na niskim poziomie jest to „napisanie bardzo szczegółowych instrukcji dla bardzo, bardzo głupiej maszyny”

Na kolejnym poziomie zajmuje się złożonością. Budowanie nowej metafory w celu uproszczenia pracy. Jak wyższa matematyka.

Z innej strony wykorzystanie technologii pomocniczych, takich jak kontrola wersji, samodokumentujący się kod, budowanie i testowanie projektów.

Z drugiej strony jego budujący interfejs „użytkownika” (nie dosłownie, mam na myśli API również interfejs użytkownika), przewiduje możliwe błędy (popełniane przez użytkownika, dane, a nawet siebie) i poprawia reakcję na błędy.

I w końcu.

Metaforą programowania jest literatura. Najpierw musisz nauczyć się alfabetu. Ale pisanie powieści na ten temat nawet się nie zaczyna.