Hirdetés
Új hozzászólás Aktív témák
-
cucka
addikt
A módosíthatóságról beszélek.
A kopipásztázás azért baj, mert ha később módosítani kell azt a részt, akkor két helyen kell majd módosítani. Sokkal könnyebb lesz mindent elrontani, mert ugyanannak a kódnak mindkét példánya már külön életet él és egymástól elszigetelten feljődik. Ezáltal lehetséges hibák egész tárházát szabadítod magadra, és egy idő után sose fogod tudni, hogy ha lefeljesztettél valamit, akkor nem-e maradt ki egy eset, illetve nem-e rontottál el közben egy másik fícsört.
Ezért kell a kód módosíthatóságára odafigyelni. Az hozza magával azt, hogy nem lesz kopipászta, meg hogy rendesen kezeled a dependenciákat, meg a jól definiált input-output állapotváltozásokat is.
-
cucka
addikt
válasz
samujózsi
#166
üzenetére
Nem az újrafelhasználhatóságról szól, hanem a módosíthatóságról.
Az egy következmény, hogy így könnyű újra felhasználni a kódodat. Nem cél.Mit nem lehet érteni azon, hogy csinálsz valamit valamilyen céllal (módosíthatóság), aminek vannak egyéb pozitív következményei (újrafelhasználhatóság)?
Ha írsz valamit ami könnyen módosítható, akkor azt újra felhasználni is könnyű. Ha írsz valamit, ami újrafelhasználható, akkor az jó eséllyel nem lesz sem könnyen módosítható, sem könnyen újrafelhasználható. így érthető?
-
cucka
addikt
válasz
samujózsi
#161
üzenetére
Igen, akkor nem ment át a lényeg, kifejtem.
Amikor újrafelhasználható kódot írsz, akkor arra gondolsz, hogy a kódodat hogyan lehet majd később máshol használni. Például olyan absztrakciókat vezetsz be, amelyek a későbbiekben lehetővé teszik, hogy azt a darab kódot máshol is felhasználd. Ez totális tévút, többnyire hibás feltételezések alapján rossz absztrakciókat fog eredményezni.
A SOLID szabályai sokkal szűkebben vannak értelmezve, és egyáltalán nem az újrafelhasználhatóság miatt találták ki őket, hanem a szoftver karbantarthatósága miatt. A cél mindig az, hogy a forráskódban könnyű legyen a meglévő fícsöröket módosítani és új fícsöröket hozzáadni.Ha belegondolsz, a kódbázisod újrafelhasználható része framework-ökben és library-kban található, ráadásul a többsége nem is a saját kódod, hanem 3rd party.
Ahogy fejlődik a kódbázis, rájösz, hogy bizonyos részeket érdemes lenne újra felhasználni. Ha az említett betűszavakat betartva fejlesztetted, akkor könnyű lesz azokat a kód-darabokat kiemelni egy librarybe és pikk pakk újra felhasználtad a kódodat.
Ha előre próbálod kitalálni, hogy mit fogsz majd a jövőben újra felhasználni, akkor beviszed magad az erdőbe, haszontalan, túlbonyolított absztrakciókat fogsz kitalálni, és amikor valóban eljön az idő, hogy újra felhasználd a kódod, akkor rájösz, hogy az előre okoskodással pont ellentétes hatást értél el, és nem hogy megkönnyítetted az újrafelhasználhatóságot, hanem nehezebbé tetted.Ezt az egész a YAGNI betűszó kifejtése, ez az elv pont erről szól, hogy nem próbálj meg előre, kitalált feltételezések mentén okos lenni, mert az a tapasztalat, hogy nem szokott bejönni.
-
cucka
addikt
válasz
samujózsi
#156
üzenetére
Azért baromság, mert a szekér mögé kötöd a lovat.
A hosszászólásomban felsorolt betűszavak a követelmények, amiket be kell tartani.
A kód újrafelhasználhatósága az az egyik következménye annak, ha betartod a követelményeket.
Kivéve ha valamilyen framework-öt vagy library-t fejlesztesz, de ott már a tervezési fázisban szempont az újrafelhasználhatóság, nem kódolás közben találod ki.(#155) Dr. Akula
Nagyon sok cég van, ahol alacsony szakmai színvonalon folyik a munka. Nem csak magyar cégek, gondolj bármely multira, ahol 15 réteg nemzetközi menedzsment alján ott ül a minimálbéres kóder valahol Bangalore-alsón, hát ő pont leszar mindent, neki elég a minimum, hogy nap végén ne kiabáljon vele a főnöke. -
-
cucka
addikt
válasz
Dr. Akula
#150
üzenetére
Szerintem még nem dolgoztál olyan helyen, ahol magas színvonalú szakmai vezetés van.
Az elképzelhetetlen, hogy a kód minősége azon múljon, hogy mennyire lelkiismeretes a programozó.
Abban igazad van, hogy az emberek lusták és a kisebb ellenállás felé mozognak. De ahol vannak előre lefektetett minőségi sztenderdek, architekturális elvárások, automata kódminőség-ellenőrzés, megkövetelt unit teszt coverage és code review, ott az általad említett problémák egyszerűen nem merülnek fel. -
cucka
addikt
válasz
Dr. Akula
#139
üzenetére
A helyesírás rész arról szól, hogy vannak emberek, akik leszarják, hogy mit adnak ki a kezük közül. Akinek tele van elgépeléssel a CV-je, mert arra sem vette a fáradságot, hogy a Word-ben bekapcsolja a helyesírás-ellenőrzést, arra kár időt pocsékolni. (Nem elvből, pusztán csak alacsony a valószínűsége, hogy ilyen hozzáállással emberünk jó fejlesztő legyen)
Az agilis fejlesztésnek van értelme, valós problémákra ad valós választ. Erre ráépült egy ipar, akik Agile trainingeket meg certifikátokat adnak ki, az elég haszontalan, mert ha ráépítesz egy merev framework-öt és szabályrendszert, akkor pont az agilitás lényegét ölöd ki.
Ha hozzátok is jött valami Agile certifikátos bohóc előadni, hogy milyen szabályokat kell betartani, akkor nem vagytok agilisek, egyszerűen csak beetették a menedzsmentet a púderrel, és most ti isszátok a levét. -
cucka
addikt
válasz
Dr. Akula
#135
üzenetére
Ha jön 3 jelölt, egyik BME, másik Gábor Dénes, a 3. semmilyen "de kisdobosbecsszóra tudok olyat is" papírral, akkor azért tudsz köztük felállítani egy minőségi sorrendet?
Ha CV alapján kell dönteni, hogy kit kell behívni, akkor a következőket nézem:
1. munkatapasztalat
2. karrierív
3. igénytelenül szerkesztett CV, helyesírási hibák (akkor jó, ha ezek nincsenek, nyilván
)
Interjún egy 15 perces whiteboardozás alatt kiderül, hogy van-e miről beszélgetni vagy sem.Példa: mondjuk ITIL (jó, nem tervezési, hanem üzemeltetési hablaty, de a példa szempontjából ugyanaz)
Hát eddig szoftverfejlesztési módszertanról beszéltünk, arra mondtad, hogy haszontalan.
Szóval ilyen it management framework-öket meg iso szabványokat ne keverd ide.Lehet hogy Fejlesztő Józsit így bármikor ki lehetne rúgni, de ennek bevezetésére pont nem Józsi lesz a legnagyobb vevő ...
Nem a dokumentáció a probléma, mert az mindig, minden esetben, minden cégnél szar.
Az a probléma, hogy van egy spagetti rendszer, amihez csak a Józsi ért, és hatalmas időbefektetés külső embernek megérteni, üzemeltetni és továbbfejleszteni. (Az idő pedig pénz, szóval ezért rossz a kis cégnek ha ilyen helyzetben van) -
cucka
addikt
válasz
Dr. Akula
#125
üzenetére
Persze, annyit állítok, hogy ha látok egy ELTE vagy BME diplomát egy önéletrajzban, az alapvetően nem jelent semmit. Ezek nem messze földön híres minőségi képzések. Nem baj, ha van a jelöltnek innen diplomája, de az se baj, ha nincs.
(#127) Dr. Akula
A sok programozási módszertanból én csak azt látom hogy szép és jó, de leginkább arra való hogy az írójának nevet szerezzen. Amúgy meg kuka.
Mondj már egy-két példát erre, miről érzed azt, hogy a módszertan szerint hasznos de valójában kuka?
Szerintem van egy kis kavarodás itt, a módszertan arra jó, hogy a kódod olvasható, karbantartható, refaktorálható és integrálható legyen, plusz azt hozza magával, hogy a programozók lecserélhetőek legyenek. (Ez utóbbi nem szemétség, hanem komoly probléma sok kis cégnél, ahol valami amatőr Józsi 20 éve tákolja a szoftverüket, és emiatt a Józsitól nem lehet megszabadulni, akármennyire is visszaél a helyzetével) -
cucka
addikt
Hát korábban azt írtad, hogy ha az ügyfél nem hoz teljes specifikációt, visszazavarod az anyjába. Most azt írod, hogy leülsz vele és tisztázzátok a helyzetet. Nagyon nem ugyanaz, előbbiből az látszik, hogy laikus vagy, utóbbiból meg nem.
A matematikai bizonyítás részhez - az elgondolásod addig működik, amíg pure function-ökről beszélünk. Ahogy bejönnek a képbe a mellékhatások, az integráció a külvilággal és a futtatókörnyezet alsóbb rétegei, ott vége az okosságnak.
Sajnos, teszem hozzá, pure function-ökkel megfogalmazni egy megoldást nagyon tiszta, száraz és biztonságos érzés, de ilyenkor a fenti problémás részeket nem tudod megoldani, csak arrébb tolni időben, vagy eltenni szem elől. -
cucka
addikt
Garanciát szokás vállalni, aminek keretében kijavítottátok azokat a hibákat, amiket a megrendelő észrevett, és amelyek a szerződés szerint is hibának tekinthetőek. Itt eddig matematikai helyesség-bizonyításokról volt szó, ez nagyon távol áll attól. Plusz garantált, hogy a garanciális hibák mellett volt még százszor annyi hiba és hibásan működő edge case, amit az ügyfél nem vett észre, vagy nem terjedt ki rá a szerződés, és ezért ott van most is benne a kódban.
Worfklow diagramokat, meg egyebeket is szokás készíteni, ha ezt pszeudokódnak tekinted, akkor igen, van pszeudokód.
Amire ott utaltam, az a feltételezés, hogy bárki bárhol fejlesztés előtt kitalálná az algoritmust és leírná pszeudokódban. Ez nem szokott megtörténni, az említett diagramok ennél sokkal magasabb szintű absztrakciót képviselnek. -
cucka
addikt
senki nem foglalkozik azzal, hogy maga a szoftver milyen. azzal foglalkozunk, hogy az általa menedzselt szolgáltatások minősége eléri-e a szerződéses célértékeket.
Látod, megfogalmaztad a lényeget, csak nem akarod elfogadni.
A megrendelő, aki rettentő sok pénzt fizet, és amiből neked fizetésed lesz, neki nincs szüksége forráskódra. Neki arra van szüksége, hogy működjön a levelezése, elérjék a fileokat a felhasználók, menjenek a rendelések a webshopban, működjön a bi rendszere, meg hasonlók.Ettől még fontos az, hogy milyen a szoftver, a bugokat számon kell tartani, a risket menedzselni kell, a specifikációt hozzá meg kell írni (néha futtatható kódként, lásd BDD).
De azt elvárni, hogy a megrendelő komplett funkcionális speckót tesz le az asztalra, meg kifizeti, hogy te matematikailag igazolod a kód helyességét, ez teljesen a fantázia birodalmában van. És pont úgy vágyhatsz rá, mint ahogy én arra vágyom, hogy 2 méteres kigyúrt vizilabdázó legyek, de egyik sem fog megtörténni, tehát érdemesebb a mentális energiákat másra fordítani. -
cucka
addikt
-
cucka
addikt
De basszus, meg lehet oldani, lehet olyan szerződést kötni, amiben a hibákért kötbért fizet a beszállító, szoftveriparban is. Két dolog miatt nem teszik
- egyáltalán nem triviális definiálni, hogy mit jelent a hibás teljesítés, és egyáltalán nem triviális bizonyítani sem
- a kötbér kockázata benne lesz az árban, és azt se te, sem más nem fogja tudni/akarni kifizetniDe hadd kérdezzem meg, részt vettél már szoftvergyártási folyamatban akár beszállítói, akár megrendelői oldalon? Mert a hozzászólásodból az süt, hogy nem, csak lököd itt a saját feltételezéseidet meg fantáziáidat arról, hogy mi hogy kéne legyen.
-
cucka
addikt
szerinted lenne ennyi vírus meg szemét a hálózaton, ha a microsoftnak nem engedték volna meg azt a világraszóló disznóságot, hogy a szoftver "as-is"?
Nem engedték meg nekik, mert nem is kellett erre engedélyt kérjenek.
De hajrá, próbálj úgy dobozos szoftvert árulni, hogy kötbért vállalsz a bugokért, biztos remekül fog menni az üzlet.mert egy szoftverfejlesztő se meri azt mondani, hogy elmész anyádba, majd akkor gyere vissza, ha már konkrétan tudod, hogy mit akarsz
Igen, gondolom te is szívesen fizetnél egy ilyen szolgáltatásért rengeteg pénzt.
Halkan jegyzem meg, léteznek emberek, akiknek az a dolguk, hogy felmérjék az üzleti igényeket és ezekből funkcionális specifikációt írjanak.
Matematikai specifikációt meg a legtöbb esetben azért nem írnak, mert nem tudnak, egyszerűen túl nagy a komplexitás és túl sok az ismeretlen. Akkor se tudnának, ha 100x annyi idejük lenne rá.és ez jó lenne. azt lehetne garantálni, hogy a program megfelel a megrendelő által rendesen ledokumentált specifikációnak
Megint a fantázia birodalmában jársz, ahol a nem-tech iparági megrendelő pontosan le tudja specifikálni, hogy mire van szüksége.
De jó ötlet, tényleg jó lenne. Az is jó lenne, ha 2 méteres kigyúrt jóképű vizilabdázó lennék, de hát nem vagyok az.ja, a boeing is jól lespecifikált mindent, a 737max műszereitől kezdve ...
Mondjuk a 737max-nál tudtak a hibáról, és direkt a szőnyeg alá söpörték a piaci előny érdekében. Nem a specifikáció hiánya volt a probléma. A többi esetet nem vágom, lehet, ott igen. -
cucka
addikt
Ez megint olyan, mint ahogy a középiskolai informatikatanár elképzeli, hogy hogyan nézhet ki a szoftverfejlesztés a való életben.
- Minden program tele van hibákkal, és egy csomót soha nem fognak kijavítani, mert nem éri meg. Annak, hogy a fejlesztő szeret-e debuggolni vagy sem, nulla relevanciája van.
- A szoftverfejlesztés 99%-a nem algoritmusok kitalálásáról szól, alapvetően a nehéz problémáknál igyekszel elkerülni azt, hogy neked kelljen megoldani.
- Senki nem ír pszeudokódot
- Nincs olyan szakma, hogy programtervező matematikus. Olyan van, hogy solution architect és enterprise architect. Őket nem az egyetemen képzik, mert ezekhez a munkákhoz a beugró a sok éves fejlesztői tapasztalat. -
cucka
addikt
Olyan embereket akik képesek egy adott szakterületen algoritmusokkal, definíciókkal bizonyíthatóan működő tervet készíteni egy adott feladat megoldására. Ez a bizonyíthatóság ma teljesen hiányzik az IT "tervezés" 99,99999%-ából.
Ebből az jön le, hogy van egy elképzelésed a szoftveriparról, aminek köze nincs a valósághoz.
A szoftverek nagy része tágabb értelemben véve üzleti szoftver. Üzleti igényeket kell kielégíteni. Ha az elképzelésed alapján készülne a szoftver, akkor
1. A szoftver fejlesztési költségeihez beírhatnál egy 5x-ös szorzót. Nem fizetné ki senki, mert nem hoz annyit a konyhára, mint amennyibe kerül.
2. Az üzleti igények folyamatosan változnak, tehát a specifikációd is folyamatosan változna, a szoftver karbantartása szintén 5x annyiba kerülne
3. Ez a legfontosabb: semmi sem garantálná, hogy az általad leírt matematikai specifikáció valóban megoldja a megrendelő problémáját és kielégíti az üzleti igényekeit. A megrendelő szempontjából az egésznek nincs semmilyen haszna.Persze, vannak területek, ahol ez nem érvényes, pl. űrhajók vagy atomerőművek vezérlő szoftverét le kell specifikálni. De az átlag üzleti szoftvernél, ami a szoftveripar 98%-a, egyszerűen haszontalan.
-
cucka
addikt
Jó, kicsit túloztam. A lényeg, hogy a projekt elején akkor tudod kiküszöbölni a jövőbeli performance problémákat, ha mindent az utolsó csavarig megtervezel még mielőtt elkezdenél kódolni.
Szóval az utólagos performance optimalizálás az mindig része a történetnek, már amennyiben fontos a performance. Sok esetben egyszerűen nem érdekel, mert nincs akkora terhelés, ahol kijönne, esetleg nincs nagy nyereség a teljesítmény javításban, vagy -ahogy a legtöbbször- nem fizeti ki senki. -
cucka
addikt
válasz
Dr. Akula
#64
üzenetére
Egy magyarországi egyetemi papír semmilyen tudásszintet nem bizonyít. Túl sok interjút kellett végigüljek egyetemett végzett, programozni nem tudó emberekkel, nem hiszek már a mesékben.
(#66) opr
Az elméleted nagyon jó, ha waterfall-ban fejlesztetek és előre specifikálva van minden. Ami soha nincs így, tehát a PoC-ot is kenheted a hajadra. -
cucka
addikt
Igen, jobb cégeknél kezdettől fogva odafigyelnek a performance-ra, szerves része a rendszer fejlődésének. Leginkább olyan helyen fordul elő, ahol saját terméket fejlesztenek. Ahol más cégnek fejlesztenek szoftvert, ott nem erre optimalizálnak. Nem azért, mert hülyék, hanem mert nem feltétlenül éri meg.
Tipikus utólagos optimalizációs kérdés az adatbázis elérés. Megírod a legszebb kódot, Bob bácsi megnyalná mind a 10 ujját, aztán kiderül, hogy nem optimálisan használod az adatbázist. ORM használatánál rendszeresen előfordul, de nem csak akkor. Szóval egyáltalán nem ritka dolog utólag optimalizálni, csak kell legyen hozzá fűződő üzleti érdek is.
-
cucka
addikt
Az idő ott jön be, hogy első körben definiálni kell, hogy a szoftverednél mi számít "elég gyorsnak", és erre teszteket is kell írni. A cache-elést megcsinálni és belőni optimálisra szintén idő. Azt megcsinálni, hogy az alkalmazás átverje a felhasználót, az is idő.
Minden performance dolgot mérni kell, ha baj van, fixálni, ez is idő.És arra, hogy megéri-e erre időt (tehát pénzt) költeni, az egy nagyon nehéz kérdés.
Ha hozzám odajönnél azzal, hogy "a cégnek időt, pénzt és energiát spórol", akkor visszakérdeznék, hogy mennyi pénzt? Szerintem nem tudnál rá válaszolni. -
cucka
addikt
A gyors szoftver elsősorban skill és idő kérdése. Addig oké, hogy az egyetemen megtanítják, hogy a négyzetes algoritmus jobb, mint az exponenciális. Ez az első lépés.
Utána lehet gondolkozni a különböző adattárolási módok teljesítmény-karakterisztikáján, azon, hogy hogyan kezeld a network latency-t, hogyan kezdj neki a perf teszt írásnak, hogyan és mit cache-elj, esetleg hogyan dizájnold meg úgy az alkalmazásod, hogy átverje a felhasználót, és gyorsabbnak érződjön, mint amilyen valójában. Feketeöveseknek meg ott vannak olyan kérdések, hogy vajon a cpu optimálisan használja-e a cachet az adott compiler flagekkel, hogyan használod a memóriát, mennyire hajtod csapágyasra a gc-t, és így tovább.Vagy el lehet menni bármely játék topikjába, ahol a laikusok panaszkodnak, hogy ezek a segg programozók nem optimalizáltak eleget ezért szaggat a játék
. -
cucka
addikt
Igen, jól látod, ez a szomorú valóság.
Az emberek jelentős részének 3 év egyetemi programozóképzés után nincsenek meg a skilljei, hogy junior programozóként elhelyezkedhessen. (Illetve ha megvannak, azokat diákmunkával/szakmai gyakorlaton/otthon pluszban tanulva szerezte meg)Unit tesztes kérdésem továbbra is nyitott. Van valaki itt, akitől elvárták ezt az egyetemen?
-
cucka
addikt
Igen, több pozitív válasz is jött, hogy a kódminőséget nézik, lehet, hogy én jártam túl régen egyetemre, vagy csak pechem volt.
A unit teszt kérdés egyáltalán nem költői, az egy nagyon fontos dolog, ami alapvető skill minden programozó számára. (Márhogy azok számára nem, akik otthon tutorialokból tanulnak, de itt egyetemi szintű képzésről beszélünk)
-
cucka
addikt
A rendszerben gondolkodást ott sajátítják el a hallgatók.
Ez tök jó lenne, ha igaz lenne, de nem az.
Futószalagon jönnek a tárgyak, közötttük nulla kapcsolat, mindegyik önnálló egységként lóg a levegőben. Definíció-tétel-bizonyítás reggeltől estig, seggeld be és mondd vissza a vizsgán.
Ettől hol fog bárki rendszerben gondolkozni?Mutasson már valaki egyetemet, ahol megtanítják programozni a diákokat. Egy tárgyat, ahol a tanár veszi a fáradságot arra, hogy code review-t csináljon és visszadobja a beadandódat, ha működik de olvashatatlan.
Nem tudom, mostanában jobb-e a helyzet, régen simán elvégezted úgy a programozó egyetemet, hogy egyetlen unit tesztet sem kellett soha írni, jobb esetben leadták valahol a unit teszt definícióját és kalap.
)
Új hozzászólás Aktív témák
ph Egy francia felmérés szerint a fejlesztők harmada külső segítség nélkül sajátította el a szükséges készségeket.
- 35" ASUS ROG Swift PG35VQ curved GAMER monitor
- LG 55G4 - 55" OLED evo - 4K 144Hz & 0.1ms - MLA Plus - 3000 Nits - NVIDIA G-Sync - FreeSync Premium
- 120 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- AKCIÓ! Samsung Z Fold5 12GB/1TB, Újszerű, Független, 1 év garanciával!
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest