Jak wytłumaczyć osobie nietechnicznej/początkującej pojęcia typu framework, backend, frontend itp?

0

Jak w temacie. Przy wielu okazjach, czy to wprowadzając znajomych do programowania czy tłumacząc rodzinie co właściwie robię w pracy jak już zabiorę się za coś produktywnego ;) miewam trudności ze sklejeniem przyjaznej dla nietechnicznej osoby definicji czym właściwie są:

  • Framework
  • Backend/frontend
  • DevOps
  • Logika biznesowa/domena
  • API
  • Testy automatyczne
  • CI/CD
  • Debugger
  • System kontroli wersji
  • Architekt oprogramowania
9

screenshot-20190913132446.png

13

Siedzi taki, klika w komputer cały dzień a potem woła sobie 20k

3

A po co chcesz im to tłumaczyć?

5

Powiedz im prawdę, że jesteś operatorem wyszukiwarki. title

4

Lubię tłumaczyć przez analogię do produkcji samochodów. Jako back-endowiec jestem w takim opisie odpowiedzialny, za to, czego nie widać, a co jest niezbędne do działania - silnik, hamulce i tym podobne. Fronci zajmują się karoserią, oprzyrządowaniem od kierownicy do radia czy chociażby dobierają kolor tapicerki. Testerzy robią kółka po torach i patrzą czy pojazd się nie rozlatuje po drodze. Architekt to główny inżynier odpowiedzialny za cały projekt. Logika biznesowa to przeznaczenie pojazdu - rodzinny samochód, ciężarówka transportowa, ambulans, pojazd wojskowy? Część pojęć raczej kiepsko się tak przekłada, ale z reguły laicy nie są aż tak zainteresowani.

0

Nie jestem przekonany, czy tłumaczenie pewnych pojęć jest sensowne. Przykładowo: być może pojęcie "debuggera" ma sens w programowaniu, ale czy w życiu? Dla mnie jest to, ot, program, który ma pewne ustalone relacje z innymi programami. Analogie @Shalom oraz @cerrato (z komentarzy post wyżej) nie odpowiadają mi, bo mieszają koncepcje "człowieka" oraz "programu". Sam nie widzę na razie jakiejkolwiek – co oczywiście nie znaczy, że nie ma.

6

Osobiście wyłożyłam się kiedyś na próbie wytłumaczenie kompletnie nietechnicznej matce, co to jest system operacyjny. Oczywiście chciała, żeby jej to wytłumaczyć "jakoś posto", ale wcześniej musiałabym wytłumaczyć słowa, które chciałam użyć w samej definicji.

Zastanawiając się nad tym później, doszłam do wniosku, że dla zupełnego laika mogłaby się sprawdzać analogia firmy/urzędu:

  • system operacyjny to dyrektor, który decyduje o przydziale zasobów,
  • programy i sterowniki to pracownicy,
  • interfejs / frondend to dział obsługi klienta,
  • backend to wewnętrzne działy niewidoczne dla klienta.
1

Ja nie tłumaczę. Zwłaszcza, że czasami sam nie rozumiem co właściwie robię.

3

Często lepiej powiedzieć "nie wiem", niż brnąć w tłumaczenie osobie nietechnicznej. Obrażą się tak czy inaczej, tyle że zbywając ich nie zmarnujemy czasu. Różne pojęcia tego typu są zbyt abstrakcyjne dla innych i nie ważne jak się wytężymy, bez wytłumaczenia podstaw się nie obędzie. Porównanie z samochodem czy czymś innym może mieć skutki odwrotne do zamierzonych: potem taki użytkownik komputera próbuje przełożyć swoje przyzwyczajenia w nieprawidłowy sposób. Na przykład liczb zespolonych nie można wytłumaczyć tak jak dzieciom z jabłkami, bo <sarkazm>jeszcze sobie te jabłka uroją</sarkazm>.
Niestety, ale tłumaczący musiałby się zniżyć do poziomu "przedszkolaka", żeby poprowadzić czyiś tok myślenia. Pamiętacie jak uczyliście się pisać albo jeździć na rowerze? Teraz przecież to takie proste. Nie powiecie dziecku: masz jedź. To musi wyryć się w podświadomości i bez ćwiczeń się nie obejdzie. Tak samo pojęcia debuger czy system operacyjny można mieć na tyle głęboko w podświadomości, że bez podstaw ani rusz.

6

Framework

Tak jak @cerrato napisał - pewnie można by to określić "zestawem narzędzi", ja bym jeszcze dodał, że te narzędzia mają służyć przyśpieszeniu pracy. Frameworki pomagają nie robić wszystkiego od nowa, tylko pozwalają na szybki start, bo wiele rzeczy już jest zrobionych, bo twórcy frameworku zebrali rzeczy, których się zawsze używa i dzięki temu można z nich korzystać jak się zaczyna nowy projekt.

Backend/frontend

backend - program działający na serwerze(serwer to jest taki komputer gdzieś w internecie. Może być w USA nawet czy w kosmosie)
frontend - program działający u użytkownika (tam gdzie użytkownik to odpali - na laptopie, na komórce itp.)
frontend i backend ponadto się ze sobą muszą komunikować - np. odpalasz mapę Google i kod frontendowy ci wyświetla ją na urządzeniu, ale to kod na serwerze ci musi dostarczyć dane do mapy (bo tych danych jest mega dużo, więc serwer się łączy z bazą danych i daje tylko np. mapę twojego miasta, a nie całego świata).

Logika biznesowa/domena

Co do domeny to myślę, że "dziedzina" myślę, że byłoby łatwiejsze do zrozumienia. Więc jak robisz internetową księgarnię, to pojęciami dziedzinowymi może być książka, czytelnik, cena, podatek VAT itp. czyli jakby branża, w której to robisz. No i pisząc program możesz też uwzględnić to, że są ksiażki, cena itp. i zakodować to odpowiednio w kodzie.

A co logiki biznesowej, to myślę, że i osoby techniczne mają z tym problem. Sam nie wiem, co to ma znaczyć, jak ktoś powie o "logice biznesowej" (szczególnie, że to się taki buzzword zrobił, że każdy używa tego słowa jak chce. Na zasadzie - logika - bo coś się dzieje w aplikacji, więc logika. A biznesowa, bo robimy komercyjną apkę, więc się dzieje biznes).

API

Ja bym powiedział, że różne części programu/systemu informatycznego muszą się ze sobą "dogadać", i żeby mogłby się dogadać, to trzeba ustalić wspólny język, sposób komunikowania się (tak jak ludzie z róznych krajów muszą znaleźć wspólny język) i API jest takim sposobem na to, żeby to zrobić (tak jak angielski, a kiedyś łacina, mogą być sposobem na to, żeby osoby z różnych krajów mogli się porozumieć.).

Testy automatyczne

Każdą aplikację trzeba przetestować, czy działa wszystko poprawnie, czy nie ma błędów. Można to zrobić klikając - czyli tester otwiera program i klika różne rzeczy i sprawdza, czy nie ma błędów. Jednak przy dużych aplikacjach jest to męczące, bo za dużo klikania się robi - więc programiści wpadli na pomysł, żeby napisać proste skrypty(małe programiki), które będą same sprawdzać błędy.

Debugger

Narzędzie, które pozwala na podgląd stanu programu w trakcie jego działania - i tym samym na skuteczną diagnozę/znajdywanie/reperowanie błędów.

System kontroli wersji

Takie coś, co pozwala ci zapisać każdą zmianę w programie, a potem ta zmiana jest w historii (tak jak w przeglądarce internetowej masz historię odwiedzonych stron). Potem możesz przeglądać te zmiany, cofać itp. Ponadto system kontroli wersji ułatwia pracę w zespole, bo gdyby ludzie pracowali na jednym katalogu i zmieniali żywcem pliki, to mogłoby się okazać, że ktoś zmieni plik, na którym właśnie pracujesz i skasuje ci cała pracę. System kontroli wersji natomiast pozwala pracować w ten sposób, że każdy pracuje na własnej kopii zapasowej plików, i zmienia u siebie tylko kopie plików (a nie oryginalny plik), natomiast każda zmiana jest zapisywana i leci potem na serwer. I system kontroli wersji na serwerze jest tak sprytny, że automatycznie potrafi łączyć różne zmiany ze sobą tak, żeby żaden plik się nie popsuł.

(ale trochę uproszczone, bo 1. taki Git nie potrzebuje wcale żadnego serwera, nawet jeśli i tak ludzie używają, to kwestia tego jak się pracuje w zespołach, a nie Gita 2. czasem jednak występują konflikty, więc pliki mogą się psuć. No ale i tak nie ma co wnikać w szczegóły, bo ktoś nietechniczny być może nawet słowa serwer nie zrozumie, a co dopiero niuansów)

Architekt oprogramowania

Ktoś, kto ma na tyle dużo doświadczenia w programowaniu, że już przestał programować i się tylko mądrzy na temat tego, w jaki sposób programowanie ma wyglądać xD

0

Weź wytłumacz na przykładzie mechanika samochodowego albo urzędu działanie internetu i modelu OSI albo jak działa "3D game engine" i do czego porównasz wektory w przestrzeni... już nie mówiąc o obliczeniach xD @cerrato wstawił dobry obrazek, jak czegoś nie potrafisz wytłumaczyć to tego rozumiesz. I coś tam było jeszcze żeby tłumaczyć prosto ale nie prosciej niż to jest możliwe.

4

A z drugiej mańki, to kiedyś się zastanawiałam, jak wytłumaczyć komuś, dlaczego nie umiem czegoś wytłumaczyć:

Mamo.

Wyobraź sobie buszmena, który nigdy w życiu nie widział lodu, zbiornika wodnego ani silnika. I teraz spróbuj mu w prosty sposób wytłumaczyć, czym jest lodołamacz z napędem atomowym.

Ew. wytłumacz czym jest alfabetyczny skorowidz książek w bibliotece temuż buszmenowi, który nigdy w życiu nie zetknął się z konceptem pisma.

2

Ja już dawno temu przestałem rozmawiać z ludźmi o tym co robię...

3

O!
W końcu prawdziwa dyskusja programistów - normalnie jak na sesji z klientem przy omawianiu ficzerów, gdzie klienta uj obchodzi jak, a programistę uj obchodzi biznes klienta (czyli po co) :P

A tak na szybko wertując posty, to taaak... nie nadajecie się panowie na pierwszy front, do tłumaczenia znaczy.
Ale spokojnie, dorośniecie do tego, ale bądźmy szczerzy - na pewno nie wszyscy ;-)

Za dużo kombinujecie. Za dużo w tym wszystkim żargonu(naprawdę uważacie, że kogoś spoza branży to obchodzi?) i zależności.
My wiemy, że to skomplikowane, ale oni - oni mają to w nosie i jak zaczynacie w ten sposób, to słyszą tylko szum...
Oni chcą co najwyżej trochę więcej wiedzieć.
A ty jakieś bakłenyd, frejmłorki i inne api.
I jeszcze kwiatuszek na koniec to Logika biznesowa/domena - maaatko... przecież tego nie rozumie co najmniej z 50% koderów.

Mi się podobało to, co powiedział kiedyś Andrzej Dragan (jego domena - fizyka kwantowa) podczas wywiadu.
Szło to jakoś tak; każdą nową teorie tłumaczy swojej babci na jabłkach (weź 2 jabłka tu, przesuń tam, itd. - zero żargonu!).
Jeśli ona tego nie jest w stanie pojąć, to znaczy że teoria jest słaba i trzeba ją zmienić.

Zresztą, jest sporo jego wystąpień na YT - można sobie wyrobić zdanie w temacie "jak tłumaczyć".

1

ostatnio opowiadałam siostrze czym sie zajmuje, i napomknąłam o uczeniu sie algorytmów. Dopytywała sie, więc powiedziałam, że algorytmy to np sortowanie liczb, czyli ułożenie ich w kolejności rosnącej i jest co najmniej kilkanaście algorytmów sortowania. Powiedziała coś w stylu "to trzeba być spostrzegawczym, tak" jakby myślała, że to sie manualnie wybiera te wszystkie liczby. Jakbym miała jej tłumaczyć jak działa merge-sort, to pewnie powiedziałabym o metodzie splatania coś w stylu: "utrzymuje sie wskaźniki do elementów obu tablic, dodaje sie element mniejszy do trzeciej tablicy i powiększa się dany wskaźnik. Operacje sie powtarza do momentu, gdy jeden ze wskaźników jest równy sumie elementów tablicy.". Problem z tym opisem jest taki, że nie zrozumie go nikt go wcześniej nie programował, nie wie, że jest coś takiego jak zmienna i można ją inicjalizować, nie wie co to tablica i że można sie do jej elementów odnosić za pomocą liczb. Trzeba byłoby więc zacząć tłumaczenie od podstaw programowania a czas mija... A jeszcze rekurencja czeka do wytłumaczenia... Ciężko byłoby mi tłumaczyć algorytmy w inny sposób niż za pomocą pseudokodu, bo tak sie tego uczyłam.

3

Wizualizacja algorytmów sortowania:

2
lambdadziara napisał(a):

ostatnio opowiadałam siostrze czym sie zajmuje, i napomknąłam o uczeniu sie algorytmów. Dopytywała sie, więc powiedziałam, że algorytmy to np sortowanie liczb, czyli ułożenie ich w kolejności rosnącej i jest co najmniej kilkanaście algorytmów sortowania. Powiedziała coś w stylu "to trzeba być spostrzegawczym, tak" jakby myślała, że to sie manualnie wybiera te wszystkie liczby.

Przeanalizuj co zaszło: Ktoś pyta Cię o pewną abstrakcję, jaką jest idea algorytmu, a Ty dajesz konkretny przykład. A przecież na podstawie jednego przykładu nie da się mentalnie wydzielić abstrakcji, bo nie wiadomo gdzie przebiega granica między abstrakcją a konkretem.Tłumacząc czym jest jakaś abstrakcja, trzeba dać albo wiele przykładów, albo dać przykład innej abstrakcji. Algorytm nie jest wcale technicznym pojęciem, jest pojęciem za zakresu matematyki czy nawet logiki, i to dość starym. Wg mnie najlepiej pasuje do niego analogia do przepisu albo do instrukcji dodanej do przedmiotów do samodzielnego złożenia. Czym jest sortowanie, wie chyba każdy, bo każdy chyba układał coś kiedyś wedle wielkości. Jeśli chodzi o rodzaje sortowania, to osobie nietechnicznej wystarczy dać coś samemu do posortowania, a potem poprosić o opisanie co robiła i dlaczego w taki a nie inny sposób. Podejrzewam, że w dość naturalny sposób użyje nie najgorszej metody. Potem pokazać jakieś mało efektywne sortowanie i podkreślić, że są różne metody robienia tego samego. Można też zwrócić uwagę, że łatwiej posortować karty np. na stole, gdzie można je rozkładać na całej powierzchni, niż w ręku - to pokaże różnicę między sortowaniem "in place" i "out of place" i kompromisem między szybkością a potrzebą pamięci, gdyby pojawiło się pytanie, o to która metoda jest najlepsza.

3

