Új hozzászólás Aktív témák
-
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.[ Szerkesztve ]
-
Dr. Akula
nagyúr
Amiről én beszélek, az a meló emberi aspektusa, amit a naívan idealista modellek sosem vesznek figyelembe. Ez nemcsak a szoftveriparban van jelen, hanem mindenhol. És amíg ezzel nem kezdenek valamit, addig az elvont elméleti modelleket tök felesleges is behozni a képletbe. Ezt kezelni csak úgy lehet, ha beépítjük a modellbe, számolunk vele, a rendszer részévé tesszük (mást úgyse tudunk vele tenni, akkor is jelen lesz, ha nem akarjuk). Ha beleolvasol egy ilyen módszertanba, akkor ott kb. a reklámokból ismert, túlvilágian boldog emberek köszönnek vissza rád, akik csakis a munkáért élnek, a világ jobbításáért. Tiszta ékorea, kedves vezér, sztahanov, élmunkások, stb. Ilyen ember nincs, vagy legalábbis nem sokáig.
-
cucka
addikt
válasz samujózsi #146 üzenetére
Azt, hogy az "újra felhasználhatóság" elvárás legyen a kóddal szemben, az egy baromság, amit ki kell verni az emberek fejéből. Ebből szoktak a fölösleges, haszontalan absztrakciók születni.
Olyan elvárások vannak, hogy SOLID, DRY és YAGNI. És unit teszt.
[ Szerkesztve ]
-
samujózsi
tag
Miért lenne baromság?
Eleve az OOP erre épül.
Meg tképp a függvények, szubrutinok is valahol erre vezethetőek vissza. Library-k/package-ek stb.Szerintem bőven van értelme úgy megírni egy kódot, ha nem valami eldugott sufnicég weblapjáról van szó, hogy később felhasználhatóak legyenek a kész kód részei máshol is, ahol hasonló, de nem azonos feladat jöhet.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
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.[ Szerkesztve ]
-
MongolZ
addikt
Bár informatikát BSC szinten csak 1 évig tanultam, aztán otthagytam, de kérdem én: melyik az a szakma, amelyre egy iskola rendesen felkészít? Egyik sem. Nem a szakmát tanulják meg az iskolában, hanem a rendszerben gondolkodást, leteszik az alapokat, stb. Lehetetlen 5 év alatt mindenre felkészíteni a tanulókat. De ez igaz minden területe, az IT a jelenleg gyors fejlődés miatt van még inkább kitéve ennek a jelenségnek. Akármilyen területen is dolgozók az ember, ha nem képző autodidakta módon magát, akkor lemarad.
[ Szerkesztve ]
-
Danex
addikt
5 év nagyon sok idő, az egy másik dolog hogy ha 20kulonbozo dolgot 40 féle módszerrel 5ev lemaradással adnak át akkor az kb semmit sem ér...
Mint pl webtech ahol a tanár megnyitja a w3schoolst azt itt az anyag gyerekek... Gyakorlatokat meg az előző evfolyambol egy 3-4est szerző benyalt ember tartja aki egyik kérdésedre se tud korrekt szakmai választ adni.
Így valóban nem lehet sokra számítani attól az 5 évtől...
-
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.
[ Szerkesztve ]
-
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ő?
[ Szerkesztve ]
-
arn
félisten
válasz Dr. Akula #153 üzenetére
Értem én, csak ha a merge előtt a code reviewnal újra kellene kodolnom az egészet, mert vki csak osszecseszi, mert "működik"... Az nem munka, hanem kétszer dolgozunk vele. Arról nem is beszélve, hogy a toldozott kódjával lehet osszeborit három másik dolgot, amiről nem tud, vagy fél év múlva a kutya nem tudja, hogy ez mihez tartozott, aztán egy szemétgombolyagot görgetsz magad előtt. Ezt vagy megtanulják, vagy nem lesz belőlük normális fejlesztő.
facebook.com/mylittleretrocomputerworld | youtube.com/mylittleretrocomputerworld | instagram.com/mylittleretrocomputerworld
-
Goose-T
veterán
válasz Dr. Akula #150 üzenetére
Biztos van itt sok naiv, lelkes kezdő programozó, de én már a 17. évemet töltöm a szakmában, így nem hiszem, hogy rám céloztál. Ha viszont neked tényleg olyanok a meglátásaid az iparról, amilyeneket a hozzászólásaid tükröznek, akkor te még biztos nem dolgoztál olyan helyen, ahol elfogadható szakmai színvonalú munka folyik. Ezért írtam, hogy rendes munkahelyet kéne keresned, ahol megtapasztalhatod ezt. Pro tipp: ne a pénzintézetek között nézelődj, ott nem jellemző ez, kevés kivétellel.
Rockbandám: https://fb.me/scharlotterhodes *** Gitárelektronikai műhelyem: https://www.fb.me/goosetgitar
-
Dr. Akula
nagyúr
Ha más veszi át a folytatást, az se tudja mi mihez tartozott. Persze, doksi, lehet sakkozni mire gondolhatott az alkotó, és miért pont úgy. Ha nem tetszik az előd kódja, ráerőlteted magad hogy az ő gondolatmenetét folytasd, vagy inkább mégis átírod számodra logikusra? Mert akkor ugyanott vagy.
-
Dr. Akula
nagyúr
Vagy neked vannak túlzottan irreális elképzeléseid az elfogadható színvonalról. Aki maximalista, az ráadásul sose fejezi be a melót, mert mindig lehet mit javítani rajta, márpedig a határidő az mindenhol No.1. szempont. Elhiszem hogy létezikl olyan cég ahol a minőség mindenek felett, csak nem nagyon, ugyanis kb. mindenhol az ellentétét láttam. Határidő és bevétel mindenek felett, a többi meg "kisdobosbecsszóra bepótoljuk", mint a pizzafutár a lemaradt üccsit fizetés után...
Arra próbáltam rávilágítani hogy szép és jó az elmélet, mindenki legyen perfekt, csak az élet azt mutatja hogy nem lesz. Most vagy vársz a tökéletes programozókra ítéletnapig (más is arra vár, miért pont hozzád mennének, többet fizetsz talán?), vagy felveszel átlagosakat, és számolsz azzal hogy ezek ilyenek. Nem lesz tökéletes a munka, de legalább el lesz végezve a valóságban is. Nem csak a programozásban van olyan hogy van akinek az művészet, önkifejezés, tökéletes akar lenni, másnak meg csak egy meló a sok közül. És utóbbiak vannak, voltak, lesznek többen.
-
opr
veterán
Mindennem rosszindulat nelkul annyit meg hozzatennek, hogy amig ilyen a hozzaallasa, addig ez nem is fog elofordulni, mert mar a nulladik koros otthoni tesztfeladaton ki fogjak a normalis helyek szorni.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
#06658560
törölt tag
Speciel anno engem a BME még osztatlan öt éves képzése remekül felkészített a járműgépészetre, azóta is jól élek az ott szerzett tudással. Csak én eleve azért mentem oda, mert ez akartam lenni, nem majd menet közben kiderül alapon torpedóztam a tárgyak felvétele során sem.
-
#25954560
törölt tag
válasz Dr. Akula #178 üzenetére
nyilvan sokkal tobb a munka, mint a jo programozo. lehetoseg szerint azt kell elerni h minel tobb reszt a jok talaljanak ki.
ami szokott tudni mukodni az az, hogy a tetejen hozzaerto koderek vannak szeles latokorrel es kepesek gyorsan poc-ot generalni. a poc utan viszonylag ertelmesen le kell tudniuk dokumentalni h mit csinaltak es ehhez kepest mit csinaljon a vegleges kod, illetve mi kell meg, ami nem volt resze a poc-nak.
ha tul nagy a projekt, akkor reszletes dokumentacio kovetkezik h mi hogy legyen megcsinalva, ha kisebb, akkor mar el is kezdhetnek dolgozni a tobbiek. de ehhez is kell egyfajta munkakultura h ha pl leragadsz valamivel ket-harom napra, akkor segitseget kersz, nem pedig elvesztegetsz meg ket hetet. illetve az implementacio ideje alatt is van ertelme kodrivjuknak meg beszelgeteseknek, hogy ne az legyen h az ember dolgozott egy honapot a sajat elkepzelese alapjan, aztan kiderul h a megoldasa tobb szempontbol sem megfelelo.minden szintu programozot kell tudni hasznalni, akkor leghatekonyabb a szervezet.
es az mar nagyon off, de sok hierarchiaban lenezik a tesztereket, pedig az igazan jo teszterek kincset ernek.
-
Dr. Akula
nagyúr
válasz #25954560 #179 üzenetére
Ritka a jó főnök. Oda a kiválasztás alapja a benyalás, a jó fizetés vágya, nem a rátermettség. Főnöknek se biztos hogy jó programozó kell, hanem aki ki tudja válogatni maga mellé a megfelelő embereket - és megtartani. Hiába jó programmer valaki, ha emberileg egy 0, és mindenki otthagyja, szétesik a csapat. A hozzáértő kóder helye a senkior / team leader, ilyen kisführer kategóriában van. Ha marasztalni kell, inkább fizessék meg, akár jobban mint a főnökét, de ne rakják adminisztratív posztra ahova nem való.
A kisebb-nagyobb doksik a projekt ellen dolgoznak. Azon megy a vita mi melyikbe kerüljön, nem az hogy milyen infók szerepelnek egyáltalán - akármelyikben. Szerintem a doksikat szerepkörökre kell gyártani, melyiket kinek kell elolvasni. Aztán hogy LLD vagy HLD, az már tökmindegy.
-
spirit007
senior tag
Kell-e tanítani a programozást?
Jah, kéne mert aki az egyetemig nem tanulta meg az ott nem is fogja...
-
DjFlanker
aktív tag
"ha tul nagy a projekt, akkor reszletes dokumentacio kovetkezik h mi hogy legyen megcsinalva"
Itt is van egy erős hibaforrás, mert a kezdeti, eredeti elképzelés általában jól dokumentált, (bár úgy tudom ez főleg üzleti elemzői munka), viszont a megvalósítás, tesztelés, UAT teszt közbeni változások átvezetése, hogy is mondjam, gyakran szenved csorbát.Jó pilóta alagútban nem katapultál
-
#25954560
törölt tag
válasz Dr. Akula #180 üzenetére
szerintem jo doksira szukseg van (/lenne). mas kerdes h en is ugy allok neki irni, mintha a fogam huznak, de az elgondolas legyen benne tisztan es erthetoen.
ha viszont egy cegnel tulburjanzik a dokumentacio, akkor az a minimum h le legyen irva mibe minek kell bekerulnie. idealis esetben egy uj teruletet legkonnyebb nagyjabol megerteni egy jo leirasbol. aztan persze ugyis Yoda a vege: 'use the source, Luke'
DjF:
igen, az implementaciohoz kozeli doksikat hiba tul koran megirni vagy nem frissiteni.[ Szerkesztve ]
-
arn
félisten
válasz Dr. Akula #172 üzenetére
en vezetofejleszto vagyok 18 ev tapasztalattal, a tobbiek meg nem ha vmit elkefelnek, es en atengedem, azonnal ropkodnek a tobb ezer euros karok a kieses miatt.
itt nem az en szemleletem van, hanem a hanyag munka, vs normalis. nem fogok senkit a sajat kodolasi stilusomra kenyszeriteni, de azt elvarom, hogy a kod atgondolt, es rendezett (rendszerezett) legyen, ami passzol a masterkodhoz. senki sem akar ketszer dolgozni.
[ Szerkesztve ]
facebook.com/mylittleretrocomputerworld | youtube.com/mylittleretrocomputerworld | instagram.com/mylittleretrocomputerworld
-
arn
félisten
válasz Dr. Akula #180 üzenetére
a ctonak nem az a feladata, hogy fejlesszen. ill kell a kockak melle a projekt menedzser, aki kommunikal a tobbiekkel. mindenki azt csinalja, amihez jobban ert.
[ Szerkesztve ]
facebook.com/mylittleretrocomputerworld | youtube.com/mylittleretrocomputerworld | instagram.com/mylittleretrocomputerworld
-
emelhu
aktív tag
az "újra felhasználhatóság" elvárás legyen a kóddal szemben, az egy baromság,
Itt kezdődik a kopipaszta huszárság.
Az első lépés hogy ugyanabban az alkalmazásban ha valamit leírtál, akkor azt ne írd meg mégegyszer, és nem a hatékonyság miatt, az a mai processzor és memória lehetőségek mellett teljesen lényegtelen. Alapelv, ami az inkonzisztencia ellen bevált.
Ha meg nem akarok lépten nyomon valamit újraírni, akkor azt centralizálva kell és jól definiált input-output-állapotváltozás dokumentálással.[ Szerkesztve ]
-
opr
veterán
Teljesen mas fajta ujrafelhasznalhatosagrol beszelsz...
Cucka projekteken ativelo ujrafelhasznalhatosagrol beszel, es alapvetoen szerintem igaza van.
Te projekten beluli ujrafelhasznalhatosagrol beszelsz, aminek viszont annyira evidensnek kene lennie, hogy szora se erdemes."Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
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.
-
Ispy
veterán
Az, hogy kiből mi lesz semmi köze a papírnak, az egyetemet végzett sem tud többet a programozásról, mint aki udemyn szedte fel a tudását, hogy hová jutsz az azon múlik, hogy mennyi energiát teszel bele élesben (főállásban). De biztos van olyan tudás, amihez egyetem kell.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
borbastomi
csendes tag
Ne haragudj, de szerintem ez nagyon sok területre nem igaz. Autó, repülőgép és vasúti szoftverfejlesztésnél is dolgoztam, ahol mindig azt láttam, hogy ha egy-két euró centet meg tudnak spórolni a gyártáson, akkor inkább hagyják a fejlesztőket még dolgozni 1-2 hónapig.
Amúgy az eredeti témához: azért a programozás kb. olyan mintha azt mondanám, hogy matematika vagy rajz. Egy építésznél sem az a lényeg, hogy tudjon szabad kézzel egyenes vonalat húzni (pedig az egyetemen először ezt osztályozzák, ha jól tudom). A szoftverfejlesztés is több kéne legyen a programozásnál. Persze minden tanulható, de sajnos sok trash kóddal találkoztam, amit olyan emberek írtak, akik nem tanultak meg szoftvert fejleszteni. Egyelőre még valamiért az követelmény, hogy sebészi beavatkozást csak végzett orvos végezhessen, 30 emeletes toronyházat pedig csak papírral rendelkező építész, de az, hogy a szoftvert, ami a távműtős robotot vezérli vagy a toronyház statikai tulajdonságait elemzi, nem kell, hogy hozzáértő emberek készítsék, az nekem furcsa.
-
_flamer
aktív tag
Szerintem aki tanulni és képezni akarta magát az megoldotta otthoni körülmények között is.
“Innovation distinguishes between a leader and a follower”
Új hozzászólás Aktív témák
- Processzorra való vizesblokk az ASUS ROG-os portfóliójában
- Gyúrósok ide!
- Honor Magic5 Pro - kamerák bűvöletében
- Anglia - élmények, tapasztalatok
- Háztartási gépek
- TCL LCD és LED TV-k
- Május 7-én lesz az új iPadek bemutatója
- Mibe tegyem a megtakarításaimat?
- Kertészet, mezőgazdaság topik
- E-roller topik
- További aktív témák...
- XBOX ONE/PS4/PS5/XBOX SERIES/NINTENDO SWITCH konzolt vásárolnék!
- XBOX SERIES/PS4/PS5/XBOX ONE/NINTENDO SWITCH konzolt vásárolnék!
- PS5/PS4/XBOX ONE/XBOX SERIES/NINTENDO SWITCH konzolt vásárolnék!
- Új Dobozos Lenovo Ideapad Flex 5 x360 Érintős Ultrabook Óriás Tab 16" -40% Ryzen 5 5500U 16/512 QHD
- PS4/PS5/XBOX ONE/XBOX SERIES/NINTENDO SWITCH konzolt vásárolnék!