ugrás a tartalomhoz

full stack webfejlesztő - mihez kell értenie?

mind1 valami név · Nov. 15. (Cs), 10.33
Csak úgy elgondolkodtam... ha valakinek olyan hülye ötlete jön, hogy egyszemélyes webfejlesztő akar lenni, annak milyen ismeretekkel kell rendelkeznie?
Szerver oldali programozás, adatbázisok, HTML, javascript, mindezek mellé keretrendszerek ismerete...
Jól látom, hogy ez nem kezdőknek való? :)

ui: nem, nem akarok belevágni ilyesmibe, csak játszadozás közben kezd kuszává válni a dolog, mert felszínes ismeretekkel elég macerásnak tűnik.
 
1

Off: Mindenhez IS.

Arnold Layne · Nov. 15. (Cs), 16.38
Mindenhez IS. És ez még csak a js. :)
3

Wow... ez szinte szóról-szóra

mind1 valami név · Nov. 15. (Cs), 17.40
Wow... ez szinte szóról-szóra az, amit már évek óta érzek, látok, tapasztalok, ami miatt már évekkel ezelőtt feladtam, hogy valaha is újra kezdjem a munkát... (és most nem tudom, hogy :D vagy :( illik ide inkább...)
7

Igazából nem annyira nehéz

inf3rno · Nov. 15. (Cs), 23.09
Igazából nem annyira nehéz megtanulni, meg mindegyik felsorolt könyvtár megold valamilyen problémát. Jó esetben a későbbiek több problémát megoldanak, mint az előbbiek, de szerintem egy Webpack vagy egy SystemJS nem sokkal tud többet, mint egy Browserify, szóval szinte mindegy, hogy melyiket választod. Kelleni kellenek, mert pl ennél a konkrét esetnél ahelyett, hogy egy baromi nagy js fájlt írnál, szét tudod darabolni több kisebb modulra, akár osztályonként, akár más elv alapján, ami éppen neked tetszik. Szóval ha csinálsz egy konkrét projektet, akkor érdemes megnézni, hogy melyik felsorolt könyvtár milyen problémát old meg, és az alapján eldönteni, hogy szükséged van e éppen rá, vagy nincs. Én személy szerint jól elvagyok Browserify-al és Bash scriptekkel az esetek döntő többségében. Ha nem single page application-t ír az ember, akkor még mindig el lehet lenni jquery-vel vagy vanilla JS-el, ha igen, akkor kellhet valami a data binding-ra, pl a React most így ránézésre nem tűnik rossznak.

Nézem közben tovább a React-et. Ez a Flux és Redux nem rossz, gondolkodom már ebben a témában egy ideje, de nem tetszik, hogy a Flux teljesen kigyomlálta az aszinkron ciklusokat és hasonlókat. Egyelőre még nem érett meg a gondolat, hogy hogyan lehetne ezt jobban csinálni, úgyhogy valszeg használnám ezeket is a React-el együtt.
5

Valahogy így. :-) Én már egy

inf3rno · Nov. 15. (Cs), 22.14
Valahogy így. :-) Én már egy ideje leszálltam a hype vonatról. Nem szívesen tanulok 1-2 évente új keretrendszert úgy, hogy alig adnak valami extrát az előzőhöz képest.
2

BE + FE

Pepita · Nov. 15. (Cs), 17.12
Ennyi elég, nem kell több. :)

Szerver oldali programozás, adatbázisok, HTML, javascript, mindezek mellé keretrendszerek ismerete...
Kimaradt a CSS, és igazad van: egy full stack nem junior. De vajon létezik valóban full stack fejlesztő?...
Én azt gondolom, hogy manapság sokkal többen kategorizálják magukat így, mint kellene. Egyetértek azzal, hogy ha valaki full stack, akkor egyszemélyes webfejlesztő tud lenni, vagyis egymaga végigvisz egy projektet.
És itt jön be a képbe a "csúnyaság": én még nem találkoztam olyan, magát full stack-ként kategorizáló fejlesztővel, akire nyugodt szívvel rá mernék bízni (egyedül) egy komolyabb projektet. Inkább az a tapasztalatom, hogy manapság az a full stack, aki hajlandó frontendhez és backendhez is nyúlni. De nem jelenti azt, hogy vérprofi akár csak az egyikben... :/

Egyszemélyes webfejlesztő meg van sok Vér Pistike, aki összekattintgat "bármit" wordpress-ben vagy más, hasonlóan profi "keretrendszerrel".
4

A CSS-t én mindig a html

mind1 valami név · Nov. 15. (Cs), 17.42
A CSS-t én mindig a html részének tartottam. :)
Viszont kimaradt, hogy nem árt érteni az üzemeltetési dolgok egy részéhez is. :D
6

Hát én egyre inkább backend

inf3rno · Nov. 15. (Cs), 22.22
Hát én egyre inkább backend vagyok, és nem szívesen foglalkozok frontend kérdésekkel. Admin oldalakat össze tudok ütni, de design, sitebuild, js ui terén nincs kapacitásom követni, hogy mi a trend. Mármint tudom nagyjából, hogy milyen keretrendszerek, library-k a menők egy-egy témában, de nincs kapacitásom évente újat tanulni, mert azt most éppen a facebook fejlesztői csinálták, és ezért most az a divat, tudni meg szinte ugyanazt tudja, mint az előzőek... Majd ha egy kicsit több időm lesz, akkor belenézek ebbe az Angular, React, stb. témába 1-2 hétig, aztán levonom a konklúziót. Szerintem nagyon kevés olyan ember lehet, aki tényleg full stack. Bár végülis megoldható, ha valakinek sok ideje van, és nincsenek hobbi projektjei, de ha valaki egyedül akar egy teljes oldalt lehozni, akkor még a design-ba, SEO-ba, üzemeltetésbe, stb.-be is bele kell kóstolnia, ami már tényleg igazán ritkaság...
8

Egyszerű

Hidvégi Gábor · Nov. 16. (P), 11.23
A webfejlesztés egy végtelenül primitív munka, és ha az alapokat ismered, bármit el tudsz készíteni a segítségükkel: HTML 4.0, CSS 2.1, Javascript 1.3. A szerveren az egyik legjobb nyelv a PHP, ha ismered ebből a 4.0 lehetőségeit, akkor nem lesz előtted akadály, amit ne tudnál legyőzni. Adatbázisnak megteszi bármelyik MySQL vagy PostgreSQL.

Ami megnehezíti az életet, az a fentiek újabb verzióiban behozott újdonságok, amelyek segítségével ugyanazt a feladatot többféleképp tudod elvégezni. Természetesen ezeket nyugodtan lehet használni, de számíts arra, hogy a featúrák számának a növelésével a hibázási lehetőségek négyzetesen nőnek a kombinációk miatt.

Ha ezt nem hiszed, kérdezd meg nyugodtan Pepitát, mekkora trágyadombot gyártottak a /censored/-nél, például hányfajta kliensoldali megjelenési technikával nehezítették meg a saját maguk életét. Gondolj bele, mennyi erőforrás elmegy a karbantartásra és az egységesítésre, valamint a különböző dolgok megtanulására.

A weboldalak és -szolgáltatások 99%-át a fentiekben leírt minimális követelményrendszer kielégíti, látszódjék az bármilyen összetettnek vagy csillogónak.
9

Elhinni elhiszem, csak ha nem

mind1 valami név · Nov. 16. (P), 12.59
Elhinni elhiszem, csak ha nem elégszem meg azzal, hogy működik, hanem "eladható" eredményt szeretnék, ahhoz valami embertelen mennyiségű ismeretre van szükség, amit elképzelni sem tudom, hogy lehet képes valaki megtanulni.

O.K., én egyébként is nehezen tanulok, de huszonegynehány éves pályám alatt talán négy embert ismertem, akiből kinézem, hogy képes lenne ilyesmire.
10

ha nem elégszem meg azzal,

Hidvégi Gábor · Nov. 16. (P), 14.01
ha nem elégszem meg azzal, hogy működik, hanem "eladható" eredményt szeretnék, ahhoz valami embertelen mennyiségű ismeretre van szükség
Ez valami megérzés, vagy alá is tudod támasztani érvekkel?
11

Egyemberes projektről

mind1 valami név · Nov. 16. (P), 14.29
Egyemberes projektről beszélek, ahol egy személyben vagy szervező (ha van még ilyen), programtervező, programozó, DBA, GUI designer, kliens fejlesztő, SEO szakértő...
És akkor még nem volt szó róla, hogy amilyen rendszereket láttam, ott a leendő felhasználók szakmájához sem ártott, ha ért valamit a fejlesztő, mert ennek hiányában elég komoly félreértések adódhatnak...

Persze, neki lehet menni úgy is, ahogy írtad, de... hát elég sok példa van rá, még céges, sok fejlesztős megvalósításban is. ;)
12

Mérce

Hidvégi Gábor · Nov. 16. (P), 16.22
Miért teszed ilyen magasra a mércét? Hogy biztosan ne sikerüljön valami? Mert akkor a siránkozásra nem kíváncsi senki.

Ha egyedül szeretnél pénzt keresni, akkor tényleg a Wordpress az egyik legjobb megoldás a problémára, szerintem még dizájnt is találhatsz ingyen.

Egyedül nagyon korlátozott minden erőforrás, így nagy projektet nem érdemes elvállalni, inkább csak kicsiket és hasonlókat, amit futószalagon tudsz gyártani. Így nem kell csillagrombolót tervezni, bonyolult adatbázisokat tervezni stb.
13

Direkt írtam, hogy ez rég nem

mind1 valami név · Nov. 16. (P), 17.18
Direkt írtam, hogy ez rég nem rólam szól, csak az egyszerűség kedvéért írok egyes szm első személyben.
Csak csodálom azokat, akik minderre egymaguk is képesek, magas színvonalon.
14

Egyszerű

Hidvégi Gábor · Nov. 16. (P), 19.12
Leírtam feljebb, a web egy piszkosul egyszerű platform, ha megtanulod és megérted az alapjait. Mivel 1991 óta minőségi változás nem volt, csak mennyiségi, és a programozás sem változott meg, egy akkori tudással ma is elkészíthetsz bármit erőfeszítés nélkül.

Ez a szakma nulla mondjuk egy orvoséhoz képest, ráadásul felelőssége sincs a művelőinek.
15

Akkor miért nem gyógyítasz? :-D

Pepita · Nov. 19. (H), 10.32
Ez a szakma nulla mondjuk egy orvoséhoz képest
Komolyan kérdezem, ha ez a szakma ennyire nem több a kukásautóra való pakolásnál, akkor Te miért nem az orvosin végeztél?

ráadásul felelőssége sincs a művelőinek
Amin jelenleg dolgozom, azt százezres nagyságrendű user fogja használni, és közvetlenül fogja befolyásolni a munkájukat. Tényleg semmi felelősségem nincs; legfeljebb pár napnyi túlórát okozhat egy - egy bug nekik, szorozd meg a nagyságrenddel és egy általad tippelt óradíjjal, és fizesd ki a hibám...
Lehet, hogy van sok felelőtlen művelője ennek a szakmának (Vér Pistikék), de ez távolról sem jelenti azt, hogy nincs felelőssége egy fejlesztőnek.
17

Ne vedd ennyire magadra (a

mind1 valami név · Nov. 19. (H), 10.46
Ne vedd ennyire magadra (a másik témában azt hiszem, igazad van) - azért egy orvosnak (ha még létezne) sokkal nagyobb a közvetlen felelőssége, mint szoftver terén bárkinek -> lásd MS felhasználási feltételek... :(
Más lapra tartozik, hogy manapság több IT-st ismerek, akiben meg tudok bízni, mint orvost, pedig orvosból (orvosként dolgozóból) sajnos már többet ismerek :(
19

Felelősség

Hidvégi Gábor · Nov. 19. (H), 11.13
Backend: egy kontrollált környezetben dolgozol, ahol van egy-két szoftverkomponens.

Frontend: van körülbelül három böngészőmotor, amiket ismerned kell.

Orvoslás: minden ember más, ráadásul egy csomó szervünk vagy a lelkünk működését nem ismerjük pontosan, sem azt, hogy ezek hogyan hatnak egymásra. De ha valami elromlik, azonnal meg kell gyógyítani, és ha egy orvos hibázik, akár hosszú évekre is lecsukhatják, eltilthatják a szakmájától.

Ezzel szemben a fejlesztőt legfeljebb kirúgják, de pár napon belül új helyen dolgozhat minden probléma nélkül.

Te fizettél már az általad okozott hibákért?
24

a fejlesztőt legfeljebb kirúgják, de pár napon belül új helyen d

Pepita · Nov. 19. (H), 12.22
a fejlesztőt legfeljebb kirúgják, de pár napon belül új helyen dolgozhat minden probléma nélkül
Hát, ha neked ilyen a hozzáállásod a kiadott munkádról....
26

Érv

Hidvégi Gábor · Nov. 19. (H), 13.10
Nekem elég, ha bemásolod a szerződésednek azt a részét, amiben a te anyagi és/vagy büntetőjogi felelősségedről van szó az elkövetett hibák függvényében.

Az egészen más dolog, hogy milyen hozzáállással dolgozol.
39

Persze, máris :)

Pepita · Nov. 20. (K), 12.44
Nekem elég, ha bemásolod a szerződésednek azt a részét
Biztosan nem fogok ilyet tenni, sőt, az előzményeket tekintve szóban sem teszem meg.
Egyébként a Mtk is előír alapvető felelősséget a munkádért (munkavállalóként), büntetőjogi felelősséged pedig külön szerződésbeli említés nélkül is van.

Az egészen más dolog, hogy milyen hozzáállással dolgozol.
Az én hozzáállásommal szerintem semmi baj (legalábbis akiket érint, eddig elégedettek vele), mondjuk nem is én mondtam, hogy "legfeljebb kirúgnak". :)
16

Olyat soha ne adj a számba, amit nem mondtam!

Pepita · Nov. 19. (H), 10.45
mekkora trágyadombot gyártottak a XXX-nél
Ezt szerintem sürgősen töröld, mert egyrészt ilyet soha nem mondtam még szóban sem, másrészt az említett cég akár perelhet is érte.
Egyébként a régióban legtöbb cég által használt ügyfélkezelő rendszer valószínűleg nem lenne az élvonalban sem, ha "trágyadomb" lenne, ehhez képest Magyar Brand díjat is kapott...

Gábor, nyomatékosan megkérlek, hogy ne vetíts rám / rólam olyan képet, amit nem mondtam, nem írtam, és legfőképpen egész másként gondolok.

Másrészt a webfejlesztés nem éppen "primitív munka", viszont ha valaki például PHP - ból 2018 - ban a 4.0 szintjén áll, akkor számára még primitívnek mondható backend feladatot sem ad önálló elvégzésre egy értelmes vezető fejlesztő vagy manager...
18

Tévedsz

Hidvégi Gábor · Nov. 19. (H), 11.07
Az, hogy a volt céged milyen minőségű terméket állít elő, azt én állítom, persze az alapján, amit te elmeséltél.

Lehet itt mindenféle díjakat osztogatni, de az tulajdonképpen mit jelent? (Webes) szakmai szempontból díjazták? Az általad küldött lejárt tanúsítvánnyal rendelkező oldalon egy tárhelyszolgáltató marketingszövege jelenik meg. Mennyire egészséges az a szoftver, ahol egy felugró ablak megnyílásának az ideje másodpercekben mérhető?

ha valaki például PHP - ból 2018 - ban a 4.0 szintjén áll, akkor számára még primitívnek mondható backend feladatot sem ad önálló elvégzésre egy értelmes vezető fejlesztő vagy manager
Nem? Mi az, amit azzal a tudással nem lehet elvégezni?
20

Csak az utolsó sorra: pl. egy

mind1 valami név · Nov. 19. (H), 11.15
Csak az utolsó sorra: pl. egy ma folyó fejlesztésbe beszállni. Akár úgy is, hogy valaki megunta, hogy a takarítónő-portás-üzemeltető-fejlesztő-sofőr volt egy személyben és az ő dolgait kell folytatni.
21

Plusz

Hidvégi Gábor · Nov. 19. (H), 11.24
Minden dolog, ami a php 4.0 óta megjelent, addícionális, azaz a meglévőket egészíti ki. Ha ismered a for ciklust, akkor nem fognak meglepetést okozni az iterátorok, vagy ha egy függvény definíciójában a visszatérési értéknek vagy a paramétereknek van típusa stb.
32

Igy is fel lehet fogni, meg

inf3rno · Nov. 19. (H), 18.42
Igy is fel lehet fogni, meg úgy is, hogy csak a visszafele kompatibilitás miatt maradt benne az a retek, ami 4.0-ban is benne van. A PHP szerintem egész értelmes nyelv lenne, ha nulláról újragondolnák, ami 5.0 előtt volt, és nem hurcolnák magukkal a kezdeti dolgok terhét. Pl a $-t minden változónév előtt vagy az alapból nem utf-8 string függvényeket, stb. Komolyan milyen webes nyelv az, aminél külön mb vagy iconv extension kell ahhoz, hogy utf-8 stringgel tudj dolgozni?!
37

Felsoroltak

Hidvégi Gábor · Nov. 20. (K), 09.53
Ez mind szokás és módszertan kérdése, mi például szinte minden karakterláncműveletet adatbázison keresztül végzünk, a kódunkban talán egy mb_ függvény van, és mivel alapból ott van minden php-ban ez a kiterjesztés, így nem érzem problémának.
22

Nem tudom, pepita mit

mind1 valami név · Nov. 19. (H), 11.26
Nem tudom, pepita mit linkelt, mert xxx van a helyén, de amit te emlegettél, annak egy korrekt oldala van.
27

Korrekt

Hidvégi Gábor · Nov. 19. (H), 13.21
Mi korrekt rajta? A kinézet vagy a kód? Azokkal az inline stílusokkal mindenképp érdekes dolgokat vetít előre.
28

Pl. nem járt le a

mind1 valami név · Nov. 19. (H), 13.46
Pl. nem járt le a tanúsítványa, a noscript ellenére, látszólag normálisan jelenik meg az oldal stb.
29

Félreértettem

Hidvégi Gábor · Nov. 19. (H), 13.56
Ja, azt hittem, hogy az excégre gondolsz. Erre nem kerestem rá.
23

kérdezd meg nyugodtan Pepitát

Pepita · Nov. 19. (H), 12.18
kérdezd meg nyugodtan Pepitát, mekkora trágyadombot gyártottak
Ezzel egyenesen azt állítod, hogy én minősítettem trágyadombnak, nem azt, hogy Te.

Az általad küldött lejárt tanúsítvánnyal rendelkező oldalon
Remélem észrevetted, hogy szándékosan rontottam el a domaint, aki akarja meg tudja találni.

Viszont mint privátban is jeleztem: az, hogy mikor melyik cégnél mennyi ideig dolgoztam, az személyes adat, amit kizárólag az én döntési kompetenciám, hogy kivel osztok meg, és akkor itt, nyilvánosan is kérem, hogy haladéktalanul töröld illetve gondoskodj a törléséről, ha te nem tudod.
Baromira elszomorító, hogy ilyen szinten nem foglalkozol vele, hogy mit csinálsz!

Nem? Mi az, amit azzal a tudással nem lehet elvégezni?
Például egy PHP 7.2.x tulajdonságait kihasználó meglévő projekthez csatlakozni esélyed sincs.
Nem mondom azt, hogy fel se fogod ismerni a kódot, de az biztos, hogy amit pluszként teszel hozzá, annak 90%+ - ra kapsz code review-n change requestet.
De ebbe inkább nem megyek bele, mert előjön a "miért borzasztó dolog objektumorientáltan fejleszteni" lemez, amit enyhén szólva unok.
25

Ezzel egyenesen azt állítod,

Hidvégi Gábor · Nov. 19. (H), 13.07
Ezzel egyenesen azt állítod, hogy én minősítettem trágyadombnak, nem azt, hogy Te.
Én biztosan. De az is sokat elárul a dologról, hogy te már nem vagy ott (arra nem emlékszem, miért jöttél el), ha közvetve, de ez sem azt igazolja, mennyire jó cég az. És igen, biztos vannak ott is jó dolgok, de összességében mégiscsak bűzlik valami.

De egy ingyenes regisztráció után bárki megnézheti a frontend forrását, és eldöntheti, mennyire jó, amit lát.

Inf3rnót megkértem, hogy moderálja ki a cégnevet. Más kérdés, hogy te azért csak beletetted a fenti linkbe : ) Ha már a privát szféráról van szó.

Például egy PHP 7.2.x tulajdonságait kihasználó meglévő projekthez csatlakozni esélyed sincs.
Nincs? Mi az, amitől alapjaiban megváltozott a PHP? Mi az, amit némi rátanulással senki sem tudna behozni, ha arra valóban szükség van?
30

Kutyulod a dolgokat...

Pepita · Nov. 19. (H), 16.17
Mi az, amit azzal a tudással nem lehet elvégezni?

vs
Mi az, amit némi rátanulással senki sem tudna behozni


Én leírtam, hogy azzal a tudással nem tud valódi 7.2-es kódot írni (gy.k.: vagyis kihasználni az új feature-ök előnyeit), mert azt kérdezted mit nem tud elvégezni. Erre most megváltozik a kérdés, hogy mit nem lehet megtanulni. :-D

Gábor, a Manyika néni, akinek a 8 általános is úgy van meg, hogy 6 x első + 2 x második, Ő is lehet profi full stack fejlesztő, ha eleget tud tanulni. Állítottad, hogy 2018 - ban elég a php 4.x tudás, ezt vitattam. Attól, hogy közben megpróbálod módosítani az eredeti kérdést, még nem lesz igazad.

Ha már a privát szféráról van szó.
Nem privát szféra, inkább személyes adat. Ne forduljon elő többször, akkor rendben van.
31

Gábor, a Manyika néni, akinek

Endyl · Nov. 19. (H), 16.32
Gábor, a Manyika néni, akinek a 8 általános is úgy van meg, hogy 6 x első + 2 x második, Ő is lehet profi full stack fejlesztő, ha eleget tud tanulni. Állítottad, hogy 2018 - ban elég a php 4.x tudás, ezt vitattam. Attól, hogy közben megpróbálod módosítani az eredeti kérdést, még nem lesz igazad.


Gábor nem írta, hogy PHP 4.x-es tudással 7.2-es csapathoz/projekthez lehetne csatlakozni minden tanulás nélkül. Pusztán azt, hogy a weboldalak nagy százalékát el lehet készíteni PHP 4.x alatt is. Ez kétségkívül igaz. Az, hogy kinek melyik kényelmes, hasznos, produktív, az lehet szubjektív, vagy legalábbis nehéz/macerás objektív mérést végezni.

Szerintem nem gond, hogy mindenre nem csak egy megoldás van, hanem vannak alternatívák (feltéve, hogy ezek nem redundánsak, hanem bizonyos esetekben az egyiket, máskor meg a másikat érdemes használni).
34

Az, hogy kinek melyik

inf3rno · Nov. 19. (H), 18.49
Az, hogy kinek melyik kényelmes, hasznos, produktív, az lehet szubjektív, vagy legalábbis nehéz/macerás objektív mérést végezni.


Ez talán akkor probléma, ha egy kezdő tanácsot kér, és megpróbálja eladni neki az elveit, amiket ha követ az illető, akkor mindene lesz, csak piacképes tudása nem.
35

Piacképes

Hidvégi Gábor · Nov. 20. (K), 09.46
Mi a piacképes? Mi az, amit PHP 7.2-ben el lehet végezni, és 4.0-ban nem?
43

A piacképes tudást úgy

inf3rno · Nov. 20. (K), 16.40
A piacképes tudást úgy értettem, hogy be tudsz csatlakozni egy mai átlag PHP-s projekthez, ami több, mint 95%-ban PHP 5.4 feletti dolgokat használ: link. Ez nem arról szól, hogy mit tudsz elvégezni, mert mindent meg lehet csinálni Assembly-ben is, ha nagyon akarod. Ez arról szól, hogy tudsz e csapatban dolgozni OOP-s 5.x-es kódon vagy sem.
44

Világos

Hidvégi Gábor · Nov. 20. (K), 19.30
Ez rendben van, csak a fórumtéma az egyszemélyes projektekről szól.

Ha mondjuk XY Bt-knek készítesz WordPress oldalakat (mivel egyedül nagyjából ennyi fér bele), és nem feltétlenül garantálható a szerverkörnyezet, akkor célszerű lehet defenzíven dolgozni. Én például nemrég vettem részt egy önkéntes projektben, ahol statikus oldalakat kellett készíteni.
45

Hát akkor elkanyarodtunk a

inf3rno · Nov. 20. (K), 22.14
Hát akkor elkanyarodtunk a témától. Az egyszemélyes kis projekteknél valóban elég lehet a 4.0 egy rá épülő CMS-el. Ha valami komolyabb kell, akkor a 4.0 talán esetleg úgy tartható, ha a CMS-t is te írod. Én legalábbis nem láttam könnyen bővíthető CMS-t még, mindegyiknél tákolni meg közvetlenül adatbázis táblákba nyúlkálni kellett ahhoz, hogy működjön, amit akarok. A gond itt max a support lehet, mert ki tudja meddig lesz visszafele kompatibilis a PHP. Ha garantálják, hogy 8-as meg 9-es verziókban is elmegy a kód, akkor rendben van, feltéve, ha az illető később sem akar cégnél vagy csapatban dolgozni, ahol mások az elvárások.
49

Miről szól az egész?

Hidvégi Gábor · Nov. 21. (Sze), 15.45
Akármit varázsolsz a szerveren, a legvégén a böngészős környezet miatt ígyis-úgyis HTML-t kell előállítani, ami történhet a szerveren vagy a kliensen. Utóbbi esetben valamilyen köztes adatformát választanak, legtöbbször JSON-t vagy XML-t. Tehát szerveroldalon valamilyen adatstruktúrát kell előállítani egy kérésre adott válaszban.

A CMS-ben mit csinál az ember? Adatokat visz fel, módosít, megtekint. Az adatok az esetek túlnyomó részében adatbázisban vannak, a lekérdezések mezőnként karakterláncokat adnak vissza egy strukturált tömbben. Ezen a tömbön elvégzünk bizonyos műveleteket, majd az előző bekezdésben említett adatstruktúrát állítjuk elő belőle.

Tehát végeredményképp tömb-, szám- és karakterláncműveletek történnek az esetek túlnyomó többségében. Ezt a PHP mindig fogja tudni.
36

Fogalmi zavar

Hidvégi Gábor · Nov. 20. (K), 09.47
Állítottad, hogy 2018 - ban elég a php 4.x tudás, ezt vitattam.
Nem vitattál te semmit, hanem tettél egy kijelentést. Vitában érvelni szoktak, Pepita, de te még nem hoztál fel érveket, csak hisztizel, mint egy óvodás.

Továbbra is kérdés, hogy mi az, amit PHP 4.0 tudással nem lehet elvégezni? Erre várnék választ.

Ezek után várom a kifejtésed, mik a PHP 7.x előnyei, újdonságai, ami miatt egy egyszemélyes vállalkozásnak csak ebben érdemes dolgoznia.

Ha ez megvolt, akkor pedig azt, hogy mennyi rátanulás szükséges a 4.0-hoz képest, hogy ezeket az új dolgokat behozd.

Tehát a kérdésem nem változott.
38

csak hisztizel, mint egy óvodás

Pepita · Nov. 20. (K), 12.31
csak hisztizel, mint egy óvodás
:-D Nem veszem személyeskedésnek, jó is lenne egész nap az oviban játszadozni. :-D