Algorytmy wygodnie się tłumaczy jako przepisy kucharskie. Masz wejście (składniki) wyjście (placek, pieczeń czy jakiekolwiek inne danie) i algorytm (przepis). To, że przepis musi być precyzyjny można przekazać mówiąc, że gotować ma nie człowiek a robot - musi mieć dokładnie precyzyjne instrukcje, że ma wałkować ciasto 10 minut, a nie 9 i pół, ponieważ nie ma własnej inteligencji i nie jest w stanie sam ocenić, że "już może być", potrafi jedynie bezmyślnie wykonywać polecenia.

0

Ja miałem na rozmowie wytłumaczyć HRce kilka rzeczy technicznych. Np. co uważam za zaletę, a co wadę Reacta. Kiedy uważam, że SPA jest potrzebne, a kiedy nie. I te pytania myślę, że jeszcze w miarę gładko wyjaśniłem. Chociaż też nie wiem, czy zrozumiała wszystko. Natomiast przy pytaniu o to, żebym wytłumaczył callback hell, po prostu odleciałem i sam siebie nie rozumiałem potem (bo starałem się nie wnikać w szczegóły techniczne, a jednocześnie nie potrafiłem tego wyjaśnić high levelowo, czym są promisy). Więc - tłumaczenie takich rzeczy bywa trudne.

Swoją drogą nie wiem, czemu mają służyć takie pytania, jeśli rozmawiamy z osobą nietechniczną. Może to być albo bezcelowe albo mające głęboki sens. Bezcelowe by było, jeśli faktycznie miałoby to sprawdzać kompetencje techniczne kandydata. Jednak kto wie, może to pytanie miało badać raczej skille miękkie - czy kandydat potrafi coś wyjaśnić prostym językiem (żeby sprawdzić, jak będzie sobie radził z rozmową np. z nietechnicznym klientem?).

Anyway, podejmując się jeszcze raz tego pytania - jak wytłumaczyć callback hell?

Jakbym znowu miał to komuś wytłumaczyć, to chyba nie wnikałbym w szczegóły techniczne, tylko odwołał się do kwestii wizualnych. Pokazałbym po prostu, jak wygląda callback hell (zagnieżdżone długie linijki), a jak wygląda kod na promisach czy async/await - że jest ładniejszy. Jeśli nie miałbym możliwości pokazania (rozmowa przez telefon) to chyba bym to opisał słowami - że jak jest callback hell, to są długie wcięcia i ciężko się to czyta, więc więcej czasu trzeba poświęcić jeśli ma się do czynienia z kodem, w którym jest callback hell (bo z perspektywy nietechnicznej chyba to jest ważne - callback hell =  programista musi poświęcić więcej czasu na czytanie i modyfikację kodu).

Bo czy warto wchodzić szczegóły typu asynchroniczność, w kwestie wywołania funkcji, zwracania wyniku funkcji, koncepcji promisów, then...? (a takie rzeczy mówiłem wtedy) No nie jestem przekonany.

1

@LukeJL: może gdybyś użył ładnych polskich zwrotów to byłoby łatwiej? Np. Piekło wywołań zwrotnych, wysokopoziomowych, w każdym razie.

2
LukeJL napisał(a):

Anyway, podejmując się jeszcze raz tego pytania - jak wytłumaczyć callback hell?


(...) Po długiej męce znalazł nareszcie kogut igłę i uradował się, jak gdyby go z rożna zdjęto. Panna dała kawałeczek sera, zaniósł ser kosiarzom, dali mu siana. Siano zaniósł krowie, dała mu mleka. Mleko zaniósł lipie, lipa dała łyka. Łyko złożył u dębu, dąb strząsnął kilka żołędzi. Z żołędziami poszedł do wieprza po kieł. Leciał jak mógł nóżkami i skrzydłami, lecz już słońce zniżało się ku zachodowi. Wieprz kła pożyczył, przyszedł do morza, morze dało wody i kogut, trzepiocząc się i podskakując z niespokojności, pobiegł do leszczyny.

Przyszedł z wodą — ale kurka już nie żyła.

1 użytkowników online, w tym zalogowanych: 0, gości: 1