A programozás általános szabályai

Sziasztok!

Nemrég került elém Kevin Hennley-től a "97 Things Every Programmer Should Know" című könyv és igen érdekes és tanulságos dolgok vannak benne.

Így elolvasva arra gondoltam, hogy itt is összeszedhetnénk olyan tippeket és tanácsokat, amelyek nem csak a kezdő programozóknak lehetnek hasznosak, hanem bárkinek aki fejlesztéssel foglalkozik.

Nem muszáj csak olyat, ami nincs benne a könyvben, szívesen olvasnám más megfogalmazásában is a dolgokat.

Hozzászólások

Bár nem feltétlenül szabályok, de szerintem ez egy elég jó gyűjtemény.

A comment a kodban nem azt jelenti hogy bena vagy, hanem hogy jofej, mert idot szansz arra, hogy az utanad jovonek kenyelmesebb legyen a fejlesztes.

Amikor egy kodreszlet allati vaganyul nez ki, akkor jo esellyel elbasztal valamit. Ha mast nem, akkor az utanad jovo megerteset.

Minden if -nek van else aga! Akkor is leszarod.

Bash -ben siman lehet irni onmodosito es objektum orientalt kodot is, a nyelvi eszkozok adottak erre, de maintenelje a kurva anyad.

A kodban nem karomkodunk, a valtozo nevek mindig legyenek polkorrektek. A frusztracio kielesere a kommenteles valo.

A performancia problemakat nem a timeout novelesevel oldjuk meg. Marmint elvileg.

Az 'eleg jo' hozzaallasbol szuletnek a 'majdnem hasznalhato' kodok, lasd a Windows 10 -be ontott rengeteg munka mennyire 'majdnem jo' lett.

Ezeket nem mint kobe vesett altalanos szabalykent gondolom. De amikor irok valamit, akkor ezeket eszben tartom.
Elterni ezektol abszolute er, sot, adott helyzetben, adott kornyezetben kotelezo is.

Igazabol sok hiba amivel talalkoztam, a fentiekbol fakadt, a kezeletlen else agak olyan tipikus hibak amikkel gyakran talalkozok.
Ugyanigy a kommentek hianya, es a varazslatos kodok amik megnehezitik a munkamat.

A kulonfele patternek es best practice -ek mar nyelv, projekt, es csapatfuggok, peldaul a goto assemblerben jo barat, de c/c++ alatt mar jonnek a raptorok ha siman parasztosan alsogatyaban hasznalod es nem pedig szmokingban, longjump -kent.
Ennel is nivosab kornyezetben mar alap hogy ilyet nem csinalunk, csak az elegans throw letezik, es ez milyen jo, mert a melyen beagyazott goto elhagyja a kornyezetet mint eb a szaharat, ergo meg lehet sporolni vele egy else agat.

Ami teljesen generalis szabaly talan az, hogy nem celszeru olyan pattern betartasa ami az adott projektre nem valo, hiaba tetszett nekunk nagyon egy korabbi projekten, vagyis a szervezes soran is talaljuk meg az adott munkahoz az optimalis szerszamot es az optimalis beallitasokat.

:-)

Olyat nem mondok, hogy mindig ki kell irni az else agat, de gondolni ra mindig kell. Anno webes silverlightos koromban rengeteg szivas szarmazott a jol ismert
if (valami != null) cucc = valami.akarmi

hasznalatabol.

Persze nem azonnal, hiszen a kolto figyelt ra, hogy mashol a cucc null-e, igy nem volt vele gond honapokig, de amikor egy masik reteg epitett ra es az mar elfelejtkezett arrol hogy a cucc esetleg nem lett feltoltve, vagy ha tobb helyen is feltoltesre kerulhetett akkor nem ott ahol vartuk. Ebbol persze nem elszallas volt, hanem csupan hibas mukodes, pl egy oldalon kicsit hektikusan jelent meg az adat. Visszakovetve persze mindig megvolt a bunos, es rajottunk, hogy hoppa, az uj mukodes szerint ez egy required fieldde valt, es igy egy mozdulat volt kijavitani, vagy egy flaget adva hozza, vagy megirni az else agat, mert a nem kitoltese is adat, mas uzleti funkcio indul el a hatasara.
A problema, hogy utana kellett jarni, mert az adott helyen felvallrol kezelt valtozo hatasa messzire gyuruzott el, es tobbnyire kiderult, hogy a hianya eddig is hibat okozott, de csak kozmetikait, egeszen addig mig egy uj modul el nem kezdte valami fontos dologra hasznalni.

De ezzel most jol kimeritettem az anekdodikus ervelesi hibat, szoval senki ne higyje hogy en az else ag profetaja vagyok, egyszeruen csak annyi rossz tapasztalat gyult fel a hianya miatt, hogy ez kialakitott bennem egy egeszeges eloiteletet.
Igy hibakereseskor HA latok egy else nelkuli if-et, AKKOR egybol jobban ranezek, EGYEBKENT nem. :-)

Akkor itt nem is az else-hiány lehet a probléma, hanem az, hogy a cucc-nak nem mindig lett érték adva.

Nem vagyok ("hivatásos") programozó, meg a kódolási divatokat se ismerem, de ezt úgy szoktam elintézni, hogy először a cucc kap valami default értéket (-1, NULL, NA vagy hasonlót), így mindenféleképpen lesz valami meghatározott (nem pedig véletlenszerű) értéke.

A cucc az null volt, ezzel a resszel nincs is gond. A gond azzal van, hogy az uzleti logikaban okozott zavart.

Igazabol korabbi odafigyelessel es jobb tervezessel megelozheto lett volna a problema, de ez szinte sosincs igy.

A tervezesi hianyossagok sokszor kodolas soran jottek ki. Ilyenkor aztan jottek a varazslatok, a workaroundok. Kesobb ezekbol lettek azok a csontvazak amik a kovetkezo versenyzo nyakaba ugranak amikor odaer a temetobe.

Sokszor kevesebb eroforrassal lehet megelozni egy else ag letrehozasaval a kesobbi draga hibakereseseket.

Nyilvan vannak trivialis if -ek, ahol nem kell else ag, de nem minden olyan egyszeru mint ahogyam az a kodban kinez. Egy else ag hianya neha jo alkalom egy kis lamentalasra, hogy na ide most tenyleg nem kell irnom semmit? Mi van ha... ?

Próbáljuk meg klarifájolni ezt a business logic kérdést. Mert mi van, ha űrhajó-leszállás-vezérlő algoritmusnak hívják? ;)
Létezik egy csomó nyelv, ahol eleve nullázott változót kapsz.
Létezik olyan tábor, akik szerint a változó deklarációja után azonnal értéket kell neki adni. Hogy legyen.

Erre a dBase-jellegű nyelvek az egyszerű negatív példa. És azért hozom pont ezt, mert egy szintaktikai és tartalmi vizsgálat során vitát is generált. Legyen az utasítás: APPEND BLANK. A vizsgált mező pedig egy irányítószám.
Kitöltés:
- ha text mező, akor 4db SPACE - ez rossz érték, mert nem numerikus
- vagy 4db 0, mert numerikus - ez egy rossz érték, mert ilyen irányítószám nincs
- 1db 0 - rossz érték, mert az irányítószám 4 jegyű
- van egy pótszabály, ami szerint van olyan, hogy nincs irányítószám

Tehát ennél az egyszerű példánál oda jutottunk, hogy sem a változó inicializálása, sem az if + else nem oldja meg a problémát.
Ezért én a "másik" táborhoz tartozom. Ha létezik egy változó, amely több értéket, de csak bizonyos értékeket vehet fel (vagyis nem flag), akkor az összes lehetséges értékre explicit meg kell írni a kezelését. Ez a módszer biztonságosabbá teszi a programot, mintha valamilféle inicializálásban vagy default értében bíznánk. Ha minden eset kezelt, akkor később vagy az algoritmus hordozásakor sem lesz meglepi.

Értelmesnek tűnik a fenti magyarázat? Lássunk egy adatcserét címekkel!
A küldemény ellenőrzéskor elhasal. - Dejszen nálunk ISO van, nem nyúltunk a programhoz évek óta. A hiba nálatok van!
Ilyenkor válaszol az ember:
- Kis országunkban nincs még 17 jegyű házszám.
- Sőt, negatív házszámok sincsenek.

Használtam ADA -t, - nem szerettem de ez egy más kérdés, - ami részben szeretné megelőzni a változó értékhatárból származó problémákat, például lehet benne olyat mondani, hogy legyen egy olyan integer ami minimum 8, maximum 16.
Ez azonnal szól ha megpróbálsz beletenni ezen kívüli számokat, ergo sokkal hamarabb meg lehet fogni a logikai hibákat.
Ez a része jól működik, kár, hogy a kódban amivel foglalkoznom kellett, nagyjából annyi változó típus volt ahány változó. Mit mondjak, nem tette könnyebbé a megértést. Mondtam már, hogy nem szerettem? :-)

Rengeteg jó koncepció létezik.
A siker titka, hogy mindegyiket ott használja az ember ahova való.

Amúgy én még a trace -ben hiszek, a bash kódjaim jó része szépen naplót vezet, hogy kedves naplóm, megtaláltam az input file-t, van benne 451 sor, nekiállok felolvasni. Kedves naplóm, a 232 -ik sorban találtam egy plusz szóközt, ezért ezt kihagyom, mert rohadtul nem egyértelmű ezek után a parseolása.
Kedves naplóm, a 45 -ik sor szerint most el kell indítanom a do_not_launch nevu alprogramot, szóval ha nem jelentkezem, isten veled, szerettelek, aláírás $BASHPID.
Kedves naplóm, túléltem, a pontos idő $(date), alig $SECONDS másodperc alatt végzett a do_not_launch, halleluja!
Kedves naplóm, befejeztem a melót, volt egy hibás sorom meg négy üres sor, szóval 446 rekordot írtam a kimeneti állományba, ide raktam: $(ls -la "$filename")

Jó, ez egy kicsit szakszerűbben és szigorúan angolul íródik, hogy úgy tűnjön mintha értenék hozzá, de a lényeg a lényeg, hogy halál vagy hiba esetén amikor rám mutogatnak a kollégák akkor én is tudjak tovább mutogatni, hogy az a szemétláda 23452 -es azonosítót viselő process a hibás, nem én, mert amikor megrágta a file-t, akkor annak a 332-dik sorában volt egy olyan érték amiről fél éve azt beszéltük a Béláékkal, hogy ott nem lesz ékezetes karakter, és ők letették a nagyesküt, most meg itt van a szemem előtt, hogy az új kollegina az export filenak az ÉNEXPORTOM nevet adta, ami unicode-ban krikszkraksz és ez agyonvágta a grepet.
Szóval Bélát seggberúgni, - ja, hogy már nincs a cégnél, ezért nem tudta senki, hogy mi az amire figyelni kell? - a kolleginát akkor oktatásra küldeni, én meg kérek egy tábla csokit hogy beleírjak még egy sor ellenőrzést, mondjuk egy ... | strings | .. féleséget, hogy vörösen villogjon ha még egy műköröm elkövet egy ékezetet.

Szóval, a mindennapi problémákra szerintem a megoldás a trace, és a csoki.
Meg a masszírozólányok, de ezt csak azért írom, hátha a főnököm is olvassa, és végre rendel nekünk irodai hát és váll masszírt.
Na, megyek dolgozni. (hallod, főnök?)

No, azért a dBase alias Cilipper is tudott a get mögé értékhatárokat, vagy tán függvényt is illeszteni. Most meg ott az xml, hogy ne is kelljen programozni. Csak használni kellene, de nem csak használni, de ésszel. Magyar embernek el kellett magyarázni az irányítószámról, - már megint irányitószám!- hogy a 0..5 karakter sztring változó nem fedi le igazán a magyar irányítószámok halmazát. Ok, legyen 4 és numerikus. De az sem jó, mert nem kezdődhet 0 értékkel. Stb.

A naplózás elég jó, csak költséges. A bash helyett meg jobb lenne a ksh. :(
Költségcsökkentésként kétszer kellett rövidítenem az üzeneteket. A végén egyszerű, pár betűs mnemonik lett belőlük. A rendszer egy FSM alapú, kvázi-online backup rendszer. összesen 140 kliens és 14 adattípus mentését végzi. Mivel ez egy bash script, amely 80M processzt futtat naponta, van mit naplózni. Megfordítva, ha mindent naplóznék, akkor jó néhány nagyságrenddel nagyobb gép sem lenne elég. Ezért aztán precízen kell programozni, minden hibát lekezelni. A naplók meg egyben a működési fázisok tranzakciói is. Így aztán, ha ráesik a balta a gépre, még mindig vissza lehet állni.
ha még egy műköröm elkövet egy ékezetet
:-D
Képzeld el ugyanezt néhány millió adatsorral! Ha a hiba miatt kidobod, akkor az ügyfél adatai nem kerülnek a rendszerbe. Ha mindent beengedsz, akkor a rendszer elszennyeződik. Ilyenkor keletkezik az önépítő hibaszótár. Vagy a "központi fűtés- víz- és gázszerelő" 350 írásmódját egységesíteni képes programocska. ;)

Egy okos ember egyszer azt mondta: "Ha egy rendszerben nem definiált a karakterkészlet, akkor működésképtelen."
Aztán találkoztam egy hardver hiba miatt dadogós raid diszkkel. Kicsit több, mint 2M fájlt kellett szétválogatnom - egy usb diszken. Szempontok: levél-e (többnyire) vagy svn rekord, duplikátum-e, kimenő-bejövő, user, majd helyére rakni és megfelelően átnevezni. Ehhez először a 25 (!) féle karakterkészletet és a gépelési hibákat kellett egységesíteni...

"A comment a kodban nem azt jelenti hogy bena vagy, " de! azt jelenti, hogy nem sikerult ugy leirni a problemat, hogy az roton latszodjon a kod olvasasabol. Cserebe kommentet kell irni. En nem hiszek a kommenteknek, ki tudja mennyire maszotak el a kodtol az idok folyaman. Ez alol egy-ket kivetelt todok elfogadni, amikor valami workaroundot kell alkalmazni. De ilyenkor illik melle tenni az issue tracker tickett, hogy lehessen kovetni, hogy kell-e meg a workaround. Masik kivetel lehet, amikor pl egy elsore nem trivialis performance javitas van a kodban, jelezve a kovetkezo kodernek, hogy nem balfeksegbol nem olvashato mondjuk a kod, oka van neki. Minden mas esetben ondokumentalo, olvashato, lehetoleg elsore ertheto es jol karbantarthato kodot kell irni, pont.

"Minden if -nek van else aga!" ha kell else ag van neki, ha nincs nem.

"es objektum orientalt kodot is" tudnal peldat mutatni? Erre nagyon kivancsi vagyok.

"A frusztracio kielesere a kommenteles valo" ez tevedes. a komment ugyanugy egyenrangu polgar a koddal. Teves felfogas masodrendu dolognak tartani. Minden tekintetben ugy kell vele eljarni mint a koddal. Pl ugyanugy karban kell tartani, csak sajna semmi nem kenyszeriti ki ezert erdemes jo messzirol elkerulni :)

A kommentes részre reagálnék:

Vegyünk néhány egyszerű példát:

Megírod a kódot, tökéletesen működik, számodra érthető, hogy mit csinál, talán még későbbiekben emlékszel is, hogy adott kód mit csinál. Viszont ez te vagy. Ha más kerül az általad írt kód elé, akkor ő vajon érteni fogja? Ugyanúgy gondolkodik, mint te és egyből érteni fogja mit akart a költő? A kommentet nem magadnak írod, hanem másoknak, akik nem biztos, hogy ugyanolyan szinten vannak, mint te.

Másik eshetőség, maradjunk ugyanazon kódnál. Te megcsináltad, te tudod mit csinál. Valaki belemódosít egy-két dolgot, amiről nem tudsz, nem nézted meg. A módosított kód már nem 100% azt csinálja, mint amire te elkészítetted. Mennyivel könnyebb lenne, ha lenne ott komment, hogy bocs belenyúltam ezt meg ezt csinálja már.

 

Lehet szórakozni olyannal, hogy egy ticket számot odabiggyesztünk, amit aztán kereshetünk ki, nézhetjük meg miért is nyitották, mi módosult, miért... Lehet adott kódrészben csak egy sor módosult, de akkor is nézhetsz át mindent. Míg ha ott van komment, akkor el sem kell hagyni az IDE-t.

 

Én szeretem, hogy ha megfelelően vannak kommentelve a dolgok, mert könnyebb és gyorsabb rájönni, hogy mit is csinál a kód. Főleg ha olyanról van szó, ami egy funkció hívásának a hívásának a hívása. Élvezet azokat visszabogarászni, hogy akkor melyik érték honnan és hogyan is érkezik.

 

Régen mikor tanultam a programozást, akkor kb minden sort kommenteltem, de most már inkább rászoktam, hogy legalább a funkciókat külön kommentelem/dokumentálom, hogy melyik mire is szolgál, maximum ha van néhány sor, ami ha random előtűnne előttem egy kódban ("Wild Spaghetti code appeared!) és nem érteném elsőre mit is csinál, na azokat szoktam külön kommentelni.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

"ugyanolyan szinten vannak, mint te." hat epp ez a business kodolas lenyege, hogy olyan faek egyszeruen kell dolgokat megfogalmazni, hogy egy junior kollega is megertse, es ott tudja folytatni, ahol abbahagytam. Kisse paradoxon, hogy az advanced koder ir basicebb kodot, de igy van.

"Valaki belemódosít egy-két dolgot, amiről nem tudsz, nem nézted meg" 1) de megnezem. 2) Es mi van, ha belemodosit es nem modositja a kommentet? epp ezert ugysem hiszem el amit a kommetnben latok, es 1. pont

"Lehet szórakozni olyannal, hogy egy ticket számot odabiggyesztünk, amit aztán kereshetünk ki, nézhetjük meg miért is nyitották, mi módosult, miért" en erre gondoltam: <code>// This is a workaround, the X blabla Y balbla. Please follow https://ticket</code&gt;

"akkor melyik érték honnan és hogyan is érkezik" ismetelni tudom magam, ha nem ertheto a kod, rosszak a valtzo nevek, akkor nem a komment segit, hanem a kod erthetore alakitasa.

"A comment a kodban nem azt jelenti hogy bena vagy, " de! azt jelenti, hogy nem sikerult ugy leirni a problemat, hogy az roton latszodjon a kod olvasasabol.

Az, hogy a jó kód dokumentálja magát egy klisé. Alapjában véve a kijelentés igaz, csak önmagában a kijelentés téves következtetésekre enged jutni, például arra, hogy nincs szükség kommentre. Ez viszont nem igaz.

Arra tényleg nincs szükség, hogy valamit elmagyarázz kommentben, amit egy jó és átlátható kód le tud írni. Csakhogy a kód jellemzően a működést leírja, annak az okát, hátterét kevésbé. A miértekre jellemzően kommentben találsz választ, ha pedig nincs, akkor vakarhatod a fejed, vagy anélkül hogy megértenéd a problémát juthatsz téves következtetésekre.

En is pont ezt akartam megfogalmazni. Nem azt kell kommentelni, hogy mit csinal a kod, hiszen az ott van. Sokkal tobbszor vakarom a fejem a miert miatt. Jellemzoen azert van ez, mert vagy nem ismerem kelloen a problemat amire a program szuletett, es/vagy mert nem ismerem a felepitesbol adodo megkoteseket.

Valami hasonlora probaltam en is utalni, csak en egy picit tovabb mentem, hogy akkor erdemes kommentelni ha a kodbol nem jon le, hogy miert kell igy vagy ugy csinalni valamit. Csak hol huzod meg a hatart? Gondolom minden sorhoz nem irod oda, hogy miert kell azt csinalni. En mivel eszmeletlen sokszor talalkoztam az elmult 19 evben azzal, hogy a komment reg elavult volt, es tobb idot vitt el mire rajottem erre, mint megerteni mit csinal a kod, ezert vegletes lettem. Tuzzel vassal uldozom a kommentet. A leheto legkevesebb komment kell, csak ha indokolt, mert a komment egy olyan karbantartando kod, ami refactor eseten sem compile sem runtime hibat nem okoz.

Es meg adod is ala a lovat :) bashben lehet OOP, minden if-nek kell else ag valamint frusztracio levezetesre ott a komment. Ez most komoly vagy csak a szarkazmus detektorom nem kapcsolt. Vagy arra utalsz, hogy kobe lehetne vesni, hogy a kokorban meg elment az ilyen hozzaallas?

Még a megjelenés évében olvastam ezt a könyvet, mert elgondolkodtam a kiadásán. Aztán valahogy érdektelennek tűnt.

97 ember elmondja, ami hirtelen eszébe jut a programozásról. 97 másik ember meg 97 másik dolgot mondana.

Nem gondolom, hogy a programozás mint tevékenység leírható volna ebben az erősen leegyszerűsítő formában.

---
Science for fun...

98. ha ugy erzed, hogy kezdessz kiegni, akkor rovid idon belul ki is fogsz. Valts poziciot / munkahelyet: ne vard meg amig tarthatatlan az allapot, mert csak depresszioba taszit.

- Próbáljunk a 'valószínű' helyett a 'biztos'-ra célozni a programozásnál [kedvenc példám: először lekérdezem a dátumot, aztán az időt -- nem valószínű, hogy pont a kettő között legyen éjfél]

Ritkán történnek csak úgy dolgok maguktól, pontban éjfélkor :-)

Ha az amerikai tech mammutcégek azt akarnák, h. főleg minőségi programok és szoftverek szülessenek a világon, nem tudna ennyi millió kókler programozóként ésvagy szoftverfejlesztőként elhelyezkedni az IT iparban.
Ehhez képest olcsó kváziképzett szalagmunkásra van szükség az IT iparban, akik ontják magukból a selejtszar kódot. Ami a webfejlesztésben megy, az mindennek a legalja. Tákolják az átláthatatlan framework-öket, amik életciklusa kb. 1-2 év, mert addigra kijön egy még bloatabb salak-framework, és ha az éppen trendibb, minden agyatlan webfejlesztő arra cuppan rá, mint csecsre.
Ezzel biztosítva h. 1 év múlva el lehessen adni ügyfélnek a "javított" kódot, ami ugyanolyan szar, de míg az előbbit Kumar írta Bangalore-ban 1$-ért ShittyFramework v0.9-ben, a következőt már Gupta írja 2$-ért EvenMoreShittyFramework beta0.12-ben.
Nincs igény a világban sehol, de tényleg sehol a minőségin átgondolt megtervezett és megírt szoftverre, amin értő emberek dolgoztak. Gyors szar kell de minél olcsóbban, ld. Boeing 737 legutóbbi sztorija. Pedig ha a repülőgép szoftverje ilyen trágya, mit vársz a tapicskolós okostelefonod, vagy a soho rútered szoftverjétől? Ezek után lehet írni 97 szép dolgot, de az leginkább csak a fiókba fog menni.
--

Nincs azzal semmi gond, hogy egyesek ontják a szart, mások meg két pofával tömik magukba. A rosszabb az, amikor a jót is elrontják. Ott van pl. a GNOME, a 2.x.x tájékán egy jól használható desktop felület volt, aztán jött a GNOME3, ami egy újragondolt fosrakás lett.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Csak közben a világ elment amellett amit a Gnome 2 tudott. Azóta megjelentek magas pixelsűrűségű kijelzők, megjelentek érintőképernyős laptopok, vagy billentyűzetes tabletek. Ezeket a Gnome 2 nem támogatta, és a forkja a Mate sem támogatja olyan kényelmesen, mint ahogy a sokak által utált Gnome 3 teszi. Lehet itt fikázni szerencsétleneket, mert van miért, de kifejezetten örülök, hogy annó ráfeküdtek az érintőképernyő támogatásra, és most egy használható rendszerem van a 2 in 1 laptopomon.

Jo, de ha az embereknek minosegibb termekre lenne igenye, es elkezdenenek kolteni arra, hogy ne az abszolut minimum szart vegyek meg, akkor ez a helyzet valtozhatna, nem? Ne felejtsd el, az atlag user ott kezdi az informatikaval valo ismerkedest, hogy arukereson megnezi melyik a legolcsobb laptop, megveszi, fel ev mulva lecsereli (mert “szar, lassu”) az epp aktualis legolcsobbra.

Szerintem egy megbízó nem azért csináltat szart pistikével mert olcsó.
Úgy vélem fizetnének többet a jobbért.
De nincs rá idejük.
A jó programot valaki(k)
- specifikálják
- tervezik
- kódolják
- tesztelik
- javítják
- karbantartják

Ez nem csak k*va drága (ezt még benyelnék...), de k*va sokáig is tart.

Ezzel szemben pityuka letölt egy egyedinek látszó templétet joomlához, a megbízó speciális igényeit beleveri a webshop pluginba, mert tud kódolni.
Persze ez utóbi lépésével a jövőbeni frissítéseket meg is ölte, de nem számít, 3nap alatt kész a céges webshop két gombóc fagyiért.
A hangsúly a 3napon van. ;)

---
"A megoldásra kell koncentrálni nem a problémára."

Hasonló dolog jár a fejemben. De hogy ezt felemeljem a topic témájához, valahogy így írnám le:

Ismerd meg a feladatot és a folyamatait (Úgy nem lehet jó terméket fejleszteni, hogy reggeli szófosások során már kódolás közben derül ki, mi is a feladat. Azt mondják lehet, de nem lehet. Akkor sem, ha jól néz ki a színes nagy táblázat a falon, ami tarka a post-it megjegyzések erdejétől és mutatja, hogy ki mit nem csinált meg.)
Ha megismerted a feladatot, válassz hozzá szerszámot, amennyiben lehet.
Dokumentáld a feladatot folyamatábrák és szöveges leírás formájában. (Ki fog derülni, mit érdemes külön egységekbe, pl. függvénybe kiszervezni és mit nem.)
Készüljön pszeudo kód.
Mehetsz kódot írni, használd a pszeudo kódot és a folyamatábrás doksijaidat. Igyekezz a környezet szabványait követni, ha lehet. A saját agyafúrt szabványokért emlegetni fogják édesanyádat.

Azaz

A jó programot valaki(k)
- specifikálják
- tervezik
- kódolják
- tesztelik
- javítják
- karbantartják

Mondjuk én lassan öreg vagyok. :) A webes dolgok engem megríkatnak, mindig a Mexikó város szegénynegyedének bádogvárosai jutnak az eszembe róluk. Úgy is működnek.

Webre fejlesztek magamnak, így mind az ügyfél és teljes fejlesztői háttér én vagyok egy személyben. Van domain ismeret, de így is sok olyan dolgot csinálok ami ködös, majd lassan kialakul, majd full újraírom, amikor már tudom mi is az amit elkezdtem csinálni. A fenti általad is idézett ciklust tartom helyesnek én is, de sajnos nekem az nem hatékony, mert sokszor még az elképzelt modellt is ki kell próbálnom.

Mondok egy példát amin most dolgozom/gondolkodom:
Raktár->Leltározás

Probléma: Jó lenne sűrűben leltározni, de ennek a költségét egyben csökkenteni is.
Ötlet: Valahogy súlyozni az adott termékek leltározási gyakoriságát.
Naiv elképzelés: A hiány pár dologból adódhat
- túl nagy forgási sebesség (a többi termékhez képest)
- túl sok tranzakciószám (a többi termékhez képest)
- összekeverhetőség más termékekkel
- lopás
- adminisztrációs hiba
Ezen problémák ismert száma valószínűleg csak részhalmaza a problématérben lakó entitásoknak. Ezért szükséges lenne pontozni a termékeket (szinte biztos, hogy a pontozó algoritmus fog változni) és ehhez megvizsgálni a fenti kérdéskört. Ha ez megvan, akkor ez alapján már csak rangsorolni kell a termékeket, az utolsó leltár és a pont alapján, majd leltározási útvonalat generálni, hogy ne sétafika legyen a leltározásból.

Több ponton közösek a problémák. Én jellemzően a céges környezeteben hiánypótló, "dolgokat" írogatok.

Többnyire úgy kezdődik, hogy kellene valami, ami megkönnyítené ezt, vagy azt. Kb. ez a specifikáció. Aztán napokig keresgetem azokat az felhasználókat, akik érintetteket, vagy későbbiekben azok lehetnek. Majd szintén napokig, de akár hetekig vitatkozunk azon, mit is szeretnének -specifikáció fogantatik-. Hosszú viták után sikerül megegyezni abban, hogy a fogalmak mit jelentenek, milyen adattípus tartozzon hozzá -specifikáció születik-.

Ezután a lehet tervezni. A kész tervet be szoktam mutatni az érintetteknek, amikor kiderül, hogy, mégsem így gondolták, kellene bele még ez-az -újratervezés-.

Magam kódolom, tesztelem, ha már jónak látom, kiadom a felhasználóknak tesztelésre, ha vannak hibák kijavítom, de maradnak benne "fícsörök" is. :-)

Karbantartás leginkább újabb funkciók kialakításából áll, korábbi "fícsörök" kijavításából.

Mindez 3 fillérért, "köszönjük", vagy még ennyi sem díjazásért.

Raktár->Leltár
Ez egy szúrópróba leltár, folyamatos leltár, vagy rovancs lenne?
(Mi is küzdünk...)
Anélkül, hogy tudnám milyen raktárról van szó (nálunk termelést kiszolgáló raktár van), ha nem titok, mekkora többlet, hiány a még elfogadott?
Van-e hibahatár a darabban nyilvántartott, de tömeg alapján kiszolgált termékekre?
Az "apró" kötőelemekre gondolok, a darabszámlálós mérlegekre. Azonos méretű, felületkezelésű csavarból az egyik dobozból kiadott 100 darab csavar a másik dobozból 102 darabnak felelt meg a mérleg szerint. A 102 darab "fényesebb" volt, mint a 100 darab. Ugyan onnan, ugyan akkor érkezett termékről van szó.
Gyakori a méter-kilogramm átváltásból adódó eltérés, főleg, a beszállító más táblázatot használ.
Ugyan ilyen probléma a technológia szerinti törtmennyiség kiszolgálása pl.: 0,1 tubus tömítő anyag, 0,4 flakon festék spray... Vételezni csak a technológia szerinti mennyiséget tudja (SAP) kiadni viszont kénytelen kiadni a csomagolási mennyiséget. Folyamatos hiány-többlet van ezekből a termékekből. Nem beszélve a kábeldobon lévő több száz, akár ezer méter kábelről, a szálanyagokról, lemeztáblákról.

Jelenleg 3 havonta 2 embernek kb 3 napja megy el. Ami kb megfelel annak, ha 1 ember mindennap 1 órát leltározna. A napi 1 óra szerintem elég minimum 20-30 termék leltározására. 3 havonta ez 50n, mert van betegség és szabadság is. Szeretném ezt a tevékenységet úgy csinálni, hogy a lehető leghatékonyabb legyen. Nálunk a kész áru db, míg az alapanyag inkább kg-ban van számolva a kettő között nem kell váltást csinálni. Lényegében én tükörleltárt csinálok, amit szeretnék valamelyest ötvözni a statisztikai leltározással, de a kiválasztás súlyozott lenne.

Eltérések:
Nézem a szumma eltérést db-ra és nézem a szumma eltérést forintra. Alapvetően közelítenie kell nullához, ha a hiba az elcserélésekből adódik, de valamerre kileng, akkor az alábbiakat vélelmezem:
Többlet esetén: adminisztrációs hiba
Hiány esetén: ha visszatérő és termékcsoportokra jellemző, akkor lopásra gyanakodom, más esetben felmerülhet azonos súllyal minden más is.

A napi leltárral máris a folyamatos leltár felé mozdulsz el, amit a Számviteli törvény el is fogad. Bár ebben az esetben a készletérték csak a főkönyvből állapítható meg, míg a fordulónapos leltár esetén a fordulónapi készlet és a mérlegkészítés időpontja közötti változást kell meghatározni. A könyvvizsgálók eddig a fordulónapost szerették. Előszeretettel jönnek és ellenőrzik szúrópróba szerűen a leltártételeket 20-40 véletlenszerűen kiválasztott tétel szerint. 4-5 ezer tételt veszünk számba, ebből természetesen sok nullás tétel is van.

Minden termék legalább egyszer sorra kerül a kurrens termékek akár többször is. Az ilyen szigor minden képpen a készletek javulását okozza :-). Fűszerezve egy kis véletlennel a tilosban járók munkáját meg lehet nehezíteni. (Tegnap még megvolt, egy hete nem mozdult a készlet, most meg hiány van? Miért?)

Mi irányított rovancsot csináltatunk. Pl. csak darabos termékek, valamekkora készletszint alatti, vagy feletti anyagok, készletérték szerinti anyagok, csak adott cikkekre (struktúrált cikkszámaink vannak, könnyű a kiválasztás), utolsó mozgás dátuma szerint kiválasztott anyagok, stb. Sajnos nincs olyan, hogy a raktárosoknak ne kellene magyarázkodniuk.

A rovancsot a raktárosok, a leltárt független leltározók végzik, de a raktárosoknak segíteni kell a számbavételt.

Amikor a készlet nagyon alacsony, akkor a folyamatba belerakható a raktáros is. Pl fotózd le és számold meg a készletet popup amit a rendszer automatikusan küldd neki.

Leltározási módszerek ötvözésében hiszek.

Nálunk évente egyszer kötelező a leltár törvényileg.

"A jó programot valaki(k)"
...
...
- megfelelően dokumentálják
- üzemeltetőknek megfelelő módon adják át
- erre kijelölt személy odafigyel, hogy ezek a folyamatok ne csak lelkesedésfüggően és esetileg valósuljanak meg, hanem MINDEN projektnél MEGFELELŐ alapossággal.

Ezert eroltetik ezt a devops dolgot a cegek, hogy legyen felelose ezeknek a dolgoknak. Marmint nem csak felelose, hanem aki ert is hozza. Mi uzemkeszen adjuk at a fejleszteseket, egy doksival a tipikus hibakrol es azok lehetseges megodasairol. Igy az uzemeltetes csak a platformmal foglalkozik az SRE pedig a skalazassal jatszik, rugdossa az alkalmazast hiba eseten, es hozzank fordul ha a doksi alapjan nem lehetett megjavitani valamit.

"Ha az amerikai tech mammutcégek azt akarnák, h. főleg minőségi programok és szoftverek szülessenek a világon, nem tudna ennyi millió kókler programozóként ésvagy szoftverfejlesztőként elhelyezkedni az IT iparban."

Két probléma van: üzletileg ki van számolva, hogy nem, nem éri meg hibátlanra programozni valamit, mert egy potenciális hiba legtöbbször nem hoz akkora gazdasági kiesést, mint a plusz órák amiket beleöltek, másik, hogy jelenleg nem is vagyok benne biztos, hogy van annyi űberprogramozó, mint amennyi kéne, mármint bolygó szinten. Ez van, erre képes jelen állapotában az emberiség, van amit nem a kereslet-kínálat hajt, hiába akarnál 1500 Usain Bolt-ot felvenni pizzafutárnak, ha egyszerűen nincs annyi a bolygón, akkor nem fogsz velük dolgozni.

Hogy mi a jó munka definíciója, az nagyon változik a körülményektől.

Egy vacak ingyenes mobilapp felülelét össze lehet taknyolni kezdőnek - ez elfogadható.

Ezzel szemben: írtunk orvosi műszer vezérlőt, ahol mázsás vasak mozognak, ha rosszul írsz meg valamit, megölik a pacienst...

Vagy: jelenleg nemtudomhány milliárd dollárt kezelő legacy pénzügyi szoftvert javítgatunk. Lehetetlen mindenre gondolni, több tízezer teszt mellett is, peer review mellett is, óvatos szemlélet mellett is, néha bizony becsúsznak kisebb gikszerek.

Tákolják az átláthatatlan framework-öket, amik életciklusa kb. 1-2 év

Aha. A nagy húzónevek közül React 6 éves, Angular 3 éves, ha az első verziót is hozzáveszed akkor 8. Vue 5 éves, betonstabil támogatással.

Persze születnek újdonságok folyton, és mivel elég nagy a fejlesztőtábor nagy a lelkesedés és nagy a visszhang, de alapjában véve a nagy nevek itt sem halnak ki gyorsan. 

Amiről te beszélsz az is létezik. De létezik máshol is. Kicsit szar érzés az általad leírtakkal egy kupacban kezelve lenni :)

Szerintem a legfontosabb "szabály", hogy tanuljon meg tanulni. Figyelje a piacot, főleg azt ami a "Völgyben" megy. Mivel ami ott van, az némi késéssel jelenik meg itthon, van ideje megtanulni.

Valamint mindig gondolkozzon el a dolgok hátterén, és ki lehet találni mi az ami felé megy az ipar és esetleg sokkal időigényesebb dolgokat is meg lehet tanulni.

Az, ahogyan ma programozunk fényévekre van attól, ahogy mondjuk a 80-as években tettük. Ne konzervekben gondolkozzunk. A konzerv azért jó mert nem halunk éhen, de ha igazán jót akarunk enni, akkor főznünk kell. Valamint ha már nem lesz konzerv a boltban, akkor nem fogunk éhen halni. Mondhatnánk, hogy konzerv mindig lesz. Hát én azért erre nagy tételben nem mernék fogadni. Sok olyat láttunk már, hogy amire azt mondták, hogy tuti nem lesz, az mégis lett.

Ha valami ilyen nagyon hangzatos tanácsot kellene adni, akkor én azt mondanám:
"Ne légy hülye!" :)

Dobok egy kis olajat a tűzre én is!

Anno fősulin, tanáraimtól szeretettel! BMF NIK 2004. - 2008. a teljesség igénye nélkül, a legemlékezetesebbek

"Nincs olyan programozási nyelv egy PROGRAMOZÓ számára, amit ne lehetne elsajátítani 24 óra alatt..."

"Aki papíron ceruzával tud programozni, az bármit tud, és bármiben tudja programozni..."

"Aki tud programozni egy két vagy akárhány programnyelven, az nem feltétlen PROGRAMOZÓ ám...Az elprogramozgat azokon a nyelveken. Az igazi programozónak a nyelv csak egy eszköz a feladat megvalósításhoz, hogy melyik nyelvet választja, az csak attól függ melyikben a legegyszerűbb megvalósítani a feladatot."

"Az OOP olyan mint a Demokrácia... Jelenleg ez a legkevésbé szar, ami emellett létezik, az még ettől is szarabb..."

"A programozási tételek: Aki nem tudja őket álmából felébredve, az nem programozó...Mondom érthetőbben: Itt még nem szerzett diplomát programozni nem tudó ember..."
(anno 2004 környékén 41 ilyen tételt tartottunk számon...ma már több van...)

"Ha nem tudod hogy működik a számítógép, programozni sem fogod tudni...."

"Minden programnyelv csak annyira jó, amennyire az interpreter-e, vagy compiler-e jó..."

"Nincs jó kód, meg rossz kód...csak optimális, vagy nem optimális feladatmegoldás....Egy feladat megoldása mindaddig optimálisnak tekinthető amíg nincs tőle jobb megoldás ugyanazon szempontrendszernek megfelelően. Szokjatok hozzá, hogy ami ma optimális, az holnap már elavult szar lesz...ilyen dolog ez az IT szektor..."

"Van az Assembly, ezt majd megtanulják azért, hogy tudják értékelni mennyivel könnyebb az élet C/C++ szal. Emellett ott a Java / C#. Nah ezek már a High Level Hawaii nyelvek, ha azon kevés embertársaik csoportjába tartoznak, akik ösztönösen tudják, érzik a helyes abszrtakciót...évfolyamonként szokott lenni 10-15 ilyen ember..."
(300an ültünk az előadóban...)

"A script az script. Minden programozó tud scriptelni, de nem minden scriptelő, nah jó...egyik scriptelő sem tud programozni. Ha tudna, akkor nem baszakodna scriptekkel."

Ezek számomra emlékezetes emlékek, és szerintem lassan 15 év távlatában a mai napig megállják a helyét, még ha nem is feltétlen értek egyet mindegyikkel 100%ig....

A továbbiakban saját magam tollából, mert megszólítva érzem magam a Kumar által Bangelor-ban írt ShittyFrameworkökkel....

Régen volt webhez a static html, css. a Php már űrutazásnak számított, nemhogy az első javascript-ek.
De nem volt más, és így ezek mondhatni stabilan voltak évekig. Ha webezni akartál akkor ez volt a Szent Négyesség..

Ezzel szemben ma már az komoly feladat, hogy kiválassza az ember fia, melyiket használja a "menő JS frameworkök" közül. Én az Angular mellett döntöttem, de pusztán csak azért, mert az állt a legjobban kézre..Emellett a ReactJS-t tartom még számon, figyelem fél szemmel, bár soha egy sornyi kódot nem írtam még "benne".
Sajnos manapság már nincs stabilitás a programnyelvek környékén, így az ember fia csak megtippeli tétre, befutóra, és vagy bejön, vagy lett belőle fekete ló, és újabb ShittyFrameworköt választ. Mert nem igen van más.
S szándékosan nem mondom hogy vissza a Php-hoz, mert szerintem a Php már lassan elavultnak tekinthető (szigorúan magánvélemény)

Én ezt javasolnám általánosságban a programozáshoz: Ne csak kódolj, azt is tudd mi, és miért történik a kódod hatására abban a kotlában amibe begépeled...

Vagy a másik kedvencem...amikor

A feljesztők Discordon beszélik meg a Jira ticketet, mert a tesztelésről visszajelzés jött git comment formájában, csak épp közben a CI/CD megtette amit megkövetelt a haza, mert a DevOps nem írt Pause Scriptet, hibás teszteredmény esetére...ezért autodeployba ment a hibás kód, és a megrendelő emailben tajtékzik, amit mindenki, kivéve a marketing nem kapott meg, mert tele van a ládája cicás jpegekkel. Így a szereptévesztett Scrum Master válság meetinget hív össze, felbassza a Kanban táblát az "autogenerált" dokumentáció alapján, mert itt senki nem eléggé Agile...

Holott elég lett volna annyit átüvölteni a szomszéd asztalhoz, hogy: "Józsi ba+, írd már át a plusz jelet minuszra, aztán mehet ki a megrendelőnek..."

KISS. Keep it stupid simple! Ez a programozásra hatványozottan érvényes.

Na, en most pont egy ilyen magam asta godor aljan vagyok.

Belso projekt, nagyjabol hobby prioritas, a cel az volt, hogy mininalis riziko mellett segitsunk a szomszed szobaban ulo kollegaknak (operatorok) ezert nem telepitunk semmit, azt hasznaljuk ami van.

Nem voltam benne biztos, hogy valoban hasznos lesz az eredmeny, ezert PoC -kent irtam meg az alapokat.

Mostanra kinott a dologbol egy imteraktiv weboldal ami hatassal van a szinten altalam irt, a termelesi rendszert monitorozo uzleti logikara.

Ez kivulrol tok szep, meg tok jo, de.

Szoval, a programnyelv bash.
Meg javascript. Amit termeszetesen bash-bol generalok. Olyan ujhullamos modern izeket mint a CSS nem hasznalok, mert bash-bol generalom a HTML tartalmat, es ott egyszerubb volt a ciklusban szazszor kiszarni hogy color egyenlo dollar fontcolor. Az nekem csak egy sor, illetve elotte egy rakas if, ami eldonti, hogy most eppen milyen tintaba martsuk a pennat.

Ami meglepo, hogy egesz jol mukodik ez a bash cgi-bin altal hajtott csilivili korhinta.

Es meg a kod sem vallalhatatlan, nincsenek benne varazslatok, csupan rohadtul nem igy kellett volna elkezdeni.

Most ott tartok, hogy egy csomo ido kene hozza hogy az egeszet atirjam php vagy python alapokra, kireszeljem belole a behozott hibakat, hogy ugyanott tartsak ahol most.

Szoval itt csucsulok a kenyelmes godromben, es azon gondolkodok, hogy kimasszak, vagy elvezzem, hogy vegre kesz van?

Amíg nem látogatók milliárdjai anyáznak téged mapi szinten, hogy a quad-core i7-esük 100%-on pörög és izzad h. lerenderelje az amúgy primitív weboldaladat, ezzel terawattokat elpazarolva, addig szerintem nem követtél el megbocsáthatatlanul nagy bűnt.
Különbség van aközött h. egy 3 ember által használt weboldal lett összegányolva géperőforrás- és árampazarlóra, vagy egy 3 milliárd ember által napi szinten látogatott.
--

Annyira ismerős és tipikus...

Kellene egy kis nyilvántartó a nyilvántartások nyilvántartására.
Nem használjuk majd sokan, max. 4-5 ember.
Kód megírva, használják bőszen, mert könnyebb lett a munka.
Aztán ripsz-ropsz azon kapod magad, hogy a 70. felhasználót is felveszed bele.

  • Csúnya a felület? Igen.
  • Minimalista? Igen.
  • Funkcionalista? Igen.
  • Gyors? Igen.
  • Többször ennyi felhasználót is ki tudna szolgálni? Igen.
  • Most másképp csinálnám? Igen.
  • Jobb lenne ha újra írnám? NEM! - Akkor meg minek babráljam.

Az optimális kód része amit ki kell egészíteni. Mikor azt mondod, hogy a kód optimális, mindig meg kell mondani, hogy milyen szempontból. Millió egy szempontból lehet optimális a kód, és nem feltétlenül (leginkább mindig) más szempontból meg nem. Manapság egyébként sok esetben a futásidő, vagy erőforrás igény szempontját inkább felváltja példáúl a karbantarthatóság szempontja, de persze project-je válogatja.
Ha a managerek hülye indikátorokat állítanak fel, akkor nyilván a programozó arra kezd el optimalizálni, hogy megkapja a bónuszt, szóval ezzel a résszel eléggé óvatosan kell bánni.

Ezt gondolom pozitívumnak szántad, de számomra ezek a kijelentések mutatják, hogy miért kell az egyetemről nulla munkatapasztalattal kiesett arcokat baltával elüldözni a cég közeléből, annál inkább minél tovább ott voltak.

"Nincs olyan programozási nyelv egy PROGRAMOZÓ számára, amit ne lehetne elsajátítani 24 óra alatt..."

"Aki papíron ceruzával tud programozni, az bármit tud, és bármiben tudja programozni..."

Ez helyesen úgy hangzik, hogy egy programozó 24 óra után bármiben tud beadandót írni. De adott nyelvben tapasztalt szakik review közben még hetekig, hónapokig a hajukat fogják tépkedni.

"Aki tud programozni egy két vagy akárhány programnyelven, az nem feltétlen PROGRAMOZÓ ám...Az elprogramozgat azokon a nyelveken. Az igazi programozónak a nyelv csak egy eszköz a feladat megvalósításhoz, hogy melyik nyelvet választja, az csak attól függ melyikben a legegyszerűbb megvalósítani a feladatot."

Nyilván, mert A PROGRAMOZÓ csak úgy lebeg a légüres térben, és magának kódolgat.

"Ha nem tudod hogy működik a számítógép, programozni sem fogod tudni...."

"Van az Assembly, ezt majd megtanulják azért, hogy tudják értékelni mennyivel könnyebb az élet C/C++ szal. Emellett ott a Java / C#. Nah ezek már a High Level Hawaii nyelvek, ha azon kevés embertársaik csoportjába tartoznak, akik ösztönösen tudják, érzik a helyes abszrtakciót...évfolyamonként szokott lenni 10-15 ilyen ember..."

Lefordítom: Pista bá'-nak még van 10 éve a nyugdíjig, addig muszáj ennek is benne lennie a tananyagban.

Helyezd magad vissza 15évvel, és úgy gondold végig az akkor elhangzottakat, nagyon is helytállóak többségében.

24 óra, az nettó 24. Valóságban kb 3-5 hét, és akinek többre van szüksége egy adott nyelv elsajátítására, az az alapokkal nincs tisztában...
Review? 15 éve nem kódreview nem volt...lófax volt...80%ban specifikáció, meg dokumentáció volt...az volt tesztelve, és ha oké volt, akkor lehetett 20% kódolni.
Ma meg jönnek a 20%ra se elég Udemy-t végzett szakférfiak, meg szakhölgyek, és 80%ban kódolnak...Te meg 80% misztikázol azon a valóban 20%ot sem elérő katyvaszon, meg szidod őket. Pedig nem biztos hogy az ő hibájuk ám...ilyenné vált a világ....
Ezért jöhetett létre olyan szakág is a programozásban mint a kód review-ja. Normális körülmények között szükségtelen lenne.

a nagybetűs PROGRAMOZÓ nem lebeg, hanem nyelv függetlenül is érti amit és amiért csinál.
Sok rakétazsenitől megkérdezed mi a különbség egy C# vagy Java, vagy egy (válassz te melyik) programnyelv objektuma között, fogalma sincs, és eszébe se jutna hogy (nyelvi sajátosságokat leszámítva) lényegében semmi. Mert ha tudná mi az "objektum", a választ is tudná.

Lefordítom: "Pythonban már írtam for ciklust, de Go-ban nemtudok. Jah hogy c#ban a button is egy objektum??? Nemtudom a form összeklikkelőben nem volt kiírva..." Na az ilyent én is azt mondom hogy üldözni kell. De jellemzően ezek nem azok az emberek akik kijönnek diplomásként...Hanem az Udemy, meg a youtube-on láttam videót róla programozók.

Működési elv, és történelem.
Lefordítom: Nem Pista bá miatt kell hogy tudd, legalább nagyjából. Hanem azért mert a mai napig így működik, még akkor is ha te reaktív funkcionális (gondolj ide még pár buzzwordot) programozol, és azt hiszed hogy az fasza, mert az párhuzamosan hajtódik végre...úgy mint a "multitask"..legalább annyira párhuzamos...

> 24 óra, az nettó 24.

Ez most komoly? Szerintem nem ugyanazt ertjuk egy nyelv elsajatitasan. Harom nap fulltime melo lenne megtanulni egy nyelvet, es azt valamennyire igenyes szakmai szinvonalon hasznalni? Ha hetfo reggel az uj kollega megkapja a laptopjat, akkor szerda EOD-re megtanulja a nyelvet? Es csutortok reggel mar erdemi munkat fog vegezni?

A nyelv elsajatitasa szerintem nem csak annyi, hogy ismered az szintaxist (persze szigoruan syntactic sugar nelkul), es kiteszed a pontosvesszot a sor vegere.

Szerintem ennek nem az volt az üzenete. Itt most a 24 órán lovagoltok.
Az értelme az, hogy ne a nyelv korlátozzon, hanem tudd mit kell megírni, képes legyél megérteni a problémát. Értsd az architektúrát amin programozol.

A nyelnek a syntax-ját kb tényleg meg lehet nagyon rövid idő alatt tanulni, aztán jönnek a finomságok, hogy hol mire érzékeny az adott fordító.
De az végül is nem vehetjük szigorúan a nyelvhez, mondjuk C fordítóból van kismillió, mindegyiknek más nyűge. Azért azt is meg kell érteni, és az tényleg nagyobb meló, de ott is érteni kell, miért hasalhat el egy problémán. Nézd meg a cell vs x86 -ot. Míg PS3-mon a papíron erősebb gépen lassabak voltak a játékok, mint X360-on. Azért mert szar volt a fordító és a programozóknak is át kellett állniuk. Aztán ez a generáció végére kisimult, és a PS3 erősen verte az X360-at. De az az üzenet nem erről szólt.

Hiába inflálod az anekdótikus egy napodat, az továbbra is arra elég, hogy beadandót tudj írni adott nyelven. De munkahelyen nem azért fizetnek. Voltam olyan projecten, ahol volt 1 tucatnyi C#-os, és csak a "tök ugyanaz" Java-ra kellett volna átszokni, de hónapok után sem sikerült mindenkinek. És nem az volt a gond, hogy ne tudta volna leprogramozni, hanem hogy úgy programozza le, hogy a nyelv, keretrendszerek, project nyűgjeit, konvencióit figyelembe vegye, az meg nem megy, hogy 500 másik fejlesztő alkalmazkodjon hozzájuk.

Ja, 15 éve nem code review volt, meg tesztelés, hanem fél óránként kékhalál. Mert azok az IGAZI PROGRAMOZÓK még tudtak specifikálni!

A nagyjából tudással meg az a baj, hogy nagyjábóllal nem oldasz meg olyan problémát, amihez behatóbb tudás kéne a számítógépek működéséről. A fejlesztők egyre nagyobb része meg azt sem tudja, hogy milyen oprendszeren, vagy akár milyen architektúrájú processzoron fut majd a kódja, nem hogy mindet behatóan ismerje.

"És nem az volt a gond, hogy ne tudta volna leprogramozni, hanem hogy úgy programozza le, hogy a nyelv, keretrendszerek, project nyűgjeit, konvencióit figyelembe vegye, az meg nem megy, hogy 500 másik fejlesztő alkalmazkodjon hozzájuk."

Ezzel kb. pont ugyanazt mondod. Nem a nyelv elsajátítása a nehéz, hanem a projekt nyűgjei, konvenciói, az 500 másik fejlesztő, a használt libek, framework-ök, ...
Az első program nyelvet hónapokig tanulod, a másodikat 1-2 hónapig.
Ha már tucat programnyelven túl vagy, akkor 2-3 óra után már tudsz értelmesen programozni bármilyen nyelven.

Programnyelveket elsajátítani nem nehéz.
Paradigmákat megérteni sokkal nehezebb, de abból nincs sok, viszont abból sokat lehet tanulni.

Ha már tucat programnyelven túl vagy, ...
Akkor 6 assemblerrel már félig megvagyok?
És aki tud tucatnyi programnyelvet, az miért nem tud megtanulni egy 35 utasításos assemblert? Megválaszolom helyetted: Mert a sokezer class az egyszerűbb.
Kicsit kitekerem a godolatsort. Ezek szerint 1 assemblerrel többet tudok, mint más tucat programnyelvvel?
Mi lesz ennek a vége? Lehet, hogy indulok Jézus választáson is... :-D

"Akkor 6 assemblerrel már félig megvagyok?"

Igen, neked már egy újabb assembler nem okozna nagy kihívást.
Hasonlóan, ha 6 OOP nyelvet ismersz, akkor egy újabb nem kihívás.
Ha ismersz 3 OOP-t, 3 procedurálist, 3 FP-t, 3 logikait, akkor vélhetően egy újabb nyelv nem fog problémát okozni.

És aki tud tucatnyi programnyelvet, az miért nem tud megtanulni egy 35 utasításos assemblert? Megválaszolom helyetted: Mert a sokezer class az egyszerűbb.

Azért, mert vélhetően csak egy paradigmát ismer és az nem a procedurális assembler.
A sokezer class meg nem egyszerűbb, csak azt ismeri esetleg.

"Ezek szerint 1 assemblerrel többet tudok, mint más tucat programnyelvvel?"
Könnyű kérdés. Nem! ;-)

Van sok probléma, amire az assembler lehet a legjobb megoldás (bár a sima C + assembler lehet, hogy azt is verné). Gyorsan, jó megoldást tudnál csinálni, míg más programnyelvnél ugyanazt nehéz vagy lehetetlen lenne megcsinálni.
Ennek a fordítottja is bőven igaz.

egy újabb assembler nem okozna nagy kihívást
Egy kivétel azért van, ha hozzávesszük a fordítót is. Azt, amelyet ifjú titánok írtak magasszintű nyelven, a magasszintű nyelvek szabályait implementálva egy assembler fordítóba. Ekkor úgy találtam magam, mint amikor a C# programozó a Studio helyett kénytelen vi editort használni. ;)
Nem kihívás volt, hanem kellett egy jobb fordítót keresni. Egyszerűen azért, hogy a munkámat el tudjam végezni.

vélhetően csak egy paradigmát ismer és az nem a procedurális assembler
Ez is egy lehetséges magyarázat. Tapasztalatom szerint nem ez a helyzet. Az assembler olyan alacsony szinten dolgozik, hogy pongyolaságnak és mellébeszélésnek helye nincs. Ha azt vesszük, hogy hányszor kerestem ki MSDN vagy php doksiban a megoldást - a tucatnyi programnyelvet beszélő kolléga problémája, akkor egészen más gondolataim támadnak.
Nyilvánvalóan elfogult vagyok. Pedig nemrég egy szoftveresre volt szükségem, ezért felhívtam egy ismerőst, mert ők sok szoftverest alkalmaznak. Előadtam a kívánalmaimat: Nem bonyolult, de pontos megbízható programokat kell írni. A válasz vége: "Halkan mondom, de még a szart is felvesszük. Nincs választék."

Na jó, 1 assemblerrel tényleg nem verem le a cölöpöt. De a 12 nyelven beszélő programozót igen!
A feladat: USB 2.0 full speed HID - maximum 1000 db 64 bájtos blokk másodpercenként.
Segítettem: Kell egy magas(abb) prioritású thread, amely csak azt csinálja, hogy az érkezett blokkot bedugja a bufferbe. END
Két hónap múlva jön a kifogás, miszerint az én programom rossz lehet, mert egyes blokkok hiányoznak. - Megcsináltad amit mondtam - Nem. - Akkor csináld meg!
A végén a két zinformatikus (szerintem ketten már 24 nyelvet is beszéltek), letöltött egy Core i7 lassító programot :-D és azzal tesztelt. A büdös blokkok meg csak nem akartak elveszni! ;)

Ebből aztán sok következtetést lehet levonni. Pl. a 12MHz-es effektív órajelű PIC leverte a Core i7-es MacBook Pro-t. ;) Lehet sopánkodni a Windows miatt is. Bár a Windows jól elvan a sokkal nagyobb sebességű, akár USB3 kapcsolattal, GBE is megy neki. Igaz, mindezeket lényegében hardver végzi, míg a programozó csak egy logikai interfészt lát.

Ezeket a dolgokat tényleg C-ben, assemblerben lehet hatékonyan programozni. De úgy néz ki, hogy a C# és a java is kiválóan megbírkózik vele - HA a programozók is hagyják. :-D

Akkor egyetérthetünk, hogy nem az új nyelv miatt nem tud hasznos munkát végezni órák után, hanem a környezet miatt.
Ha 5 hónapig tanulná a nyelvet külön és odaülne egy ismeretlen projekthez, libekhez, ..., akkor sem tudna, csak sok idő múlva haladni.
Hasonlóan, attól is kevésbé függ, hogy az új széken mennyi idő alatt tud értelmesen munkát végezni. Ez nem az új széktől függ. Hiába ülne rajta hónapokat, akkor sem fejlődne ebben.

Azért infláltam, hogy megértsd.
Mások egyből értették, infláció nélkül is, te meg kiragadtad a 24 órát.
Pedig....

"ahol volt 1 tucatnyi C#-os, és csak a "tök ugyanaz" Java-ra kellett volna átszokni, de hónapok után sem sikerült mindenkinek. És nem az volt a gond, hogy ne tudta volna leprogramozni"

Ezzel lényegében helyt adtál neki, mert te magad mondtad el, hogy "hamar" átszoktak C#ról Javara. Amit utána írtál az meg már nem nyelv specifikus, hanem környezet, projekt, nevezd aminek akarod...
S lényegében itt nem arról van, volt szó, hogy beilleszkedjen az adott nyelven valahova, vagy bekapcsolódjon egy projektbe, hanem hogy az adott nyelvet mennyi idő elsajátítani, ha megvan az előzetes háttérismeret, szemléletmód hozzá más programnyelven.

De akkor mégjobban lebaltásítom...
Először amikor plc-t programoztam, Mitshubishit, hónapok teltek el. Akkor láttam életemben először létradiagrammot, alig állt rá az agyam és stb. stb.
De végigcsináltam, és ma már több országban, összesen több mint 50 ilyen ipari berendezés fut hibamentesen.

Másik ilyen találkozásom Delta PLC-vel volt, el is bíbelődtem vele vagy 3 hetet (elég sokat...)

Hát ha most elém raknál egy Siemenst, vagy Omront, vagy válassz egyet te melyiket, és nem menne a dolog max "nettó 24" óra (azaz evéssel, alvással, szarással ez max 3 nap....) alatt, akkor szellemi fogyatékos vagyok, vagy részeg....
S aztán ha megismertem az adott plct, jöhet a feladat megvalósítása...az meg már feladatfüggő, hogy a "kész termék" mennyi idő alatt készül el.

A legnagyobb gond azzal van, hogy az "Enterprise" szoftverfejlesztés vált standarddá, és a nagy cégek, az oktatók és a programozók többsége azt gondolja, hogy azok alapján lehet jó minőségű programokat készíteni.
Holott pont azon elemek miatt lesz nagyon rossz minőségű a program.

Vannak akik ezt felismerték, vannak akik csak egy részét ismerték fel.

Ha találkozol ezen szimptómákkal, akkor Te is rossz minőségű kódon dolgozol:
- az idő előrehaladtával egyre több időbe kerül egy-egy funkció beépítése,
- nem nagyon mersz egy-egy kódrészlethez nyúlni,
- ha valahol módosítod a kódot, akkor valahol másutt elromlik valami,
- nem érted, hogy az adott kód részlet miért nem működik jól,
- nem érted, hogy az adott kód részlet miért működik jól,
- nem érted, hogy Nálad miért működik jól, másnál vagy éles rendszeren meg miért rosszul,
- nem érted, hogy Nálad miért jó a performancia, másnál vagy éles rendszeren meg miért rossz,
- időnként rejtélyes hiba lép fel valahol,
- egy hiba megkereséséhez nem tudod hová kellene töréspontot rakni,
- egy hiba megkereséséhez nem tudod hová kellene naplózást tenni és mit kellene kiírni,
- teszteléshez Mock (stub)-ot kell használni,
- már nem öröm a programozás az adott kódon.

üzemeltetőként én sokszor már annak is örülnék, hogy ha azok a "programok", de nevezzük inkább kódkatyvasznak, amik a cégen belül hozzánk kerülnek élesítésre úgy készülnének, hogy:
- van egy elfogadott spec, ami alapján fejlesztik, és nem ad-hoc találna ki a fejlesző dolgokat
- van róla egy olyan élesítési doksi, amit bárkinek odaadva ki tudja tenni élesbe az adott programot, mert nekünk aztán végképp lövésünk nincs, hogy a program hogyan működik. amikor van 20-30 alkalmazás egy 4-5 fős csapatra, viszonylag nehéz megérteni mindent, míg a fejlesztési oldalon 1-2 ember foglalkozik 1-1 alkalmazással. Tehát ők csak azzal az egy rendszerrek kelnek és fekszenek.
- élesítés előtt tesztelnék, és nem akkor derül ki, hogy az új verzió funkcióinak a fele vagy egésze nem vagy rosszul működik, amikor kitesszük élesbe este 11-kor...
- legalább a fejlesztő tisztában lenne azzal, hogy az általa készített program mit csinál, és hogyan működik, de ha mégsem, akkor log-ot írna a program, és nem csak egy felugró ablakban kiírja, hogy "hiba!"

A hibaág kezeléséről már álmodni sem merek.
Bár a dologhoz hozzá tartozik, hogy nálunk a szervezői/fejlesztői csapatnál ettől komolyabb gondolkodásmódbeli problémák is vannak.

Ja, és az sem volna baj, ha tudnák, és dokumentálnák a fejlesztők, hogy a programjuknak mikre van szüksége, és azokból milyen verzióra.
Volt már, hogy frissítettem fejlesztő új progijával, és megsuvadt az egész. Majd egy fél napot nyomozott a saját programjában, mire rájött hogy milyen liblóf*aszból használ ő újabbat mint a prod rendszer.
De erről már másik topic-ban írtam valami szeretetteljeset... :)

---
"A megoldásra kell koncentrálni nem a problémára."

Az igazán jó programozók tudják, hogy ezeknek a szabályoknak mi az eredete, és mikor lehet áthágni őket. Mikor van fontosabb egyéb szempont?

Az igazán jó programozók talán távolról követik az új divatokat, de nem ugornak bele fejest gondolkodás nélkül. És főleg nem várják azt, hogy egy új eszköz majd minden problémájukat meg fogja oldani. Nem fogja.

Néhány szabály:

* A programozás során a legszűkebb keresztmetszet az emberi felfogóképesség. Ezért az egyszerűségre kell törekedni, arra hogy a lehető legkevesebb dolgot kelljen egyszerre fejben tartani.
* Ha egy konstanst csak egyszer használsz, akkor _NE_ emeld ki konstans változóba! Növeli a sorok számát, és plusz egy indirekció, ami feleslegesen bonyolítja az értelmezést! Ha elfelejted, hogy már használtad egyszer, akkor legközelebb használva úgyis újradefiniálnád más néven.
* DRY - Don't Repeat Yourself! Írd le százszor, mert ez a legfontosabb!
* Ha egy mintát többször használsz, akkor nézd meg, hogy lehet-e általánosítani és kiemelni függvénybe vagy makróba!
* Amit lehet egy repóba tegyél, és kerüld a külön verziózást! Amit lehet kezelj belső API-ként, amikre nem vonatkozik a nehezen változtathatóság és a visszafelé kompatibilitás őrzése!
* Belső API-kon nem kötelező a mezők setter/getterbe rejtése: felesleges sorokat generál, és ha szükség lesz rá, akkor az IDE megcsinálja a bekapszulázást. A hasonló formára vonatkozó szabályokat is kezeld lazán, ha úgy látod helyesnek!
* Amit lehet - a külső függőségeid közül is - forrásként importáld az IDE-be. Az API dokumentáció sosem lesz olyan pontos, mint a forráskód, időnként nem árt beledebuggolni, beleolvasni a könyvtárakba is.

Gyakorláshoz módszerek: mivel az emberi felfogóképesség a szűk keresztmetszet, ezért ezt kell fejleszteni. Különösképpen a munkamemóriát!

* Nemtriviális méretű programot írj meg IDE támogatás nélkül parancssori fordítóval! Mivel nehézkesek a körbefordulások, illetve a keresés, ezért javítja a koncentrálóképességet és a memóriát!
* Írj nemtriviális programot papíron úgy, hogy arra törekedj, hogy begépelve egyből működjön!
* Nemtriviális programot debuggolj kizárólag trace üzenetekkel, debugger nélkül!
* Nemtriviális valósidejű programot debuggolj oszcilloszkóppal! Csinálj hozzá szimulátort!
* Írj programot (legalább programrészt) assembler nyelven!

Nem ezek a legfontosabbak, csak éppen ezek jutottak eszembe. És ezek az ellentmondásosak, amik vihart generálhatnak jó esetben :-)

Jó, akkor ne viccelődjünk!
Amíg egy 50x komplexebb program elindul 2 másodperc alatt, addig a kollégák szinte semmit nem csináló programja 25 másodperc alatt. Legyen az a fejlődés célja, hogy a huszonöt kettővé váljon! És nem érdekelnek a magyarázatok!
Persze, ha engem kérdezel, akkor a fenti esetben kevés és kis komplexitású dolgokat tartottak fejben a kollégák. A vicces tanácsokat megfogadva meg támadt volna lila fingjuk arról, hogy egy számítógépet programoznak.

Jól kiragadtad az elindul részt, de az csak példa volt...de maradjunk a sebességnél. Lehet, hogy téged az nem érdekel, de amikor egy komplex futás mondjuk nyolc órás, este tízkor tudod elkezdeni és az üzemszerű működés szerint reggel hétre végezni kéne, akkor elkezded keresni, hogy kinek a gány kódja miatt ilyen lassú és ki miatt mész igazgatói raportra, ha hiba van és reggel nem nyit ki a cég, mert futás ismétlés van. Ennyit hát a sebességről. De ugyanez a kisebb kódokra is igaz. És nem csak az idő tekintetében.

Barcsak egyszer olyat olvasnek a hupon, hogy elvek vegtelen ismetelgetese helyett a feladathoz valasztana valaki az eszkozt. Idore is lehet optimalizalni, karbantarthatosagra is, koltsegre is, eroforras-igenyre is, meg meg ezer dologra, de altalaban max 1-2 dologra egyszerre, ezert donteni kell. Nem hittem volna, hogy ezen ennyire sokat kell rugozni.

> szerintem 0 fejlődést lehet elérni velük

Miért? Én indokoltam is, hogy talán a legfontosabb a munkamemória tornáztatása. Illetve lentebb írták a lépegetést a kicsi és a nagy kép között, amire szintén jók ezek a módszerek. Ha szerinted ezek nem tornáztatják az agyat, akkor miért nem, és mit ajánlanál helyette?

> ne kevés darab, hanem kis komplexitasu dolgot kelljen fejben tartania egy programozonak.

Igen is, de a sok darab egyből bonyolult is lesz az emberi agynak még akkor is ha külön-külön egyszerűek.

Mivel az agyi kapacitás a szűk keresztmetszet, ezért javaslom hogy az agyat tornáztassuk akár túl bonyolult dolgokkal is, élesben viszont törekedjünk az egyszerűségre.

Nem jól fejeztem ki magam. A cél a komplexitás alacsonyan tartása, mindegy, hogy darabszámmal vagy egyszerűbb dolgokkal.

Az emberi memória fejleszthető, igen, pl.:
https://www.cell.com/neuron/fulltext/S0896-6273(17)30087-9?_returnURL=h…

Viszont ennek azért bőven vannak felső határai - lehet, hogy 10 egységnyi komplexitású helyett majd 20 dolgot tudsz fejbentartani egyszerre, de 10-ről 100-ra természetes körülmények között, edzéssel sosem fogsz felugrani. Ezért tartom inkább viccesnek ezeket a gyakorlatokat, mint valódi hasznot hozónak.

Pedig lényeges, ha belegondolsz ugyanannak az érmének két oldaláról beszélünk. Azt mondod, hogy egyszerűsíteni kell a megoldást, hogy beleférjen az ember fejébe. Sokszor levinni 10-ről 7-re a fejbentartandó dolgok számát komoly erőfeszítés. És levinni 5-re szinte lehetetlen. Ha mondjuk egy zseni programozó tud 10-et, egy jófejű 7-et, egy gyenge meg 5-öt, akkor az adott problémát a zseni meg tudja könnyen oldani, a jófejű rengeteget gondolkodva és a problémát egyszerűsítve (az egyszerűsítéshez persze nem ártana zseninek lenni...), a gyenge viszont fel sem ér hozzá.

Gyakran az 5 és 7 közötti kis különbségből adódik hogy egy problémára lesz-e megoldás, vagy nem. Aki meg eljut a tízig, az már egy egész más perspektívát lát ugyanarról a problémáról.

Erre szokták mondani, hogy ha a gyenge programozó nem érti, akkor nem jó a megoldás. Amivel részben egyet is értek, a probléma csak az, hogy a probléma dekompozícióját csak olyan tudja megcsinálni, akinek megvan hozzá a képessége. Például azért mert képes fejben tartani több dolgot is egyszerre. A gyenge programozó tehát csak más által előre megrágott problémákat tud kezelni. Vagy csak egyszerű dolgokat.

A munkamemória fejlesztésére irányul a matek oktatás nagyrésze, főleg a feladatmegoldások. A témakör első feladataiban 1-szer kell alkalmazni a tanultakat egy számon. Aztán amikor már kialakult a séma a fejben, akkor kétszer, aztán visszafelé, aztán oda-vissza háromszor, végül általánosítva N-re. Aki rendesen végigjárta ezt az iskolát, az pontosan ezt a fajta képességét fejlesztette.

Az általam javasolt gyakorlatok ugyanerre irányulnak, csak programozós kontextusban.

Sajnos van egy másik megoldás is arra, hogy sok dolgot kelljen megjegyezni.
Egyszerűen csak nem akarsz megjegyezni mindent, sőt, még csak tudni se akarsz róla.
Ezt a megoldást szokták alkalmazni mindenhol.

Lásd pl. Exception.
Fogalmad sincs, hogy mikor, mi, hogyan kezeli a hibát, egyáltalán, hogy mi, milyen hibát dob.
Nem szúr szemet, meg sem próbálsz utánanézni, főleg nem megjegyezni.
Hasonló a DIc is.

Mi az a DIc?

Persze, vannak trükkök, amikkel lehet csökkenteni az egyszerre szem előtt lévő bonyolultságot, és érdemes is. De a vége mégiscsak az, hogy a problémáknak vagy egy inherens bonyolultsága, ami magából a problémából adódik, és nem lehet kiküszöbölni. Ha eddig eljutottunk, akkor mondhatjuk, hogy megszabadultunk a sallangtól, és a lényegre sikerült fókuszálni.

DIc = Dependenci Injection container.

A problémából adódó bonyolultságot nem lehet csökkenteni, de valamelyest el lehet rejteni, ahogy írod is.
A probléma viszont abból van, ha mi magunk adunk hozzá bonyolultságot.
A legrosszabb az, ha olyan bonyolultságot adunk hozzá, amit még el is rejtünk.
Pl. Exception, DIc, mutating, ORM, ...

Hú, a DIc-et én is utálom. Ebben legalább egyetértünk :-). Pár éve lett divat, azóta senki nem tudja, hogy mi történik a rendszerek belsejében.

Az Eclipse-t újraírták DIc-cel sok év alatt, és a vége az lett, hogy évekig senki nem tért át az új verzióra, mert folyton eseményviharok törtek ki, amik kővé lassították a rendszert. Évek alatt nagyjából kifaragták használhatóra.

Nézd meg ezt a kommentem, abból látszik mi a bonyolult az Excption-ökkel.
Ha figyelmesen átgondolod, akkor rájössz a DI egyik nagy hibájára is:
- fogalmad sincs, hogy mi fogja implementálni, így azt sem tudhatod, hogy ténylegesen mit fog csinálni.
Ha ténylegesen tudni akarjuk, hogy mit csinál, akkor az összes implementációt meg kell néznünk.
Pl. az exception-ös példámnál, lehet, hogy az egyik implementáció dob exception-t, a másik meg nem. Így, ha egy interfésznél biztosra akarsz menni, hogy dobhat-e RuntimeException-t, akkor minden implementációját meg kell nézned. Ha nem dob egyik sem, majd utólag az egyik dobni fog, akkor kerülhetsz bajba rengeteg helyen, ahol használva van.

Ugyanez a baj minden más absztrakcióval is.
Előnyük, hogy
- a problémateret szétdarabolják, így egy-egy részt könnyebb megérteni önmagában,
- könnyedén le tudod cserélni másra,
- sokkal több helyen és több mindenre használhatod.
Hátránya, hogy
- nehezebb az egészet megérteni, hogy ténylegesen mit csinál,
- utólag is módosulhat, hogy ténylegesen mit csinál, anélkül, hogy bármi átírásra kerülne.

"azt sem tudhatod, hogy ténylegesen mit fog csinálni." de ez nem csak a DI-al problema (gonsolom az IoC-re gondolsz most), hanem meg egy rakas design patternnel is, kezdve pont a Dependency Injection Design Patternnel, ami egy alap minta a code copling elkerulesere. Vegtelenul leegyszerusitve ket valasztasod: interface moge rejted a mukodest es ezzel a problemaval szembesulsz vagy coupled lesz a kod. En a elobbit preferalom, minden hibajaval egyutt.

Vegtelenul leegyszerusitve ket valasztasod: interface moge rejted a mukodest es ezzel a problemaval szembesulsz vagy coupled lesz a kod.

Pontosan!
Az egyszerűbb mindig a jobb!
- Ha egy helyen fontos a lecserélhetőség, akkor ott a kettő közül a DI az egyszerűbb, mert a másik nem is jó oda.

- Ha nem fontos a lecserélhetőség, akkor meg a tight coupling a jobb, mert a kettő közül az az egyszerűbb. Számtalan esetben használunk erős kötést, fel sem tűnik és nincs velük semmi gond. (BigDecimal, String, ...) A gond az, hogy számtalan helyen használunk DI-t, pedig nagyon kevésszer használjuk ki a lecserélhetőséget. Ha elkezdjük a DIc-et használni, akkor meg végünk is van, mert mindent csak úgy tudunk felhasználni, ha injektáljuk.

"pedig nagyon kevésszer használjuk ki a lecserélhetőséget"  mert nem irtok teszteket ;) mert vegulis a teszt is egy lecsereles. Nekem az a bajom a tight couplinggal, hogy nem eredmenyez tesztelheto kodot. Es igy nincs is baj, amig olyan side effectecrol beszelunk, amiknek full specifikalva van a mukodese, es ugymond megbizunk benne: BigDecimal, String, .... A baj az amikor nem ilyen "primitivek" is ossze vannak tarsitva.

"Pl. az exception-ös példámnál, lehet, hogy az egyik implementáció dob exception-t, a másik meg nem." Ha van a signaturaba checked exception, akkor tudod, hogy dobhat hibat, es eldontheted, hogy kezeld vagy tovabbdobod. Es ettol tok fuggetlenul barmilyen hivas dobhat runtime exceptiont, es szinten eldontheted, hogy kezeled vagy tovabb dobod. Elobb utobb a hivasi lancon kell lennie hibakezelesnek, az ellenorzott kivetelekre is meg a futasideju tarsaikra is.

Szerintem nem bonyolult se az Exception, se a DI, ha nem idiota modon vannak az exceptionok meg az interface-ek hasznalva.

pl random hibat dobni anelkul hogy az interfaceben definialnank ,az anti pattern https://community.oracle.com/docs/DOC-983543#throwingException
Aki csinalja azt lampavasra kell huzni.

A SOLID, azon belul az L, a Liskov behelyettesitesi elv lenne alkalmzva a kodban, es nem defaultban minden osztaly orokol 20 masiktol, akkor a DI is egy jo koncepcio.

 

Az Exception teljesen jó dolog, és pont azért jó, amit ellene hoztál fel: egyszerűsíti a kódot és leveszi a programozó válláról azt a terhet, hogy fejben foglalkoznia kelljen még több mindennel. Pl. egy C-ben írt szerverben valahol jó mélyen biztosan vannak socket(), bind(), listen(), accept() hívások, amelyek mindegyikénél gondolni kell rá, hogy ellenőrizd a visszatérési értékeket. Ugyanez Javaban elhagyható - az egész cuccot beteszed egy try-catch blokkba, és minden szépen "elintéződik" anélkül, hogy gondolkodni kellene. Szerintem ez jó, mert ettől több kapacitása marad a programozónak, hogy a fontos dolgokra figyeljen.

Egyszerűen csak nem akarsz megjegyezni mindent, sőt, még csak tudni se akarsz róla.

Sok embernek ez a megoldás tetszik, mert egyszerűnek látszik. Az ilyen megoldással lehet írni a rossz minőségű kódokat.

Ugyanez Javaban elhagyható - az egész cuccot beteszed egy try-catch blokkba, és minden szépen "elintéződik" anélkül, hogy gondolkodni kellene.

Tudom, hogy minden példa rossz, de ez ugyanolyan megoldás, mint amikor a 24 tételes vizsga esetén úgy egyszerűsítesz, hogy 20 tételt kihagysz. 4 tételt sokkal könnyebb megtanulni, mint 24-et!

Nézzünk egy programozási példát!

public BlogPost update(...) {
  storage.store(post);
  tempFileService.removeTempFile(post.fileName);
}

- Szép egyszerű megoldás!
- Valóban?
- Nem. ;-)

A gond az vele, hogy a store hibája esetén nem törli a temp fájlt.

- Persze, hisz try-catch-be kellene rakni a store-t!
- Miért? Minden sort try-catch-be kell rakni?
- Nem, hülye, csak azt ahol hiba lehet és fontos, hogy az utána levők is lefussanak.
- Ja, OK, de honnan tudom, hogy a store-ben hiba lehet?
- Szól az IDE (Checked exception).
- Itt most nem szól.
- Akkor ott van a store dokumentációjában, hogy RuntimeExceptiont dob.
- Itt nincs ilyen.
- Akkor nézd meg a store forrását.
- A storage egy interféce.
- Akkor keresd meg, hogy mi implementálja.
- Megvan, csak ennyi van benne: repository.save(post). Itt se szól az IDE és nincs a doksiban sem, persze a repository is interfész.
- Kutakodj tovább!
- Megvan, CrudRepository.save. Itt se szól az IDE és nincs a doksiban sem, persze ez is interfész.
- Kutakodj tovább!
- Megvan, SimpleJpaRepository. Ez már nehezebb volt, mert a neten kellett keresgélnem. Ebben az EntityManager persist és merge metódusát hívja. Azoknál sem szól az IDE, de a doksiban benne van, hogy EntityExistsException-t, IllegalArgumentException-t és TransactionRequiredException-t is dobhat.
- Na látod! Ezért kell azt belerakni try-catch-be. Máskor ne légy ilyen figyelmetlen, minden sort kövess vissza! Ilyen egyszerű ez, ha megakarod érteni, hogyan is működik ténylegesen!

Ezt a problémát fordítva szokás megfogni ezzel a gondolkodási mintával:

 * Minden dobhat exceptiont - legalábbis úgy vesszük erőforrásfelszabadítás szempontjából

 * A "kézzel" felszabadítandó erőforrásokat mindig try/finally close-mintával kell használni. A Java-ban az AutoClose osztály és a hozzá való try(AutoClose x=createResource()) minta tartozik ide. A fordító szól ha ezek nem jól vannak használva. Az egyetlen ahol gondolkodni kell az az, ha átadunk egy ilyen erőforrást paraméterként, és a fogadó oldalnak átpasszoljuk a zárás felelősségét. Ezt viszont többnyire el lehet kerülni. (De lehet, hogy erre is van valami annotáció, csak én nem ismerem.)

Azt elismerem, hogy még erre is egy kicsit figyelni kell. Bár ha csak az autoclose mintát engedjük meg, azt tudja ellenőrizni a compiler.

Hogy oldod meg ugyanezt az általad propagált csodamódszerekkel?

Minden dobhat exceptiont - legalábbis úgy vesszük erőforrásfelszabadítás szempontjából

Miért csak az erőforrás felszabadítás szempontjából? A többi esetben működhet rosszul, ha egy hibát nem ott kezelünk, ahol kellene?

Ezt egyébként se tartaná be senki, mert nem is lehet, ha meg betartaná, akkor teli lenne try-catch-csel az egész kód, ami nem kissé lassítani le az alkalmazást és tenné teljesen olvashatatlanná a kódot.

A try-with-resource nem rossz megoldás, ha már exception-öket használunk.
Hátrányai:
- kicsit verbose,
- elfelejthető a használata,
- nem lehet több szálú végrehajtásnál használni,
- csak AutoCloseable-nél használható.

Hogy oldod meg ugyanezt az általad propagált csodamódszerekkel?

Pl. Execute Around mintával (dr. Venkat Subramaniamnak van egy jó videója erről), effekt könyvtárakkal.

> Miért csak az erőforrás felszabadítás szempontjából? A többi esetben működhet rosszul, ha egy hibát nem ott kezelünk, ahol kellene?

> Ezt egyébként se tartaná be senki, mert nem is lehet, ha meg betartaná, akkor teli lenne try-catch-csel az egész kód, ami nem kissé lassítani le az alkalmazást és tenné teljesen olvashatatlanná a kódot.

Ha nem ott kezeljük a hibát ahol kellene, az nem az eszköz hibája, hanem a használójáé. Az exceptiönt így kellene használni:

 * Ha exceptiön jön az azt jelenti, hogy a hívott oldal nem futott le jól. _Ami erre a műveletre épül_ annak a további futtatásának nincs értelme. A saját erőforrásait felszabadította, de a hívó fél erőforrásait nyilván nem tudja.

 * A catch helyét az határozza meg, hogy hol van az a pont, ahol hiba esetén is van értelme továbbfutni. Itt követik el a legtöbb hibát: teleírják catch-csel a programot, mert az ellenőrzött kivétel megköveteli. Pedig nem is tudnak kezdeni vele semmit, csak kiloggolják, és rossz értékekel fut tovább a program. Ez gyakori hiba, de én nem írnám az eszköz számlájára.

 * A legtöbb esetben nincs értelme a különböző kivételeket külön kezelni: a megfelelő helyen el kell kapni, és loggolni, usernek hibaüzenetet adni, vagy becsomagolva továbbdobni. Mivel a hívott fél mindent elvarrt, ezért nincs értelme megkülönböztetni őket. Ritka kivétel, ha például van értelme újrapróbálni - pl adatbázis tranzakció exception esetén.

 * Az ellenőrzöt kivételeket én sem szeretem, mert egyrészt arra utal, hogy ami nem dob ilyet, az nem dob semmit - dehogynem, RuntimeException-t bármi dobhat - másrészt meg arra sarkall, hogy ott is elkapjuk, ahol nem kéne - a throws nem ismerete miatt. Ezért nekem alapmintám, hogy elkapok mindent és becsomagolom egy RuntimeException-be. A másik, hogy minden függvényem throws Exception - mindent dobhat.

 

Szóval az exceptiön handling kicsit tényleg bonyolult, de hajlok arra, hogy ez inherens bonyolultság: a hibás esetek helyes lekezelése nem egyszerű feladat, és ahhoz képest ez még egy jó kompromisszum. Biztosan jobb, mint a C-ben gyakran használt kötelező visszatérési-érték ellenőrzés/elágazás végtelen mélységben. Pláne goto tiltással és egy visszatérési érték legyen formai követelményekkel karöltve szép mentális gimnasztika mindent megfelelően körbeiffelni.

Nézőpont kérdése, az execute around minta is tekinthető-e bonyolításnak? A vonatkozó stacoverflow oldalról:

https://stackoverflow.com/questions/341971/what-is-the-execute-around-i…

"It seems to me that the Execute Around Method is sort of like Inversion of Control (Dependency Injection) that you can vary ad hoc, every time you call the method."

Ráadásul a tipikus implementációban pont egy try/resource van benne. Mitől egyszerűbb ez, mint a try/resource?

Hátrányaiból ellenérvek:

> - elfelejthető a használata

compiler warningot tud adni rá, amit kezelhetünk errorként is

> - nem lehet többszálú végrehajtásnál használni

alapkiépítésben az execute aroundot sem. Több szálról használni egy erőforrást eléggé komplex önmagában, szerintem antipattern speckó esetektől eltekintve.

Szóval az exceptiön handling kicsit tényleg bonyolult, de hajlok arra, hogy ez inherens bonyolultság

Nem, ez nem inherens bonyolultság. Ez az amit hozzáteszünk az alap problémához. Itt esélyünk sincs, hogy eldöntsük egy adott helyen, hogy ott olyan hiba jöhet-e, amit ott kell lekezelni, vagy olyan, amit tovább kell engedni, vagy nem is jöhet hiba egyáltalán. Plusz a throw egy olyan goto, ami nem tudjuk hova ugrik, a catch meg egy olyan label, aminél nem tudjuk honnan ugrottunk oda. Ez nem inherens bonyolultság.

A másik, hogy minden függvényem throws Exception - mindent dobhat. ... és ahhoz képest ez még egy jó kompromisszum

Nem, ez nem jó kompromisszum. Senki sem tudja, hogy valami dobhat-e hibát vagy sem, ha igen, akkor miért dobja, mi okozza. Egy egy kód sor esetén fogalmad sincs, hogy ott el kellene kapni a hibát és lekezelni, mert olyan hiba jött, vagy hagyni tovább menni, vagy nem is agyalni rajta, mert ott nem jöhet hiba.

Több szálról használni egy erőforrást eléggé komplex önmagában

Effekt könyvtárak esetén a legtöbb esetben nem ad plusz bonyolultságot hozzá, nagyjából a problémából eredő bonyolultsággal kell dolgoznod.

Számomra (és sok más kolléga számára) ez sokkal egyszerűbb, átláthatóbb, gyorsabb, jobb, mint pl. ezt a C kódot nézni, hogy hol van benne a hiba:

errno = 0;
n = write(sockFD, msgrec->Data, msgrec->DataLen);
sprintf(line, "write errno=%1d wrote=%1d, desired=%1d\n", errno, n, msgrec->DataLen);
write(sockFD, '\n', 1);
if (n != msgrec->DataLen) {
  sprintf(line, "socket write error write=%1d, desired=%1d\n", n, msgrec->DataLen);
}

Mert ugye a kód nem jól működik, ha a TX offloading engedélyezett a hálókártyán - és milyen könnyű megfeledkezni a protokollimplementálás hevében (kell még egy enter a küldendő adat végére) bizonyos dolgokról...

C-vel régen volt dolgom, így nem biztos, hogy pontosan tudom mi az elvárt működés. Illetve nem látom, hogy mihez képest melyik az egyszerűbb. Itt két "ez" van és egy példa.

Itt van egyébként bármilyen hibakezelés a logoláson kívül?

Javaban a fenti működés így nézne ki kb. Exception-nel:
 

long errno = 0;
long n = 0;
try {
  n = write(sockFD, msgrec->Data, msgrec->DataLen);
} catch {
  n = -1;
}
line.printf("write errno=%1d wrote=%1d, desired=%1d\n", errno, n, msgrec.DataLen);
try {
  write(sockFD, '\n', 1);
} catch {
}
if (n != msgrec->DataLen) {
  line.printf("socket write error write=%1d, desired=%1d\n", n, msgrec->DataLen);
}

Nem hiszem, hogy erre gondoltál az egyszerűbb alatt.

Nem, egyszerűbb alatt valami ilyesmire gondoltam (ami nem valid java kód, de az elvet nézd):

try {
  socket.write(data);
  socket.write('\n');
}
catch (IOException e) {
  System.out.println(e.toString());
}
  

Szerintem ez sokkal egyszerűbb, mint mindenféle hibaflagekkel meg hasonlókkal bűvészkedni...

Igazából itt sincs nagyon hibakezelés, de fogjuk rá!
Így még egyszerűbb:

socket.write(data);
socket.write('\n');

Aztán valami majd elkapja a hibát vagy nem, de egyszerűnek látszik.

Ha hiba esetén újra akarod küldeni valamelyiket akkor máris nem lesz olyan egyszerű.

A hibaflagesnél ránézésre látod, hogy egy-egy sornál van-e hibakezelés vagy nincs (jó vagy rossz az más kérdés, de van-e valami). Az előző példádnál a 3. után volt egy if, ott volt valami "hibakezelés", az első kettőnél semmi.
Az én mostani példámnál nem látszik, hogy bármelyik is lenne hibakezelve, bár lehet, hogy valahol van valamelyik hívási ágon, akár mindegyiken. A mostani példádnál látszik, hogy van valami, de az nem, hogy melyiket kezeli, az sem, hogy egyik kezelése elfedi-e a másikat. Nem látszik, hogy a catch ág az első sor miatt van-e ott, a második miatt vagy mindkettő miatt vagy tök feleslegesen, mert egyik sem dobhat hibát.

Az egyszerűnek látszik és az egyszerű az nagyon nem ugyanaz.

A "buta" (egyszerű) dolgoknak, mint a hibaérték visszaadás,  az "okos" (bonyolult) dolgokkal szemben, mint az Exception, az a legfőbb előnyük, hogy gondolkodásra késztetnek és segítik a jó desgin kialakítását.
1. Itt visszajön egy hiba, de ezzel itt nem tudok semmit kezdeni,
2. akkor visszaadom itt is hibakódként,
3. de itt nem adhatok vissza hibakódot az interface miatt,
4. akkor ide már úgy kellene érkeznie, hogy itt nem keletkezik hiba,
5. a hívó részt át kell dolgozzam.

Az így átgondolt problémák miatt egyre jobb lesz a program felépítése, mert már feljebb, ahol tud is mit kezdeni vele a kód, kezeli a hibát és feleslegesen nem küld le hibát adó dolgokat. (Mellékesen gyorsabb is lesz és kevesebb erőforrást használ.)

Ugyanez Exception-nél így néz ki:
1. Itt visszajön egy hiba, de ezzel itt nem tudok semmit kezdeni,
2. tovább dobom, majd fent kezdenek vele valamit.

Így meg egyre rosszabb lesz a felépítés, egyre több olyan hiba dobódik lent, amire a felső szintek nem készültek. Minél régebbi a kód, annál nehezebb lesz hozzányúlni.

Off: az `0 < n < msgrec->DataLen` egyáltalán nem hiba, hanem egy teljsen legális, kezelendő kimenetel.

Szintén nem hiba az `n==-1, errno==EWOULDBLOCK` eset.

Hiba viszont a write után write szekvencia, mert felelegesen növelheti a hálózati forgalmat, vagy a masodik write tényleges elküldését késleltetheti a Nagle-algoritmus.

Ennél sokkal rosszabb a hiba a kódban, és konkrétan ebben a sorban van:

write(sockFD, '\n', 1);

Ha a write() hívás nem sikerül, akkor a hiba nincs kezelve, nincs hibaüzenet, nincs újraküldés, nincs semmi. Ez nyilván eltöri azt a protokollt is, amit a kliens meg a szerver beszél (hiányzik a másik oldal által várt enter karakter). És igen, a gyakorlatban van olyan eset, amikor az első write() sikerül, a második meg nem sikerül...

Mennyivel jobb lett volna egy try{} blokkba belerakni az egész write()-olós mizériát, aztán egy catch{} blokkban kezelni a hibát!... :-)

Az arányok sajnos egyáltalán nem ilyenek. Egy-egy jobb programozó akár 10x-100x produktívabb tud lenni, mint egy rosszabb - de nem amiatt, mert ennyiszer komplexebb dolgokat képes fejben tartani...

A matekoktatás hasonlóképpen nem a "memóriaméret" növeléséről szól, legalábbis nagyrészt nem. Vannak kis dolgok, amelyeket érdemes megjegyezni (pl. szorzótábla), de sokkal fontosabb az összefüggések felismerése, pl. hogy mi az összefüggés az összeadás és a szorzás között. Ezeket meg nem megjegyezni kell, hanem (ideális esetben) a kölkök maguktól rájönnek az összefüggésekre (persze némi rávezetéssel a tanár részéről).

Szerintem ezeket a dolgokat nagyon másképpen látjuk.

"a legszűkebb keresztmetszet az emberi felfogóképesség" hozzatennem, hogy debugolni nehezebb mint irni a kodot. Szoval ha tudasod legjavaval irod a kodot nem fogod tudni debugolni :)

"akkor _NE_ emeld ki konstans változóba" ez nem orok ervenyu szabaly, mi van pl a magic numberekkel?

Mi az a magic number?

Szerintem ha egy konstanst egyetlen egy helyen használunk, akkor nem érdemes kiemelni névvel ellátni, akár külön fájlba tenni stb. Pont ugyanakkora fáradság megkeresni a kódban a használatát - sőt akár egyszerűbb is, mivel ha baj van vele, akkor ebből az irányból fogunk rálelni - mint megkeresni a definiálás helyét. A definiálás több sor, plusz egy ugrás, pazarlás az emberi felfogóképességgel szemben.

Éppen ezért akár magic numbereket is írjunk bele nyugodtan a kódba! Pont azért írtam le ezt a véleményemet, mert fél évszázados hittel megy szembe, ami szerint ezeket mindig el kell nevezni, ki kell emelni, stb.

Ha már töbször használjuk, akkor van értelme elnevezni: nem csak azért, hogy meg lehessen változtatni - van ami tényleg soha nem változik meg  - hanem hogy keresővel gyorsan lássuk mit függenek össze.

Ellenben első használatkor ha nem tudjuk, hogy lesz több használat, akkor ne emeljük ki, mert ha nem lesz, akkor fölösleges erőfeszítés. Ha meg lesz, akkor is előfordulhat, hogy aki másodszorra használja, az nem veszi észre, hogy már van, és felveszi újra. Ilyet is láttam, ahol ugyanaz a konstans ki volt emelve többször különböző neveken. Mert a probléma ugye az, hogy felismerjük, hogy ez ugyanaz ami már egyszer szerepelt. És ezt bizony észből kell felismerni, a rendszer kevés segítséget ad - bár lehetne ilyen funkció, ami megkeresi az egyező konstansokat és végigvezeti a programozót rajtuk.

Szerintem nem erre gondolt, hanem az elsőre a listából:

https://en.wikipedia.org/wiki/Magic_number_(programming)

"In computer programming, the term magic number has multiple meanings. It could refer to one or more of the following:

  • Unique values with unexplained meaning or multiple occurrences which could (preferably) be replaced with named constants
  • A constant numerical or text value used to identify a file format or protocol; for files, see List of file signatures
  • Distinctive unique values that are unlikely to be mistaken for other meanings (e.g., Globally Unique Identifiers)
  • Variable values used to accumulate values of register (e.g. variable). It can be changed at any point in time."

De ha a fájltípus azonosítóra gondolt, akkor is tartom amit írtam: ha egy helyen szerepel csak a kódban, akkor felesleges változóba kiemelni.

+0.5, ha egyertelmu, akkor persze tokmindegy, de ha segiti a kod megerteset, akkor az egyszer hasznalatos konstanst is ki lehet emelni. Nem kell masik fajba, meg ilyesmi, akar a fuggveny elejen is elfer.

Pl. multkor egy szazalekos erteket visszaado fuggvenyt lattam, aminek az outputjat meg kellett szorozni tizezerrel. Kiderult, hogy ahol ezt az erteket felhasznaljak, az nem %-ot var, hanem bps-t. Ezt viszonylag konnyen ki lehetett talalni, de megsporoltam volna par perc kerdezoskodest, ha ez lett volna:

val someResult = // do something
val percentValueToBps = 10000
someResult * percentValueToBps

mint ez:

/* do something */ * 10000

(obviously ez egy egyszerusitett pelda, a fuggvenyben oda-vissza kellett valtogatni szazalek es bps kozott)

Pl. ha van egy I2C / SPI szenzorod és egyfajta drivert írsz hozzá, ezért elnevezed a regisztereket és azon belül az egyes konfigurációs biteket érthető névvel (pl. adatlap alapján), az azért tudja segíteni a munkát...
...ellenben azzal, amikor csak ödaböknek egy számot és találd ki, mit szeretnének vele...

Pont ezekben az esetekben zavar a konstansba kiemelés. Ha működik, akkor mindegy, nem nézegetem. Ha nem működik, akkor gyanakodhatok arra is, hogy rossz a konstans: össze kell vetni a konstans értékét az adatlappal. Amihez oda kell navigálni a konstans definíciójához: plusz egy indirekció. Amit nem kellene megtenni, ha oda lenne bökve a konstans a kódba.

Ilyen esetben ésszerűbb pl helyi kommentet használni: 1 sor legalább 2 helyett. Plusz elválasztó üres sorokkal együtt egy közepesen egyszerű driverben ez másfél-kétszeres fájlméretet jelenthet, amit másfél-kétszer annyi idő átlátni.

SPI.send(0x33); // Start temperature measurement command.

 

Igazából ez az egész szőrszálhasogatás: számomra nagyjából mindegy is, hogy melyik megoldást választja valaki. Ami rohadtul zavar az az, amikor egy ilyen esetben valaki ilyen 60-as évekből való (vagy legújabb csillivilli divat szerinti) ökölszabály szerint meg van győződve arról, hogy csakis az egyik megközelítés lehet a helyes. Nem. Meg lehet indokolni a másik megközelítést is, és rugalmasan kell ezeket tudni kezelni. És én úgy fogom csinálni ahogy nekem tetszik. És ha más máshogy csinálja tolerálom, nem hülyézem csak ezért le. Vagy csak magamban, LOL.

Meg lehet próbálni meggyőzni, vagy ha eleget fizetnek akkor betartom a megkövetelt guideline-okat.

Pont ezekben az esetekben zavar a konstansba kiemelés.

...pedig éppen ezekben az esetekben (is) lenne értelme.

 Ha működik, akkor mindegy, nem nézegetem.

...aztán módosítani kell a konfiguráción és veheted elő az adatlap különböző részeit egyidejűleg...

 Ha nem működik, akkor gyanakodhatok arra is, hogy rossz a konstans: össze kell vetni a konstans értékét az adatlappal. Amihez oda kell navigálni a konstans definíciójához: plusz egy indirekció. Amit nem kellene megtenni, ha oda lenne bökve a konstans a kódba.

Ha csak "magic numbert" írsz oda, akkor is hasonlítgathatod az adatlappal, de legalább minden egyes esetben, ahol használod.
A konstans definíciójához nem feltétlen kell odanavigálnod (bár jelen esetben az eszközhöz tartozó header fájlban jó eséllyel megtalálod), ezt az információt egy modern IDE azért elég könnyen előrántja, ekkor láthatóvá válik a definícióhoz tartozó "magic number" is.

Másfelől, ha nem működik, az sem biztos, hogy egyáltalán a kód problémája.
Lehet pl. SPI CLK polaritás/fázis vagy sebesség- (órajel) probléma is... mindenesetre nem baj, ha egyértelműen látszik, hogy mi történik (minek kellene történnie).

pl.:

{...}
	m.x = ADXL355_24_to_32bit(ADXL355_Read_Reg(dev->spi, XDATA, 3));
	m.y = ADXL355_24_to_32bit(ADXL355_Read_Reg(dev->spi, YDATA, 3));
	m.z = ADXL355_24_to_32bit(ADXL355_Read_Reg(dev->spi, ZDATA, 3));

	switch (dev->acc_range){
		case ADXL355_CFG_FS__2G:
			{...}
			break;
		case ADXL355_CFG_FS__4G:
			{...}
			break;
		case ADXL355_CFG_FS__8G:
			{...}
			break;
		default:
			break;
	}
{...}

 

Szerinted ehelyett a következő beszédesebb?

{...}
	m.x = ADXL355_24_to_32bit(ADXL355_Read_Reg(dev->spi, 0x08, 3));
	m.y = ADXL355_24_to_32bit(ADXL355_Read_Reg(dev->spi, 0x0B, 3));
	m.z = ADXL355_24_to_32bit(ADXL355_Read_Reg(dev->spi, 0x0E, 3));

	switch (dev->acc_range){
		case (0x01):
			{...}
			break;
		case (0x02):
			{...}
			break;
		case (0x03):
			{...}
			break;
		default:
			break;
	}
{...}

Én az ilyen SPI.send(0x33); soroktól tudok messzire futni, amikor n soron át csak ilyen "magic number"-eket küldözget, de sem egy kommentet nem ír mellé, sem az egész koncepció nem túl szerencsés.
Arduino kódokban eléggé jellemző ez a felépítés...

Nem állítom, hogy minden esetben kötelező lenne így használni, de vannak elég bonyolult eszközök is, ahol komplikált számításokat kell végezni, hogy egyáltalán használható adatod legyen.
Nem baj, ha, amit csinál a program, az legalább követhető... akár egy másik fejlesztő számára is...

Sok mindenen múlik:

Hogy szerepelnek a konstansok az adatlapon? Névvel, vagy csak egy táblázatba besomva? Hasonló szerkezetet csinálnék a kódban is. Ha többször van valami használva, akkor viszont én is nevet adok neki mindig, mert akkor már praktikus oka is van.

Az egyik kód mellé oda kell képzelni a konstansok listáját. A másikhoz viszont kommentbe odatenném, hogy mit hivatkozik a regiszter indexe, mire való az adott konstans. És máris pont ugyanannyira olvasható, de cserébe sok sorral kisebb.

Nekem mindkettő oké, és magamtól az egyszerűbbet csinálnám, ha módomban áll.

Van, ahol névvel szerepelnek, van, ahol funkció szerint.
Esetleg lehet, hogy valamely beállítással van jelenleg használva, de más körülmények között más beállítás kell.
Le lehet ezt írni érthetően is, hogy ne kelljen minden esetben adatlapot túrni (ismerni ettől még kell az eszközt), meg úgy is, hogy mindenképpen kelljen...

Egyébként mi lesz "sok sorral" kisebb?
Egyik esetben kommentben írsz le valamit, másik esetben a headerben definiálod egy beszédesebb névvel.

Egyébként azért is célszerűbbnek tűnik a beszédes név, mert egy ilyen eszközt több program is tartalmazhat, vagy adott eszközből lehet több egy rendszeren.
Itt gyakorlatilag a lényegi információ kerül az eszközhöz írt függvénykönyvtár helyett a kódban lévő kommentekhez, más projektnél, ugyanezzel az eszközzel meg vadászhatod össze máshonnan a miérteket (vagy jön az adatlap)...

...de mindegy, nem győzködni akarok, biztos van olyan eset, amikor az érthetőség szempontjából is fölösleges így kezelni.
pl. adott formátumú fájlt hozunk létre, akkor az mindig úgy kezdődik, hogy "xyz..." - itt bőven elég lehet, ha tudja a program, hogy így kell kezdeni, max. kommentben odakerül, hogy az az oka, hogy...

A konstansoknak nem csak az az értelme, hogyha esetleg változtatni kell az értéken, akkor csak egy helyen kell megtenni. Látszólag neked csak ez az egy feature-e érdekes. Hanem az is, hogy értelmet adjunk neki. Pont erről szól ez a szál, hogy kerüljük el a magic konstansok használatát (azaz, hogy csak oda van dobva egy szám, de nem látszik, az értéke miért pont annyi). A konstanst általában tudod definiálni a használhat helyétől nem messze, nem kell ugrálni a kódban. Az egy maradi gondolkodás, hogy a konstansokat mindenképpen tegyük egy helyre valahova a file elejére. Nyilván ez igaz lehet, ha valami sokszor használt konstansról van szó. De ha csak egy helyen használod, akkor felesleges. Tedd oda a használat helyéhez a konstansot. A sorok számával kapcsolatosan: nem az a lényeg, hogy valamit a lehető legkevesebb sorból valósíts meg. Ez is szempont persze, de kb. az utolsó. Tényleg úgy gondolod, hogy a komment az jobb megoldás, mint egy rendes nyelvi elem, a konstans? Csak hogy egy sort megspórolj?

 

Mi van pl. akkor, ha a kód megírása pillanatában úgy jön ki, hogy egy adott konstans csak egy helyen van használva, de utána aztán mégis több helyen lesz? Először odaírod a számot simán, aztán pedig kiemeled konstansba? Mi van, ha utána mégis csak egy helyen lesz használva? Akkor meg kitörlöd?

> Mi van pl. akkor, ha a kód megírása pillanatában úgy jön ki, hogy egy adott konstans csak egy helyen van használva, de utána aztán mégis több helyen lesz? Először odaírod a számot simán, aztán pedig kiemeled konstansba?

Általában igen. Ez is egy elv egyébként: semmit ne csinálj, amit nem feltétlenül muszáj. Ugyanezen okból nem írunk metódusokat amik logikailag oda tartoznak ugyan, de soha senki nem hívja meg az adott projektben. Majd ha tényleg kell, akkor megírjuk, addig csak foglalja a helyet.

> Mi van, ha utána mégis csak egy helyen lesz használva? Akkor meg kitörlöd?

Akár ki is törlöm, de inkább nem: ez nagyon ritka eset - hiszen csak a második használatkor emelem ki, és ennyi inkonzisztencia nekem belefér a végtermékbe.

Jó, hogy a hozzászólásom nagy részére nem reagáltál, de sebaj.

 

Mi az, hogy "feltétlenül muszáj"? Ha 2 helyen használsz egy konstansot, akkor se muszáj kiemelni. Simán odaírhatod mind2 helyre magát a konstansot. Még sort is spórolsz vele.

 

Mind1, különösebben nem látom hasznát, hogy erről vitatkozzak veled, mindenki úgy programozik, ahogy akar.

Ezen felül lehet, hogy az eszköznek annyit kell átadni, hogy 0x33, de ez valójában három, értelmezhető define-ból áll össze, ami a preprocessor után lesz 0x33 - a programkódban viszont beszédes, hogy miért annyi, és nem is feltétlen az érdekes, hogy az 0x33, hanem az, hogy a 4. és 5. bit 1-es és a 0. és 1. bit is az.

Ez jelentheti azt, hogy inverz megjelenítés, aktív üzemmód és mondjuk 20% fényerő.

Ha az adatnak jelentése van, akkor miért ne jelöljük a jelentését a programkódban, ha az segíti a munkát?

Ezzel nem értek egyet. Ha egy adott konstansot csak 1 fv. használ, és logikailag oda tartozik, akkor a fv-be érdemes tenni (arról nem is beszélve, hogy a fv-en kívül nincs túl sok kontextus. Emiatt lehet, hogy az adott konstansnak hosszabb, nyakatekertebb neve lesz, ha fv-en kívül deklarálod). Ha egy osztály használja az adott konstansot, akkor az osztályon belül érdemes deklarálni. Általában nincs semmi haszna annak, hogy összegyűjtjük a mindenféle konstansokat egy helyre.

Valoban nem voltam egyertelmu, es ezert bocsi. Amikor egy helyen hasznalsz egy "magic" szamot (nem minden szam magic :)), es nem teszed konstansba, akkor a futtato kornyezetre bizod, hogy hogyan dolgozik vele (ez alol kivetel, ha mar compile time eldolt minden tipus). Ha pl egy feltetel vizsgalatban szerepel, akkor a felhasznalas modja fugghet attol, hogy mi szerepel a masik oldalon (ami runtime dolog), ami szelsoseges esetekben okozhat problemat: WAT!. Mig ha kiteszed konstansba, a futtato kornyezet nem valthat tipust, ezert mindig ugymond a konstanshoz fogja hasonlitani a masik erteket.

From what I’ve seen personally and gathered from experts, great developers share several key traits. These are (in no particular order): the patience to fully understand the problem they’re trying to solve; the ability to hold a lot of information in their heads at one time; the ability to move quickly from small to large and back down again; and finally, deep knowledge of their primary tools. Of these traits, the first and last are ones you can easily teach yourself. The other two rely more on innate abilities although, of course, they too can be acquired through discipline and hard work.

https://blogs.oracle.com/javamagazine/really-know-your-tools

Igen, ezek jó tanácsok, hogyan legyünk "jó" programozók.
Olyan programozók, akik a mai projekteknél jól elboldogulnak.
Rossz kódot is tudja megérteni, tudjon rajta változtatni.

A mai programok és megoldások világában valóban ezek a legfontosabb szempontok.

Egy ideális világban pedig ezek lennének a jó programozó ismérvei:
Tudjon nagyon egyszerű kódot írni,
- ahol nagyon kevés dolgot kell fejben tartani,
- ahol a legegyszerűbb szövegszerkesztővel is jól lehet haladni,
- elég legyen egy absztrakciós szintet átlátni, ne kelljen folyamatosan fel-, leugrálni a szintek között.

A programozás legfőbb szabálya, hogy nincs szabály! :D

> Tehát, ha az egészségügyben a bérek nem csökkentek, az a fent említettekhez képest relatív béremelés.

Szerkesztve: 2019. 10. 31., cs – 06:50

Van egy nagyon fontos szabály, amelynek betartásával lehetne könnyen érthető, könnyen karbantartható, könnyen módosítható, könnyen tesztelhető, magas színvonalú programokat készíteni.
Sajnos azt az egy szabályt nem hogy nem tartják be, hanem minden eszközzel ellene mennek.
A probléma abból fakad, hogy bár a legtöbb fejlesztő ismeri ezt az egy szabályt, de nem tudja, hogy ez mennyire fontos szabály és nem alkalmazza szinte soha sem, vagy csak nagy ritkán.

Ez az egy szabály: a KISS (Keep It Stupid Simple), de jobban leírja az Occam borotvája.
Lefordítva: ha egy feladatra van két (vagy több) jó megoldásunk, akkor mindig az egyszerűbbet válasszuk.

Honnan tudjuk, hogy melyik az egyszerűbb? A legkönnyebb úgy eldönteni, hogy melyik a "butább", melyik tud kevesebbet.

Rengeteg vita volt ebben a topikban, hogy literált használjunk vagy konstanst.
Mind a két oldalnál remek, valid érvek és ellenérvek vannak.

Azt javaslom, hogy vizsgáljuk meg a fenti szabály fényében a dolgot!

A programozásban kétségtelenül a "legbutább" (legegyszerűbb) dolog a literál.
A konstans is az egyszerű dolgokhoz tartozik, az a legegyszerűbb absztrakció, de mégis sokkal "okosabb" (bonyolultabb), mint a literál.

A literál pontosan azt jelenti, amit látunk is, ott van definiálva, ahol használjuk.
Nézzük meg mivel okosabb a konstans!

1. A konstansnak más lehet a neve, mint az értéke.
2. A konstanshoz, a neve segítségével, jelentést társíthatok.
3. Máshol definiálhatom, mint ahol használom.
4. Egy konstanst több helyen is felhasználhatom.

Sajnos sokan úgy gondolkodnak, hogy egy eszköz minél több mindent tud, annál jobb, annál inkább azt használjuk, pedig pont fordítva lenne jó.
A konstanst csak akkor érdemes használni a literál helyett, ha a fenti négy szempont közül egy vagy több is fontos nekem. Ha egyik sem igazán fontos, akkor a literált válasszuk.
Ha valamelyik szempont fontos, akkor már nem tudjuk a literált választani, mert az nem tudja ezeket, ilyenkor kell a konstanst választani.

Miért ne az okosabb eszközt válasszuk?

Nézzük meg, hogy a konstans használata milyen problémákkal jár a literállal szemben!

1. A konstansnak más lehet a neve, mint az értéke.

Ezzel mindössze csak az a baj, hogy ahol használom, ott nem látom, hogy mi a tényleges értéke.
Modern IDE-k korában ez már nem gond.
Így van, de :-)
- Sima szövegszerkesztő esetén már nem olyan egyszerű látni az értékét.
- Ha csak a forráskódot nézem egy böngészővel, mert nem akarom letölteni és felkonfigurálni az adott forrást, akkor megint problémát okoz az érték megkeresése.

2. A konstanshoz, a neve segítségével, jelentést társíthatok.

Ha a társított jelentés pontos, akkor nagyon nagy segítség a megértésben. Ha pontatlan, akkor meg nagyon nagy hátrány lehet, mert mást értek alatta, mint amit kellene.

3. Máshol definiálhatom, mint ahol használom.

Itt a probléma nagysága attól is függ, hol van definiálva a konstans. Ha a felhasznált helyhez közel, akkor kicsi a gond, ha távol, akkor nagyobb! ;-)
A gond ezzel az, hogy ahol használva van, az függőségbe kerül azzal ahol definiálva van.
Lehet másik fájlban vagy osztályban, másik modulban, egy libraryban, vagy akár egy framework-ben is.
A függés miatt, ha tesztelni akarjuk vagy újrafelhasználni, akkor a függőséget is fel kell oldanunk. Oda kell rakjuk a másik fájlt vagy osztályt, másik modult, libraryt, vagy framework-öt.

4. Egy konstanst több helyen is felhasználhatom.

Itt az a probléma, hogy ha megváltozik az értéke, akkor nem biztos, hogy ez minden felhasználási helyen jó. Ilyenkor ellenőrizni kellene minden felhasználási helyet.

Konklúzió

Nagyon egyszerű kis absztrakció a konstans, nagyon hatékonyan tudja segíteni a programozók munkáját, de a nagyobb tudása mellé nagyobb problémákat is kapunk.
Ezzel ronthatjuk az érthetőséget, a karbantarthatóságot, az újrafelhasználhatóságot, a tesztelhetőséget és több hibalehetőséget is kapunk.
A konstanst csak akkor érdemes használni a literál helyett, ha a fenti négy szempont közül egy vagy több is fontos nekem. Ha egyik sem igazán fontos, akkor a literált válasszuk!