PHP 4.0 tudással továbbra sem fogsz tudni érdemben csatlakozni egy PHP 7.x tulajdonságait kihasználó projekthez. Nyilván újra tudod (valahogy) írni 4.0 alatt, de továbbfejleszteni csak akkor tudod, ha megtanulod és megszokod a különbségeket - akkor viszont már nem 4.0 a tudásod. :)

PHP 7.x előnyei (a teljesség igénye nélkül):
7.0:
- Type declarations
- Return type declarations, ezekkel jól tudod biztosítani, hogy mindig azt kapd, amit vársz (még procedurálisan is)
- Új operátorok -> rövidebb kód
- Generator Return Expressions és még pár generator feature
- Egész osztás
7.1:
- Nullable types
- Void functions - végre azt is deklarálhatom, hogy nincs visszatérési érték
- Class constant visibility - attól még, hogy Te ördögtől valónak tartod, ez egy fontos OOP feature
- Multi catch exception handling
7.2:
- New object type
- Abstract method overriding
- Password hashing with Argon2 - nyilván ez is tök haszontalan, hisz ott van a jó öreg md5 is... :-D
- Exif support updated
- Enhancements to the ZIP extension

Ezen kívül nem szabad elfelejteni, hogy van pár dolog, ami nem kompatibilis visszafelé, régi kódot 7.x-re téve ilyeneket is igen át kell nézni. Természetesen ha 4.0 rutinnal odaülsz a 7.x kód elé, indirect variables gondod rögtön lesz.

ami miatt egy egyszemélyes vállalkozásnak csak ebben érdemes dolgoznia
Nem mondanám azt, hogy "csak ebben", de ha már PHP, akkor lehetőleg a legújabb stabil verziót érdemes használni, mint minden más programnyelvnél. Egyébként ha lehet még találni hostingot 4.0-ra, hát lehet, hogy épp azért menekülnék hanyatt - homlok attól a hosting cégtől, mert vállalja üzemeltetni. :)

Valószínűleg ha valóban érdekelne téged, hogy mire jó egy - egy programnyelvnek (és fejlesztőnek) a fejlődése, vagy egyáltalán: érdekelne a fejlődés, akkor nem tőlem vagy mástól várnád azt az információt, hogy "mitől jobb", "mitől több", hanem utánajárnál, olvasnál róla és csak specifikáltabb kérdést tennél fel. Tessék, fentebb egy egyáltalán nem teljes lista, mondjuk inkább ízelítő, amiknek én örülök, hogy fejlődött.
Igazán boldog akkor leszek, ha majd lehet futtatni a PHP-t (mondjuk 8.x?) "szigorúan típusos módban".

Ha ez megvolt, akkor pedig azt, hogy mennyi rátanulás szükséges a 4.0-hoz képest, hogy ezeket az új dolgokat behozd.
Pontosan annyi, amennyivel utol tudsz érni 3 főverziót, alverziókkal együtt. :-D
Remélem ezt nem gondoltad komolyan, hogy én mondjam meg, hiszen nincs két egyforma tanuláskészségű ember.

Nekem egyébként úgy tűnik, hogy te "állítottál" előbb dolgokat, aminek egy része nettó butaság, csak a te rögeszméd.
2018 - ban ne sugalljuk már egy esetleges kezdő olvasónak, hogy elég PHP 4 - et feltenni valahogy, és indulhat a "webfejlesztés". Egy juniornak annál jobb, minél újabb verzión kezd el egy nyelvvel foglalkozni, annál kisebb az esélye, hogy lemarad, mire megszokja használni.
Remélem ezzel végre zárhatjuk ezt a dolgot, mert tök haszontalannak érzem.

(Inf3rno popcorn nem kell több. :) )
40

Szövegértés

Hidvégi Gábor · Nov. 20. (K), 13.46
Igyekeztem tényleg egyszerűen megfogalmazni, de úgy látszik, így sem volt érthető, sajnálom. De akkor a kedvedért kibontom, hátha úgy átmegy.

Mi az a feladat, amit php 4.0 tudással nem lehet elvégezni?

Hol írtam én, hogy 4.0 verziót kell használni? Ez hülyeség lenne, hisz már sehol sem támogatott. Tudást említettem, ami teljesen mást jelent.

Pontosan annyi, amennyivel utol tudsz érni 3 főverziót, alverziókkal együtt
Most 7.x-nél tartunk, közben volt egy főverzió, a 7 a második, a 6.0 sosem volt publikus.

Tehát át kell gondolni, hogy mit tudott a php 4.x:
- típusok
- változók,
- konstansok,
- kifejezések,
- operátorok,
- kontroll struktúrák (if, for és társaik),
- függvények,
- objektumorientált programozás,
- hibakezelés,

- standard library,
- kiterjesztések.

Az általad felsorolt 7.x dolgok mind a meglévők csiszolása. Új dolog a php 5.x-ben a kivételkezelés, a névterek és a generátorok, továbbá ide sorolhatjuk a függvényparaméterek típusának megadását (5.0 és nem 7.x).

Tehát a kérdésre adott válasz részét képezi, hogy lehet-e kivételek, névterek és generátorok nélkül dolgozni. Szükségesek-e ezek ahhoz, hogy valaki elvégezze a feladatát, vagy csak bizonyos funkcionalitás alternatíváját jelentik, választási lehetőséget nyújtanak, hogy mindenki ízlése szerint dolgozhasson?

Mik a PHP 7.x előnyei, újdonságai, ami miatt egy egyszemélyes vállalkozásnak csak ebben érdemes dolgoznia?

Ha shared hoston van, akkor nincs választása, azt a PHP verziót kell használni, amit kap. Fel lehetett volna hozni, hogy a használt külső keretrendszereknek, rutinkönyvtáraknak is van verziókövetelménye.

A mondandódat sokszor hegyezed ki a típusdeklarációkra. Érdemes lenne kifejteni, hogy mit nyer ezekkel az ember. Mivel a kiértékelés futásidőben történik, ezért annyi a különbség típusdeklarációk használatakor, hogy a függvényhívás elején kapsz hibaüzenetet, míg ha nem használod őket, abban az esetben pedig akkor, amikor a kapott paramétert felhasználnád (például karakterláncot vársz, de tömböt kapsz helyette). Amit el tudok képzelni, hogy vannak kódelemző programok, amik segítségével a típuseltérésből adódó hibák egy részét még fejlesztés közben elkapd, de a működésből adódik, hogy nem lehet mindet.

Érdemes azt is kifejteni, hogy mi szól a magasabb php verziók ellen, mert ilyen problémába is lehet futni. Vagy azt, hogy milyen esetekben érdemes a legújabb (al)verzióra frissíteni, és mikor irreleváns.

ha valóban érdekelne téged, hogy mire jó egy - egy programnyelvnek (és fejlesztőnek) a fejlődése, vagy egyáltalán: érdekelne a fejlődés, akkor nem tőlem vagy mástól várnád azt az információt, hogy "mitől jobb", "mitől több", hanem utánajárnál, olvasnál róla
Köszönöm a kioktatást. Nem nekem van erre szükségem, mert egyrészt én ezekkel tisztában vagyok, másrészt te állítottad azt, hogy a 7.x jobb és többet tud, hát akkor támaszd alá, hogy miért is érdemes energiát feccölni az újdonságok megtanulásába, használatába, tapasztalatszerzésbe, mi az, amit adnak és mi az, amit elvesznek.

»Ha ez megvolt, akkor pedig azt, hogy mennyi rátanulás szükséges a 4.0-hoz képest, hogy ezeket az új dolgokat behozd.«
(...)

Remélem ezt nem gondoltad komolyan, hogy én mondjam meg, hiszen nincs két egyforma tanuláskészségű ember.
Tanulni ugyanannyit kell, hisz az eltérések mennyisége fix. Az teljesen irreleváns, hogy ezt valakinek x, másnak y idő abszolválni.

Nekem egyébként úgy tűnik, hogy te "állítottál" előbb dolgokat, aminek egy része nettó butaság, csak a te rögeszméd.
2018 - ban ne sugalljuk már egy esetleges kezdő olvasónak, hogy elég PHP 4
Azt elég gyorsan bebizonyítottad, hogy egyszerűsége ellenére nem értetted a kérdést.

Ismételten kioktatsz, amire nincs szükségem, köszönöm.
41

Ne már

Pepita · Nov. 20. (K), 15.03
Szövegértés vs Ismételten kioktatsz

Tényleg menj el politikusnak, mert tényleg nagy érzéked van hozzá, hogy lyukat beszélj az emberek hasába.. :)

Hogy a te szótáradban mit jelent a "dolog" és a "csiszolás", bocsi, de nem érdekel. Tőlem egy új feature-t is nyugodtan hívhatsz mezei nyúlnak is, ez nem fog változtatni az értékén.
Nem tudom, mi értelme van a tudást verzióhoz kötni, mert tutira nem úgy működik az emberi agy, hogy számok alapján külön-külön területekre "tároljon". Inkább a tapasztalat az, amit lehet konkrét verzió(k)hoz kötni, és itt jobban kijönnek a különbségek is..
De ha tudásnak hívod, és verzióhoz kötöd, akkor is ugyanúgy nem, vagy kényelmetlenül, lassan tudod felhasználni más verzió alatt.

De mind1, komolyan meguntam, nem fogok veled szélmalomharcosat játszani, hiába próbálsz sértegetni / bosszantani, legfeljebb egy másik fajta türelmem is elfogyasztod az ilyenekkel:

Azt elég gyorsan bebizonyítottad, hogy egyszerűsége ellenére nem értetted a kérdést
Azt a fajta türelmem viszont nem javasolt elfogyasztani.
42

Nehéz

Hidvégi Gábor · Nov. 20. (K), 16.01
Mintha nem értenél magyarul, és még a kérdésre sem tudtál válaszolni. Így nehéz.
46

Miért az a helyes kérdés,

BlaZe · Nov. 21. (Sze), 01.47
Miért az a helyes kérdés, hogy mi az, amit egy 15+ éves verzióval nem lehet elvégezni? Assemblyben is lehet weboldalt készíteni, de senki nem csinálja, mert nem éri meg. A PHP 4 tök őszintén egy faék volt és hiányzik belőle rengeteg feature, ami később bejött, és támogatja a hatékony és kulturált fejlesztést, segít csökkenteni a hibalehetőségeket.

Az egy sokkal fontosabb kérdés, hogy milyen és hány céghez tudsz csatlakozni azzal a tudással. Illetve hogy ha 4.0 alapon készítesz egy projectet, akkor kit tudsz bevonni a fejlesztésbe, vagy kinek tudod továbbadni. Meg hogy mik azok a projectek, amik még támogatják a 4.0-t és tudsz rájuk épülni, ha kell valami. Mindkettő kb egy üreshalmaz. Az első (milyen céghez tudsz csatlakozni) talán nem olyan fontos, ha magányos farkasként dolgozol. Bár akinek ez nem szempont az kb bolond :) A másik viszont akkor is fontos, ha egyedül fejlesztesz. Senior ember ilyet nem csinál. Mekkora költséget okozunk azzal, ha PHP4 alapon írunk meg valamit, aztán kell valaki, aki átveszi, vagy beszáll? Borítékolható, hogy újra lesz írva az egész. Tehát még ha igaz is, hogy PHP4-ben mindent ugyanolyan jól meg lehet csinálni, ez akkor se egy vállalható alternatíva, amennyiben próbáljuk figyelembe venni az ügyfél pénztárcáját és mozgékonyságát (time to market).

Pl Java7-es projectre már igen nehéz fejlesztőt találni, pedig az egyrészt közel sem olyan régi, mint a PHP4, másrészt sokkal közelebb van a legfrissebb Java-hoz, mint a PHP4 az aktuális verzióhoz, és még sok lib által támogatott is.
47

+1 amugy hihetetlenul

MadBence · Nov. 21. (Sze), 14.21
+1

amugy hihetetlenul vicces, hogy 2018-ban egy (elvileg) szakmai oldalon arrol megy a diskurzus, hogy tanuljon-e valaki PHP4-et, ha szeretne webfejlesztessel foglalkozni...

megkerestem a PHP4 hivatalos doksijat, ez all benne (vagyis inkabb helyette):

The PHP 4 documentation was removed from the PHP Manual in August 2014, approximately six years after PHP 4 reached its end of life.


ertelmetlen arrol vitatkozni, hogy mi mindent lehet megcsinalni egy 2008 ota senki altal nem tamogatott nyelvben. nem csak hogy ertelmetlen, de egyenesen karos barkit arra buzditani, hogy hasznaljon PHP4-et.
50

Hát gondolom Gábor képviseli

inf3rno · Nov. 21. (Sze), 18.21
Hát gondolom Gábor képviseli a piac azon 0.1%-át, akire senki nem gondol. :-) A támogatás biztonsági szempontból számít egyébként? Gondolom a dokumentációt csak le lehet rántani hozzá valahonnan...
48

Tudás

Hidvégi Gábor · Nov. 21. (Sze), 15.38
Akkor neked is linkelem ezt a hozzászólásomat, emellett emlékeztetnélek a témafelvetésre, továbbá a szerzőnek, mint írja, van pár ismerőse, akik egyszemélyes kommandóként dolgoznak, és én is ismerek ilyeneket.

Az első (milyen céghez tudsz csatlakozni) talán nem olyan fontos, ha magányos farkasként dolgozol. Bár akinek ez nem szempont az kb bolond :)
Körülbelül annyira, mint aki ilyen kijelentést tesz. Nem vagyunk egyformák.

Nem mindenkinek célja, hogy cégekhez csatlakozzon, mert az mindenképp kötöttségekkel és bizonyos fokú rugalmatlansággal fog járni, ami nem biztos, hogy számára elfogadható.

De vegyük példaként mondjuk a típusosságot, ez hasznos lehet, ha csapatban dolgozik az ember, így van rá esély, hogy főleg nagyobb kódbázis esetén kontrolláltan derüljenek ki bizonyos hibák. De ha valaki egyedül dolgozik, és megvan hozzá a fegyelme, szükség van-e erre? Nem vagyok róla meggyőződve. Mi nem vagyunk sokan, nem használjuk ezt a lehetőséget, sőt, mind frontend, mind backend oldalon kihasználjuk a dinamikus típusok előnyeit. Mi tehát sok esetben vesztenénk, ha élnénk ezzel a lehetőséggel.

A másik viszont akkor is fontos, ha egyedül fejlesztesz. Senior ember ilyet nem csinál. Mekkora költséget okozunk azzal, ha PHP4 alapon írunk meg valamit, aztán kell valaki, aki átveszi, vagy beszáll?
Na, mekkorát? Erre kíváncsi lennék. Az elején azt állítottad, hogy a PHP 4 egy faék egyszerűségű rendszer, ami tény és való. Mivel kicsi az eszközkészlet, maga a program is egyszerű lesz, ha valaki ránéz, egyből tudni fogja, hogy mit csinál.

Ha a PHP 4 faék, akkor a PHP 7 jóval bonyolultabb. A featúrák számával azok kombinációja miatt a hibázás/félreértés/tévedés valószínűsége négyzetesen növekszik. Mi garantálja ezek után, hogy a 7-esben, teljes eszközkészlettel megírt program jobb lesz?
51

Mi garantálja ezek után, hogy

inf3rno · Nov. 21. (Sze), 18.29
Mi garantálja ezek után, hogy a 7-esben, teljes eszközkészlettel megírt program jobb lesz?


Gondolom ez a becsapós kérdés, mert már te is meg mások is leírták elég sokan, hogy ugyanaz megoldható mindkét verziónál.

Valószínűleg a fejlesztési idő alacsonyabb lesz PHP7-ben, mert az új feature-ök bizonyos dolgok automatizálását jelentik, amiket PHP4-ben újra és újra be kell gépelned. Nagyjából ennyi a különbség, meg az, hogy foltozzák a biztonsági réseket, készülnek hozzá kiterjesztések, keretrendszerek új technológiákhoz, szóval nem kell mindent magadnak megírni, ha esetleg valami új dolgot akarnál használni. Bár rólad tudom, hogy nem akarsz. :D
52

Teljesen mindegy, hogy kinek

BlaZe · Nov. 21. (Sze), 19.38
Teljesen mindegy, hogy kinek hány milyen ismerőse van. Ha PHP4+ libeket kell egyáltalán használod, aminek az interface-e PHP4+, akkor ismerned kell a szükséges PHP4+ featuret. Ha valamiért bele kell nézni valami részletért, akkor meg pláne. Ha ez a tudásod nincs meg, akkor tökmindegy, hogy PHP4, vagy PHP7 futtatja az alap eszközkészlettel működő programodat. Vagyis sajnos továbbra sem igaz amit írsz, a PHP4+ nem elég akkor sem, ha egyedül dolgozol egy alagsorban.

Nem mindenkinek célja, hogy cégekhez csatlakozzon, mert az mindenképp kötöttségekkel és bizonyos fokú rugalmatlansággal fog járni, ami nem biztos, hogy számára elfogadható
Nem azt mondtam, hogy csatlakozni, hanem hogy képesnek lenni csatlakozni. Sokminden képes megváltozni, ha pl az embernek családja lesz :) Az is, hogy mennyi pénzt visz haza, mekkora felelősséggel és rendelkezésre állással. De a lényeg, hogy PHP4-es tudással a lehetőséged nincs meg. Lehet neked ez nem fontos, mert évek óta nem méretted meg magad a piacon. De ez egyrészt általában idő kérdése csak (nem kevés embert interjúztam, akinek valaha piacképes tudása volt, de ma már semmit nem ér vele), másrészt ezt vallani, és ezt ajánlani két külön dolog.

Na, mekkorát? Erre kíváncsi lennék.
Egy szükségtelen nemnulla költséget.

A featúrák számával azok kombinációja miatt a hibázás/félreértés/tévedés valószínűsége négyzetesen növekszik.
Ez egy b*romság, már bocs :) Rengeteg feature kerül a nyelvekbe, ami pont ez ellen hat. Ezt elmondhatod 100x, de attól még nem igaz.

Ami tény, hogy ha csak PHP4 tudásod van, akkor gyakorlatilag nullára csökkented az esélyét, hogy munkát találj. Legyen az egyszemélyes, vagy többszemélyes munka.
55

Ha PHP4+ libeket kell

Hidvégi Gábor · Nov. 22. (Cs), 13.15
Ha PHP4+ libeket kell egyáltalán használod, aminek az interface-e PHP4+, akkor ismerned kell a szükséges PHP4+ featuret. Ha valamiért bele kell nézni valami részletért, akkor meg pláne. Ha ez a tudásod nincs meg, akkor tökmindegy, hogy PHP4, vagy PHP7 futtatja az alap eszközkészlettel működő programodat. Vagyis sajnos továbbra sem igaz amit írsz, a PHP4+ nem elég
A PHP7 egy-két szintaktikai apróságon kívül visszafele kompatibilis a PHP4-gyel. De amit leírsz, abból nem következik az utolsó mondatod. Miből vontad le a következtetést, hogy a PHP4 nem elég?

A munkahelyemen összesen négy külső könyvtárat használunk, ebből kettő még PHP4-ben lett anno megírva (egy SQL daraboló és egy PDF nyomtató), és máig tökéletesen működnek. Ez hogyan lehetséges?

Az is, hogy mennyi pénzt visz haza, mekkora felelősséggel és rendelkezésre állással. De a lényeg, hogy PHP4-es tudással a lehetőséged nincs meg.
Ez kinyilatkoztatás, vagy alá is tudod támasztani valamivel? Tudom, nem számít, de szabadúszó koromból még máig vannak PHP4-es projektek, amik a mai napig működnek. Ha újat kéne készíteni, azokra az alapokra nyugodtan lehetne építeni, mert a weboldalak és -szolgáltatások nem változtak meg belülről az utóbbi huszonöt évben.

Egy szükségtelen nemnulla költséget.
Tudsz esetleg számokat is mondani? Üzleti döntést csak úgy lehet meghozni, ha pontosan ismerünk minden körülményt. És az is érdekelne, hogy a számokat mire alapozod, egy kutatás sem ártana, hogy legyen alátámasztva tudományosan.

Ez egy b*romság, már bocs :) Rengeteg feature kerül a nyelvekbe, ami pont ez ellen hat. Ezt elmondhatod 100x, de attól még nem igaz.
Kifejtés nélkül ez is a kinyilatkoztatás kategória, az pedig csak annyit jelez, hogy itt nem vitatkozunk, hanem te megmondod a tutit, más meg fogadja el csak azért, mert te azt állítod.

Minden bevezetett új featúra jár előnyökkel, de hátrányokkal is. Rengeteg példát lehetne felhozni, többek között rendszerprogramozásban miért ragaszkodnak a legtöbb helyen máig az ősi C-hez, miért lehet olvasni a neten olyan cikkeket, hogy C++ kódban nem használnak beépített "újdonságokat", például kivételkezelést. Magasabb szintű nyelveknél is akadnak problémák, ahol nem lehetséges a többszörös öröklés, a mixinekkel tudnak gondok lenni, a PHP típusajánlás sem tökéletes minden esetben, a példákat elég sokáig lehetne sorolni. És akkor ne is menjünk bele olyanokba, hogy a funkcionális programozás terjedésével az új PHP verziók featúráit nem is lehet kihasználni, mert nincs értelme.

Nincs olyan, hogy valami csak pozitív, és nincsenek árnyoldalai. A sütemények finomak, és nagyon könnyű belőlük energiához jutni, mert a szervezet az enegiát szállító cukrot közvetlenül tudja a sejtekhez szállítani belőle. Nemrég olvastam, hogy egy férfi csak süteményt adott a gyerekeinek, akiknek emiatt tönkrementek szépen a fogaik.

Érdekes lenne felmérni, hogy mennyi időt vesz igénybe ezeknek az új dolgoknak a megismerése, megtanulása, a tapasztalatgyűjtés, hogy mi mire jó és mire nem, mi mivel ütközik. Érdekes lenne felmérni, hogy mennyi idő a PHP4 eszköztárával (függvények, for ciklus, alap típusok: karakterlánc, egész szám, törtszám, tömb, null, és esetleg objektumok) elkészíteni egy projektet, és ugyanez mennyi idő az újabbakkal s azok újdonságaival. A nagyobb eszközkészlet mindenképp nagyobb szellemi erőfeszítést igényel, de a végeredmény ugyanaz lesz, karakterláncok bűvölése, hisz a böngészők azzal dolgoznak.
58

A featúrák számával azok

inf3rno · Nov. 22. (Cs), 14.40
A featúrák számával azok kombinációja miatt a hibázás/félreértés/tévedés valószínűsége négyzetesen növekszik.


Szerintem ez is kinyilatkoztatás kategória. A legtöbb ilyen fejlesztés pont a hibázás elkerülésére készül, és azért automatizálnak, hogy ne kelljen ugyanazt kézzel bevinni, mert úgy könnyű hibázni. A feature csoportokat alkothatnak, és nem feltétlenül lehet tetszőlegesen kettőt összepárosítani. Szóval én nagyon meglepődnék, ha igaz lenne, amit írsz. Jó lenne, ha valamivel alátámasztanád. És itt valami referenciára, kutatásra, stb. gondolok, ahol ténylegesen ki is próbálták, és ez jött ki eredménynek.
70

Példa

Hidvégi Gábor · Nov. 23. (P), 15.18
Az egyszerűség kedvéért maradjunk a PHP-nál és a típusoknál. A következő program nem fog működni több okból sem:
<?php
class klassz {
  function hehe(int $szam) {}
}

class orokolt extends klassz {
  function hehe(float $szam) {}
}

function proba(klassz $klassz) {
}

  proba(null);
?>

Ha egy metódus paraméterét egy bizonyos típussal deklarálod, akkor az örökölt osztály metódusában a paraméter típusa csak az vagy annak a leszármazottja lehet. PHP-ban a float nem az integerből származik, így egy szép figyelmeztetést fog generálni a futtatókörnyezet.

Csak nyalánkságnak tettem oda, hogy a proba függvényt nem lehet null paraméterrel hívni, ami szerintem elég nagy hiányosság, hisz az is egy információ, hogy egy paraméternek nincs értéke.

Továbbá a paraméterek típusának ellenőrzése futásidőben történik, tehát az adott függvény vagy metódus meghívásánál a PHP megnézi, hogy az adott paraméter megfelel-e a kritériumnak, ha nem, akkor figyelmeztetést generál. Ha nem adod meg a paraméter típusát, és mondjuk egész számot vársz, de karakterláncot kapsz, akkor a program mindenképp hibát ad, amikor ezt a paramétert felhasználnád:
<?php
function osztas_tipus(int $szam) {
  $eredmeny = 5 / $szam;
}
function osztas($szam) {
  $eredmeny = 5 / $szam;
}

osztas_tipus("haha");
osztas("hehe");
?>

Futtatáskor az első egy fatal errort ad, a másik warningot, de mindenképp fog valamilyen hiba történni.

Ezek után a nagy kérdés, hogy mit nyertél az egész típusosdival: ellenőrizned ígyis-úgyis kell, akár használsz típusokat, akár nem, mert mindkét esetben hiba fog történni a programban. Emellett típusos paraméter esetében tudnod kell, hogy csak olyan típusú paramétert szabad átadnod, null-t nem (pedig adatbázisban lehet bármilyen mező értéke null).

Tehát az elvégzett munka ugyanannyi, de a program írásakor fejben kell tartanod az egyes típusokat, mi miből öröklődik, mit nem lehet átadni. Például ha egy publikus rutinkönyvtárat készítesz, akkor egyáltalán nem ildomos a paramétereknek típusokat adni, mert nagyon megkötöd vele a későbbi felhasználók kezét, akik nem feltétlenül ugyanazt a típust szeretnék használni, amit te elképzeltél.

A fenti egy konkrét példa volt, némi absztrakciót követel, ha általánosítani szeretnél belőle. Ha két hasonló dolog kerül be egy programnyelvben, akkor két featúránál kell fejben tartanod, hogy mit lehet vele csinálni és mit nem. Ezek kombinációja esetében pedig négyzetesen nő a hibázási lehetőségek száma.
72

Tehát az elvégzett munka

MadBence · Nov. 23. (P), 19.30
Tehát az elvégzett munka ugyanannyi, de a program írásakor fejben kell tartanod az egyes típusokat, mi miből öröklődik, mit nem lehet átadni.

Vegyuk eszre, hogy a tipusok nelkuli vilagban is eszben kell tartani ugyanezeket dolgokat, raadasul mivel semmi sincs ledokumentalva, igy minden informacio implicit erheto csak el. Ez sokkal megterhelobb, es nehezebb fejben tartani. Tovabbra sincs rola semmilyen fogalmam, hogy honnan veszed ezt a negyzetesen no a hibak szama marhasagot.
74

Gondolom arra gondol, hogyha

inf3rno · Nov. 23. (P), 22.44
Gondolom arra gondol, hogyha van n darab feature, akkor a kombinációk száma n^2 (ha saját magával is kombinálható ugyanaz a feature). Aztán úgy sejti, hogy a hibák száma ezzel egyenesen arányos lesz. De erősen kétlem, hogy ennek lenne valami valóság alapja. Maximum korrelál vele a hibák száma, de ha teszteletlen kódot ír és debuggol, akkor tökmindegy mennyi a feature, így is, úgy is csurig lesz hibával a kód.

Csak magamról tudom, hogy közepesen bonyolult főleg SQL-ekkel operáló kódot utólag tesztelve integrációs tesztekkel 25 hibát találtam, úgy, hogy én azért eléggé jól koncentrálok, és ritka, amikor hibázok. Ha valaki kicsit figyelmetlen, akkor dupla ennyit is simán összehoz, és általános használatnál annyira elő sem jöttek ezek, mert viszonylag ritka útvonalakon voltak. Egyébként ijesztő, hogy ez a TDD, BDD mennyire szitokszó egyeseknél. Annak idején prohardver programozós fórumba írtam egy kezdőnek, hogy érdemes lenne úgy elkezdenie programozni, hogy beletanul ilyenekbe, aztán egyből le lettem hurrogva, hogy ez mennyire felesleges, meg hogy csak csillagrombolók programozásához kell, kis projektekre kezdőknek szükségtelen, stb. Megvan ott is a színvonal...
78

Gondolom arra gondol, hogyha

BlaZe · Nov. 26. (H), 13.31
Gondolom arra gondol, hogyha van n darab feature, akkor a kombinációk száma n^2 (ha saját magával is kombinálható ugyanaz a feature). Aztán úgy sejti, hogy a hibák száma ezzel egyenesen arányos lesz. De erősen kétlem, hogy ennek lenne valami valóság alapja. Maximum korrelál vele a hibák száma
Mondjuk azt képtelen vagyok megérteni, hogy ha egy programban használok fort és foreachet, ami két feature ugye (ha már annak lett nevezve) és elég jelentős az átfedés a felhasználási területek között, akkor hogy tudom vele növelni a programomban a hibák számát. Úgy se tudom elképzelni, ha egymásba ágyazom őket. Legalábbis ekvivalens átalakítást feltételezve, tehát pl részhalmazon iterálást nem cserélek le teljes halmazon végigiterálásra. Ha nem ekvivalens átalakítást végzek, az pedig nem a feature kombináció hibája, hanem én vagyok hülye, és ugyanazt a hibát el tudom követni for használatával is.

Továbbá azt se értem, hogy mivel a nyelvek fejlődése azt a célt szolgálja, hogy korábban is megvalósítható funkcionalitást tudj egyszerűbben leírni, hogy tud itt bármi hibanövekedés előfordulni. Jelentsen ez bármit. Ugyanis egymás alternatíváiról beszélünk, nem egymás kombinációiról. Az első mondatból kiindulva pedig, mivel tipikusan arról van szó, hogy rövidebben, kevesebb "featuret" használva írjuk le ugyanazt, kevesebb lesz a programban a "feature"-ök felhasználási száma. Ezért még ha lenne is értelme ennek az egész feature kombinálásnak, az új feature-ök használatával kisebb számokat "hatványozunk", bár nem tudom pontosan milyen hatványról is beszélünk itt, illetve hogy minek a megjelenésére számítunk a kitevőben.

Ha egy program 10 for ciklusból áll, akkor az 10 potenciális hibázási lehetőség (amennyiben ignoráljuk a ciklusok magját, ami a választott példa miatt irreleváns). Ha ebből 5-öt lecserélünk foreach-re, akkor hány hibázási lehetőségünk lett? Mivel 2 feature-t használtam 10^2=100? Vagy maradt az 5+5=10? Vagy 5+0=5, hiszen egy foreach-et még egy újszülött se nagyon bír elrontani? Ha nem az első, azzal megcáfoltuk Gábor állítását. Ha az első, akkor viszont én elmegyek műkörmösnek...

(Ezt nem kellett volna végiggongolnom, mert most az agyam kicsit matekosabb fele elkezdett visítva leolvadni :))
79

Paks 2

Pepita · Nov. 26. (H), 14.40
Ajjaj, ne csinálj az agyadból Paks 2-t, mert #mindmeghalunk! :-D

ha egy programban használok fort és foreachet ... hogy tudom vele növelni a programomban a hibák számát
Szerintem olyasmire gondolt Gábor, hogy így már megtöbbszörözöd a hibázási lehetőséget, mert (csak példa):
- for helyett használsz foreach-et vagy fordítva;
- for -t próbálsz meg foreach szintaktikával leírni és fordítva -> syntax error
- nem is iterálsz, hanem kitalálsz helyette valami rosszabbat.
Látható, hogy pusztán nézőpont kérdése, mennyire "hatványozottan nagyobb" a hibalehetőség, ha kényelmesen / elegendően nagy eszközkészlettel dolgozol.
Olyan ez, mint a szerelés: ha a szerszámos ládádban 12 féle csavarhúzó van, akkor sokkal nehezebben választod ki az adott csavarhoz a legjobbat, mint ha csak egy kalapácsod van. Ha ez elég nagy, akkor minden csavart be tudsz vele ütni, kifelé meg szedje ki az, aki akarja. :)

Persze ha van egy komolyabb szerszámkészleted, és már valamennyire megszoktad a szerszámokat, akkor sokkal rövidebb idő alatt sokkal szebben fogod összerakni ugyanazt a konyhaszekrényt, mint egy darab kalapáccsal - de hát az én szövegértésemmel baj van, úgyhogy nyilván nincs igazam. ;)

Ha ebből 5-öt lecserélünk foreach-re, akkor hány hibázási lehetőségünk lett?
Gábor "számítása" szerint 40.
Mert 1 vezérlési szerkezetet használva 10 volt, akkor 2-t használva 2^2 = 4 lesz a szorzó, amivel a 10-et szorozni kell.
Szerintem pedig az egészben egy hiba van csak: a (z alapvető) vezérlési szerkezetek minden nyelvben meg vannak, így ez nemigazán feature.

Az egész lényege - amennyiben jól értem a szövegeket :-D - annyi, hogy felesleges a profi szerszámkészlet, mert kőbalta is van, és az ősember is el volt ezzel egy darabig, akkor meg minek bármi mást / többet használni.
80

Mert 1 vezérlési szerkezetet

BlaZe · Nov. 26. (H), 16.56
Mert 1 vezérlési szerkezetet használva 10 volt, akkor 2-t használva 2^2 = 4 lesz a szorzó, amivel a 10-et szorozni kell.
Értem, szóval van egy elszabhatjuk koefficiens, amit a használt_featureszám^2 formulával határozhatunk meg :)

Egyébként komolyabbra fordítva, Gábor nem azt mondja (ha jól értem), hogy a programban fog négyzetesen nőni a hibák száma, hanem hogy exponenciálisan növekvő számú módon tudunk hibát vinni a rendszerbe. Ami oké, csak semmit nem jelent. A fű zöld, az ég meg kék :) Mondjuk azt is írta, hogy
A featúrák számával azok kombinációja miatt a hibázás/félreértés/tévedés valószínűsége négyzetesen növekszik
ami viszont már teljesen mást jelent, és nem is igaz, ugyanis a hibák választási lehetőségének számával nem növekszik arányosan a valószínűség, mert az feltételezné, hogy a helyes választások száma konstans.

Szóval összességében Gábor azt mondja, amit te is írtál: ne adjunk választási lehetőséget, mert az csak összezavarja a programozókat. És egyébként is meg kell tanulni használni a dolgokat, ami "kidobott idő", hisz a lefejlesztett funkcionalitás ugyanaz lesz, ezért a tanulással és a funkcionalitáshoz szükséges eszközök kiválasztásával eltöltött idő nettó veszteség. Ennek elsőre blikkre van értelme. Másodikra viszont nincs. Ugyanis ez ignorálja, hogy a fejlettebb feature-ök többnyire csökkentik a választások számát, emiatt csökkentik a fejlesztési időt, viszont cserébe növelik az olvashatóságot, karbantarthatóságot, ami szintén csökkenteni fogja a karbantartási időt, amikor legközelebb az adott részhet kell nyúlni. És akkor körbeértünk :) Erről ugyanis nem lehet meggyőzni, még olyan példákkal se, amik nyilvánvalóak és ő is elismeri (Assembly vs PHP). Úgy érzem Gábor úgy gondolja, hogy az absztrakciók szintjének növelése egy szintig hatékony, afölött kontraproduktív. Ami valószínűleg igaz, amíg a megoldandó feladat komplexitása konstans. Márpedig Gábor a leírása alapján olyan környezetben dolgozik, ahol ez igaz, ezért azt gondolja, hogy a többi webes rendszerben is így van. Valójában viszont a fejlesztők szemével nézve a feladatok komplexitása folyamatosan növekszik (pl skálázhatóság, magas rendelkezésre állás, vásárlói profil alapú termékajánló stb). Egyrészt az idővel, a technológiai fejlődéssel, másrészt jó eséllyel a senioritás szintjével is.

Innen már el lehet ugrani oda, hogy a rendszerben lévő hibák száma is nő, hiszen az a komplexitással, a futó kód méretével, az absztrakciók számával valóban jellemzően nő. De ezt nem a feature-ök száma határozza meg, hanem a feladat komplexitása. A feature-ök csak a növekvő komplexitás elérésében támogatnak. Na mindegy, továbbra is parttalan a vita, csak kijött :)
81

Úgy érzem Gábor úgy gondolja,

inf3rno · Nov. 26. (H), 18.59
Úgy érzem Gábor úgy gondolja, hogy az absztrakciók szintjének növelése egy szintig hatékony, afölött kontraproduktív.


Persze, ez így van. Létezik overengineering. De ő messze nem arra a szintre tette a mércét, mint az átlag fejlesztő, hanem már az OOP alkalmazása is túl absztrakt neki.

A négyzetes micsodát szerintem sincs értelme tovább gondolni.
86

Igen

Hidvégi Gábor · Nov. 28. (Sze), 10.22
Jól érted, amit írtam, de a konklúziókban tévedsz.

Az pedig nagyon jól látszik, hogy a segédeszközök és az absztrakciók számának a növelése nem segít a problémák megoldásában. Nem véletlenül nő a betörések száma a nagy informatikai és egyéb cégekhez: a feladatok komplexitása messze meghaladja a programozók intelligenciáját, azaz nem látják át a rendszer működését és az egyes komponensek interakcióit.

A feladat összetettsége lehet természetes és mesterséges, ez utóbbi pedig abból adódik, amikor programozók mindenféle best practice-re hivatkozva elbonyolítják a rendszert.

Szabadidőmben szeretek nyílt forráskódú szoftvereket vagy könnyen letölthető és visszafejthető frontend alkalmazásokat elemezni. Az a legegyszerűbb eset, hogy például a használt jQuery teljesen felesleges, vagy hogy OOP-t használnak ott, ahol egyszerű függvényekkel is meg lehetett volna oldani a problémát jóval kevesebb munkával, de az is általános, hogy a legtöbben nem értik az objektumorientált programozást. A programok nagy része feleslegesen overengineered.
88

Jól érted, amit írtam, de a

BlaZe · Nov. 28. (Sze), 11.02
Jól érted, amit írtam, de a konklúziókban tévedsz.
Miben? Hogy jelentősen bonyolódtak a megoldandó problémák, amit egyre komplexebb eszközkészlettel vagyunk kénytelenek kezelni? Nem konklúziónak nevezném, hanem tapasztalatnak...

Az pedig nagyon jól látszik, hogy a segédeszközök és az absztrakciók számának a növelése nem segít a problémák megoldásában
Tök őszintén, hány magas rendelkezésre állású, masszívan skálázható, microservice alapú, zero downtime, multisite stb rendszeren dolgoztál az elmúlt években? És mekkora az automata teszt lefedettségetek?
105

Leírtam, a komplexitás egy

Hidvégi Gábor · Dec. 2. (V), 12.34
Leírtam, a komplexitás egy része mesterséges, és ez épp a választott eszközöknek köszönhető. Ráadásul egy-egy eszköz lehet, hogy bizonyos problémákat megold, de újabbakat hoz be.

Minden absztrakció egy hazugság, de legalábbis féligazság. NFS esetében csináljunk úgy, mintha helyi meghajtó lenne, ami mindaddig működik, amíg a hálózat elérhető és nem dugul be. Építsünk rá egy szolgáltatást! Az csak addig fog működni, amíg a hálózat is elérhető. Minél több ilyenből áll össze valami, annál nagyobb valószínűséggel fog kiesni belőle valami.

És annál nagyobb eséllyel fognak rá betörni, mert a készítői nem látják át, melyik absztrakció hol szivárog. Friss a Marriott hotel esete, de idén betörtek a Google-hoz, korábban a Microsofthoz, nagyon sok eset van, ahol tízmilliós nagyságrendben vitték az adatokat. Pedig ezeken a helyeken van pénz, vannak szakemberek, van tudás, és mégis.

Hozzátok hányszor törtek be eddig?

Én egyébként tizenkét éve egy cégnél dolgozom, és a felsoroltak nem céljaink, vagy másképp oldjuk meg. A microservice-ekben nem hiszek, továbbá az automata tesztekben sem.
109

Minden absztrakció egy

BlaZe · Dec. 2. (V), 15.42
Minden absztrakció egy hazugság, de legalábbis féligazság
Hát... ez egy érdekes mondat :)

NFS esetében csináljunk úgy, mintha helyi meghajtó lenne, ami mindaddig működik, amíg a hálózat elérhető és nem dugul be. Építsünk rá egy szolgáltatást! Az csak addig fog működni, amíg a hálózat is elérhető. Minél több ilyenből áll össze valami, annál nagyobb valószínűséggel fog kiesni belőle valami.
És ezért az NFS haszontalan? Vagy a hálózati szolgáltatások bármelyike? Mit akarsz ezzel mondani? Pl a weboldalak, amiket készítesz elérhetőek hálózat nélkül?

Érteni kell, amit csinálunk. Ehhez tanulni kell és tapasztalni. Ezért nem igaz, amit írtál, hogy a webfejlesztés egy egyszerű szakma. Nagyon nem az. Te csak a frontend részét látod. Attól még, hogy PHP-t is ismered, nem láttál még igazi backend rendszert, mert akkor nem írnál ilyet. A LAMP önmagában egy komolyabb rendszerben a frontend, nem a backend. Emiatt egy tényleg fullstack dev (ha létezik ilyen egyáltalán) egy nagyon komoly tudású ember lehet csak.

Hozzátok hányszor törtek be eddig?
Erre nehéz válaszolnom. Amit 2013 és 2017 vége között csináltam, az egy banki trading rendszer volt privát hálón. Ott eleve mások voltak a kihívások. Jelenleg pedig egy libet készítünk a kollégáimmal, ezért nincs klasszikus prod rendszerünk. Rengeteg helyen futunk viszont prodban. 2013 előtt dolgoztam webes rendszereken. Biztos voltak sechole-ok, de betörésről nem tudok. Ugye dolgoztunk együtt is ilyen rendszeren, ahol te csináltad a frontendet :)

Sőt... emlékeim szerint tartottunk közösen prezentációt a smartyról, és hogy miért kéne beemeljük a stackünkbe ;) Ami ugye egy erősen absztrakciókkal dolgozik. Ez persze nem ma volt :)

Én egyébként tizenkét éve egy cégnél dolgozom, és a felsoroltak nem céljaink, vagy másképp oldjuk meg. A microservice-ekben nem hiszek, továbbá az automata tesztekben sem.
Mert nem láttál még olyan problémát, amit ezek megoldanak. De ez nem azt jelenti, hogy nem léteznek a problémák, amiket megoldanak. Jelenleg már az AWS lambda és a hasonló FaaS szolgáltatások mennek nagyon, nem is ok nélkül.

Azzal egyetértek, hogy egyre komplexebb elemeket emelünk be a programjainkba, amikkel jönnek azok hibái is, nem csak a megoldásai. De enélkül sok feladatot nem lehetne megoldani. Neked ott van a PHP nyelv, a DB stb. Komplexebb rendszerekben ugyanez van, csak nagyobb volumenben. Pl amint az írást is skáláznod kéne, vagy multisite rendszert építeni, meg lennél lőve a stackeddel, és kénytelen lennél elmozdulni komplexebb megoldások irányába. Manapság pedig nagyon megnőtt az ilyen rendszerek száma.

Az automata tesztek hasznosságát vitatni pedig kb az a szint, mint a korong alakú Föld mellett kardoskodni. Ez egy teljesen meghaladott alapvetés. A mikéntjén lehet vitatkozni, a szükségességét kérdőre vonni viszont értelmetlen. Nekünk pl van a buildben kb 35k automata tesztünk, ami nélkül nem merge-ölhetünk. Emellett vannak egyéb release verifikációs tesztek, amik közel két napig futnak. Ezeket hogy oldanád meg kézzel?
119

»Minden absztrakció egy

Hidvégi Gábor · Dec. 4. (K), 14.49
»Minden absztrakció egy hazugság, de legalábbis féligazság«
Hát... ez egy érdekes mondat :)
Tudod cáfolni?

És ezért az NFS haszontalan? Vagy a hálózati szolgáltatások bármelyike? Mit akarsz ezzel mondani?
Minél több a függőség és absztrakció, annál nagyobb az esélye, hogy a rendszer nem fog működni.

Attól még, hogy PHP-t is ismered, nem láttál még igazi backend rendszert, mert akkor nem írnál ilyet. A LAMP önmagában egy komolyabb rendszerben a frontend, nem a backend.
Attól még, hogy te egy ideje nagy cégnél/multinál dolgozol, nem jelenti azt, hogy minden cég akkora, és minden cégnek ugyanazok az igényei, mint a tiednek.

Én biztos vagyok benne, hogy az állításaid nagy része igaz, és bizonyos szint felett szükségesek különféle eszközök és technikák a hatékony fejlesztéshez. De évekkel ezelőtt feltettem a kérdést, amire máig kíváncsi vagyok, hogy mi az a szint, ahol OOP-t érdemes használni? Mert az látszik a korábban hozott példákból, hogy az OOP bevezetésével a projekt komplexitása növekszik, azaz a hatékonyság csökkenni fog. És ugyanígy kérdés, hogy azok az emlegetett eszközök vajon mikor lesznek szükségesek.
121

Tudod cáfolni? Inkább neked

inf3rno · Dec. 4. (K), 15.07
Tudod cáfolni?


Inkább neked kéne bizonyítanod, hogy igaz.
125

Tudod cáfolni?Előbb definiáld

BlaZe · Dec. 4. (K), 15.59
Tudod cáfolni?
Előbb definiáld mit jelent amit írtál, és bizonyítsd be, hogy szerinted miért van igazad. És ne ellenpéldákkal, hiszen szerinted egy általános érvényű tételt mondtál ki :)

Minél több a függőség és absztrakció, annál nagyobb az esélye, hogy a rendszer nem fog működni.
Akkor még egyszer:
És ezért az NFS haszontalan? Vagy a hálózati szolgáltatások bármelyike? Mit akarsz ezzel mondani?


Attól még, hogy te egy ideje nagy cégnél/multinál dolgozol, nem jelenti azt, hogy minden cég akkora, és minden cégnek ugyanazok az igényei, mint a tiednek.
Nem csak a nagy multik esetében változott meg a világ. A kis cégek is nagyon (sőt) mennek pl cloudba, mert sokkal olcsóbb. Manapság alacsony a belépési küszöbe a magas rendelkezésre állású, skálázható rendszereknek, egy egész iparág áll mögötte, ezért szinte mindenki abba az irányba megy. Tudok olyan webshopról itthon, ahol a fejlesztők magasról tettek a rendelkezésre állásra, és egész éjjel állt a rendszer, többtízmilliós bevételkiesést okozva. Ok, ez az egyik leganagyobb webshop itthon, de a példa jó. Ez igaz kicsiben is, kisebb számokkal. Nyilván van az a szint, ami a küszöb alatt van, de sokkal kevesebben vannak, mint gondolod.

De évekkel ezelőtt feltettem a kérdést, amire máig kíváncsi vagyok, hogy mi az a szint, ahol OOP-t érdemes használni?
Én nem tudok ilyen szintet mondani. Csak te gondolod ezt nehezebbnek, bonyolultabbnak stb. A valóságban ilyen nincs. Ahol nem OOP-t használnak, ott annak technikai okai vannak, nem bonyolultsági. Mivel manapság szinte minden mainstream eszköz az OOP támogatására van kihegyezve, jelenleg ez a leghatékonyabban használható paradigma. De legalábbis nincs lemaradva semmi mástól.
128

Én nem tudok ilyen szintet

inf3rno · Dec. 4. (K), 16.46
Én nem tudok ilyen szintet mondani. Csak te gondolod ezt nehezebbnek, bonyolultabbnak stb. A valóságban ilyen nincs. Ahol nem OOP-t használnak, ott annak technikai okai vannak, nem bonyolultsági. Mivel manapság szinte minden mainstream eszköz az OOP támogatására van kihegyezve, jelenleg ez a leghatékonyabban használható paradigma. De legalábbis nincs lemaradva semmi mástól.


Talán a legjobb példa erre, hogy még a js is oo nyelv, pedig annak idején csak arra hozták létre, hogy tudjad a menü háttérszínét változtatni mouseoverre. Nagyon alacsony a dolog belépési küszöbe, viszont ez is olyan, hogy én is tudok vésőt használni, mégsem lesz belőlem sosem fafaragó művész, mert ahhoz más kvalitások meg rengeteg gyakorlás kell. Az szerintem nem érv arra, hogy valamilyen eszköz haszontalan, hogy nem tudod egyből fél perc után mesteri szinten használni...
133

Absztrakció

Hidvégi Gábor · Dec. 7. (P), 23.40
Állítás: minden absztrakció hazugság, vagy legalábbis féligazság.

Bizonyítás:

Vegyük a következő nagyon egyszerű programkódot:
$valtozo = 'ertek';
print $valtozo;
$valtozo = 'ertek';
print $valtozo;
$valtozo = 'ertek';
print $valtozo;
Nagyon könnyű észrevenni az ismétlődést, ezért egy függvénybe teszem, amit háromszor egymás után meg fogok hívni. A függvény egy absztrakció.

A futás során az történik, hogy egy változónak értéket adunk, majd kinyomtatjuk a képernyőre.
function fuggveny() {
  $valtozo = 'ertek';
  print $valtozo;
}

fuggveny();
fuggveny();
fuggveny();
A program kimenete szempontjából ez ugyanazt fogja csinálni, de vajon belül ugyanaz történik?

Nem. A második programban egyrészt definiálunk egy függvényt, majd ezt háromszor meghívjuk. A függvény meghívásakor az történik, hogy a függvény címére ugrik a program, létrehoz egy ideiglenes memóriarekeszt, ahol a függvény változóit tárolhatjuk. Létrehozunk benne egy változót, annak értéket adunk, majd kinyomtatjuk. A függvény futásának befejezésekor a memóriarekesz tartalmát felszabadítjuk.

A második programnak tehát ugyanaz lesz a kimenete, mint az elsőé, de lassabban fog lefutni a plusz memóriaműveletek miatt, valamint több memóriát is foglal.

Az absztrakció azt jelenti, hogy elvonatkoztatok a valóságtól, és csak azt veszem figyelembe, amit fontosnak tartok. A valóságból kivonok egy kis részt, ezzel egyszerűsítem a problémát.

Esetünkben programozóként a következőképp gondolkodom: a függvény háromszori meghívásával a programom pontosan ugyanazt fogja csinálni és ugyanúgy fog működni, mintha a függvény tartalmát háromszor egymás után másolnám.

A valóság ezzel szemben az, hogy a függvény meghívásakor egyéb műveletek is történnek, ezért a program lassabb lesz.

A fenti gondolatmenetem tehát hamis, mert a második program nem ugyanúgy működik, mint az első. Az állításomat bizonyítottam.




Bizonyos szintig minden absztrakció szivárog. Ez nyilván ismerős kijelentés.

A számítástechnikában minden absztrakció teljesítményvesztéssel jár, bár ez a legtöbb esetben elhanyagolható. Emellett pedig magasabb logikai szinteken az absztrakciók nagyobb problémákat hoznak, egy jó példa erre az elosztott nyolc alapvető tévedése. Ezért hoztam fel az NFS-t.
134

Állítás: minden absztrakció

inf3rno · Dec. 8. (Szo), 03.38
Állítás: minden absztrakció hazugság, vagy legalábbis féligazság.


Nekem nem jött le, hogy a fenti hogy bizonyít ezzel kapcsolatban bármit. Mondjuk maga a kijelentés is elég fura. Azt eddig is tudtuk, hogy szivárognak az absztrakciók, de senkit nem érdekel, mert a gyakorlatban ennek nagyon ritkán van komoly hatása. És ha van, akkor foglalkozunk vele pl optimalizálásnál. Ha meg nincs, akkor meg bőven megéri őket használni. Gondolom te is hívsz függvényeket ahelyett, hogy lemásolnád az előző kódot csak hogy ugyanazt csinálja.

Ez is olyan dolog, amiben meg kell találni az egyensúlyt. Az egyik oldalról a DRY principle miatt érdemes szinte mindent újrahasznosítani, a másik oldalról meg a szivárgó absztrakciók miatt esetleg lehet sebességbeli veszteség, vagy hibák, vagy bármi egyéb. Általában az első szokott nyerni, de az sem örökérvényű szabály. Bár ritkán, de előfordulhat, hogy a DRY nem érvényesül, mert valami felülírja. Az meg hogy absztrakciókra van szükség egyértelműen következik abból, hogy újra kell hasznosítani a kódot.
139

Szintek

Hidvégi Gábor · Dec. 8. (Szo), 20.38
Hát, azért elég merész kijelentés az, hogy ritkán van az absztrakcióknak komoly hatása, elég csak a Spectre és a Meltdown bugra gondolni, az egyik javítása szélsőséges esetekben akár 50%-os teljesítményvesztést is okoz. De az is általános szakmai hiba, amikor a vastagkliens egy állapot megváltozásakor elindít n darab kérést, amiket így jóval több idő és erőforrás feldolgozni, mintha egy ment volna ki.

Nem az a kérdés, hogy kell-e őket használni vagy sem, hanem az, hogy hány szinten – minél kevesebb, annál jobb.
141

A spectre/meltdown továbbra

BlaZe · Dec. 8. (Szo), 22.21
A spectre/meltdown továbbra sem az absztrakció következménye, hanem az implementációé.

De az is általános szakmai hiba, amikor a vastagkliens egy állapot megváltozásakor elindít n darab kérést, amiket így jóval több idő és erőforrás feldolgozni, mintha egy ment volna ki.
Batching rulez :) De ennek mi köze van az abszrakciókhoz?

Nem az a kérdés, hogy kell-e őket használni vagy sem, hanem az, hogy hány szinten – minél kevesebb, annál jobb.
Nem. Ott kell használni, ahol kell használni. Néha a több a jobb.
160

Spectre

Hidvégi Gábor · hétfő, 19.34
Ha nem lenne a processzorokban cache és out-of-order execution, akkor lenne Spectre és Meltdown?

De ennek mi köze van az abszrakciókhoz?
Ha a programozó ismeri a korábban linkelt listát (a 4-es és 6-os pont nem érdekes itt), vagy használja a fejét, akkor eleve eszébe sem jut ilyet csinálni. De nem így van, tesztelés közben pedig, amikor helyi hálózaton vagy mockolt objektumokkal folyik a munka, sosem fog kiderülni, hogy mennyire rossz ötlet így dolgozni. Ez tipikus absztrakciós hiba, a fő terjesztője pedig a Facebook.
163

Ha nem lenne a

BlaZe · hétfő, 20.37
Ha nem lenne a processzorokban cache és out-of-order execution, akkor lenne Spectre és Meltdown?
Ezek részei az x86 architektúrának? Ha nem, akkor miért kell ebben a témában ezekről beszélgetni?

És továbbra sem értem mi köze a distributed computing fallacies-nek ahhoz, hogy egy hálózati kommunikáció szét tud esni, illetve tulajdonságai vannak. Itt a hozott példádban pont direktben látszik, hogy hálózati kommunikációval érünk el tartalmat, tehát nincs absztrakció mögé bújtatva. Itt ha valaki ezeket figyelmen kívül hagyja, az nem absztrakció miatt van, hanem tudatlanság miatt.

Mellesleg ez a lista nem csak WAN hálózatokra igaz. Managed networkön ugyanígy van. Mégha a költségek és a valószínűség kisebb is. Simán lehet pl split brain LAN hálón is.
143

Ha elfogadom, hogy a Spectre

inf3rno · Dec. 9. (V), 10.36
Ha elfogadom, hogy a Spectre és Meltdown hibás absztrakciók miatt jöttek létre (ami BlaZe szerint nem igaz), akkor is simán a ritka esetek közé tartoznának. Hiszen nap mint nap írunk függvényeket, osztályokat tucat számra, és mégsem valami sűrűn okoznak problémát. Ellenkező esetben a C nyelv annak idején meg sem született volna, mert annyira zavaró lett volna a függvényhívás, mint absztrakció mellékhatása, hogy senki sem használná. Még mindig lyukkártyákat használnánk, ha nagyon konzervatívan állunk az absztrakciókhoz. Bár maga a lyukkártya is absztrakció, hiszen az ismétlődő műveleteket szokták lyukkártyára tenni, hogy egyszerűen csak be tudják olvasni róla, ahelyett, hogy újra bevinnék kézzel. Visszamehetünk egészen Platónig, vagy az ősemberig, hiszen a szavak, amiket használunk is absztrakciók. Nekem nem tűnt úgy, amikor találkoztunk, hogy "fosod a szót", pedig hát ha tömören beszélsz valamiről, az is az absztrakciók használatát jelenti, és csak ritkán vezet félreértésekhez a kommunikációban. Ebből a szempontból elég kontrasztos, hogy bár használod az absztrakciókat napi szinten, mégis rossz dolognak tartod őket és minimálisra szeretnéd korlátozni a használatukat. Nem érzel itt némi önellentmondást?

Nem az a kérdés, hogy kell-e őket használni vagy sem, hanem az, hogy hány szinten – minél kevesebb, annál jobb.


Ez így két szempontból is hibás elképzelés. Egyrészt minél jobban a minimális mennyiségű absztrakcióra törekszel, annál nagyobb része a kódnak nem lesz újrahasznosítva, és a kódismétlés lerontja a karbantarthatóságot. Másrészt az absztrakciókat azért használjuk, hogy javítsuk a kód érthetőségét. Ha nem teszünk bele kellő mennyiségű absztrakciót a kódba, akkor nehezen érthető lesz, ami szintén lerontja a karbantarthatóságot. Abban egyetértünk, hogy a túl sok absztrakció is rossz, viszont az optimális mennyiség nem a minimális, hanem inkább az a tartomány, amiben az átlag fejlesztő jól érzi magát, és a segítségével könnyebben boldogul a kód fejlesztésével és karbantartásával. A túl sok absztrakció is lerontja a karbantarthatóságot, mert annyi osztály és metódus lesz, hogy egy csomó plusz lépés megtalálni, hogy hol van a kód, amit módosítanod kell. Az overengineering is ugyanígy a karbantarthatóságot rontja le, és a kód érthetőségét nehezíti, hogy mesterségesen, gyakorlatilag jó ok nélkül iktatnak bele új absztrakciós szinteket, csak azért, hogy bizonyítsák, hogy ők olvastak erről vagy arról a tervezési mintáról.

Az, hogy kinek mi az optimális mennyiségű absztrakció, elég egyedi. Egyesek szerint minél kisebb és egyszerűbb egy metódus, annál jobb, legalábbis olvastam ilyet jó néhány könyvben. Én azért ezt fenntartásokkal kezelem, és jobban szeretem csak a lényeges dolgokat metódus nevekkel ellátni. Persze ha egy metódus túl nagyra hízik, akkor az erős jelzés, hogy érdemes szétbontani több apróbbra, és azoknak szintén külön nevet adni. Én inkább ilyen módon fejlesztek, és ha nagyjából körvonalazva van, hogy milyen modell szerint csinálom a kódot, akkor onnantól hagyom, hogy a kód beszéljen magáért, és feleslegesen nem tépem szét ezer darabra. Legtöbbször ha egy kódrész nehezen érhető az nem azt jelenti, hogy ki kell szervezni több külön metódusba, amik elmagyarázzák, hogy mit csinál, hanem hogy rosszak a változónevek. Érdekes, hogy olvastam olyan (egyébként elég népszerű) könyvet, ami pedig a fentit propagálja.
145

Az x86 architektúra

BlaZe · Dec. 9. (V), 18.11
Az x86 architektúra definiálja, hogy hogyan működnek az ezen architektúrát használó processzorok. Ennek része az utasításkészlet, a regiszterek stb. De nem része hogy ez hogyan van implementálva, pontosan hogy néz ki a CPU pipeline, a cache subsystem, a branch prediction stb. Konkrétan erről az x86 semmit nem mond, azt se, hogy ezek léteznek. Ez a microarchitektúra területe, ami leginkább a programokban az implementációhoz hasonlítható. Ilyen microarchitektúra pl a Sandy Bridge, a Haswell stb.

Tehát nem létezik olyan absztrakció, amiről HG beszél. Meg hát by definition az absztrakció erről nem mondhatna semmit, ha létezne is rá absztrakció. Ez teljesen az implementáció belügye. És ez a sebezhetőség rendre benne van az elmúlt jópár generációjú prociban.

Azt mondjuk nem tudom, hogy a valóságban valaha ezt kihasználta-e bárki bármilyen támadáshoz. Amikor olvasgattam róla, akkor még nem volt ilyenről információ. Illetve annyira lassú és bonyolult is az adatszivárogtatás, hogy a gyakorlati felhasználhatósága limitált. Ez nem a rootkites Pistikék szintje :)

Szóval a probléma létező, de semmi köze az absztrakciók témájához.
150

Ok. Max titkosszolgálatok

inf3rno · Dec. 9. (V), 23.30
Ok. Max titkosszolgálatok használhatták ezek alapján. Még akár az is lehet, hogy az ő kérésükre került bele a processzorokba. Na nem konteozok tovább. :D
161

Lyukak

Hidvégi Gábor · hétfő, 20.02
Próbálom tovább egyszerűsíteni a dolgot, hogy érthető legyen, amit mondok.

Korábban idéztem a Wikipédiából: absztrakción "a lényeges tulajdonságok kiemelését és a lényegtelen tulajdonságok figyelmen kívül hagyását értik"

Tegyük fel, hogy van száz kockád, nevezzük ezt az Igazság állapotának. Eljön az absztrakció ideje, kiveszel belőlük egyet. Még mindig nagyon jól lehet játszani, mert így is rengeteg maradt, de ritka esetben, amikor összeszámolnád őket, akkor kiderül, hogy már csak kilencvenkilenc van ott.

Megint jön egy absztrakció, megint kiveszel egyet. És így tovább. Tehát minden ilyen alkalommal egy picike információ eltűnik a rendszerből.

Ebből a szempontból elég kontrasztos, hogy bár használod az absztrakciókat napi szinten, mégis rossz dolognak tartod őket és minimálisra szeretnéd korlátozni a használatukat. Nem érzel itt némi önellentmondást?
Nem. Nap mint nap szinte csak olyan website-okat látok, ahol olyan magas absztrakciós szinten dolgozott a készítője, hogy gyorsan kiderül: semmit nem ért semmihez és fogalma sincs semmiről. Sok értelmetlen rutinkönyvtár van, az egyik ilyen a jQuery, egyszerűen minden funkciója fölösleges, ha az ember tud programozni. Vagy az Angular/React a különböző transpilerekkel, virtual DOM-mal és egyéb hülyeségekkel. Ezek teljesen szükségtelen absztrakciók, ráadásul minden szempontból megnehezítik a munkát és rosszabbá teszik a végeredményt, mintha nélkülük dolgozna valaki, ismerve a szakmát.
167

Tegyük fel, hogy van száz

BlaZe · hétfő, 22.38
Tegyük fel, hogy van száz kockád, nevezzük ezt az Igazság állapotának. Eljön az absztrakció ideje, kiveszel belőlük egyet. Még mindig nagyon jól lehet játszani, mert így is rengeteg maradt, de ritka esetben, amikor összeszámolnád őket, akkor kiderül, hogy már csak kilencvenkilenc van ott.
Ebbe a kockás példába kicsit beleszédültem, de végül azt hiszem értem mit akarsz mondani :)

Megint jön egy absztrakció, megint kiveszel egyet. És így tovább. Tehát minden ilyen alkalommal egy picike információ eltűnik a rendszerből.
Értjük mit jelent az absztrakció. Viszont nem tűnik el a rendszerből információ. Csak adott szinten nem jelenik meg. Ez nem kis különbség.

Sok értelmetlen rutinkönyvtár van, az egyik ilyen a jQuery
Azért emlékeim szerint a jQuery konkrétan anno megreformálta a dinamikus weboldalakat. Annyira azért nem tűnik értelmetlen dolognak.

Ezek teljesen szükségtelen absztrakciók, ráadásul minden szempontból megnehezítik a munkát és rosszabbá teszik a végeredményt, mintha nélkülük dolgozna valaki, ismerve a szakmát.
Ha így lenne, senki nem használná őket. De használják, nem is kevesen. Szerintem inkább az van, hogy egyszerűen ignorálsz tipikus use case-eket saját példád alapján. Itt megint loopba kerültünk :) Industry standardek, ember pótlásának költsége, támogatás költsége, time to market stb.
144

Olvasgattam egy kicsit a

inf3rno · Dec. 9. (V), 16.29
Olvasgattam egy kicsit a témában, és azt hiszem ez fogja meg leginkább a dolog lényegét:

I agree with Joel’s statement that all non-trivial abstractions are leaky in the sense that, by their very nature, abstractions hide details that are considered less important at that particular level. An abstraction has “leaked” the details that it abstracted away.[1]

I disagree, however, with your statement that all abstractions are “failed” abstractions, mostly because you’ve not defined failure. You’ve even provided a pragmatic point-of-view where abstractions are not failures (usability, and ease of understanding).

Basically, if an abstraction hides the details that we are concerned with, then it is our job as developers to choose a different (less abstract) abstraction. If you are concerned with query timing and LINQ doesn’t give you fine-grained control over that, then LINQ is the wrong abstraction to use.

Abstractions only fail when they are wrong tool for the job, but in that case it’s the developer that has failed.

[1] Of course, it is possible to prove that any given abstraction has a one-to-one correlation with what it is abstracting, thus making it a “leakless” abstraction. For instance, one might be able to prove that the SQL grammar is fully covered by the LINQ grammar. But in Joel’s argument, I’ll assume he considers such an abstraction to fall into the “trivial” category.



https://discourse.codinghorror.com/t/all-abstractions-are-failed-abstractions/160/4
135

Mi volt a célod ezzel a hozzászólással?

T.G · Dec. 8. (Szo), 10.27
Most komolyan, azt írod, hogy szerinted érdemes az első programkódot használni a másodikkal szemben?

Szerintem ez kínosan szakmaiatlan. Érvelni amellett, hogy ne használjunk függvénykiemelést? Fájt olvasni.

Ha a junior kolléga érvelne az első verzió mellett, akkor kapna egy rohadt nagy lecseszést. Ha esetleg egy senior kolléga érvelne e mellett, akkor azonnal jelezném a főnökömnek, hogy vagy ő vagy én távozok a cégtől.

Most komolyan, hozol egy példát, amivel te sem értesz egyet, csak azért, hogy cáfoljál valamit, amit senki nem állított? Ennek mi értelme?

Nem hiszek benne, hogy tőled valaha is kaphatunk érdemi kódot, de azért szeretnélek emlékeztetni, hogy évekkel ezelőtt, már sokszor ígértél olyat, hogy bemutatsz egy valós keretrendszert (?) vagy mit is, ahol megnézhető, hogy az általad preferált módszertan, rendszer, akármi nagy projektek esetén is működik. Üres ígéreteken kívül ebben a témában még semmit nem kaptunk tőled.

De, hogy érdemben is reagáljak a hozzászólásra. A refaktorálás lényege, hogy olvashatóbb, jobban kezelhetőbb kód szülessen ugyanolyan kimenettel. Ezt hasznosabbnak tekintjük azzal szemben, hogy egy függvény létrehozása, többszöri meghívása mekkora plusz terhet jelent a processzornak. Nem csak a gépeknek, hanem embereknek is írjuk a kódunkat, emiatt az olvashatóság kiemelten fontos. Így teljes egyértelmű, hogy a második programkód jobb, mint az első.
138

Nem

Hidvégi Gábor · Dec. 8. (Szo), 20.26
Úgy látom, szövegértésből nem vagy erős. Az általános iskola arra van ->

A leírtak nem arról szólnak, hogy melyik programkódot kell választani.
158

Szövegértés

Pepita · hétfő, 17.09
Egyre többen vannak, akiknek szerinted ez gondot okoz - természetesen rajtad kívül.
Érdemes lenne picit gondolkodni rajta, hogy nem lehet-e, hogy fordítva van.
136

Amit itt "bebizonyítottál",

BlaZe · Dec. 8. (Szo), 12.42
Amit itt "bebizonyítottál", az nem más, mint hogy az absztrakció semmit nem mond a megvalósításról. Ami ugye a kb definíciója. De te azt állítottad, hogy az absztrakció hazugság. Én meg azt állítom, hogy ez egy értelmetlen állítás. Hazugság akkor lenne, ha nem azt csinálná, hogy print 'ertek', amikor azt hirdeti magáról. De speciel itt az történik, amit a függvény ígér.

Abba most ne menjünk bele, hogy normális futtatókörnyezetben nem az történik, amit írtál. De értem, amire céloztál.

Esetünkben programozóként a következőképp gondolkodom: a függvény háromszori meghívásával a programom pontosan ugyanazt fogja csinálni és ugyanúgy fog működni, mintha a függvény tartalmát háromszor egymás után másolnám.
Ezt programozóként kikérem magamnak :)

A fenti gondolatmenetem tehát hamis, mert a második program nem ugyanúgy működik, mint az első. Az állításomat bizonyítottam.
Viszont a kimenete helyes...

A számítástechnikában minden absztrakció teljesítményvesztéssel jár
Ez így ebben a formában nem igaz. Ezt az állításod már én is többször megcáfoltam.

Emellett pedig magasabb logikai szinteken az absztrakciók nagyobb problémákat hoznak, egy jó példa erre az elosztott nyolc alapvető tévedése. Ezért hoztam fel az NFS-t.
Ez így van. Ezért ez megint egy jó példa arra, hogy miért érdemes absztrakciókat használni: mert tudunk expertek tudására támaszkodni. Ettől még persze kell érteni dolgokat. Úgyhogy eljutottunk oda, hogy
kimondhassuk: ez egyáltalán nem egy szögegyszerű szakma...

Szóval ami a féligazság, az az, amit te közvetítesz itt, miszerint az absztrakció rossz. Ráadásul teszed ezt olyan környezetben dolgozva, ami gyakorlatilag az egyik legmagasabb absztrakciós szinten létezik, így még kicsit bort is iszol és vizet is prédikálsz. Ami a te dolgod, csak megint evidenciák puffogtatásával próbálsz meggyőzni nálad adott témában (OOP, automata tesztelés, elosztott rendszerek, futtatókörnyezet stb) tapasztaltabb kollégákat, hiszen ezekkel te bevallottan nem dolgoztál.
137

Szóval ami a féligazság, az

Hidvégi Gábor · Dec. 8. (Szo), 20.22
Szóval ami a féligazság, az az, amit te közvetítesz itt, miszerint az absztrakció rossz.
Ez egyszerűen nem igaz, én ilyet soha nem állítottam. Mindig is a(z egymásra épülő) túl sok absztrakciós szinttel volt gondom.

Az absztrakció wikipédiabeli megfogalmazása így hangzik: "a lényeges és lényegtelen tulajdonságok elválasztását, a lényeges tulajdonságok kiemelését és a lényegtelen tulajdonságok figyelmen kívül hagyását értik rajta"

Tehát nem a teljes igazsággal dolgozik, hanem az absztrakciót végző azt mondja, hogy a számára lényegtelen dolgokkal nem foglalkozik, úgy veszi, mintha azok nem lennének ott. Tehát az absztrakció féligazság vagy hazugság. A wikipédiás példát továbbgondolva ez olyan, mintha kijelentenéd, hogy minden madár magvakat eszik, de amikor találkozol a Darwin pintyek egy alfajával, hazaviszed kalitkában, de megdöglik, mert utólag kiderül, hogy épp vérrel táplálkozik. Hibás volt az absztrakciód.

»A számítástechnikában minden absztrakció teljesítményvesztéssel jár«
Ez így ebben a formában nem igaz. Ezt az állításod már én is többször megcáfoltam.
Elég, ha egy cáfolatot hozol, mert én erre nem emlékszem.

hiszen ezekkel te bevallottan nem dolgoztál
Ez sem igaz, mert dolgoztam OOP-vel és automata teszteléssel is, de nem váltották be a hozzájuk fűzött reményeket. Elosztott rendszerekkel csak kicsiben, mert eddig erre volt szükség. A futtatókörnyezeten nem tudom, mit értesz.
140

Ez egyszerűen nem igaz, én

BlaZe · Dec. 8. (Szo), 22.18
Ez egyszerűen nem igaz, én ilyet soha nem állítottam. Mindig is a(z egymásra épülő) túl sok absztrakciós szinttel volt gondom.
vs
Tehát az absztrakció féligazság vagy hazugság

Amellett, hogy utóbbi egy értelmetlen kijelentés, nehéz belemagyarázni, hogy nem gondolod rossznak az egészet. Illetve mindig csak negatívan írsz a témáról. Emiatt alakul ki az a kép az emberben a véleményedről, amit fentebb írtam. És ezért frusztráló már a téma a többségnek.

Az egymásra épülő absztrakciós szintek meg sok esetben szükségesek. Nem ez a baj, hanem a céltalan halmozásuk. De akkor itt ezt a témát szerintem örökre lezárhatjuk, mert ebben mindenki egyetért.

minden madár magvakat eszik, de amikor találkozol a Darwin pintyek egy alfajával, hazaviszed kalitkában, de megdöglik, mert utólag kiderül, hogy épp vérrel táplálkozik. Hibás volt az absztrakciód.
Vagyis? Hülye voltam. Ez mi mellett, vagy mi ellen érv?

Elég, ha egy cáfolatot hozol, mert én erre nem emlékszem.
Hozok párat:
1) Method inlining (csak a kódban létezik az absztrakció, runtimeban nem)
2) Többszintű öröklődés: több absztrakciós szintre bontottad le az osztályodat, de a típus ismert, ezért futásidőben ebből semmit nem veszel észre, statikus hívások vannak virtuális helyett.
3) A függvények/subrutinok nélküli spagetti kód memóriaigénye végtelen, hiszen minden egyes utasítás külön memória területet igényel, az ismétlődőek is.
4) CPU cache (és úgy általában a cache-ek): a CPU szemszögéből a memóriaművelet egy absztrakció, ami elfed egy nagyon komplex rendszert, tehát az állításod szerint ez teljesítményromláshoz kéne vezessen, de ennek az ellenkezője az igaz: jellemzően masszív teljesítménynövekedéshez vezet. És persze leakel, hiszen a "memóriaműveletek" nem garantálják a láthatóságot a CPU-k között, arról programozóként neked explicit módon kell gondoskodnod. (Ez az ára a jó teljesítménynek)

Ez sem igaz, mert dolgoztam OOP-vel és automata teszteléssel is, de nem váltották be a hozzájuk fűzött reményeket
Eddig ez nem jött át, és nem is ezt mondtad. A hozott példáid és ellenérveid alapján nagyon az az ember érzése, hogy egyikkel se találkoztál a valóságban. Csak valamivel, amire valaki azt mondta, hogy OOP, vagy hogy rendes automata tesztelés.

Az OOP-ről lehet hitvitát folytatni. Van ahol az kell, van ahol nem. Az automata tesztelés viszont egy annyira alapvető eleme a programozásnak, hogy ennek a hasznosságát kétségbe vonni - egy elvileg vezető programozó ember által - konkrétan az ijesztő kategória. Védőháló nélküli kötéltánc.

A futtatókörnyezeten a HW/OS/(VM/)stb-t értettem. Nyilván ez kell minden programozáshoz :) De amit ebből rendszeresen kiemelsz a példáidat alátámasztandó (lásd előző hozzászólásod), az már rég nem úgy működik, egy része meg régen sem úgy működött. Legalábbis amíg rendszerközeli dolgokról beszélünk. Afölött meg úgyis mindegy, hiszen egy PHP/JS amúgyis rémálom, ha teljesítményről van szó, a függvényhívás a legkevesebb... Bár a modern JS motorok ebben már elvileg elég jók.
162

Amellett, hogy utóbbi egy

Hidvégi Gábor · hétfő, 20.36
Amellett, hogy utóbbi egy értelmetlen kijelentés, nehéz belemagyarázni, hogy nem gondolod rossznak az egészet.
Az absztrakció szükséges, hisz a számítógép végül is csak nullákkal és egyekkel dolgozik.

Mint írtam korábban, az általam elemzett kódokból számomra egyértelmű, hogy rengeteg programozó túl sok absztrakciós szinttel dolgozik. Ennek a következménye a sok lassú program és az, hogy elképzelésük sincs, mi is történik igazából.

Példáid:
1, akkor ez nem is absztrakció,
2, izgalmas volna megnézni, hogy ha van egy programod procedurálisan megvalósítva, valamint egy másik OOP-vel, mekkora lesz a lefordított kód mérete, valamint a futásidő és memóriahasználat is érdekes,
3, ez egy érdekes felvetés, még gondolkodom rajta,
4, pont ezen gondolkodtam az este, hogy a hardverben a cache memória vagy a RAM az absztrakció; a tudásom itt némileg hiányos, mert ilyen mélyre még nem mentem le, úgyhogy itt tévedhetek.

A következőre jutottam: a modern processzorokban a RAM az absztrakció, mivel a CPU közvetlenül a cache-sel dolgozik. A memóriaalrendszer felelős a cache és a RAM közti másolásokért.

Emiatt ha egymás mellé teszel két processzort, az egyikben van cache, a másikban nincs, akkor a kettő nem egyezik meg, nem hasonlíthatod őket össze, mert az egyik alma, a másik körte.

Az absztrakciós szivárgás a cache-sel rendelkező CPU-kban akkor jelentkezik, amikor a gyorstárban nem található meg a szükséges adat, ezért a RAM-ból be kell olvasni a megfelelő lapot.

Emiatt a 4-es példád sem jó.
166

1, akkor ez nem is

BlaZe · hétfő, 22.18
1, akkor ez nem is absztrakció,

Hogyne lenne. Ott a függvény. Csak ki van optimalizálva.

2, izgalmas volna megnézni, hogy ha van egy programod procedurálisan megvalósítva, valamint egy másik OOP-vel, mekkora lesz a lefordított kód mérete, valamint a futásidő és memóriahasználat is érdekes,
Valóban izgalmas lenne, de ennek semmi köze ahhoz, amit írtam. Nem az OOP vs nem OOP volt kiemelve, hanem a többszintű öröklődésről (ami absztrakciók sora) állítottam valamit.

Amúgy ha már előkerült, nem az OOP vs nem OOP miatt lesz bármi különbség a méretben, vagy teljesítményben, hanem amiatt, ahogy használva van az OOP. Egy objektum nem más, mint egy struct és egy hozzárendelt procedurális kód. Ha hozzáveszed még a polimorfizmust, akkor megjelennek a virtuális hívások, vagyis a konkrét megvalósítás meghívásához fel kell oldani egy címet. Ilyen procedurális kódban is létezik, pl egy switch is hasonlóan működik (ha folytonos range-ből vannak az eseteid, egy jump table-lel 2 lépésből találja meg a konkrét lefuttatandó ágat). Szóval ez a struct+procedurális kód még kiegészülhet egyéb, implementáció specifikus dolgokkal, amik szükségesek pl szinkronizációhoz, GC-hez (bár a GC és az OOP nem jár kéz a kézben) stb. De ezek egyike se kötelező eleme az OOP-nek. Pl a 64 bites Oracle/OpenJDK JVM-ben 16 byte a minimális mérete egy objektumnak. Ennyi a sallang. Viszont nem (illetve nem mindenhol) kell menedzseljen free listeket a memory allocation miatt, abból kisebb waste keletkezik, mint egy default malloc implementációból. Szóval nehéz ezt összehasonlítani, mert implementációkat tudsz összehasonlítani az optimalizációjukkal és specifikumaikkal, nem pedig elméletet. És jellemzően managed envet nem managed envvel. Na mind1, a téma tulajdonképpen nem ez volt :)

3, ez egy érdekes felvetés, még gondolkodom rajta,
Szerintem nem sok gondolkodnivaló van rajta :) Amit nem újrafelhasználsz, azt le kell újra írni. Az meg memóriát foglal, ezért egy tetszőleges ideig futó program elméleti memóriaégénye végtelen.

Ha már a teljesítmény szóba kerül, itt van is egy trade-off. 2 fő ok miatt szoktak a compilerek inline-ozni. Az egyik, hogy megspórolják a minimális stack használatot tipikus esetben (mai procikon ez a return address és sok esetben a base pointer elmentése), a visszatéréskori ugrást és a hibás spekulációt. Ez utóbbi a komoly költség, nem a stack használata. A másik dolog pedig, hogy ha "egyenesen" folytatódik a program futása, vagyis ha az utasítások egymást követik szekvenciálisan a memóriában, akkor nem kell megfizetni annak a költségét, hogy esetleg a main memoryból elővarázsoljuk a következő utasítást egy random címre ugrás után. Erre nagyon durván optimalizálnak is a fordítók egyébként. A JVM JIT-je pl ha van egy nagyon magas százalékban végrehajtott ág (pl bimorphic, multimorphic hívás esetén), akkor a tipikus ágat "egyenesen" képes inline-ozni egy type check után. Vagyis ilyen esetekben a kód szekvenciálisan hajtódik végre tipikusan az L1 instruction cacheből. Ilyet csinálnak amúgy az AOT compilerek is. És mivel trade-off, itt számít egy metódus mérete pl, akármit nem fog a fordító inline-ozni, mert baromi nagyra növelné a lefordított natív kód méretét, ezáltal a memóriahasználatot. Illetve így gyakorlatilag akár az iCache-t is simán felülírná a szekvenciális inline-olt utasításokkal, ami adna egy nagy pofont az egésznek. Ezért a JVM-nek be tudsz állítani pl egy thresholdot, hogy mekkora (bytecode) méretű metódust inline-ozhat maximum. Ez pl egy érv a kisebb metódusok mellett, ha fastpathon vannak használva. Na, megint elkanyarodtam kicsit :) A lényeg, hogy a spagetti kód nem mindig nyerő teljesítmény szempontból, hiába látszik úgy.

Se nem a RAM, se nem a cache az absztrakció. A memóriaművelet az absztrakció. Amögött transzparansen meg van oldva, hogy cache, vagy main memory access (is) történik. A te programod erről semmit nem tud. Ezért írtam korábban, hogy nincs cache absztrakció az architektúrában. A procin belül persze van.

De nem csak CPU cache esetében van így. Az oprendszer disk cache ugyanez. Vagy az adatbázis előtti L1 és L2 cache ORM-ek esetében. Mind transzparens, mindhez szükséges absztrakció, és mind jellemzően komoly teljesítményjavuláshoz vezet.

Az egész cache by definition ugye azt jelenti, hogy javítjuk a data locality-t vagyis minél közelebb próbáljuk tartani az adatot a kódhoz. Hogy ne növeljük a kód komplexitását, absztrakció mögé rejtjük. Tehát az eredeti adatforrás (main memory, DB, disk) helyett először egy cache-ből próbáljuk elővenni az adatot, majd ha miss volt, egy következőből stb. Emiatt jó példa. Sosem cache-t címzel, csak onnan próbálja meg először feloldani.

Az absztrakciós szivárgás a cache-sel rendelkező CPU-kban akkor jelentkezik, amikor a gyorstárban nem található meg a szükséges adat, ezért a RAM-ból be kell olvasni a megfelelő lapot.
Ez igaz, ezért kell ismerni a hw-t, amin futni fog a programod, ha maximális teljesítményre gyúrsz. De ez nem jelenti azt, hogy nem jó a példám, hiszen a cache jelenléte egy absztrakció mögött javítja a teljesítményt.

Emiatt ha egymás mellé teszel két processzort, az egyikben van cache, a másikban nincs, akkor a kettő nem egyezik meg, nem hasonlíthatod őket össze, mert az egyik alma, a másik körte.
Főleg, mert ezek más dolgokban is teljesen eltérnek. Viszont egyazon procin meg tudod nézni, hogy ha folyamatosan main memoryhoz kell forduljál, akkor milyen az access time, és milyen, ha L1, L2 cacheből dolgozol.
169

Az absztrakció szükséges,

inf3rno · kedd, 04.49
Az absztrakció szükséges, hisz a számítógép végül is csak nullákkal és egyekkel dolgozik.

Mint írtam korábban, az általam elemzett kódokból számomra egyértelmű, hogy rengeteg programozó túl sok absztrakciós szinttel dolgozik. Ennek a következménye a sok lassú program és az, hogy elképzelésük sincs, mi is történik igazából.


Húha, sikerült idáig eljutni onnan, hogy az absztrakció rossz és tűzzel vassal irtani kell? :D
142

Jó lenne már eldönteni, hogy

inf3rno · Dec. 9. (V), 09.55
Jó lenne már eldönteni, hogy mit állítasz. Bár nyilván így nehezebb megcáfolni, hogy egyik pillanatban állítasz valamit, a másikban meg egy totál más dolgot. Esetleg úgy csinálod, mint én, hogy vita közben gondolod át a témát? Az valóban hasznos lenne, de általában zavarja a vita partnereket, és nem tűnik úgy, hogy nagyon gyorsan haladnál vele...

Ha tényleg csak a túl sok absztrakciós szinttel van problémád, akkor jó lenne valami példát látni, hogy szerinted mi a túl kevés, túl sok és optimális. Mi sem szeretjük az overengineering-et, de részben stílus függő is, hogy mit tekintünk annak. Valaki a sok apró függvényt/metódust szereti beszélő nevekkel, én inkább valami közepes méretet preferálok, ahol nincs az "i = i + 1" is megmagyarázva. A helyesen használt absztrakció is ezt jelentené, hogy kiemeljük, hogy mit csinál az adott kód, mint lényeges részt, és beleírjuk az osztály, metódus, változó nevébe, hogy könnyebben legyen követhető. Azt, hogy hogyan csinálja, meg csak olyan szintig magyarázzuk meg, amennyire szükséges. Ebben is vannak egyéni dolgok, mert valaki csak úgy érti meg, ha szájbarágósan magyarázod, valaki meg elég jól tudja követni anélkül is.
159

+1

Pepita · hétfő, 17.15
Jó lenne már eldönteni, hogy mit állítasz
Ott a pont. :-D

Én emiatt szoktam javasolni Gábornak, hogy politizáljon, mert azon a területen ez egy rendkívül hasznos tulajdonság manapság. ;)
Lehetetlen cáfolni, mert akkor csak az derül ki, hogy szövegértési problémáid vannak. :)

Te készítetted a popcorn-t, én már mind megettem...
164

Nem

Hidvégi Gábor · hétfő, 20.41
Érdemes visszaolvasni a hozzászólásaimat, teljesen konzekvensen a túl sok absztrakció ellen érvelek, és nem az absztrakciók ellen.
165

Mi a konkluzió?

T.G · hétfő, 21.34
Ha valamiből túl sok van az nem jó. Ez elég triviálisnak tűnik. :) Az a jó ebben az állításban, hogy nem kell definiálnunk a valamit, mert bármit helyettesítünk oda, akkor is igaz állítás marad. De ezzel mit akarsz mondani?
168

Viszont érdemes lenne

BlaZe · hétfő, 22.42
Viszont érdemes lenne belátnod, hogy a túl sok helyett nem a minél kevesebb a cél, hanem a helyes középút megtalálása. A kód legyen jól olvasható, karbantartható, tesztelhető. Ezen kritérimoknak se a "túl sok", se a "minél kevesebb" nem felel meg.

Illetve hogy egy random kódbázist tekintve simán lehet olyan absztrakció, amit te szükségtelennek találsz belepillantás után, de fontos oka van, hogy bekerült. Triviális példa a tesztelhetőség, amit csak a prod kódot böngészve nem biztos, hogy megtalálsz.
170

Triviális példa a

inf3rno · kedd, 04.59
Triviális példa a tesztelhetőség, amit csak a prod kódot böngészve nem biztos, hogy megtalálsz.


+1, én is nemrég tettem be egy külön metódust valahova, csak hogy jobban tesztelhető legyen a kód, és ne "uncaught exception"-ből kelljen előrántani, hogy mit dob bizonyos aszinkron hibáknál. A mocha fejlesztésénél sajnos nem gondoltak rá, hogy ilyesmire is lehessen tesztelni, és elég ocsmány lenne hozzátákolni.
113

Építsünk rá egy

inf3rno · Dec. 2. (V), 17.33
Építsünk rá egy szolgáltatást! Az csak addig fog működni, amíg a hálózat is elérhető. Minél több ilyenből áll össze valami, annál nagyobb valószínűséggel fog kiesni belőle valami. És annál nagyobb eséllyel fognak rá betörni, mert a készítői nem látják át, melyik absztrakció hol szivárog.


Gondolom ezek szerint egy spagetti kódos oldal minden szempontból jobb, mert annál nincsenek absztrakciók. Vicc az egész. :D
84

Kombináció

Hidvégi Gábor · Nov. 28. (Sze), 09.54
Vannak alternatív megoldások és vannak kombinációsok, és ezeket bárhogy keverheted egymással.

Fentebb linkeltem, hogy PHP-ban a típusos paraméterek a bevezetésükkor gondot okoztak bizonyos esetekben, emiatt a programban új interface-eket kellett betenni, hogy működjön. Később javították ezt a hibát, de fejben kellett továbbra is tartani, hogy az adott program melyik verzión fut, mert ha régin is, akkor ott továbbra is interface-ezni kellett, ami bonyolítja a helyzetet.

Ha már olyan egyszerű példát hozol, mint a for ciklus, meg lehetett volna említeni a manapság divatos funkcionális array.forEach()-et is, ami első ránézésre ekvivalens vele, másodikra pedig kiderül, hogy ha a futási környezet nincs rá optimalizálva, akkor lassabb jóval a natív alternatíváinál.
89

Fentebb linkeltem, hogy

BlaZe · Nov. 28. (Sze), 11.48
Fentebb linkeltem, hogy PHP-ban a típusos paraméterek a bevezetésükkor gondot okoztak bizonyos esetekben, emiatt a programban új interface-eket kellett betenni, hogy működjön. Később javították ezt a hibát, de fejben kellett továbbra is tartani, hogy az adott program melyik verzión fut, mert ha régin is, akkor ott továbbra is interface-ezni kellett, ami bonyolítja a helyzetet.
Ha a fentebb bemutatott példádra gondolsz, arra mások már elmondták, hogy a példa volt rossz. Ha arra, hogy PHP-ban nem volt method overloading, most meg már van (ha van), az semmit nem bizonyít azon kívül, hogy a PHP egy átgondolatlan nyelv.

Ha már olyan egyszerű példát hozol, mint a for ciklus, meg lehetett volna említeni a manapság divatos funkcionális array.forEach()-et is, ami első ránézésre ekvivalens vele, másodikra pedig kiderül, hogy ha a futási környezet nincs rá optimalizálva, akkor lassabb jóval a natív alternatíváinál.
Ami semmit nem mond semmilyen hibáról. Erre valók a senior emberek egy projecten, hogy a mélyebb dolgokat értsék. Pl értsék, hogy az általad hozott forEach alapjaiban tök más, mint egy for ciklus és komoly előnyökkel bír vele szemben (pl nincs side-effect). Illetve hogy ha nem csak a ciklust magát nézed, hanem a benne lévő ciklusmagot is, akkor is igaz-e az a megállapítás, hogy jelentősen lassabb. Illetve hogy manapság is igaz-e, hogy annyival lassabb. Illetve hogy ha jelentősen lassabb is, akkor a valóságban számít-e ez valamit, vagy egyéb előnyei miatt bevállalható-e ez a lassulás.

Szóval ez a hozott aspektus tök más, mint amiről szó volt. És ha csak ezt az aspektust vizsgálja az ember, az szűklátókörűség, ilyen alapokon nem lehet helyes döntéseket hozni. Erre lehet mondani, hogy akkor vegyük el az egyéb előnyökkel járó választás lehetőségét a fejlesztőtől, hiszen ő buta. De nem buta, max tanulnia kell.
106

Ha arra, hogy PHP-ban nem

Hidvégi Gábor · Dec. 2. (V), 12.59
Ha arra, hogy PHP-ban nem volt method overloading, most meg már van (ha van), az semmit nem bizonyít azon kívül, hogy a PHP egy átgondolatlan nyelv.
Ez félrebeszélés, teljesen lényegtelen, hogy mennyire átgondolt egy nyelv. Behoztak egy alternatív featúrát, ami bizonyos módon működik, és bizonyos módon lehet használni. Aztán kijavítják, és másképp fog működni. Aki használja aktívan, annak fejben kell tartania ezeket. Aki nem használja, az pedig zéró befektetéssel dolgozik tovább ugyanúgy, mint addig.

Erre valók a senior emberek egy projecten, hogy a mélyebb dolgokat értsék.
Értem, tehát egy egyszerű ciklushoz is már senior emberek kellenek, hogy értsék. És szerinted a JS programozók mekkora százaléka senior programozó, és nem csak a stackoverflow-ról copy-paste-eli össze a munkáját?

Eleve, ha zavarnak a mellékhatások, akkor sima for ciklusból is lehet függvényeket hívni, tehát ott volt választási lehetőség, forEach esetében pedig nincs. Nem tudom, én sosem találkoztam mellékhatással (persze ez nem jelenti azt, hogy nincs, de húsz év alatt azért megír az ember pár for ciklust). Másrészt tíz éve nincs igazán fejlődés a processzorok sebességében, a memóriák elérési ideje és sebessége pedig jóval kisebb mértékben nőtt, mint a CPU-ké. Nyilván lehet optimalizálgatni a futtatórendszert (fordító, JS motor), akkor meg ott fizeted meg az árát. Ma, ha elindítasz egy böngészőt üres lappal, 150-200 megabájt memóriát kell hozzá lefoglalni, és egy átlag weboldal is megeszik száz körül. És mindezt (szimbolikusan) egy forEach ciklus kedvéért.

akkor vegyük el az egyéb előnyökkel járó választás lehetőségét a fejlesztőtől, hiszen ő buta. De nem buta, max tanulnia kell.
A fejlesztő buta. Ha nem lenne az, akkor nem kéne állandóan hibát javítgatni. Vagy nálatok sosincs bug, minden frissítésnél csak az új featúrák kerülnek a kódba?
110

Ez félrebeszélés, teljesen

BlaZe · Dec. 2. (V), 16.12
Ez félrebeszélés, teljesen lényegtelen, hogy mennyire átgondolt egy nyelv. Behoztak egy alternatív featúrát, ami bizonyos módon működik, és bizonyos módon lehet használni. Aztán kijavítják, és másképp fog működni
Mert átgondolatlanul beemeltek egy eredetileg környezetidegen featuret. És igen, tudni kell hogy működik. Van mögötte komoly elmélet is, inf3rno utalt is rá. Speciel Barbara Liskov nem véletlenül Turing díjas :) Egyebek mellett.

Most az eredeti kijelentésed ellen érvelsz, miszerint a webfejlesztés szög egyszerű. És hozod sorban az ellenpéldákat :)

Értem, tehát egy egyszerű ciklushoz is már senior emberek kellenek, hogy értsék.
Ki mondta neked, hogy a forEach egy egyszerű ciklus?

Nem tudom, én sosem találkoztam mellékhatással
Ez úgy helyes, hogy nem vetted észre. Vagy úgy, hogy már elfelejtetted :)

Másrészt tíz éve nincs igazán fejlődés a processzorok sebességében, a memóriák elérési ideje és sebessége pedig jóval kisebb mértékben nőtt, mint a CPU-ké.
Ez azért így ebben a formában egyáltalán nem igaz. Single threaded performanceban is volt komoly fejlődés az elmúlt 10 évben. Multi-threaded teljesítményben meg pláne.

a memóriák elérési ideje és sebessége pedig jóval kisebb mértékben nőtt, mint a CPU-ké
Szóval akkor a CPU-k teljesítménye mégis növekedett :) Itt jön be az, hogy érteni kell ezt a szakmát, és hogy hogy működik a gép. Ha érted hogy működik a cache subsystem, a branch predictorok stb, akkor sokszoros teljesítményt tudsz kihozni egy modern hardware-ből. És nem utolsó sorban alkalmazni tudod ezt a tudást akár elosztott rendszereken is.

A fejlesztő buta. Ha nem lenne az, akkor nem kéne állandóan hibát javítgatni. Vagy nálatok sosincs bug, minden frissítésnél csak az új featúrák kerülnek a kódba?
Én nem sok buta fejlesztővel dolgoztam az elmúlt években. Sőt, eggyel sem. Úgyhogy ezt a nevükben kikérném :) A buta és a nem tud végtelen komplexitását átlátni az nem ugyanazt jelenti. A géped is csak véges méretű állapotteret képes kezelni. De megint oda lyukadtunk ki, hogy ez a szakma nehéz :) És a tudás a kulcs a komplex rendszerek megértéséhez és kezeléséhez.
118

Mert átgondolatlanul

Hidvégi Gábor · Dec. 4. (K), 14.30
Mert átgondolatlanul beemeltek egy eredetileg környezetidegen featuret.
Te is hoztál fentebb Java-s példát a hibás nyelvi elemre, tehát ők sem szentek.

Most az eredeti kijelentésed ellen érvelsz, miszerint a webfejlesztés szög egyszerű.
Félreértesz, mert ez az egész szál pont az ellentétéről szól. Az volt a kiinduló kérdés, hogy lehet-e PHP4 tudással ma bármilyen szolgáltatást elkészíteni? És mellé teszem, hogy eszközkészlettel.

inf3rno 51-es hozzászólása szerint igen.

A hibás nyelvi elemet valahol az 5.x-ben hozták be. De fog-e ezzel valaki találkozni, aki jóval egyszerűbb módon programozik? Lehet-e szögegyszerű eszközökkel fejleszteni? Feltétlenül jobb lesz-e az a kód, ami komplex eszközökkel készült?

Ki mondta neked, hogy a forEach egy egyszerű ciklus?
Ha megnézed bármelyik JS kódot, mindenhol így használják.

Szóval akkor a CPU-k teljesítménye mégis növekedett :)
Azt írtam, hogy nincs igazán fejlődés a processzorok sebességében. Ez nem azt jelenti, hogy nincs.

Vicces dolog a chache-ekre meg a branch predictorokra hivatkozni, amikor havonta derülnek ki ezek hibái. Nemrég olvastam egy cikket, hogy hét új Spectre/Meltdown-jellegű hibát fedeztek fel, úgyhogy nagy kérdés, hogy vajon ezek a dolgok meddig maradnak a processzorokban a biztonság kárára.

Én nem sok buta fejlesztővel dolgoztam az elmúlt években. Sőt, eggyel sem.
Az, hogy valaki buta vagy okos, mindig a feladat függvénye. Biztos vagyok benne, hogy intelligens emberekkel dolgoztál együtt. Biztos vagyok benne, hogy a Google-nál, Microsoftnál, Facebook-nál és társaiknál nagyon intelligens fejlesztők vannak. De minden hiba, amit vétenek, csak azt bizonyítja, hogy ez kevés a megoldandó feladat komplexitásához képest.
122

inf3rno 51-es hozzászólása

inf3rno · Dec. 4. (K), 15.09
inf3rno 51-es hozzászólása szerint igen.


Én továbbra is tartom, hogy lehet. Az már más kérdés, hogy érdemesnek érdemes e...
124

Te is hoztál fentebb Java-s

BlaZe · Dec. 4. (K), 15.37
Te is hoztál fentebb Java-s példát a hibás nyelvi elemre, tehát ők sem szentek.
Hát én tök mást írtam... 2 dolgot írtam. Egyik egy API, ami JVM és Java primitívek segítségével magasabb absztrakciójú concurrency konstrukciókat ad, ezáltal nagy mértékben leegyszerűsítve és biztonságosabbá téve a többszálú programozást. A másik pedig a Java Memory Model volt, ami szükséges volt a multicore és aszinkron módon memóriát író gépek elterjedése miatt. Ez nem épp arra példa, amire te gondolod :)

Az volt a kiinduló kérdés, hogy lehet-e PHP4 tudással ma bármilyen szolgáltatást elkészíteni? És mellé teszem, hogy eszközkészlettel.
Ezt a kérdést feltenni sem érdemes, hisz ez egy eleve megválaszolt kérdés. A helyes kérdés, hogy érdemes-e. Nem tudom miért ignorálod megint a válaszokat...

Azt írtam, hogy nincs igazán fejlődés a processzorok sebességében
Ami egyáltalán nem igaz, mert nagyon jelentős fejlődés volt az elmúlt 10 évben. Vesd össze egy 10 éves gép single-threaded benchmarkját egy maival. Ég és föld. Amire gondolsz, az az órajel. De az nem a teljesítménye egy CPU-nak, az csak a frekvenciája. Hogy milyen a teljesítménye, azt az órajelén kívül a belső architektúrája, a pipeline-ja stb határozza meg. Ebben nagyon komoly fejlődés volt.

Vicces dolog a chache-ekre meg a branch predictorokra hivatkozni, amikor havonta derülnek ki ezek hibái. Nemrég olvastam egy cikket, hogy hét új Spectre/Meltdown-jellegű hibát fedeztek fel, úgyhogy nagy kérdés, hogy vajon ezek a dolgok meddig maradnak a processzorokban a biztonság kárára.
Változhatnak implementáció szinten, de bent fognak maradni. Architekturális alapvetések. Nem csak Intel, egyéb CPU-kban és architektúrákban is megvannak ezek.

De minden hiba, amit vétenek, csak azt bizonyítja, hogy ez kevés a megoldandó feladat komplexitásához képest
Ahogy írtam is, nem tudunk végtelen méretű állapottérrel dolgozni. Az absztrakciók egyik fontos tulajdonsága, hogy a használatukkal fixálni tudod az állapottér méretét egy funkció vonatkozásában, és ezen (bizonyítottan helyesen működő) funkciókat felhasználva építesz komplexebb rendszert. Bár az igaz, hogy amíg a teszteket emberek írják, és az absztrakciókat is emberek készítik, addig ezekben lehet hiba, az a bekezdésem eléjéből látszódnia kell, hogy a komplexitás kezelésének a kulcsa az absztrakció. Szóval pont fordítottak az arányok, mint amit sugallni próbálsz...
127

a bekezdésem eléjéből

inf3rno · Dec. 4. (K), 16.41
a bekezdésem eléjéből látszódnia kell, hogy a komplexitás kezelésének a kulcsa az absztrakció


+1
94

Nem rémlik, hogy lett volna

inf3rno · Nov. 28. (Sze), 23.44
Nem rémlik, hogy lett volna ilyen gondom PHP 5-el. Mondjuk nem írtam keretrendszert abban a nyelvben. Azoknál az API-nál esetleg előfordulhat ilyesmi, de belefér, hogy egy-egy metódusnál nem használunk type hintet, hanem if-else-el ellenőrizzük. Nekem még az is belefér, hogy típusonként eltérő metódus van, vagy hogy csinálunk egy Traversable wrapper osztályt a tömböknek.
73

Az osztásos öröklődéses

inf3rno · Nov. 23. (P), 22.35
Az osztásos öröklődéses példád hibás, mert abból indul ki, hogy a valós számok az egész számok részhalmaza, és nem fordítva. Egyébként az eredmény ugyanaz lenne, és ez nem véletlen.
OOP-nél vannak szabályok, amiket be kell tartani a minőségi kód írásánál, ilyen szabály a  Liskov Substitution Principle (LSP), amit a fenti kód megsértene. Ezek mögött a szabályok mögött van néhány évtized gyakorlati tudás, és mindegyik jó okkal született. Ha a fenti módon akarod alkalmazni az OOP-t, akkor nyilvánvalóan nem ismered sem ezeket a szabályokat, sem az okokat, amiért használjuk őket.
Miért van az, hogy az OOP-vel kapcsolatos kritikáidat mindig hibás példákra alapozod? Miért gondolod azt, hogy az OOP az öröklődésről szól elsősorban, holott az esetek döntő többségében egyáltalán nem is használjuk? Tudsz esetleg olyan - nem egysoros - példát mutatni, ahol a fenti int -> float probléma megjelenik, és lenne valami gyakorlati haszna?
A null átadása nálam opcionális paraméter esetében fogadható csak el, egyébként ha olyan kód fut le null-al, ami számot várna, az egyértelműen hibás paraméter, és kivételt kellett volna dobni rá már az ellenőrzéskor. Ez azt hiszem ízlés kérdése, nekem ez vált be.

Például ha egy publikus rutinkönyvtárat készítesz, akkor egyáltalán nem ildomos a paramétereknek típusokat adni, mert nagyon megkötöd vele a későbbi felhasználók kezét, akik nem feltétlenül ugyanazt a típust szeretnék használni, amit te elképzeltél.


Ez így egyáltalán nem igaz. Ha valami általános paramétert akarsz, akkor interface-t kell megadni, aztán ahhoz esetleg elkészíthetsz néhány alap implementációt a könyvtáron belül. Ha valamiből örököltetni kell egy könyvtár használatánál, akkor az nálam hibás tervezésre utal. Keretrendszereknél esetleg bizonyos esetekben elfogadható ilyesmi, de szerintem minden megoldható könyvtárakkal, és nincs szükség rá, hogy valaki más mondja meg, hogy mi legyen pl. a könyvtár szerkezet, vagy ilyesmik, ami általában keretrendszereknél divat. Szóval én azokért sem vagyok oda.

A fenti egy konkrét példa volt, némi absztrakciót követel, ha általánosítani szeretnél belőle. Ha két hasonló dolog kerül be egy programnyelvben, akkor két featúránál kell fejben tartanod, hogy mit lehet vele csinálni és mit nem. Ezek kombinációja esetében pedig négyzetesen nő a hibázási lehetőségek száma.


Én nem szoktam fejben tartani. Ha valami ritka dologról van szó, akkor megnézem a dokumentációt, ha valami gyakran használtról, akkor esetleg megjegyzem. Ha mégsem, akkor a tesztek úgyis azonnal jelzik, hogy valami hiba van. Gondolom debuggolsz, ha ennyire félsz a hibázástól. A BDD vagy TDD elég sokat tud segíteni, hogy ne érdekeljen, mert ha van teszted az éppen fejlesztett kódra, akkor azonnal tudod, hogy nagyjából hol hibázik, mert éppen azokat a sorokat írtad le fél perce. A hibaüzenetet meg pár másodperc megfejteni. Ellenben ha debuggolsz, akkor órákat el tudsz tölteni a hiba okának a felderítésével.
87

Tesztek

Hidvégi Gábor · Nov. 28. (Sze), 10.33
A BDD-t nem ismerem, de a TDD szerintem sokat nem ér. Eleve a programkód növekedésével arányosan nő a hibák száma, továbbá drágább a projekt elkészítése és karbantartása, valamint a rugalmasságot is csökkenti. Meg csak akkor van értelme, ha a teszteket más írja, mint a programkódot, hisz ha a két személy megegyezik, akkor, mivel ugyanúgy gondolkodik, ugyanazokat a hibákat és figyelmetlenségeket fogja elkövetni mind a program, mind pedig a tesztek megírásakor.

Az integrációs tesztek viszont fontosak.
91

drágább a projekt elkészítése

BlaZe · Nov. 28. (Sze), 12.35
drágább a projekt elkészítése és karbantartása, valamint a rugalmasságot is csökkenti.
Ezzel alapvetően szögesen ellentétes tapasztalatok vannak. Lehet rosszul és értelmetlenül tesztelni és használni a TDD-t. De ha jól használod, akkor egyértelműen nem igaz, amit írsz. Tök véletlenül pont most jött szembe ez a cikk.

Pl amit olvashatsz róla, hogy ha nem használod, az egy idealista elképzelés. Ha mereven ahhoz akarunk ragaszkodni, akkor az sok esetben tényleg hülyeség. Mindent előre tudsz, mindent előre értesz, mindent előre tud a product owner, mindenre jó interface-eket tudsz már előre kitalálni, ezért előre megvan minden teszted stb. A gyakorlatban ez azért így nem mindig kivitelezhető, így amit a valóságban csinálunk, hogy prod kódot megfelelő tesztek nélkül nem engedünk be a repoba. Hogy a megfelelő teszt unit, és/vagy magasabb szintű teszt, az már egy másik kérdés. Mindenre nem érdemes unit testet írni. Meg az is egy másik kérdés, hogy a tesztet előre írod-e meg, vagy a prod kóddal párhuzamosan.

Viszont tesztek nélkül fejleszteni vakrepülés és a valóságban sokkal több időt is igényel. Ez azt is jelenti, hogy a tesztek jelentős részét a fejlesztők fogják írni, viszont a funkcionális megfelelőséget más személynek kell vizsgálni. Ez viszont történhet teljesen, vagy részben a fejlesztő által írt tesztek alapján is, amennyiben van átfedés a teszt forgatókönyv és a tesztek között.
96

Pl amit olvashatsz róla, hogy

inf3rno · Nov. 29. (Cs), 00.34
Pl amit olvashatsz róla, hogy ha nem használod, az egy idealista elképzelés. Ha mereven ahhoz akarunk ragaszkodni, akkor az sok esetben tényleg hülyeség. Mindent előre tudsz, mindent előre értesz, mindent előre tud a product owner, mindenre jó interface-eket tudsz már előre kitalálni, ezért előre megvan minden teszted stb. A gyakorlatban ez azért így nem mindig kivitelezhető, így amit a valóságban csinálunk, hogy prod kódot megfelelő tesztek nélkül nem engedünk be a repoba. Hogy a megfelelő teszt unit, és/vagy magasabb szintű teszt, az már egy másik kérdés. Mindenre nem érdemes unit testet írni. Meg az is egy másik kérdés, hogy a tesztet előre írod-e meg, vagy a prod kóddal párhuzamosan.


Én először mindig API-t tervezek, csak utána foglalkozok a tesztekkel, utána meg az implementációval, de azt már váltakozva. Azért általában lehet tudni előre, hogy mi az, amit elvárunk a kódtól, és csak a hogyan, ami kérdéses, szóval ha van egy jól megtervezett API, akkor nem jellemző, hogy az később változna. Esetleg akkor változhat, ha nem megvalósítható valamilyen logikai akadály miatt, amit nem láttunk előre. A teszteknél általában csak egy-egy feature-el kapcsolatos teszteket, esetleg egy-egy scenario-t írok meg előre, és utána implementálom azt a részt. Aztán jöhet a következő. Ha nem tetszik az implementáció, akkor is inkább nagyobb egységeket szoktam átírni úgy, hogy az API és a tesztek közben változatlanok, aztán egy idő után zöldbe megy újra az egész. Ritka az, amikor annyira félresikerül, hogy revertálni kell mindent, aztán nulláról újrakezdeni, általában akkor fordul elő ilyesmi, ha egyszerre túl nagy darabot akarok átírni. Ez is olyan, hogy ki kell tapasztalni. Nagyjából most ez az optimális nekem. Gondolom másnak más. Attól függ, hogy mennyire fontos a coverage, hogy mennyire könnyen találja meg valaki a hibát eltérő méretű kódrészletekben, mennyire érzi macerásnak karbantartani a teszteket és szabályosan minták alapján refaktorálni, mennyire érzi szükségét, hogy minden percben legalább egyszer zöldbe menjen a teszt, stb... A unit teszteknek én sem látom egyébként már annyira értelmét, nekem túl "fine grained" az a megközelítés. Viszont az olyan alapelveket, mint először a teszt, utána az implementáció, illetve váltogatjuk a teszt és a kód írását, stb. azóta is betartom, mert azok nagyon hasznosak.
98

Igen, ez jól működik addig,

BlaZe · Nov. 29. (Cs), 10.03
Igen, ez jól működik addig, amíg tiszta, hogy mit kell csinálni. Illetve hogy pontosan hogy kéne összeérjenek a részek. De ha a feladat valami kutatás jellegű pl, akkor erről eleinte fogalma sincs az embernek.

Most pl amit csinálok, az egész jó példa erre. Van egy elég komplex XML konfigurációnk, amit sokezer sornyi kód dolgoz fel, és még sokezernyi tesztel. A feladat, hogy mostantól legyen YAML is :) Tegnap reggel még csak ötletem volt hogy kéne összeérjenek, de hogy pontosan hogy, és milyen sarok esetek vannak, az még nem volt világos. Így értelmes teszteket se tudtam írni. Szóval egész nap csak implementáltam, és most már nagyjából működik. Úgyhogy most el lehet majd kezdeni gondolkodni az API-n, a refaktoráláson, a teszteken. A lényeg, hogy vannak ilyen típusú munkák, hogy sailing in the fog, ahol a TDD nem segít. Persze masterbe semmi nem ment és fog bemenni teszt nélkül, és amikor már látszik mi az irány, akkor visszajönnek a keretek. De azt jó tudni, hogy a TDD - és úgy általában a szigorú processek - az early feedback ellen hat.

Még pár példa, ami eszembe jut:
- Integrálódni kell egy másik párhuzamosan fejlesztett service-zel. Itt még esetleg alakulhat az interface, legalábbis a közös. Változhat a protocol, bármi. A gyorsabb haladás eleinte itt is fontosabb tud lenni.
- Teljesítménykritikus részek. Itt is az API előtt néha azt jobb tudni, hogy az implementáció hogyan viselkedik (ez persze megint automata teszteket jelent :))
100

Szóval egész nap csak

inf3rno · Nov. 29. (Cs), 22.42
Szóval egész nap csak implementáltam, és most már nagyjából működik.

Nyilván valamit megnéztél manuálisan rajta, amiből tudod, hogy nagyjából működik. Onnantól meg, amit megnéztél rajta, ugyanazt tudnád automatizálni is, és máris van egy teszted...

A lényeg, hogy vannak ilyen típusú munkák, hogy sailing in the fog, ahol a TDD nem segít.

Persze, de én sem TDD-ről beszéltem feljebb. Nekem sok ilyen hobbi projektem van, amik ez a kategória, és azoknál is el lehet indulni magasabb szintről lefelé. Pl a te esetedben van valamilyen feldolgozód, ami eltérő formátumú adatokat dolgoz fel. Kapásból ott van, hogy "iDataProcessor.process(String data, MIME type) -> iResult result". Aztán amikor agyalsz, hogy mit kell tudnia a feldolgozónak, akkor le tudsz írni egy scenariot, aminél megnézed, hogy bizonyos data mellett bizonyos feltételek teljesülnek e a result-ra. Ha nincs még ilyen közös result adatstruktúra vagy objektum, esetleg maga a feldolgozó többféle eltérő metódust hívogat más objektumokon, nem adatstruktúrát állít elő, akkor érdemes lehet ezeket az objektumokat a processor-ba injektálni, és első körben azon keresztül meghívni a metódusaikat, később esetleg külön metódusokat csinálni a processor-on belül, amik majd meghívják őket, stb... Én nem tudok elképzelni olyan esetet, amikor a top-down megközelítés előre megírt tesztekkel ne lenne jobb megoldás a bottom-up megközelítésnél link és az utólagos tesztelésnél. Csináltam mindkettőt, és utólag tesztelni és debuggolni nagyon macerás. Nem is beszélve arról, hogy baromi lehangoló ha az ember egész nap csak tesztel egy késznek mondott kódot azzal összehasonlítva, amikor tesztel és fejleszt is egyszerre.

Persze macerás átírni a teszteket, viszont ha nincs sok belőlük, csak ilyen magasabb szintűek, akkor az implementáció az API alatt bármilyen mélységben szabadon változhat, mégis ha valami hiba van, akkor a tesztek azonnal jelezni fogják. Annyi hátrány van az alacsony szintű teszteléssel szemben, hogy nehezebb megtalálni a hibát, és valamennyi debuggolás is szükséges hozzá, illetve messze nincs minden lefedve tesztekkel, viszont nem kell minden változtatásnál átírni a teszteket, és azonnal jeleznek, ha valami komolyabb gond van a kóddal. Ha meg már kiforrott menet közben, hogy hogyan lesz megoldva a dolog, akkor egyrészt át lehet írni az API-t a véglegesre, másrészt meg fokozatosan kialakul fentről lefelé, hogy az alacsonyabb szintek hogyan épülnek fel, és lehet azokra is teszteket írni.

Na majd egyszer írok valami cikket vagy csinálok videot arról, hogy én hogyan tesztelek, mert lehet ez így nem nagyon érthető.
101

Nyilván valamit megnéztél

BlaZe · Nov. 30. (P), 00.52
Nyilván valamit megnéztél manuálisan rajta, amiből tudod, hogy nagyjából működik. Onnantól meg, amit megnéztél rajta, ugyanazt tudnád automatizálni is, és máris van egy teszted...
Igen, de pont ezt mondom, hogy itt a teszt csak lassít, és ebben a fázisban nem azzal kell foglalkozni, hanem hogy egyáltalán működik-e az ötlet. Mire megnéztem manuálisan valamit, addigra kellett kódot írni viszonylag sokat. És nyilván ez egy POC volt, nem teljesen úgy fog kinézni a kód, ahogy összehánytam :) Tesztek meg ott vannak az XML-re, csak az inputot kell paraméterezni. A prod kód majd lefedve megy be, de ezesetben biztos nem TDD-vel. Itt az van, hogy kb 1000 tesztesetet kell paraméterezni, amik nagy része automatice zöld lesz. Aztán majd lehet iterálni a törő teszteken, és a már meglévő kódot javítani, kiegészíteni.

Amúgy normálisan valóban nem deployolt alkalmazással próbálunk ki kódot. Bár a jelenlegi munkámban a deploy mint olyan értelmezhetetlen :) De a lényeg, hogy van egy test harness, és azt használjuk a fejlesztéshez is. Szóval általában teszt alapú fejlesztést csinálunk és csinálok már sok éve. De nem a klasszikus, nagykönyvi TDD-t.
102

Szóval általában teszt alapú

inf3rno · Nov. 30. (P), 06.27
Szóval általában teszt alapú fejlesztést csinálunk és csinálok már sok éve. De nem a klasszikus, nagykönyvi TDD-t.


Én is valahogy így vagyok vele, már nagyon régóta nem TDD-ztem. Nekem ez a megközelítés annak idején Liz Keogh valamelyik BDD videojával jött be. Utána elkezdtem rendesen BDD-zni cucumberrel. Aztán ráuntam, hogy egy csomó plusz munka volt a feature fájlokat írogatni komolyabb haszon nélkül, úgyhogy végül ott kötöttem ki, hogy a unit tesztekre kitalált keretrendszereket használom BDD stílusban, és szinte csak átfogó integrációs teszteket írok velük, amik azt mutatják meg, hogy a kód azt csinálja, amit elvárok tőle, nem azt, hogy az implementáció egy bizonyos módon van megoldva. Az utóbbi nekem alapból érdektelen legalábbis addig, amíg nem csinál valamilyen bottleneck-et vagy ilyesmi.

Egyébként nemrég volt egy olyan ötletem, hogy a kód benchmarkolását is automatizálni kellene, és pl e2e teszteknél megmondani előre, hogy mekkora a futási idő ami elvárt. Aztán akkor pirosba menne a teszt, ha ez az idő nem teljesül. Egy test accounttal akár ugyanazt az e2e tesztet lehetne használni dev környezetben a működés tesztelésére és production környezetben a betöltési idők tesztelésére. Egyelőre ennek az egésznek a hogyanját még nem találtam ki. Azt tudom, hogy vannak terheléses tesztek, de azok inkább arra mennek rá, hogy elbír e sok felhasználót a rendszer, nem arra, hogy milyen a felhasználói élmény vele egy adott pillanatban. Ami még érdekes lehet ezzel kapcsolatban, hogy akár folyamatosan is lehet monitorozni így a felhasználói élményt pl 10 percenként egy alap tesztsort végigtolva az éles szerveren. Valami hasonlót egyébként csinálnak most is, de inkább a rendes felhasználók kéréseit loggolják az időkkel együtt, aztán azt dolgozzák fel utólag, ami legtöbbször nem azonnali visszajelzést és riasztást jelent, hanem hetekre vagy hónapokra rá megnézik a logokat, meg hogy hol volt gond. Aztán ennyivel később már nem biztos, hogy rendelkezésre áll elég info arra, hogy kiderítsék mi okozta a problémát. Az ilyen jellegű tesztelés mondjuk szerintem még nagyon nincs benne a fejlesztői kultúrában, vagy csak a nagy projekteknél van jelen. Nyilván a kis projekteknél legtöbbször nem éri meg a ráfordított időt. Ez akár meg is változhatna, ha lenne valami szög egyszerű módszer ilyen tesztek írására.
103

A throughputra tesztelni

BlaZe · Nov. 30. (P), 13.13
A throughputra tesztelni kicsit könnyebb, mint latencyre. Throughputnál azt nézed, hogy 2 időpillanat között mennyi requestet dolgoztál fel, és számolsz egy átlagot, hogy mondjuk másodpercenként mennyit dolgoztál fel, aztán vagy örülsz, vagy nem. Hogy milyen eloszlása volt a throughputnak, az mondjuk egy másik kérdés :)

Latencynél viszont nem lehet átlagolni, mert azzal pont az értékes adatot veszíted el. Alertelés pedig azért nehéz, mert vannak outlierek, amik simán belenyalnak az alert zónádba. Pl ha microsec range-be vársz egy mérési eredményt, de pont belerúg egyet a scheduler, simán láthatsz millisec időket is emiatt. Laptopomon pl voltak ilyenek, amikor láttam, hogy a processem félre lett rakva, és emiatt jelent meg ms mérési eredmény. Webes rendszereknél talán ez kevésbé ennyire éles, de ott is megjelenik. Ami miatt ez érdekes, hogy a maximum és a nagyon magas (99.9%+) percentilis mérések fognak megjelenni a jelentős többségi user élményben. Az olyanokat, minthogy átlag response time el kell felejteni, az semmit nem jelent. Azon kívül, hogy elmondhatja az ember, hogy annál szinte biztosan csak rosszabb élménnyel fog találkozni a user :) Ez az egyik probléma, hogy a maximumokra nehéz thresholdot húzni. A másik probléma, hogy az emberek nem is értik amit mérnek. Ezért ha csinálnak is hasonló teszteket, azok rosszak. A toolok többsége is, amik léteznek, rosszul mérnek és rosszul reportálnak.

Illetve van még a coordinated omission problem, amibe nagyon komoly szakik is belefutottak. Ez gyakorlatilag annyit tesz, hogy ha már ki van nyomva a rendszer szeme és nem tud újabb kérést fogadni, vagy egy adott kérés várakoztatja másik kérések kiszolgálását, akkor ezek a mérések vagy el vannak dobva, vagy kozmetikázva vannak azzal, hogy csak a request rendszerben megjelenésétől a feldolgozás végéig mérjük. Ha csak a szerver oldalon töltött időt nézzük, nagyon klassz kis grafikonokat lehet kapni. Ha belevesszük azt is, hogy mikor indult a kérés, akkor viszont egyébként jól kinéző grafikonok fordulnak át horrorba és magyaráznak nagyon komoly teljesítményproblémákat. Ha érdekel a téma, ajánlom Gil Tene latency measurement pápa How NOT to Measure Latency előadását. Ez a fickó az egyik legnagyobb koponya a szakmában szerintem, ha low-level és performance kérdésekről van szó. Ez az előadása pedig kötelező darab :)

Amit mi használtunk előző helyemen load testing kiértékelésére és prodon mérésre, az pedig egy in-house Google Dapper implementáció volt. Ennek a distributed tracing megoldásnak az az előnye, hogy by design tartalmazza a várakozásokat is (az első mérési ponttól), így pontosan meg tudod mondani a main latency contributorokat. Azt tudja nagyvonalakban, hogy nyit egy mérést (span) egy bemenetnél és lezárja a kimenetnél, így kapsz minden bemenetre egy tree of spanst. Ehhez persze minden adatot meg kell tartani, ami nagyon komoly adatmennyiség, és ha magas request mennyiséggel dolgozol, akkor ez nem éppen egyszerű. De ha ilyen alapon futtatod a load tesztedet, és a load teszt nyitja a legkülső spant, akkor már tudsz értelmes grafikonokat rajzolni, és a grafikonról a minták alapján azonnal leordít, ha valami félrement. Ezt kiértékelni persze manuális munka, de nagyon hasznos.

Szóval vissza az elejéhez: lehet thresholdokat beállítani baseline-ok alapján, de az esélye, hogy alerted lesz arányos a baseline-hoz képesti toleranciáddal. Nehéz jól belőni. Ráadásul a tolerancia megengedi a regressziót...

Ezek miatt nem tipikus, hogy erre automatizálnának a fejlesztők. Ezeket a teszteket nagyon rendszerre kell szabni, érteni kell mit és hogy kell tesztelni és hogy mit csinál a rendszer. Ez pedig mind időigényes, komoly tapasztalatot igényel és ezért drága.

Szóval a latency mérés automatizálása egy rabbit hole :)
104

Köszi! Nekem is úgy tűnt

inf3rno · Nov. 30. (P), 18.41
Köszi! Nekem is úgy tűnt elsőre, hogy komoly hozzáértés kell hozzá. Nem meglepő, hogy már foglalkozott a témával valaki. Nézem a videot, abból majd kiderül milyen mély a nyúl ürege. :-)
107

Idő és pénz

Hidvégi Gábor · Dec. 2. (V), 13.25
Aha, nagyon jó cikk, csak arról nem szól, amit te leírsz, hogy "lehet rosszul és értelmetlenül tesztelni és használni a TDD-t" vagy "mindenre nem érdemes unit testet írni".

Te hány fölösleges tesztet írtál meg, mire rájöttél a ezekre? Mennyi idő ment el vele feleslegesen? Mindezért vállaltad a felelősséget? Hány juniornak kellett elmagyaráznod, hogy hol és mit szabad tesztelni és mit nem?

Pont erről szól az, amit fentebb állítok, hogy a komplexitás egy része mesterséges, azaz a programozók csinálják saját maguknak, és nem a feladatból következik. Érdemes lenne felmérni a projekteket, hány ilyennel vannak tele.
111

Te hány fölösleges tesztet

BlaZe · Dec. 2. (V), 16.40
Te hány fölösleges tesztet írtál meg, mire rájöttél a ezekre? Mennyi idő ment el vele feleslegesen? Mindezért vállaltad a felelősséget? Hány juniornak kellett elmagyaráznod, hogy hol és mit szabad tesztelni és mit nem?
Szvsz nem írtam ilyet. Mivel minden teszt amit írtam egy prod funkcionalitást fedett le, ami pl a signoffhoz kell. Így értelmetlen feleslegességről beszélni. Olyan van, hogy tesztek részben átfedik egymást. De ha jól van megszervezve a kód, helyes absztrakciókkal dolgozik, akkor ez jól kontrollálható. Pl pont ez az egyik előnye az OOP-nak, hogy alapkoncepció szintjén támogatja a vertikális és horizontális izolációját is a kódnak, ezért szeretjük használni. Értem ez alatt, hogy dolgozhatsz konkrét egymásra épülő kóddal, ahol az izolációt a metódusok adják meg. Illetve tudsz ilyen alrendszereket párhuzamosan építeni, majd azokat kombinálva újabb rendszert építeni. Emiatt pedig tudsz jól izolált teszteket is készíteni. Mielőtt megkérdezed, ez megvalósítható OOP nélkül is természetesen. Viszont azt a környezetet neked kell kialakítani, és végső soron az OOP koncepciókat is neked kell implementálni.

Pont erről szól az, amit fentebb állítok, hogy a komplexitás egy része mesterséges, azaz a programozók csinálják saját maguknak, és nem a feladatból következik.
És tollal is lehet embert ölni. Logikai hiba azzal érvelni bármi ellen, hogy lehet rosszul is használni. Létezik overengineering, igen. De nem ez felelős minden komplexitásért. És amit te annak gondolsz, még nem feltétlenül az.
114

Szerintem meg keveri a

inf3rno · Dec. 2. (V), 17.44
Szerintem meg keveri a komplexitás fogalmát azzal, hogy mennyi zaj van a kódban. A kettő nagyon más. A komplexitást a feladat határozza meg, az overengineering meg nyugodtan tekinthető a fejlesztő által hozzáadott zajnak. Egyébként nehéz eltalálni, hogy mennyire bontsa ki az ember és magyarázza meg minden sorát a kódnak. Ha túlságosan kibontja és megszórja tervezési mintákkal teljesen feleslegesen, akkor az lerontja az olvashatóságot. Bizonyos körökben azt mondják, hogy egy metódus legyen baromi rövid, egy osztály meg legyen kicsi. Én ezzel nem értek egyet, mert sok esetben teljesen feleslegesen vezet zajos kódhoz, és a végén több lesz az osztály deklaráció benne, mint a lényegi része a kódnak.
116

Pont ezért nem (sem) olyan egyszerű a fejlesztés

Pepita · Dec. 3. (H), 11.15
Bizonyos körökben azt mondják, hogy egy metódus legyen baromi rövid, egy osztály meg legyen kicsi. Én ezzel nem értek egyet,
Szerintem minél nagyobb egy fejlesztői csapat, annál pontosabban kell ezt csapatszinten definiálni, mert az mindig relatív, ember függő, hogy ki mit milyen részletességgel bont le.
Ha egyedül dolgozik valaki, sokkal nagyobb az esélye, hogy ha más fogja olvasni / módosítani a kódját, annak nem fog tetszeni. Vagy "hosszabb", vagy "rövidebb" fv-eket szeretne látni, vagy több, vagy kevesebb osztályt, de biztosan lesz eltérés a saját szájízéhez képest.
Nem új, de szerintem jó támogató eszköz erre a PHP Mess Detector. Jól konfigurálható, használatával nagymértékben csökkenthető a codereview idő- és módosításigénye. Persze ez se 100% - os "védelem", és ugyanígy (szerintem se) gyakorlatban nem feltétlen jó szentírásnak venni clean code, solid, stb alapelveket. Iránynak nagyon jók, de valóban, ha tökéletesen meg akarsz nekik felelni, akkor a ló túlsó oldalán landolsz.
117

Hol?

Hidvégi Gábor · Dec. 4. (K), 14.11
A kérdések nem erre vonatkoztak, hanem arra, hogy ha már tudod, hogy nem érdemes mindenhez unit tesztet írni, akkor mennyi idő volt, amíg erre rájöttél? És a hivatkozott cikk írói miért nem írták le, hogy hol szabad és hol nem tesztelni? Mekkora funkcionalitást érdemes lefedni stb.
120

Mert nem tudják. :)

Pepita · Dec. 4. (K), 15.02
És a hivatkozott cikk írói miért nem írták le, hogy hol szabad és hol nem tesztelni?
Valójában "mindenhol" szabad, és sehol sem kötelező.
Nincs az a logikai (összefüggés-) rendszer, amivel gondolkodva egyértelműen és kizárólagosan meg lehetne állapítani, hogy az adott kódot pontosan hogyan és milyen teszttel kell tesztelni.
Amikor olyan fejlesztők is vannak a világon, akik azt mondják, hogy "nem is kell automata teszt, felesleges", akkor mégis milyen szabályrendszer tudná meghatározni, hogy hol és hogyan? (Ha egyáltalán az sem mindenki által elfogadott, hogy kell-e.)

A saját szakmai véleményem az, hogy mindent kell tesztelni, de azt leginkább a megvalósítandó célok és az elvárt működési és minőségi elvárások határozzák meg, hogy mit mivel érdemes.
Unittesztelni olyan osztályokat érdemes, amik
- jól szervezettek (jól körülhatárolt, aránylag szűk működést valósítanak meg)
- emiatt könnyen "kiemelhetők" a környezetükből
- fontos, hogy önmagukban precízen működjenek (vagyis fontos, hogy pontosan és szigorúan azt csinálják, ami a specifikációban van)
- későbbi bármilyen módosításuk esetén azonnal (bőven élesítés előtt) tudni akarjuk, ha károsan módosult a működésük

Minél több feltétel igaz ezek közül az adott egységre, annál inkább érdemes egységtesztelni. Persze ha pl tele van (nem kívánatos) külső függőségekkel, akkor sokkal nehezebb / több munka utólag tesztet írni, mert köré kell építeni azt a (mock) "világot", amiben üzemszerűen működhet. De hát gagyi kódot gagyin lehet tesztelni is... (Ezért is vagyok TDD "párti", ha megtehetem.)
123

Soha nem írtam mindenre unit

BlaZe · Dec. 4. (K), 15.17
Soha nem írtam mindenre unit tesztet. Arra érdemes unit tesztet írni, aminek nem szögegyszerű belső logikája van, általános célú osztály/függvény és még sok más dolog. Összességében aminek a tesztelésére nem elegendő egy komponens, vagy integrációs teszt, mert túl messze vagy a logikától, hogy hatékony integrációs tesztet írj rá. Úgy is lehet mondani, hogy a unit tesztek inkább az alkalmazás belső kontraktjainak, konzisztenciájának a lefedésére valók. Az integrációs tesztek pedig az input/output vizsgálatokra. Eléggé leegyszerűsítés, de kb ez.

Hogy mondjak példát is, amikre a közelmúltban írtam unit tesztet:
- tailored hashtable implementációra
- objektum szerializációja rollup/rolldown esetekre
- listener implementáció kontraktjaira

Amire nem készítettem, mert elegendő volt az IT:
- Egy globális szinkronizációs mechanizmus service szintű osztályára (de azokra igen, amin a logika függ)

De nincs polcról levehető okosság erre se. Gondolkodni kell.

Ez a kérdés olyan, hogy mennyi idő kellett ahhoz, hogy megtanuld mikor kell elöl és hátultesztelő ciklust írni? Mikor kell lefelé számláló ciklust írni? Mikor használunk fort, whilet, mikor foreachet? Ezek értelmetlen kérdések :)
126

A kérdések nem erre

inf3rno · Dec. 4. (K), 16.29
A kérdések nem erre vonatkoztak, hanem arra, hogy ha már tudod, hogy nem érdemes mindenhez unit tesztet írni, akkor mennyi idő volt, amíg erre rájöttél? És a hivatkozott cikk írói miért nem írták le, hogy hol szabad és hol nem tesztelni? Mekkora funkcionalitást érdemes lefedni stb.


Nem tudom pontosan mennyi idő, ami biztos, hogy több év volt. Szabadni mindenhol szabad tesztelni, csak pl egy todo listnél nincs értelme részletekbe menően e2e teszteket, integrációs teszteket, unit teszteket írni, mert a végén több lesz a teszt, mint maga a kód. Ha meg egy hiba átcsúszik valahogy a tesztelésen, akkor az egy kis kellemetlenség csak a felhasználóknak, és küldenek egy bug reportot róla, ha nagyon zavarja őket. Utána persze a report alapján máris lehet pótolni a hiányosságokat, és hozzácsapni egy új tesztet, ami azt a scenariot csinálja végig, aztán kijavítani a hibát. Ezzel szemben ha komplex a rendszer és/vagy kimondottan fontos, hogy tökéletesen működjön, akkor akár érdemes többféle mérettartományt átfogó tesztet is írni hozzá, pl e2e, integrációs és unit teszteket, illetve részletekbe menően kell tesztelni, pl minden egyes hiba típusra, ami előfordulhat, nem csak a gyakoriakra. Aztán még az is előfordulhat, hogy a projekt egyik része fontosabb, a másik meg kevésbé fontos, és ezért eltérő módon kell tesztelni a kettőt. Szóval szerintem nem olyan egyszerű erre valami általános tanácsot adni, hogy mikor hol és hogyan teszteljünk. Ez is egy eszköz, aminek meg kell szokni a használatát, aztán egy idő után az ember rájön, hogy neki hogyan fekszik a legjobban és milyen szituációban hogyan használja. Szerintem itt is igaz, hogy nincs golden hammer. Bár ez is csak egy vélemény a sok közül, mert Pepita láthatóan megoldja unit tesztekkel az összes projektjét.
129

Nem igazán

Pepita · Dec. 4. (K), 18.16
Pepita láthatóan megoldja unit tesztekkel az összes projektjét
Ez nem így van, jelenlegi (elég nagy) projektben egy csomó olyan logika van, amire nem vállaltam a unit tesztet, akkora db / adat függés van benne, aminek még ráadásul jelentős része "idegen" db-kből szinkronizált adat. :) (Ezek mögé a mock db-t felépíteni - addigra nyúgdíjba is mennék kb. :-D)
Ezen kívül pár éve megismertem a Seleniumot, és rögtön rá is kaptam olyan dolgok tesztelésére, amiknél nem igazán az a fontos, hogy hogyan és milyen logikával (részleteiben) jutott pl a user A - ból B - be, hanem az, hogy odajutott. Természetesen a kettő vegyítve jön be nekem igazán: ami önmagában tesztelhető backend, azt lehetőleg TDD fejleszteni, ha nem, akkor utólag unit tesztelni, ami viszont inkább működési és / vagy frontendet is érint, azt jobb "megnyomkodni".
Mondjuk a megtetszéshez az is hozzájárult, hogy első etupként a meglévő, élesítésenként kötelezően (tesztelő kolléga által) végrehajtott checklistet kódoltuk végig, és ami addig egy embernek min 1 óra volt, az Seleniummal 5 perc lett... Persze volt az elején rengeteg gondunk vele, de az mindig van, amikor újat tanulsz / vezetsz be.
130

Ez nem így van, jelenlegi

inf3rno · Dec. 4. (K), 20.17
Ez nem így van, jelenlegi (elég nagy) projektben egy csomó olyan logika van, amire nem vállaltam a unit tesztet, akkora db / adat függés van benne, aminek még ráadásul jelentős része "idegen" db-kből szinkronizált adat. :) (Ezek mögé a mock db-t felépíteni - addigra nyúgdíjba is mennék kb. :-D)


Ilyesmire jobb csinálni egy db fixturet ezzel: https://phpunit.de/manual/6.5/en/database.html, aztán arra lefuttatni a kódot és megnézni, hogy a kívánt eredményt adja e. Természetesen nem a táblában turkálva, hanem a kód metódusaival, amik az SQL-t gyártják. Úgy baromi lassú, ha minden testcasenél újra felépíted a táblákat meg hozzácsapod az adatot. Inkább úgy érdemes megoldani, hogy van egy fixture, amit az összes teszt használ, és amit az elején betöltesz. Utána tranzakcióba rakod, amit éppen tesztelsz a végén meg rollbackelsz, hogy ne változzon a fixture. Ehhez előfordulhat, hogy refaktorálni kell a kódodat, ha tranzakció kezelés van benne, de szerintem megéri, mert így elfogadható a teszt sebessége, és napi többször is simán le lehet tolni a teszteket. Esetleg még tovább lehet gyorsítani, ha verziózod a fixturet és pl a teszt adatbázisod nevébe beteszed a fixture verzióját. Igy nem kell minden teszt futtatásánál felépítened az adatbázist, ami az egyik bottleneck it.

Ezen kívül pár éve megismertem a Seleniumot, és rögtön rá is kaptam olyan dolgok tesztelésére, amiknél nem igazán az a fontos, hogy hogyan és milyen logikával (részleteiben) jutott pl a user A - ból B - be, hanem az, hogy odajutott. Természetesen a kettő vegyítve jön be nekem igazán: ami önmagában tesztelhető backend, azt lehetőleg TDD fejleszteni, ha nem, akkor utólag unit tesztelni, ami viszont inkább működési és / vagy frontendet is érint, azt jobb "megnyomkodni".


Nekem is bejön az e2e, mert sokkal felhasználó közelibb. Aztán ha van user story, akkor az alapján kapásból lehet e2e teszteket írni és gyorsan el lehet indulni az egész projekttel top-down irányba. Utána ki lehet egészíteni integrációs tesztekkel, unit tesztekkel az egészet attól függően, hogy mennyire akarsz alapos lenni.
131

Ez tök jó cucc,

Pepita · Dec. 5. (Sze), 14.01
nézegettem már (a fixturet), de mint említettem, több helyről is származik szinkronizált adat, és nem az határozza meg az elkészítés idejét, hogy ezeket sql-be dumpolom ki vagy xml-be, hanem a közöttük lévő viszonyok helyes beállítása.
Illetve amit előzőleg nem írtam, és eleve megkérdőjelezi a PHPUnit használatát: van jónéhány külső függőség is, ami közvetlenül összefügg (id-k formájában) a saját és a szinkronizált db-adatokkal. Pl auth sem saját van, hanem webservice, és még néhány hasonló nyalánkság, amik miatt szintén tud bukni a mutatvány. Amire van teszt, annak van mögötte (mysql) db is *, amire nincs, arra többnyire a túl sok külső függőség miatt nincs (és itt a külső függőségek közé sorolom a hosszan összefüggő / nagy mennyiségű db rekordokat is).
Van, amit ezek közül sajnos e2e-vel sem lehet "végignyomkodni", mert a folyamatnak része pl egy mq üzenet elküldése, majd x idő után egy másik rendszer szintén mq-ban "válaszol", itt is van egy matek, majd ezután y naptári idő múlva, megint egy mutatvány. :)
Azért érdekes ez a projekt, mert több másik rendszerrel együtt kell működni, amik szintén nem önmagukban működő cuccok. Viszont ezek miatt bizonyos részek nagyon nehezen tesztelhetők.

SZERK: (*): Tudom, hogy ez is egy kvázi felesleges külső függőség (működik-e a teszt mysql szerver), de lényegesen egyszerűbb táblákat másolni így egyik db-ből a másikba.
132

Mock

BlaZe · Dec. 5. (Sze), 16.44
Ezekre (MQ, WS) mind tudsz írni mockokat. Persze azért az nincs ingyen. Viszont cserébe elég hasznos. Ha jól csinálod, kapsz egy kellemesen olvasható DSL-t és így egy áttekinthető teszt forgatókönyvet. Plusz a kezdeti időbefektetésért cserébe drasztikusan lecsökkenti a fejlesztési időt, és még a teszt által használt ID-ket is te tudod menedzselni.

Előző projecten készítettünk az ilyen külső függőségekből in-memory és deployolható mockokat, amiket a teszt fel tudott magának programozni, hogy milyen inputra milyen választ adjanak. Így gyakorlatilag ezeket használtuk fejlesztés közben, CI-ban, és a mockolt teszt környezetekben is.

Ami még előnye ennek a módszernek, hogy ezzel tudsz negatív eseteket is tesztelni (timeout, NACK, hibás válasz, bármi error), hisz nem kell elrontani egy szolgáltatást egy környezetben a teszteléshez, amin mások esetleg szintén függnek.

Én ilyesmi teszteket írok a pet projectemen is, és így egyáltalán nem kell a külső függőség a fejlesztéshez:
@Test
public void testPositionAfterMultiplePartialFills() throws Exception {
    instrumentBehavior.givenEurUsdDefined();
    final OrderCreatedImpl orderCreated = orderEventBehavior.givenLimitOrderCreated()
            .withInstrumentId(EURUSD)
            .withLimitPrice(1.07835D)
            .build();

    marketBehavior.when()

            .orderBookEventSent(givenOrderBookEvent(EURUSD)
                    .withValuationBidPrice(1.07833D)
                    .withValuationAskPrice(1.07834D)
                    .build())

            .orderCreatedSent(orderCreated)
            .orderFilledSent(orderEventBehavior.givenOrderFilled(orderCreated, 10D, 1.07831D).build())
            .orderFilledSent(orderEventBehavior.givenOrderFilled(orderCreated, 10D, 1.07832D).build())
            .orderFilledSent(orderEventBehavior.givenOrderFilled(orderCreated, 10D, 1.07833D).build())
            .orderFilledSent(orderEventBehavior.givenOrderFilled(orderCreated, 10D, 1.07834D).build())
            .orderFilledSent(orderEventBehavior.givenOrderFilled(orderCreated, 10D, 1.07835D).build())

            .orderBookEventSent(givenOrderBookEvent(EURUSD)
                    .withValuationBidPrice(1.07834D)
                    .withValuationAskPrice(1.07836D)
                    .build());

    orderCreatedPipelineBehavior.thenWaitForPipelineInvocations();
    orderBookPipelineBehavior.thenWaitForPipelineInvocations();
    positionBehavior.thenPositionInInstrument(EURUSD)
            .quantity(50D)
            .averagePrice(1.07833D)
            .profitOrLoss(5.0D)    // 0.00001 * 50 * 10000
            .profitOrLossUsd(5.0D);
}
Lehet még rajta csinosítani (pl IDE nélkül a givenOrderFilled paraméterei nem egyértelműek azonnal), de a lényeg látszik. És itt is több egyedi azonosító mozog a teszten belül, de az meg se jelenik a teszt kódjában, mert a fixture elfedi. DB-ben a rekordokat is fel tudod ugyanígy építeni, akár tesztből kapott azonosítókkal is.
93

Meg csak akkor van értelme, ha a teszteket más írja, mint a prog

Pepita · Nov. 28. (Sze), 15.17
Meg csak akkor van értelme, ha a teszteket más írja, mint a programkódot
Szerintem a TDD-t sem ismered. Így "működik" kb:
1. Kapsz egy feladatot
2. Megérted
3. Megtervezed (lebontod) egységekre, hogy mikből fog összeállni az egész
4. Az egyes egységeket is megtervezed, mi mit hol hogyan csináljon.
5. Elkezdesz tesztet írni, az első egységet (mondjuk) be kell tölteni (new valami)
6. Futtatod a tesztet -> elszáll hibával: class not exists.
7. Létrehozod a class-t.
8. Futtatod a tesztet: success.
9. Beírod a tesztbe a legelső dolgot, amit az egységnek kéne csinálnia.
10. futtatod: fail / error, mert nincs kód.
11. Így ismételgetve mész végig, apró lépésenként.

Miért is ér ez sokat?
Mert míg a tesztet írod, addig feladat-megértés / vizsgálódás szemszögből nézed a dolgot, olyan tesztet írsz, ami a specifikációt fedi le (illetve egy kis szeletét).
Elsőre persze failel a teszt, de utána lényegesen gyorsabban írod hozzá a sokkal jobb kódot, mert már egy másik szemszögből is átnézted / átgondoltad a problémát.
Emiatt (klasszikusan) TDD-ről akkor beszélünk, ha egyszerre készül a teszt és a kód, és ezt ugyanaz az ember csinálja.
Persze szokták a TDD-t egy kalap alá venni a PHPUnit-tal, de nem ugyanaz, sőt, unittesztelni is lehet utólag / másképp, nem csak "TDDézve".

ugyanazokat a hibákat és figyelmetlenségeket fogja elkövetni mind a program, mind pedig a tesztek megírásakor
Ha a fenti sorrendet tartja, vagyis a teszt mindig egy picit előrébb jár, mint a kód, akkor pont, hogy jól kihozza az esetleges réseket.
Más kérdés, hogy ha "majd utólag megírom rá a teszteket" hozzáállás van, akkor könnyen előfordul, hogy elferdül a teszt, hogy lefedje, de egyrészt még így is nagyobb a valószínűsége, hogy észreveszi a fejlesztő a hibát, másrészt az ilyen utólagos teszt írás nem TDD.

Valódi (fizetett, nem hobby) munkában mennyit fejlesztettél TDD-ben? Mert én azt szoktam kritizálni, amivel már szereztem kellő mennyiségű tapasztalatot.
A ráfordítandó időről pedig annyit, hogy nekem már volt szerencsém csaknem ideális TDD - ben fejleszteni, és max 10% - al volt több idő, mint minden teszt nélkül ugyanezt lefejleszteni. Cserébe egy lényegesen tisztább kód született, 100% - os lefedettséggel. :)
Mondjuk ehhez hozzá tartozik az is, hogy sokkal több időt vitt el (az egészből) a teszt írása, de mire odajutottam, hogy egy - egy teszt mögé tehettem a kódot, akkor azon már alig kellett gondolkozni, hihetetlen gyorsan ment.
Sokan nem szeretik ezt, mert - főleg eleinte - sokáig "semmit nem csinálsz" (vagyis működő, üzleti kódot nem), de aztán a vége felé egyszer csak "kipottyan" a kész kód, nagyon rövid idő alatt.
97

Sokan nem szeretik ezt, mert

inf3rno · Nov. 29. (Cs), 00.39
Sokan nem szeretik ezt, mert - főleg eleinte - sokáig "semmit nem csinálsz" (vagyis működő, üzleti kódot nem), de aztán a vége felé egyszer csak "kipottyan" a kész kód, nagyon rövid idő alatt.


Ja nekem is ugyanez az életérzés szokott lenni a TDD-vel, hogy eleinte úgy érezm, hogy semmit nem csinálok, és csak visszafog, mert nem a lényegi, logikai résszel foglalkozom. Utána viszont azt is ugyanolyan egyszerű belefejleszteni, mint a new class-t kb. Szívesen használtam a TDD-t, de sosem szerettem karbantartani a unit teszteket.
99

Karbantartani én sem :)

Pepita · Nov. 29. (Cs), 17.36
Valóban, a későbbi (komolyabb) módosításokon lehet eggyel többet agyalni, illetve macerás akkor is folyton a tesztekhez nyúlkálni, de ha a módosítást is sikerül a teszttel kezdeni, akkor azért hawaii. ;)
95

Nehéz megmondani az alapján,

inf3rno · Nov. 29. (Cs), 00.07
Nehéz megmondani az alapján, amit írtál, hogy a tesztelés ellen vagy, vagy csak a TDD ellen. A legtöbb érved ráhúzható bármelyik tesztelési megoldásra.
- "a programkód növekedésével arányosan nő a hibák száma". Ezek szerint nem szabad teszteket írni, mert azokban is hibázhatunk.
- "drágább a projekt elkészítése és karbantartása" - Szóval ne írjunk teszteket, mert az plusz idő és azokat is karban kell tartani. Tesztek nélkül viszont jóval nehezebb elkészülni és karbantartani, mert párszáz sor felett a debuggolásra jóval több idő megy el, mint az automatizált tesztelésre.
- "a rugalmasságot is csökkenti" - Ezért nem szeretem én sem a TDD-t annyira. Elég macerás minden kis módosításkor ezer helyen beleírni a tesztekbe.
- "csak akkor van értelme, ha a teszteket más írja, mint a programkódot" - Ez nem igaz. Ennyi erővel ha begépelsz egy szöveget, és újra olvasod, akkor nem fogod megtalálni a hibákat benne, mert ugyanúgy gondolkodsz, mint amikor elgépelted. Talán az egyetlen eset, amikor ez igaz lehet, amikor a user interface-t vizsgáljuk, hogy mennyire könnyen használható. Talán az egyedüli tesztekkel kapcsolatos dolog, aminél az ilyesfajta szűklátókörűség szóba jön, az az A/B testing.
- "az integrációs tesztek viszont fontosak" - Én is jobban szeretem őket, mint a unit test-eket, már egy ideje csak ezeket használom. Viszont ez inkább tapasztalat függő. Ha valaki nehezen látja át több osztály interakcióját, akkor jobb ha unit test-ekkel áll neki a dolognak. Én jobb szeretem az integrációs teszteket, mert bár nem teljes a coverage, de nagyjából azok is lefedik a projektet, és nagyobb lépésekben lehet haladni velük, illetve a karbantartásuk is egyszerűbb, mint a unit test-eknek.
108

Tesztek nélkül viszont jóval

Hidvégi Gábor · Dec. 2. (V), 13.27
Tesztek nélkül viszont jóval nehezebb elkészülni és karbantartani, mert párszáz sor felett a debuggolásra jóval több idő megy el, mint az automatizált tesztelésre
Ezt alá tudnád valamivel támasztani?

Ennyi erővel ha begépelsz egy szöveget, és újra olvasod, akkor nem fogod megtalálni a hibákat benne, mert ugyanúgy gondolkodsz, mint amikor elgépelted
Pontosan. Ezért vannak a cikkekben hibák, mert az írója mindig ugyanúgy gondolkodik, ezért van szükség korrektorra. És te is csak úgy veszed észre az általad vétett elgépeléseket, hogy a futtatókörnyezet vagy a fordító erre figyelmeztet.
112

Ezt alá tudnád valamivel

BlaZe · Dec. 2. (V), 16.44
Ezt alá tudnád valamivel támasztani?
Le tudod manuálisan tesztelni+debugolni ezer sor kód minden funkcionalitását néhány millisec alatt? Naponta mondjuk 50x? Pont ugyanúgy, hiba nélkül. És emellett még fejleszteni is?
115

Ezért vannak a cikkekben

inf3rno · Dec. 2. (V), 18.13
Ezért vannak a cikkekben hibák, mert az írója mindig ugyanúgy gondolkodik, ezért van szükség korrektorra.


Vagy talán mert sosem olvassa vissza, amit leírt. Én van, hogy 2-3x is elolvasom, amit írok, aztán javítom a hibákat, vagy néha átírom az egészet, mert le tudom írni ugyanazt fele annyi sorban is, ha egyszer már átgondoltam.

Ezt alá tudnád valamivel támasztani?


Persze, csináltam már mindkettőt, és ezt tapasztaltam.

Egyébként a legnagyobb előnye az automatikus tesztelésnek a debuggolással szemben, hogy kevesebbet kell keresni, hogy hol a hiba. Már ha 5 perce még zöld volt a teszt, aztán pirosra vált, akkor nyilvánvalóan abban van a hiba, amivel az elmúlt 5 percben foglalkoztál. Ezzel szemben a kézi tesztelés sokkal időigényesebb, és emiatt nem csinálják kellő gyakorisággal, vagy ha igen, akkor csak a nagyon alapvető teszteket csinálják meg. Az első esetben nem az elmúlt 5 percben írt kódban kell keresni a hibát, hanem az elmúlt 1 hónapban írtban. A második esetben majd mondjuk 1 hónap múlva kiderül, hogy valami nem úgy működik, mint kéne, csak nem lett tesztelve, és ugyanúgy az elmúlt 1 hónap kódjában keresgélhetsz. Ezen kívül az is előny, hogy amíg futnak a tesztek (ha hosszúak), addig te csinálhatsz mást.

Amúgy az egész felvetés, hogy az automatizált tesztek rosszak lennének szembe megy a szakma lényegével. Azért programozunk, hogy automatizáljunk valamilyen ismétlődő folyamatot, és ne kelljen embereknek dolgozni rajta. A tesztelés is sűrűn ismétlődő folyamat, mert csak ezzel tudjuk biztosítani, hogy nem törtünk el valamit, amikor hozzányúltunk a kódhoz. Emiatt több, mint nyilvánvaló, hogy érdemes automatizálni a tesztelést is, és ha kellően gyorsak a tesztjeink, akkor napi többször lefuttatni őket, illetve legalább minden commit előtt.
76

Rossz példa

Pepita · Nov. 26. (H), 09.22
Nem értem, hogy ha már példát írsz, akkor miért rosszat.
PHP-ban a float nem az integerből származik
Ez eléggé nagy szerencse! Mégis, hogyan származhatna?
Az első "példa" amiatt (is) hibás, mert nem definiál semmiféle célt, hogy
- miért származik a második az elsőből,
- mi a művelet, amit szeretne a bemenő paraméteren végrehajtani,
- miért szükséges az eltérő input típus.
Ezen kívül nincs visszatérő érték, vagyis 2 void csinál két eltérő semmit két eltérő inputból kimenet nélkül, vajon szükség van egyáltalán öröklődésre?...
Tartok tőle, hogy az első "példa" egyetlen sorral leírható:
<?php
;
a PHP megnézi, hogy az adott paraméter megfelel-e a kritériumnak, ha nem, akkor figyelmeztetést generál
Type error - t inkább nem hívnám figyelmeztetésnek, mert E_ERROR szintű hiba. Vagy légyszi váltsunk már 7.x-re, gondolom az 5.x "új" tulajdonságait más se kívánja megvitatni.

ellenőrizned ígyis-úgyis kell

- Azért, mert nem csinálok vele semmit? Akkor mire ellenőrzök?
- Egyszerű fv-ek esetében legtöbbször elég, ha olyan típusú a paraméter, amit várok. OK, ha pont osztani kell vele, akkor ne legyen 0. De ilyen fv-t meg felesleges írni.

csak olyan típusú paramétert szabad átadnod, null-t nem
De, lehet nullable a típusos is, viszont ennek csak opcionális paraméterként van értelme.

de a program írásakor fejben kell tartanod az egyes típusokat
Bocs, de ez így nettó butaság. Pont nem kell fejben tartanod, ha deklaráltad, mert rögtön hibát kapsz, ha elrontod. Emellett - ha értelmes IDE-t használsz - a function osztas_tipus(int $szam) fv - edre már a szerkesztőd is fogja jelezni, hogy oda egy egész számot várnak. Így kell a legkevesebbet fejben tartani.
mi miből öröklődik
Azt gondolom, hogy egy aránylag tiszta kódban az osztályoknak legalább 90%-a nem öröklődik. De ha onnan közelítenél meg egy valós problémát, hoyg egy fv egy dolgot csinál, akkor nem is lenne ilyen paraméter - problémád. Mert lenne egy fv, ami egész számmal oszt 5-öt, és egy másik, ami valós számmal. Máris két fv-ről beszélünk, és nem is létezik az a "probléma", ami szerinted akadály.
a későbbi felhasználók kezét, akik nem feltétlenül ugyanazt a típust szeretnék használni, amit te elképzeltél
Végülis persze, ha veszek egy rollert a sportboltban, azzal meg kell tudni oldani egy költöztetést is, mi az, hogy nem bírja el a szekrénysort a kanapéval és a mosógéppel együtt? Ja, hogy a rollernek a bemenő paramétere csak ember lehet, és csak 1? De gagyi, ne vegyetek rollert soha!
Szóval ha ráírom a rollerre (deklarálom), hogy csak ember jöhet, akkor azzal meg is kímélem "a későbbi felhasználókat" a kellemetlenségektől. Ha "nem azt a típust szeretné használni", akkor nem arra a függvényre van neki szüksége.

A fenti egy konkrét példa volt, némi absztrakciót követel, ha általánosítani szeretnél belőle.
Nem éppen konkrét "példa", mert egyik fv se csinál semmit, így aztán roppant nehéz bármit is bemutatni vele.
Ha lehet, a jövőben tényleg konkrét példa legyen, kissé szélesebb látószöggel.
60

Érdekes...

Pepita · Nov. 22. (Cs), 15.45
a PHP típusajánlás sem tökéletes minden esetben

- Semmi sem tökéletes. :)
- A linkelt cikk 4 éves, és PHP 5.5 - nél megáll
- Hivatkozik egy másik "cikkre", miszerint TDD - vel felesleges a "típusozás". Ajjaj, a kettőnek kb semmi köze egymáshoz.
- PHP 7.x alatt típus deklaráció van már, ez több, mint ajánlás, és szerencsére return type-ra is van (vagyis ha egy fv eredményére pl foreach-elni akarsz, nem kell félned, hogy nem várt esetben null-t vagy egyéb noniterable értéket kapsz tőle)

Egyebekben egyetértek Inf3rnoval: mérd fel (és valódi mérés legyen), csinálj belőle tanulmányt (többedmagaddal, mert egy fecske nem csinál nyarat), támaszd alá megfelelően, és meglátjuk milyen hatással lesz.
Azt gondolom, hogy ha valamiről 5-10 ember nagyon hasonlóan gondolkodik (és mindannyian a saját tapasztalataik alapján), 1 pedig egész másképp, akkor nem feltétlenül a tíznek kell érvekkel meggyőznie az egyet, hanem fordítva.. Persze az is egy lehetséges megoldás, hogy meghagyják az egyet a saját tévhitében, "ő baja" gondolattal.
61

Abszolut egyetertek a

MadBence · Nov. 22. (Cs), 15.50
Abszolut egyetertek a hasonlattal, a PHP4 sutemeny, es tonkreteszi a fogakat, szoval kerlek ne hasznaljatok!
64

Miből vontad le a

BlaZe · Nov. 22. (Cs), 21.56
Miből vontad le a következtetést, hogy a PHP4 nem elég?
Leírtam pedig. Ha kell PHP4+ lib, akkor a PHP4 tudásod nem lesz elég. Azt azért fogadd már el lécci, hogy ha valamihez nem ért valaki, akkor nem alkalmas rá, hogy használja :)

A munkahelyemen összesen négy külső könyvtárat használunk, ebből kettő még PHP4-ben lett anno megírva (egy SQL daraboló és egy PDF nyomtató), és máig tökéletesen működnek. Ez hogyan lehetséges?
Senki nem vitatta, hogy lehetséges-e. Viszont keress hozzá fejlesztőt, aki szívesen dolgozik PHP4-re szűkített nyelvi eszközkészlettel. Vagy keress supportot a PHP4 libjeidhez.

Mi az az SQL daraboló amúgy? Tokenizer?

Ez kinyilatkoztatás, vagy alá is tudod támasztani valamivel?
Igen. Keress PHP állásokat, és nézd meg hányan kérnek PHP4 tudást. Kb 0-t fogsz találni.

Tudsz esetleg számokat is mondani? Üzleti döntést csak úgy lehet meghozni, ha pontosan ismerünk minden körülményt. És az is érdekelne, hogy a számokat mire alapozod, egy kutatás sem ártana, hogy legyen alátámasztva tudományosan.
Leírtam ezt is. Bővíteni kell, te nem tudod (mert nincs pl időd rá) -> kell PHP4 onlyra ember -> nincs ilyen ember -> a) az ügyfélnek meg kell várjon téged, b) újra kell írni nem PHP4 alapokon c) valakit pöttyösre kell fizetni, hogy hozzányúljon. Egyik se 0 költség az ügyfélnek. Ehhez nem kell kutatás. De ha kutatást akarsz, dobj fel valahova egy szavazást, hogy dolgoznál-e PHP4-ben 2018-ban olyan opciókkal, hogy a) szívesen b) csak ha nagyon megfizeted c) semmi pénzért.

Kifejtés nélkül ez is a kinyilatkoztatás kategória, az pedig csak annyit jelez, hogy itt nem vitatkozunk, hanem te megmondod a tutit, más meg fogadja el csak azért, mert te azt állítod.
Te tényleg elvárod, hogy minden lila, légbőlkapott állításod meg legyen tételesen cáfolva? Ha vitatkozni akarsz szakmai dolgokról, hozz szakmai érveket. Ez a négyzetesen növekvő hibázási lehetőség egy blődség. Mindenki, aki valaha dolgozott PHP4-gyel, és újabb verziókkal tudja, hogy ég és föld a kettő hatékonyság szempontjából. Más nyelveknél szintén sokat egyszerűsödött a fejlesztés.

De tessék, mondok egy példát. Nem PHP, mert nem abban dolgozok. Java5 előtt nem volt concurrency package a Java API-ban, csak wait/notify stb. De nem volt még csak memory model sem. Java5-től van, és egyre fejlődő az eszközkészlet. Egyre bonyolultabb, és egyre hatékonyabb használni. És nem mellékesen nem a hozzá nem értő emberek írta kódok okozta bugokat kell vadászni, hanem expertek írták. Úgyhogy egyszerre lett komplexebb, hatékonyabb és biztonságosabb a többszálú programok készítése Javaban. Ez egy elég erős példa, ami cáfolja az általános állításodat.

Érdekes lenne felmérni, hogy mennyi időt vesz igénybe ezeknek az új dolgoknak a megismerése, megtanulása, a tapasztalatgyűjtés, hogy mi mire jó és mire nem, mi mivel ütközik. Érdekes lenne felmérni, hogy mennyi idő a PHP4 eszköztárával (függvények, for ciklus, alap típusok: karakterlánc, egész szám, törtszám, tömb, null, és esetleg objektumok) elkészíteni egy projektet, és ugyanez mennyi idő az újabbakkal s azok újdonságaival.

Hajrá :)

A nagyobb eszközkészlet mindenképp nagyobb szellemi erőfeszítést igényel
Ezt cáfoló példát ugye hoztam fentebb a kedvedért. Megint egyetlenegy, saját példából próbálsz általános igazságokat kreálni.

De ugye most nem kezdesz el amellett érvelni, hogy felesleges képezni magunkat és újakat tanulni?
65

Kicsit olyan ez, mintha egy

inf3rno · Nov. 23. (P), 00.19
Kicsit olyan ez, mintha egy ámissal vitatkoznál a technológia vívmányairól. :-)

Én csak azt nem értem továbbra sem, hogyha Gábor ennyire ellenzi az absztrakciókat, meg az általánosítást nyelvi eszközöknél, külsős könyvtáraknál, keretrendszereknél, akkor miért egy olyan szakmát választott, ami arról szól, hogy automatizálunk dolgokat, és az egészet absztrakciókkal fedjük el?! Vágom, hogy ennek van egy olyan vonala, hogy azt akarja, hogy a kódja ne függjön szinte semmitől, amit nem kontrollál, de akkor meg nem webfejlesztésben kellene részt vennie, hanem valami katonai vagy banki rendszereket írni, ahol ez valószínűleg követelmény, de talán még ott sem veszik ennyire szigorúan a dolgot... Az, hogy használunk egy keretrendszert arról szól, hogy más dolgozott helyettünk, ami jó, mert időt spórolunk, de lehet rossz is, ha nem megfelelő minőségben végezte el a munkát. Azért a nevesebb keretrendszereknél, könyvtáraknál általában nincs ilyen gond, illetve új nyelvi feature-ök bevezetésénél is szinte kizártnak tartom. Szerintem a programozók túlnyomó többsége megdöbbentőnek találná ezt a hozzáállást, alkalmazni valakit ilyen megközelítéssel meg biztosan nem alkalmaznának. A cégek többségénél a határidő, ami szent, és nem a hibátlan kód, és azzal, hogy valamit nulláról megírunk simán kicsúszhatunk többszörösen is a határidőből. Ezért van az, hogy gyakorlatilag minden cég inkább fizetne egy működő keretrendszerért az adott témában, mint hogy házon belül lefejlessze ugyanazt. És ez nem csak a szoftverfejlesztő cégekre igaz, pl itt egy helyi cégnek volt egyedi rendszere, ami teljesen jól működött, aztán olyan 5-10 éve lecserélték az egészet SAP-re. Az átállás nem volt annyira egyszerű, de végső soron most már csak az üzemeltetéssel kell foglalkozni, és már nem dolgoznak szoftverfejlesztők a cégnél, mint előtte. Nem tudom, hogy mi a mérlegük ezzel kapcsolatban, de úgy sejtem, hogy hosszú távon jobban megéri így, mint saját fejlesztőket fizetni havi bérben, különben nem lépték volna meg. Nem érdekes, hogy nekik jobban megérte függeni egy másik cégtől, mint hogy saját maguk csinálják meg azt a munkát, ami a cégnek egyébként abszolút nem profilja?
66

Ugyan a régi társaságból már

mind1 valami név · Nov. 23. (P), 00.57
Ugyan a régi társaságból már csak nyomokban vannak az utolsó munkahelyemen és a régi rendszerek is csak archívumként működnek, de sajnos így sem lenne illendő elmesélnem részleteket...
2000-ben jött a zseniális ötlet: picsába a fejlesztőkkel, majd a külsősök megoldják.
Tíz év elteltével ezeket a külsősöket is cserélték másik külsősre, de még mindig ugyanaz a helyzet, ha jól vagyok informálva: ugyan külsős a fejlesztő, de a cégnél dolgoznak helyileg, épp csak, mivel nem érdekük igazán a cég jóléte, mert ha ez nincs, lesz más ügyfél, a munka minősége is olyan, amilyen...
Amíg volt normális, saját munkaerő, addig kicsit más volt a hozzáállás mindenhez.
Csak egy példa: a 2000-es vadiúj rendszerrel úgy 3-4 évnyit esett vissza a szolgáltatások színvonala és közel két évbe tellett, mire a korábbi szintet hozta az új csoda...
68

Gondolom cége válogatja, hogy

inf3rno · Nov. 23. (P), 02.28
Gondolom cége válogatja, hogy normális munkát végeznek e. Meg az árfekvés is ehhez igazodik.
67

Kicsit olyan ez, mintha egy

BlaZe · Nov. 23. (P), 02.27
Kicsit olyan ez, mintha egy ámissal vitatkoznál a technológia vívmányairól. :-)
:) Az ámisok emlékeim szerint egyszer hosszabb időre beszabadulnak a technológiailag fejlett világba, hogy el tudják dönteni mi elől vonulnak el, ha elvonulnak előle.

valami katonai vagy banki rendszereket írni, ahol ez valószínűleg követelmény, de talán még ott sem veszik ennyire szigorúan a dolgot
Katonaihoz nem volt szerencsém, bankihoz igen. Részben igaz, de a bank se költ arra, amire nem muszáj. Úgyhogy vannak ott is külsős megoldások. Absztrakcióból meg szerintem pont több van, mint egy átlag helyen, bár feladata válogatja.
69

Katonaihoz nem volt

inf3rno · Nov. 23. (P), 02.39
Katonaihoz nem volt szerencsém, bankihoz igen. Részben igaz, de a bank se költ arra, amire nem muszáj. Úgyhogy vannak ott is külsős megoldások. Absztrakcióból meg szerintem pont több van, mint egy átlag helyen, bár feladata válogatja.


Én a külsős dolgoktól való függésre írtam, hogy szigorúan veszik, nem az absztrakció hiányára. Egyébként biztos vagyok benne, hogyha párszáz sornál hosszabb kódot ír a Gábor, és nem valami ocsmány spagetti az egész, akkor nála is ugyanúgy megjelennek legalább valami kezdetleges formában az absztrakciós szintek, pl. egymást hívogató függvények formájában. Az egész a DRY principle-ből egyenesen következik, mert ha újrahasznosítasz valamit és beteszed egy függvénybe, akkor máris lesz több hívó és egy hívott függvény, és az utóbbi szinte biztosan alacsonyabb szintre kerül, mint amik hívják. Ezért nem is értem, hogy miért szidja ennyire az absztrakciót. Talán olyasmire gondol, hogyha találsz egy általános mintát, és arra csinálsz valami általános könyvtárat, akkor az rossz, mert nem fed le minden ritka esetet. De ezt meg problémája válogatja.
71

Pedig linkeltem feljebb a

Hidvégi Gábor · Nov. 23. (P), 16.27
Pedig linkeltem feljebb a kedvedért azt, amit Pepitának leírtam, mert neki szövegértelmezési problémái voltak azzal, mit jelent a PHP4 tudás, és azt, hogy ez nem egyezik meg azzal, hogy valamilyen PHP4 verziót használsz, de úgy látszik, elkerülte a figyelmed vagy nem ment át, amit nagyon sajnálok, hogy nem fogalmaztam elég érthetően. De akkor kifejtem.

Leírtam pedig. Ha kell PHP4+ lib, akkor a PHP4 tudásod nem lesz elég.
Nézzük a következő egyszerű PHP4-es programot:
<?php
class klassz {
  function klassz() {}
}
?>
Ezt PHP7 alatt futtatva egy nagy Deprecated hibát fogunk kapni. Mit jelent a PHP tudás? Ha hiba van a képernyőn vagy a logban, akkor annak utánajárunk és kijavítjuk. Átírom a metódus nevét, és fut a programom. Így volt ez a PHP4-ben? Igen. Ez a PHP(3|4|5|7){1} tudás.

Mi az az SQL daraboló amúgy? Tokenizer?
Igen, egy lekérdezésből egy asszociatív többdimenziós tömböt készítünk, amiben benne van minden szükséges információ.

Keress PHP állásokat, és nézd meg hányan kérnek PHP4 tudást. Kb 0-t fogsz találni.
Ez valószínűleg így van, ha alkalmazott szeretnél lenni. De vállalkozóként te szabod meg a feltételeket, akár hazai, akár nemzetközi oldalakon keresel munkát.

Leírtam ezt is. Bővíteni kell, te nem tudod (mert nincs pl időd rá) -> kell PHP4 onlyra ember -> nincs ilyen ember -> a) az ügyfélnek meg kell várjon téged, b) újra kell írni nem PHP4 alapokon
Miért kéne újraírni bármit is? Feltettem a kérdést, de még nem kaptam rá választ senkitől, hogy mi az a feladat, amit PHP4-es tudással (fentebb definiáltam párszor) nem lehet elvégezni?

Analógia: C-ben nagyon sok lehetőség nincs meg, ami C++-ban. Mégsem írnak át minden C-ben készült programot C++-ra. Miért nem? Sőt, fentebb hoztam példát arra, hogy egy projektet C++-ról írtak vissza C-re, bár persze ez nem általános.

Ez a négyzetesen növekvő hibázási lehetőség egy blődség.
A 70-es hozzászólásban hoztam erre példát. De az általad írt Java példát alapul véve az ötös verziótól tudod használni programíráskor a régi wait/notify lehetőséget, valamint az új, komplexebb dolog, amit leírtál. A visszafele kompatibilitás miatt gondolom, hogy benne kellett hagyni a wait/notifyt, amit így párhuzamosan lehetett használni az újjal. Két modul, kétszer annyi hibázási lehetőség. A példa kedvéért hozzunk be egy harmadik modult, és nevezzük el őket 1, 2, 3-nak. Ekkor ismerned kell az 1-es modult és azt, hogy hogyan kell használni, a 2-est és a 3-ast. Ismerned kell, hogy mi történik, ha az 1-est mixeled a 2-essel, és ha mixeled a 3-assal. Ismerned kell, hogy mi van, ha a 2-es modult mixeled az 1-essel és a 3-assal. Valamint ismerned kell, mi történik, ha mixeled egyszerre az 1-es, a 2-est és a 3-ast. Ez így hét különböző variáció. Nem teljesen négyzetes, de közelíti, és a modulok számával exponenciálisan nő.

PHP-ban egyébként nem volt ilyen jellegű újítás, mint amit leírtál.

A cégeteknél Java-ban dolgoztok?

De ugye most nem kezdesz el amellett érvelni, hogy felesleges képezni magunkat és újakat tanulni?
Eszem ágában sincs. Minden írásomnak az a célja, hogy aki olvassa, gondolkozzon el azon, hogy mi igaz abból, amit mondanak neki. Jelen esetben azt, hogy a PHP újabb verziói milyen előnyökkel és hátrányokkal járnak (mindenképp lesznek hátrányok, lásd sütis példa), és hogy az előbbiek negálják-e az utóbbiakat.

A másik viszont akkor is fontos, ha egyedül fejlesztesz. Senior ember ilyet nem csinál. Mekkora költséget okozunk azzal, ha PHP4 alapon írunk meg valamit, aztán kell valaki, aki átveszi, vagy beszáll?
Ez egy korábbi kérdésed. És mi lesz, ha senki sem fogja átvenni, mennyit spóroltunk akkor?

Egy felmérés szerint a startupok 90%-a megbukik, azaz tíz esetből kilencszer minden erőfeszítésed, ami arra irányult, hogy future proof legyen a munkád, teljesen felesleges volt. Érdemes-e tehát nagy eszközkészlettel és bonyolult eszközökkel dolgozni? Tízből kilencszer senki sem fogja átvenni a munkát tőled.
75

PHP4 tudás, és azt, hogy ez

BlaZe · Nov. 24. (Szo), 11.49
PHP4 tudás, és azt, hogy ez nem egyezik meg azzal, hogy valamilyen PHP4 verziót használsz, de úgy látszik, elkerülte a figyelmed vagy nem ment át
Egy szót sem írtam runtime verzióról...

Ez valószínűleg így van, ha alkalmazott szeretnél lenni
És ugye pont ez volt az állításom, amibe belekötöttél...

Feltettem a kérdést, de még nem kaptam rá választ senkitől, hogy mi az a feladat, amit PHP4-es tudással (fentebb definiáltam párszor) nem lehet elvégezni?
De, kaptál rá választ többektől is...

Amit a javas példára válaszoltál, az ékes bizonyítéka annak, hogy miért nincs értelme szakmai dolgokról vitatkozni veled. Egy általad teljesen ismeretlen példára is ráhúztad ezt az exponenciális költeményed. Azok után, hogy leírtam, hogy az mennyire erősen cáfolja az állításodat. Legalább megnézhetted volna, hogy miről van szó, akkor nem írtál volna le ilyet... Ha gonosz akarnék lenni, akkor azt mondanám mutasd meg, hogy a wait/notify párral, és egy elemi eszközkészlettel hogy implementálnál egy olyat, amivel egy (vagy több) szálat blockolni tudunk, amíg N másik szál el nem ér egy meghatározott pontra a feldolgozásban. De nem akarok gonosz lenni :) A lényeg, hogy 3 sornál többet kellene írnod, és szinte biztos lenne benne hiba.

Egyébként igen, javaban dolgozok már egy jó ideje, és már lassan 6 éve nem webes rendszereken.

Tízből kilencszer senki sem fogja átvenni a munkát tőled.
Attól még nem kell staffing szempontjából meggyilkolni a projektet, hogy az elején nem tudod menni fog-e tovább. Egyebkent ha project alapon is dolgozol, akkor ez egy olyan tény, amire illene felhívni a megrendelőd figyelmét.

Ha te nem tudsz modernebb eszközkészlettel hatékonyabban dolgozni, mint a limitáltabb régivel, az sajnálatos, de nem az eszközöket minősíti. Kiváltképp, ha a veled ellentétben azt ténylegesen használók ellentétes véleményen vannak.
85

»Ez valószínűleg így van, ha

Hidvégi Gábor · Nov. 28. (Sze), 10.06
»Ez valószínűleg így van, ha alkalmazott szeretnél lenni«
És ugye pont ez volt az állításom, amibe belekötöttél...
Naná, hisz eleve ez a fórumtéma azokról szól, akik egyedül dolgoznak. Nagyjából olyan, mintha almás topikban felhoznád, hogy de vannak, akik a körtét szeretik. Igen, vannak, csak rossz helyen jársz.

Attól még nem kell staffing szempontjából meggyilkolni a projektet
Ki mondta azt, hogy ha valaki a lehető legkisebb eszközkészlettel dolgozik, az "staffing" szempontjából legyilkolja a projektet? Ez hülyeség. De az a megrendelő és a projekt elindulásának szempontjából mindenképp hátrányos tízből kilenc alkalommal, ha olyan rétegeket teszel a programba, amit a kutya sem fog kihasználni.
90

Naná, hisz eleve ez a

BlaZe · Nov. 28. (Sze), 11.56
Naná, hisz eleve ez a fórumtéma azokról szól, akik egyedül dolgoznak
Egész pontosan arról volt szó, hogy mit kell tudjon valaki, amire mondtad, hogy a PHP4 tudás elég. Nem elég. Azt is leírtuk sokan, hogy miért nem elég akkor sem, ha egyedül szeretnél dolgozni.

Ki mondta azt, hogy ha valaki a lehető legkisebb eszközkészlettel dolgozik, az "staffing" szempontjából legyilkolja a projektet? Ez hülyeség.
Szerintem is hülyeség. De ilyet nem is írt senki. A 15 éves, senki által nem támogatott és használt technológia vs legkisebb eszközkészlet közel sem jelenti ugyanazt.

De az a megrendelő és a projekt elindulásának szempontjából mindenképp hátrányos tízből kilenc alkalommal, ha olyan rétegeket teszel a programba, amit a kutya sem fog kihasználni.
Persze. És ha írsz egy számlázó programba egy tetrist, az is hátrányosan fogja érinteni a megrendelőt. Ne érveljünk már azzal, hogy a programozónak gondolkodnia kell. Kell neki. Ez a dolga, ezért kapja a pénzt, és ezáltal tud fejlődni. Nem mellesleg ezért nem jó egyedül dolgozni, mert nem tud az ember nála tapasztaltabb emberektől tanulni munka közben. De ez egy tök másik téma.
77

Én értettem elsőre is, te nem

Pepita · Nov. 26. (H), 10.13
mert neki szövegértelmezési problémái voltak azzal, mit jelent a PHP4 tudás
Én értettem elsőre is, te nem érted még mindig, amit többen többféleképp próbáltunk veled megértetni. :)
53

+1

Pepita · Nov. 22. (Cs), 11.42
Assemblyben is lehet weboldalt készíteni
Én fogok is, minek fárasszam magam 2018-ban php 7.2-vel, mikor assemblyben még string sincs? :-D
54

Ugye? Jóval egyszerűbb úgy,

inf3rno · Nov. 22. (Cs), 12.00
Ugye? Jóval egyszerűbb úgy, minek ilyen absztrakt dolgokkal fárasztani magunkat?! Jóval átláthatóbb is. :D
56

Pláne ha még

Pepita · Nov. 22. (Cs), 13.33
interNYET, akkor aztán semmi gondunk se lenne. :-D
57

Az tuti. :D

inf3rno · Nov. 22. (Cs), 14.31
Az tuti. :D
59

Hát nem tudom, te milyen

mind1 valami név · Nov. 22. (Cs), 15.27
Hát nem tudom, te milyen assembly-t ismertél, én láttam már olyat, amiben volt valami stringhez hasonló dolog (IBM360/R20-R22 sorozatok és koppintásaik... :) )

ui: abba belegondoltatok már, hogy a magasszintű nyelvek végsősoron csak keretrendszerek az assembly-hez? :D
62

milyen assembly

Pepita · Nov. 22. (Cs), 16.15
Ezzel indultam PC-n, de előtte jópár(száz) órát nyüstöltem C-16 - ot is. :)

láttam már olyat, amiben volt valami stringhez hasonló
Fordítója válogatja, ha kimondjuk azt, hogy az assembly a gépi kódú programozást teszi olvashatóbb formába, és nincs több "dolga", akkor nincs benne sem string sem egyéb hasonló, csak byte, word, dword, stb.
A linkelt könyvben (vagy a 2. részében?) is van rá példa, hogy adott hosszúságú memóriaterületre másolgatod mondjuk a leütött billentyűk ASCII kódját, majd kiíráskor ezeket szép sorban másolod a képernyőmemória megfelelő részébe. A 0 byte jelenti a "string" végét. :)
Lehet olyat is, hogy ' - ok közé a kódodba (adatterületre) a szöveget írod, és a fordító az ASCII - vel fogja menteni, de ettől még a te programodnak kell kezelnie (kb byte-onként) a továbbiakban. Talán ez lehet a hasonló? :)

magasszintű nyelvek végsősoron csak keretrendszerek az assembly-hez
Nem. Leginkább azért nem, mert nem azok.
Nézzünk pár példát:
- PHP: nem jön létre hosszú távon újrahasznosítható byte kód, részben azért is, mert "futásidőben" dől el, hogy mi kerül fordításra (pl if - en belüli require). Így nincs is nagy jelentősége, hogy mennyire optimális a fordítás, gyakorlatilag annyi a cél, hogy egyszer le tudjon futni. -> tuti, hogy ha ugyanazt assembly-ben írnád meg, sokkal kevesebb lenne a byte kód és gyorsabb a futás (és egy webalkalmazást kb 30 évig fejlesztenél).
- JAVA: itt már van byte kód, de nem közvetlenül a processzor utasításkészletére, hanem egy köztes környezetre, aminek egyik fő feladata, hogy a nyelvben írt kód egyáltalán ne függjön a gépi kódú lehetőségektől. -> köze sincs a (forrás-) nyelvnek az assembly-hez.
- Delphi (Object Pascal): na ez már egy csöppet közelebb van, mert "ugyanolyan" exe-t is tud, mint egy assembly fordító, sőt, lehetőség van benne assembly-ben is megírni kódrészeket, ezeket közvetlenül fordítja. Annyiból viszont mégsem hívnám keretrendszernek, mert egyáltalán nem szerepel a céljai között az, hogy az assembly nyelvű programozást támogassa.
- C, C#, stb: szintén kicsit közelebb vannak a procihoz, de nincs tapasztalatom bennük, úgyhogy inkább kihagyom.

Összességében elmondható, hogy ma már kevés olyan magasszintű nyelv van, ami közvetlen futtatható gépi kódra fordít, de még ezek sem nevezhetők assembly-keretrendszernek szerintem. De a felvetés érdekes. :)
63

Assemybly string:

mind1 valami név · Nov. 22. (Cs), 17.22
Assemybly string: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.asma400/asmr1021199.htm :)
92

asm vs hlasm

Pepita · Nov. 28. (Sze), 14.47
HLASM integrates almost all of the functions of past assemblers and provides extensions and improvements. HLASM Toolkit provides tools to improve application development, debugging, and recovery.


Haladunk a korral, rendben van, de ezt azért nem hívnám hagyományos Assembly-nek, mint ahogy ők sem. :)

Viszont érdekes, jó a cucc.
33

De ebbe inkább nem megyek

inf3rno · Nov. 19. (H), 18.46
De ebbe inkább nem megyek bele, mert előjön a "miért borzasztó dolog objektumorientáltan fejleszteni" lemez, amit enyhén szólva unok.


Készítem a popcornt. :D
82

Bonyolultabb kódok, bonyolultabb feladatok

T.G · Nov. 26. (H), 22.00
Szerintem nem kell félteni Gábortól az kezdőket. Engem nagyon meglepne, ha bármilyen kezdő programozó idetévedne a Weblabor-ra, ide csak ugyanazok a fanatikusok járnak, és ugyanazokat írják le évről-éve. :-)
Nosztalgikus hangulatba kerültem a topik kapcsán. Ha visszaemlékszem, akkor 10-15 évvel ezelőtt meg voltam győződve arról, hogy amit mi csinálunk a cégnél az nagyon bonyolult, és igen összetett folyamatok vannak benne. És azt gondolom, hogy az adott környezetben ez még igaz is volt. Akkor még a PHP-t a világ legjobb nyelvének tartottam.
Megmosolyogtat, ha ma visszagondolok arra, hogy akkor extra ficsörnek tekintettük, hogy más cégektől kaptunk XML fájlokat, illetve adtunk nekik válasz XML-eket.
Ezzel szemben ma már nem is feltétlen kell tudnom, hogy kivel hogyan kommunikálok a „sok absztrakció miatt” el van ez előttem rejtve.
Sokkal bonyolultabb feladatokat oldunk meg ma, mint 10-15 évvel ezelőtt. Elsírnám magamat, ha ugyanabban a környezetben kellene megint mozognom, mint akkor. És remélem, hogy 15 év múlva még kényelmesebb lesz a környezet.
Biztos lesz valaki majd akkor is, aki elmondja, hogy Lambda-kalkulussal is mindent meg lehet oldani, és nincsen hasznuk a többség által hájpolt parasztvakításoknak… :)
83

Biztos lesz valaki majd akkor

inf3rno · Nov. 27. (K), 06.59
Biztos lesz valaki majd akkor is, aki elmondja, hogy Lambda-kalkulussal is mindent meg lehet oldani, és nincsen hasznuk a többség által hájpolt parasztvakításoknak… :)


Hát abban tutira nem lesz hiány. :D
148

Furcsa. Én örülnék, ha újra

mind1 valami név · Dec. 9. (V), 21.27
Furcsa. Én örülnék, ha újra abban a környezetben dolgozhatnék, amiben 16-17 évesen... nagygépek, lyukkártya, cserélhető diszkek, 30-60MB kapacitással... én szerettem.
Ezt a mostanit nem annyira.
Nem véletlen, hogy akkor net nélkül többet tanultam egy hét alatt, mint mostanában egy teljes év alatt.
152

A net a tanulás legnagyobb

inf3rno · Dec. 9. (V), 23.33
A net a tanulás legnagyobb akadálya manapság. Mindig ott van a kényszer, hogy valami mást csinálj a neten. Bármit csak ne olyat, ami "muszáj"...
153

Az egy más téma.

mind1 valami név · hétfő, 02.15
Az egy más téma. Szerintem.
Ha az ember valamit kedvvel, lelkesedéssel csinál, azt csinálja nettől függetlenül.
Ha annyira érdekelne ma is a dolog, mint akkoriban, akkor a net egyéb rejtelmei nem vonnák el a figyelmem a tanulásról.
El tudod képzelni, hogy nulla orosz tudással, ruszki dokumentációkból bányásztam ki érdemi infókat? Nem sokat, de még ilyesmire is képes voltam, annyira érdekeltek a dolgok.
Volt egyfajta hangulata: fehér köpeny, légkondis, nyáron is hideg gépterem és a lyukkártyákból következően viszonylag lassú tempó... nem az eszetlen hajtás, a legyél kész tegnapra a holnapival, hiba nélkül. És hát nem volt jellemző a sok ezer-tízezer soros kód sem.
154

Ja vágom. Nézegettem

inf3rno · hétfő, 03.44
Ja vágom. Nézegettem mostanában a lyukkártyákat wikipedian. Érdekes, hogy a vezérmű a kocsikban is hasonló elvekre épül, mint az első lyukkártyák. Többszáz éves technológia, mégis a mai napig használják.
155

Hm?? Milyen kocsikban?

mind1 valami név · hétfő, 04.48
Hm?? Milyen kocsikban? Mondjuk a trabi s601 óta nem láttam autót kibelezve ;)
156

Gondolom az összesben. Bár

inf3rno · hétfő, 11.24
Gondolom az összesben. Bár talán a nagyon drága kocsikban már elektronika vezérli, nem vezérmű. Ugyanaz az elv, mint a zenedobozoknál, hogy forog egy henger alakú cucc, aztán a rajta lévő bütykök vagy lyukak nyitják és zárják a szelepeket, stb.
157

Van egy olyanom, hogy ez ma

mind1 valami név · hétfő, 11.30
Van egy olyanom, hogy ez ma már nem jellemző, inkább elektronikus vezérléssel mennek, de persze tévedhetek. :)
Azért a lyukkártya az messze nem mechanikus dolog volt.
A nagyon régi olvasók úgy működtek, ha jól emlékszem, hogy drótszálakból készített kis kefék voltak a lyukkártya fölött és amikor lyukra futott a kefe, akkor rövidre zárt egy áramkört a kártya mögötti érintkezővel és ennek a jele ment tovább a gép felé.
Az újabbak, amikkel én is dolgoztam, már optikai alapon működtek: átvilágították a kártyát és ahol lyuk volt, azt a mögötte lévő fotodióda érzékelte.
171

Wikipedia szerint nem csak

inf3rno · kedd, 05.06
Wikipedia szerint nem csak elektronikához használták még nagyon régen, hanem pl szövőszékekhez is: https://hu.wikipedia.org/wiki/Lyukk%C3%A1rtya#T%C3%B6rt%C3%A9nete
172

Hát... igen, végül is az is

mind1 valami név · kedd, 09.10
Hát... igen, végül is az is egyfajta lyukkártya volt. :)
Szövőszékről valahogy egy Hollerith nevű úriember neve ugrott be, arról meg a Hollerith-konstans, de mi a fene lehet az? (Google nélkül tudja valaki? :D)
173

Passz. Wikipedian olvastam

inf3rno · kedd, 16.54
Passz. Wikipedian olvastam tegnap valami ilyen nevű fazonról a lyukkártyák kapcsán, de nem jegyeztem meg.
174

FORTRAN-ban a szöveges

mind1 valami név · kedd, 17.03
FORTRAN-ban a szöveges konstans... :)
Ha még jól emlékszem, Hollerith készítette az első lyukkártyás szövőgépet.
146

Basszus... ha tudom, hogy

mind1 valami név · Dec. 9. (V), 21.05
Basszus... ha tudom, hogy ekkora vita lesz belőle, nem nyitom meg ezt a topic-ot...
( :) )
147

Szerintem ne aggódj, nincs

BlaZe · Dec. 9. (V), 21.20
Szerintem ne aggódj, nincs nagy összefüggés a kérdésed és a "vita" között :) Konstans függvény random inputra eset, a WL-en bármilyen input ezt a lemezt rakja fel :)
149

:) nem olvastam végig, csak

mind1 valami név · Dec. 9. (V), 21.28
:) nem olvastam végig, csak megláttam a hozzászólások számát.
151

Szeretnénk már végleg lezárni

inf3rno · Dec. 9. (V), 23.31
Szeretnénk már végleg lezárni ezt a vitát, mert kezd unalmas lenni, hogy minden topicban ez jön föl. Ha 1000 hozzászólásba kerül, akkor annyi lesz.