- gban: Ingyen kellene, de tegnapra
- Szevam: Érzelmi magabiztosság/biztonság - miért megyünk sokan külföldre valójában?
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
Új hozzászólás Aktív témák
-
bambano
titán
"Ennek mi köze az optimalizáláshoz? Semmi.": és akkor elolvassuk az előtte levő mondatokat is, hogy ne essünk a szándékosan kotvány idézés hibájába. tehát a kijelentés eredeti teljes formájában:
"neked például mennyivel több idő olyan kódot írni, ami legalább nem elvi hibás? például ha c-ben programozol, mennyivel több idő az sprintf helyett snprintf-et írni"tehát ebben a kérdésben nem optimalizálásról beszéltem, hanem elvi hibás programról.
"Például úgy, hogy az optimalizáltság egészen egyszerűen nem része a követelményeknek, vevői oldalról sem.": mert a vevő valószínűleg nem is tudja, hogy mi mindenről kellene beszélni a megrendeléskor. ezt nektek kell tudni és nektek kell érvényesíteni, akár akarja a vevő, akár nem.
egyébként tereljük vissza a beszélgetést az optimalizálásról a legalább helyesen működő programokra.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz #06658560 #46 üzenetére
azon a volvón az uber önvezető rendszere futott és az hozta meg a hibás döntést, hogy nem látja a biciklist. a biztonsági sofőr "csak" nem korrigálta ezt a hibát.
tehát a baleset elindítója egy hibás szoftver volt.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Reggie0
félisten
sprinf hasznalata snprintf helyett egyaltalan nem jelent elvi hibat. Sot leginkabb azt mutatja, hogy nem tartod kezben az inputot es az output limitalasaval akarod a hibat megfogni. A tervezesnel elkovetet lustasagot a sok hibaellenorzes miatti lassabb koddal oldod meg, ez pont az optimalizalas ellentetje. Szoval jo lmondta.
-
dabadab
titán
"mert a vevő valószínűleg nem is tudja, hogy mi mindenről kellene beszélni a megrendeléskor. ezt nektek kell tudni és nektek kell érvényesíteni, akár akarja a vevő, akár nem."
Ha a megrendelő ráteszi a cuccot a legkisebb virtuális gépére és a memória háromnegyede üres, a proci meg 10% körül pörög és nincs semmilyen érzékelhető lassulás benne, akkor hogyan magyarázod meg neki, hogy baromira megérné, hogy fizessen kétszer ennyit a programért és akkor még kevesebb memóriát meg processzort használna? Sehogy.
DRM is theft
-
bambano
titán
mondom, kanyarodjunk vissza a fullra optimalizált programtól az elvileg helyesen működik programig.
de a te példáddal szemben azt hogyan magyarázod meg, hogy a világon az összes desktopot folyton upgradelni kell, mert az aktuális windows hardverigénye mindig nő?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Pernyo
csendes tag
A Te kommentedre írok, mivel egyetértek ezzel és kiegészítem egy kicsit. Leegyszerűsítve az agilis szoftverfejlesztés kilépési pontja nem a kész termék, hanem az idő. Általában 2 hetes sprintek vannak, ami alatt be kell valamit szállítani a termékbe.
Sokan írják, hogy tanuljanak meg a programozók kódot írni. Tudnak, csak mivel nem mindenki robot és másképp gondolkodik, bizonyos komponensek más "gondolkodásmóddal" készülnek.
Én tesztelőként dolgozom, és a kódminőség megfelelő, csak a együtt nem működnek a komponensek, ezt nagyon nehéz kijavítan, mivel messze nem 1 fejlesztőcsapat dolgozik ezeken (30-40, helyileg sincsenek egy helyen), ez pedig nehezíti a kommunikációt.
Nem akarok senkit megsérteni, de találkoztam már olyan fejlesztővel, aki nagyon jó fejlesztő, de nem egy komplex rendszert fejleszt és ebből indul ki. Egy számlázó program és egy IMS (Internet Protocol Multimedia Subsystems) között nem kis különbség van. -
-
bambano
titán
az, hogy én mondom, túlságosan sokat nem jelent.
az, hogy bekerült a nyelvbe, libc-be, mindegymibe, jelzi, hogy olyan jelentős problémát kellett megoldani, ami nem maradhatott benne az implementációba.tehát ha alapos indokkal belerakták, használd. ha nem használod, és megtalálják a módját annak, hogy kihasználják az ezzel nyitott bugot, te vagy a hibás.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
dabadab
titán
"elvileg helyesen működik program"
Ilyen nincs, a programhelyességbizonyítás nemtriviális programokra nem működik, sőt, matematikailag megmutatható, hogy nem lehetséges (az u.n. megállási probléma, amiről a jelek szerint még nem hallottál).
"a te példáddal szemben azt hogyan magyarázod meg, hogy a világon az összes desktopot folyton upgradelni kell, mert az aktuális windows hardverigénye mindig nő?"
Szerintem ezt úgy magyaráznám meg, hogy terelsz, miután rájöttél, hogy hülyeséget írtál.
DRM is theft
-
félisten
Igen, én dolgoztam, de nem fejlesztőként.
Szerintem nincs igazad.A vezetőség az, aki az utolsó pillanatban meggondolja magát, hogy máshogy kéne, de több időt nem ad a rendes átalakításra.
A felsőbb vezetőség várja el, hogy a fejlesztés közben már rögtön az elejétől legyen demo, hogy hol tartanak a dev-ek, és a középvezető ba*sztatja a fejlesztőket, hogy legyen minél színesebb, szagosabb a demo mutatható funckinalitással, és ha a fejlesztőnek emiatt össze kell csapnia valamit, akkor utána nem kap időt rendesen megcsinálni, mert "dehát láttuk, hogy működik".
Szintén a vezetőség erőlteti azt, hogy a cégen belül egyszer már lefejlesztett komponenst minél több projecten használjanak fel, még akkor is, ha nem alkalmas mindenre, és ezért a fejlesztőnek rusnya kényszermegoldásokat kell alkalmaznia. Utána meg a vezető mutogatja a slide-okon, hogy milyen "smart" volt a cég, hogy "egyszer dolgoztak, többször kaszáltak".
Van még pár ilyen pontom, de azokból már kiderülne a cég is.Egyébként én főleg a webes szolgáltatások piacán tapasztalom ezt, de sok ex-kolléga meséli, hogy máshol is ez van kisebb-nagyobb mértékben.
[ Szerkesztve ]
Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
Reggie0
félisten
-
Felesbandi
senior tag
Dolgoztál már valaha programozóként nagy cégnél? Mert a kommented alapján nem úgy tűnik. Pont a programozókat zavarja a legjobban ha összecsapott kódot kell kiadniuk a kezeik közül. Az összecsapott, pocsék kód kb. mindig a management siettetése és irreális elvárásainak a következménye. Aztán jönnek a hozzád hasonló okosok akik mindenhez jobban értenek és közlik hogy "meg kell tanulni programozni".
-
bambano
titán
azt kellene végre megérteni és elfogadni mindenkinek, hogy amíg a vezetés nem képes saját maga megírni a programokat, addig a projektre ténylegesen felhasználható időt és minőséget nem a vezetés határozza meg. A vezetés max. előirányoz vagy kér, ha esetleg úgy gondolja, akkor kirúg. És ha kirúgott, akkor valójában kivel tolt ki? hint: magával.
tehát kizárólag a programozón múlik, hogy egy kód mennyi idő alatt és milyen minőségben készül el. ha a programozó túlzottan szervilis, akkor a kód elkészül az elvárt határidőre, találgatásom szerint ótvar minőségben. a másik véglet pedig az, amikor a programozó magasról tesz arra, hogy mit pampog a főnöke, ekkor a kód akkora fog elkészülni, amikor a programozó készen lesz, és változó minőségben.
a tapasztalat azt mutatja, hogy ezen két elméleti véglet között sokféle verzió van az életben, de a vége mégis mindig az, hogy a kód akkor készül el, amikor a programozó elkészíti.
tehát ha a programozó nem hajlandó kotvány munkát kiadni a kezéből, akkor a főnökségnek két lehetősége van: felmondanak neki, vagy eltűrik, hogy annyi idő kell rá.
egyébként is a tapasztalatom az, hogy az irreális határidő mindig a vezetés hibája, leggyakrabban rosszul megsaccolt erőforrásigény miatt. vagy nem rosszul, hanem szándékosan alultervezett erőforrás miatt, hogy többet lehessen kaszálni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
egy lehetséges védelmi megoldás nem használata ostobaság. ezen teljesen felesleges tovább rugózni, nincs észérv ellene.
a normális mérnökről: te például tudod, hogy tervez normális mérnök hidat? megtervezi úgy, hogy kb. jó legyen, majd utána, mivel a normális mérnök pontosan tudja, hogy mit nem tud, megszorozza 6-8-cal a kiszámolt értékeket, és az alapján épül fel a híd. ezért nem szoktak hetente leszakadni a hidak.
tehát az helyes, ha normális mérnök kiszámolja a puffert, ellenőrzi az inputokat, stb. amit leírtál. de mivel normális mérnök tudja, hogy nem tudhat mindent, ezért odateszi azt is, ami ilyenkor védelmet adhat. n-es függvényt, non-exec stacket és társait. *MINDENT*
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
félisten
Amit írsz az logikus, de nem számoltál azzal, hogy a munka csapatban folyik, gyakran 100 ember dolgozik egy terméken sok kis csapatra osztva.
Ahhoz, hogy a fejlesztő kiálljon az igaza mellett, ahhoz az egész csapatnak egy emberként kell állást foglalnia, ami marha ritka.
Ha pár ember kezd széllel szemben pisálni, akkor sem kirúgás lesz a vége eleinte, hanem gyengébb előmenetel, kevesebb pénz, stb.
Ha kirúgják, vagy felmond, akkor a következő cégnél is pont ugyanez lesz.
A változás érdekében egyszerre kellene kiállni.[ Szerkesztve ]
Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
Reggie0
félisten
De van eszertv ellene: ettol lesz lassu es optimalizalatlan a kod. Pl. egy uint16_t-t, ha tudom, hogy 1000 alatti az input, akkor 3 bajtos bufferbe gondolkodas nelkul sprintf-elheto es nem az a megoldas, hogy snprinteffel bajtonkent ellenorzom, hogy atleptem a bufferhatart. Inkabb azt ellenorzom az snprintf elott, hogy 1000 alatt van-e a szam. Az egyik egy uint16_t komparalas, a masodik pedig bajtonkent, tehat haromszor size_t-t komparal. Ez eszetlen pazarlas, ha surun vegzet muvelet, pont ettol lesznek szarok a kodok.
Az epiteszet erosen empirikus tudomany, tapasztalatok es okolszabalyok alapjan fejlodott, messze nem hasonlithato az informatikahoz. Esetleg a homeopatiat is idekeverhetned... Esetleg epitsuk feketedobozbol a repulot, hogy ha lezuhan ne torjon ossze?
Latod, viszont sokszor tudni eleget ahhoz, hogy optimalisan legyen megolva az ellenorzes. Ezert sem lehet sem elvi sem gyakorlati hiba az snprintf mellozese.
[ Szerkesztve ]
-
Felesbandi
senior tag
Tapasztalatból mondod?
Láttam már kiemelkedően jó programozókat akik elindultak egy irányba a kóddal és ahogy haladt a projekt és rajzolódtak ki az akkor még homályos követelmények, rájöttek hogy az addigi kódjuk egyszerűen nem skálázható hosszabb távon.
Nem olyan könnyű gyors, skálázható, olvasható és tesztelhető kódot írni, hogy a követelmények akár hetente változnak.
-
-
Felesbandi
senior tag
Igen. De siman bejohet egy olyan követelmény amivel az eddig jol skalazodo kod mar nem skalazodik olyan jol ha csak megfelelően at nem irjak a kodot. Csak ugye erre nem mindig hagynak időt. Plane ugy hogy a fofejesek demo appokat meg prototipusokat akarnak latni rendszeresen. Es sajnos az a valosag hogy ha rongyossa optimalizalsz mindent es nem marad időd arra hogy a demo ui csili-vili legyen, megszolnak érte. Ha meg optimalizalatlan spagettit gyartasz de a demo app csili-vili, akkor te vagy a faszagyerek. Lattam mar ilyet. Most őszintén melyiket valasztanad? Becsuletes, jo munkavegzesert lecseszest, vagy a hatterben osszecsapott spagetti kodert amit szep megjelenitessel elfedsz egy hatbaveregetest? Sajnos szep demora es jo kodra sokszor nincs ido. Plane ha a vezetoseg mentalitasa az hogy minden kodnak elsore hibatlannak kell lennie. Lehetsz akármilyen jó, ez akkor se lesz egy realis elvaras.
-
Predatorr
őstag
Na, ezt a hozzáállást büntetném min. 5 év börtönnel. Mint írtam, más terméknél a hiba/csalás büntit ér, de a lúzerek többségének fejébe beleültették már ezt a baromságot. Diplomavédésen kérdezték, hogyan végzek hibakeresést a programjaimon. Közöltem, hogy sehogy, mindig hibátlanul működnek, mert jól programozok. Nem találtak benne semmit, még készakarva sem, pedig rendesen nekiálltak, ha már ennyire őszinte embert láttak. De nem kellett idióta főnöknek dolgoznom, és amikor később kellett volna, ott hagytam, ne rám szálljon X felhasználó átka.
Felhasználóként kizárólag az érdekel, hibátlan-e a szoftver, nem egy rabszolga sirámai. Az menjen orvoshoz, vegyék ki a tüdejét vakbél helyett, hogy jaj, hát hibás a szoftver/hardver, de már fejlesztjük.[ Szerkesztve ]
"Amely probléma nem megoldható, azt meg kell szüntetni."
-
flexxx2
őstag
Elolvastam minden HSZ-t. És ugyanez van itt is mint a munkában. A programozót nem értik a NEM programozók. A programozó meg nem érti a NEM programozókat.
Amúgy ez sose lesz másképp, mert mindenkinek más az elvárása, és ahogy ti is leírtátok: idő - változó üzleti követelmények - többféle csapat - motiváció - világos célok hiánya - stb... Ezek mind a "rendes" kód ellen dolgoznak.
Azért lefikázni az ÖSSZES fejlesztőt mert ezekben nincs kedve vagy ereje vagy tehetsége lavírozni, az azért nem szép dolog. -
addikt
Most komolyan, tök nyilvánvaló ez mindkettőnknek, most simán csak nekiálltál trollkodni. Ha nem így van, akkor mégis mire reagáltál #17-ben?
(#81) flexxx2
Az ugye megvan, hogy a kritikát nem csak az itteniek fogalmazták meg, hanem a cikkben szereplő Linus Torvalds nevű fickó is? Ismerős a figura? Szerinted ő nem programozó?[ Szerkesztve ]
-
Predatorr
őstag
A programozó dolga az ügyfél (nem programozó) igényeinek megfelelő szoftver írása. Értsd: az ügyfél megértése. Én még ezt tanultam. Innentől kezdve a programozó magára vessen, ha szidják. Ma matematika logika (néha még az sem) szerint működő, a való élet igényeit jobbára teljes mértékben figyelmen kívül hagyó szoftvereket gyártanak. Ezt a felhasználók többsége nem érti meg, nem is várható el tőlük. Nem véletlenül nem lesz mindenki programozó. Nap mint nap látom a cégben, ahogy diplomás, művelt emberek nem tudják az urambátyámék gyártotta szoftvert kezelni, annyira életidegen a szakmájuktól.
"Amely probléma nem megoldható, azt meg kell szüntetni."
-
sutszi
veterán
Én elhiszem, hogy sokdiplomás polihisztor vagy, de menj el kicsit főállásba fejleszteni és lehet akkor kicsit átrendeződik pár dolog benned. Az, hogy te magadnak írogatsz kis programokat, amik az üzemeltetés automatizálásban segítenek az nem egyenlő azzal, hogy bármilyen komplex rendszert fejlesztesz amit utána átadsz egy ügyfélnek...
Volt itt aki a tanfolyamosokat kezdte ekézni, van aki a folyamtokkal bíbelődik...más a programozók tudását kérdőjelezi meg... Én meg már lassan sírok, annyira messze kerülünk a mindennapok valóságától.
Van, hogy egy feladat 3-szor átalakul, mire kiderül mit is akartak tényleg..és ez csak egy feladat...A komplett projekt meg rengeteg feladatból is állhat. Az alfeladatokról nem is beszélve, ha tovább bontogatjuk. Addig meg folyamatosan megy az implementálás. Nem attól lesz rossz a kód mert valaki egyből rosszat ír. Amúgy sem az az igény, hogy az első leütéstől az utolsóig patika legyen minden. A feladat lezárás előtt is lehet refaktorálni a kódot... Aztán amikor jön a 125. módosítás...amiben azt kérik, hogy legyen inkább mégis az ami a 75. volt, de közben a kódkörnyezet megváltozott... akkor azért nehéz rendet tartani... Meg a legszebb, amikor nem is találják ki jó az üzleti folyamatokat és a végén azért kell szétfosni a kódot, mert totál szürreális dolgokat kérnek, mert a jogi osztály ezt találta ki... Szóval biztos vannak jó, helyek ahol jól csinálják a dolgokat, de sok olyan is van ahol nincs rá lehetőség. De ezt csak az tudja megérteni, akkor már volt ilyen helyzetben valaha. Aki nem az csak a partvonalról béget.Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage
-
Rive
veterán
Hát, ha 'végső soron' akkor Linus a programozói mundér védelmében egyszerűen kihagyta a nulladik, szoftveres problémát: miszerint karban tartandó kódbázis mérete a rendelkezésre álló munkaerővel többé már nem teszi lehetővé a folyamatos foltozgatás által generált foltozási kényszer kielégítését. És ehhez a hardvernek nagyon kevés köze van...
/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!
-
flexxx2
őstag
Más egy kernelt programozni mint pl webshopot vagy backoffice rendszereket. Ezerféle programra ezerféle programozó van. Mind más típus.
(#84) Predatorr sikerül is megértenem ha az ügyfélnek van esze ahhoz amit csinál, kvázi érti a szakmáját. De ha nem akkor ne várja tőlem, hogy nem jutok vele sehova.
[ Szerkesztve ]
-
bambano
titán
"de menj el kicsit főállásba fejleszteni és lehet akkor kicsit átrendeződik pár dolog benned.": nem kell elmennem fejleszteni ahhoz, hogy analóg eseteket tapasztaljak.
üzemeltetésben is van olyan, hogy a főnökség hülyeséget akar, és akkor az üzemeltetőn múlik, hogy mit dönt.
saját példa: [link]
nekem az a tapasztalatom, hogy hosszú távon jobban járok én is, meg a végfelhasználó is, ha az ember időnként bajuszt akaszt a vezetőséggel. különös tekintettel arra, hogy a vezetőségnek igen gyakran nem feladata tisztában lenni a műszaki kérdésekkel. nekem pedig jobb friss álláskeresőnek lenni, mint mindent kritikátlanul benyelni."te magadnak írogatsz kis programokat, amik az üzemeltetés automatizálásban segítenek az nem egyenlő azzal, hogy bármilyen komplex rendszert fejlesztesz amit utána átadsz egy ügyfélnek...": kérdés, hogy az a full isp menedzsment rendszer, amit írtam, (web frontend 52 ezer sor jávában, 12 ezer sor php backend), az kis program-e még vagy sem.
"Meg a legszebb, amikor nem is találják ki jó az üzleti folyamatokat": akkor kitalálod nekik, helyettük.
"De ezt csak az tudja megérteni, akkor már volt ilyen helyzetben valaha.": én voltam már olyan helyzetben multinál, hogy rám akartak erőltetni egy nyilvánvalóan rossz döntést a külföldi központból. Tettem rá. és amikor a külföldi adatközpontjukkal probléma lett, és ebből mindenhol brutális pr katasztrófa meg kötbérezés lett, kivéve nálunk, akkor többet nem piszkáltak érte.
továbbra is állítom: kizárólag rajtad múlik, hogy milyen kódot adsz ki a kezedből. ekvivalens állítás: kizárólag rajtad múlik, hogy mennyire hódolsz be a főnöki hülyeségnek. kizárólag te döntöd el, hogy jobb fizető állásban maradni keserű szájízzel vagy jobb nyugodt álláskeresőnek lenni. A magam részéről határozottan a második, ha egy főnök nem tűri el, hogy a hatalmának vannak határai, akkor én nem dolgozom ott.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
buherton
őstag
A C nyelvben az a szép, hogy semmi sem egzakt. Ha pointert adsz át függvénynek, akkor mindig ellenőrzöd, hogy null-e és le is kezeled a hibát? Ha igen, akkor elmondhatod, hogy biztonságosan írsz programot, de tetű lassú lesz. Mint mindehol itt is komprosszimut kell kötni. A komponensek határait kell levédeni
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
attila9988
őstag
A lassú kódról nekem mindig ez a nyanvadék electron jut eszembe. Mindent egy átkozott böngészőre akarnak felhúzni, ami nem erre való, és egy "weboldalt" komoly software -ként eladni, ami már egy átlagos laptopot is kifektet, főleg ha valami rendes os helyett win10 van alatta. 90 -es évek életérzés, amikor épp erőszakoltak mindent gui -ra, és folyton várakozni kellett... És évről évre egyre rosszabb.
Ez ugyanannak a problémának a másik oldala. De alkalmazásszinten szerintem pont a fentiek miatt még komolyabb gond van ezzel a tendenciával.[ Szerkesztve ]
„Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)
-
buherton
őstag
Elég szomorú, hogy az interfészek nincsenek dokumentálva, mert pont ennek nem kellene problémának lennie. A requirementek szerint kellen az üzeneteknek mennie.
Nálunk 4 hét volt és aztán lett 3 hét a sprint. Nagy legacy kódokon felejtős az agile.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
Necroman_Mk2
őstag
Moore-törvény - ÁÁÁááÁ! Az informatika egyik legnagyobb bullshitje, mert egy üzleti stratégiát próbál kvázi természeti törvénynek beállítani. Bahhh...
"Élő gondolkodó lény vagyok, aki az információ tengeréből született!"
-
flexxx2
őstag
Ha mindegyik ugyanazt mondaná
Amúgy a fejlesztőként rengetegszer kaptam meg, hogy ez lassú, vagy tele van hibával (ha 1 hiba volt akkor az már tele volt). Viszont én is programozó által írt programokkal dolgozok. De mivel én vagyok ott engem talál meg. Itt ezt éreztem most, hogy minden programozó egy szemét, lusta, stb.. Ezért szóltam bele. -
flexxx2
őstag
válasz Necroman_Mk2 #94 üzenetére
Ja, totál igaz. Mindig sírok ha olvasom. Mintha 1 hét napsütés után azt mondanám, most már örökké fog sütni a nap.
-
buherton
őstag
A vezetőségnek számtalan eszköze van arra, hogy a kód minőséget javítsa. Az első, hogy a teszt osztályt létrehoznak és a lehető legmesszebb teszik a vállalati hiearchiában a fejlesztéstől. Különböző tesztelési szinteket határoznak meg, megkövetelik a dokumentációt, különböző analizáló toolok használatát, stb.
Az interfészeken igen kell ellenőrizni és azért én is kéz törést adnék, aki nem teszi meg, de a komponensen belül csak lassítja a programot. Persze itt is lehetnek kivételek a teljesítmény miatt.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
Új hozzászólás Aktív témák
- Ryzen 9 5950X
- AirPods Max - Silver (Hibátlan és tökéletes állapot, tulajdonképpen új, pár napot volt használva)
- LEGJOBB ÁR! GAMER PC - RTX 3070 - Ryzen 5500 - 16GB DDR4 - 500GB Nvme SSD
- ÚJ Playstation 5 CFW képes (feltörhető), lemezes
- ÚJ Dell Vostro 3520 - 15.6" IPS 120Hz / i5-1235U / 8-16Gb DDR4 / 512Gb / HUN backlit / 3 ÉV GAR.
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen