Hogyan legyek még jobb programozó?

Hogyan legyek még jobb programozó?
2012-05-17T13:56:37+02:00
2017-07-26T10:11:23+02:00
2022-10-19T12:41:57+02:00
  • Hali, hasonló cipőben járok én is jelenleg ezzel a senior kolléga kérdéssel. Ajánlom az oktatós oldalakat. pölö: Udemy, pluralsight, coursea. Persze az angolnak alapnak kell lennie. Adott oktató csomaghoz vannak értékelések és kommentek is a tematikán kívül, azok segítenek dönteni. Egyetemek is hirdetnek ingyenes online résztvételt az óráikon. 
    Érdemes bevonni a cégedet ha olyanok.
    Fizessenek elő neked tanfolyamokra, vagy vegyenek accountot a fentebb említett oldalhoz(vhol anyaghoz van köve a fizetés nem accounthoz).
    Képbe jön az is hogy kapsz-e dedikált időt a dologra? Ha nem akkor a párnapos oktatásokat tudod arra felhasználni és/vagy szabadidődet.
    Ha olyan cégnél vagy ahol ilyen tuskó muskó a főnököd akivel együtt dolgozol, vagyis nem tudsz tőle semmit sem tanulni és a feladatok segítségével sem tudsz tanulni és kaksi gyurma minden nap, akkor válts mert nincs értelme. Nem mutat sehova, és ez a szakma eléggé keresett hogy egy héten belül találj melót.
    Design patternek gyakorlati szemlélettel: http://www.dofactory.com/net/design-patterns



    A tisztakód, a solid és hasonló elvek azok amiket  elolvasol és beépíted a tudásodba. Nem agysebészet.

    Vannak fejlesztő környezetekhez segédprogik amik a munkádat segítik, érdemes ilyeneket is használni.

    Zinternet jó barát erre.
    Mutasd a teljes hozzászólást!
  • Szóval ilyeneket keresnék még.

    Ilyeneket nem szabad "keresni", főként nem szabad tanulni.

    Ezeket vagy "érzi" (tudat alatt, az agy háttértevékenységében kiértékel és dönt) egy programozó, vagy sem.
    Mutasd a teljes hozzászólást!
  • Amikor pedig egy Suzuki áthalad a 30 munkaállomás mindegyikén, akkor a végén 30 Suzuki lesz belole, mert 30 munkaallomason haladt át. Szép is lenne :D
    De ez sajnos csak térkompjúterben lehetséges.


    Amúgy jópofa vagy. 
    Mutasd a teljes hozzászólást!
  • sajnalom hogy nem erted a pipelineok mukodeset,  a processzor belsejeben tobb vegrehajtoegyseg talalhato,  load/store , sse, integer, float, cimzo stb, ezek mindegyike sajat pipelien-al rendelkezik, es mind parhuzamosan fut, ezert eszmeletlen sok utasitas van egyszerre vegrhajtas alatt, ne egy elavult risc processzorbol indulj ki
    Mutasd a teljes hozzászólást!
  • "ujabb cpu-knal 15 - 22 hosszu a pipeline, orajelenkent akar 7 utasitast is vegrehajthatnak , akkor az 20 * 7 = 140 utasitas (!!!!) van egyszerre feldolgozas alatt"

    Amire te gondolsz, az az utasitasnak csak egy konkrét lépése/munkafázisa/stage-ja. Egy az általad idézett 15-22 -bôl.
    Szoval probalod elkenni, de 7 utasitas != 140 utasitas.

    Egy erthetobb hasonlattal elve:
    7 krumpli == 140 szelet krumpli,
    ez viszont hamis:
    7 krumpli == 140 krumpli.
    Mutasd a teljes hozzászólást!
  • mar latom mi a problema, a regebbi risc architecturakat ismered csak, az ujabb intel technologiat mar nem,  a regebbi processzorok tenyleg 4-8 pipeline-al rendelkeznek, elore se latnak tobbet par tiz utasitasnal, 
    viszont az intel-nel es az ujabb cpu-knal 15 - 22 hosszu a pipeline, orajelenkent akar 7 utasitast is vegrehajthatnak , akkor az 20 * 7 = 140 utasitas van egyszerre feldolgozas alatt, plusz meg a instr window-ban meg 100 korul , tehat ugy durvan 200-300 utasitas fut egyidoben
    Mutasd a teljes hozzászólást!
  • Van ám ott 6-8 pipeline stage is. Nyugodtan oszd csak el vele azt a 128-at. 

    Vagy nálad kulon utasitasnak szamit ugyazon utasitasnak a fetch szakasza meg mondjuk a store szakasza? Ugye nem :D
    Mutasd a teljes hozzászólást!
  • Szerintem meg nagyon sokszor az "A" megoldás a nyerő. Egyrészt azért, mert jó eséllyel van egy általános(abb) eset (az nem 50-50% a két kimenetel), amitől az if-es eltér, másrészt meg rövidebb, áttekinthetőbb is.

    Most nincs kedvem keresgélni, hirtelen ezt találtam a témában.
    Mutasd a teljes hozzászólást!
  • "On the instruction side, Intel had to enlarge Nehalem's instruction window to accommodate more instructions in-flight. Specifically, Nehalem's reorder buffer (ROB) has been enlarged to 128 entries from Core 2's 96 entries, a 33 percent increase. (Architecture trivia buffs will recall that the Pentium 4 could track 126 instructions in-flight.) To go along with this much larger number of in-flight instructions, Nehalem's reservation station has been expanded to 36 entries form Core 2's 32."

    ha nem ertesz valamihez , legalabb ne hirdesd, bar tolem nyugodtan nyomathatod ezt a fellengzos stilust, hisz nyilvanvalo hogy ki ert hozza :D
    Mutasd a teljes hozzászólást!
  • /* "thankfully-you-don't-need-to-maintain-this" level */

    Mutasd a teljes hozzászólást!
  • "a processzor 100 utasitassal elore lathat"

    http://alfahir.hu/sites/default/files/indexfoto/facepalm_monitor_kep..

    Maximum egy térkomjúter:D


    A fordito/interpreter az ami jóval elôrébb láthat 32byte gepikodon is tul, es az fogja rendberakni azt az if-et ugy, hogy a felesleges ertekadast nem koveti el.
    A processzor is megcsinalhatná, de nem csinalja, mert annak boven eleg az, hogy parhuzamositsa az utasitasokat es megakadalyozza, hogy azok ossze vissza irkaljanak a regiszterekbe elrontva az eredmenyeket.
    Mutasd a teljes hozzászólást!
  • <?php $month = 2; $year = 2016; echo ($month == 2 ? ($year % 4 ? 28 : ($year % 100 ? 29 : ($year %400 ? 28 : 29))) : (($month - 1) % 7 % 2 ? 30 : 31));
    Mutasd a teljes hozzászólást!
  • a helyedben ilyenen nem ragodnek, ez erosen processzor fuggo , es attol is fugg a feltetel kiertekelese mikor tortenik, a processzor 100 utasitassal elore lathat, igy van amikor atmegy az egeszen mint egy uthenger, valamikor meg fennakad
    Mutasd a teljes hozzászólást!
  • Az én mindjárt expert kollégám azt se tudja, hogy bonyolítsa túl, meg hogy tömje tele a kódot mindenféle jólhanzó technológiákkal. Aztán mi juniorok meg professionelek persze nem is tudjuk a szintén buggy kódját kijavítani, sőt, még megérteni sem. Úgyhogy a "hogy legyek jobb programozó" kérdésben az ilyenek nem sokat tudnak segíteni. Persze ő nevezi más kódját "komplett szemét"-nek, de hát tudjuk, hogy miért. Amit kérdezni szeretnék: Hol találok hasonló jó elveket, példákat, viszont kódszinten, mint pl.:

    A megoldás:
    $text = 'alma';
    if (...) {
        $text = 'körte';
    }

    B megoldás:
    if (...) {
        $text = 'körte';
    } else {
        $text = 'alma';
    }

    Itt a B a jobb megoldás, mert minden esetben 1 feltétel kiértékelés, és csak 1 értékadás történik. Szóval ilyeneket keresnék még. Köszi!
    Mutasd a teljes hozzászólást!
  • Csak nem egy idôgépet tesztelsz?! 
    Mutasd a teljes hozzászólást!
  • miért nem lehet toleránsabb lenni a kezdőbbek felé?

    Szerintem a toleranciával semmi gond. Ne keverd össze a tanácsot a kritikával. Itt a prog.hu-n biztosan mindig találsz +1 lépésnyi tanácsot, vagy 16M truecolor skála gazdagságával akármilyen kemény kritikát. Azt kapod, amelyiket kéred.
    Mutasd a teljes hozzászólást!
  • Valóban jó régi poszt :)
    Kicsit aktualizálva hozzátenném, hogy most már mind szép és jó, ha OOPtől nem riadsz meg és, ha nem is álmodból tudod, de azért érted, hogy melyik design patternnek mi a lényege, mire használható, ezekhez még legalább egy ismertebb framework ismerete erősen ajánlott, mert valószínűleg, ha nem is feltétel azzal fogtok dolgozni előbb-utóbb és ha elég jól ismered azt az fwt amit használsz rákényszerít, hogy értsd meg a patterneket, dryt stb.
    Nem mellesleg nagyon meg tudja könnyíteni az életed. Persze ezek használata is megfontolást érdemel, mert minek agyúval verébre lőni.
    Mutasd a teljes hozzászólást!
  • Nem mai a poszt, de hátha másnak talán hasznos lehet.

    A design patternek közül nem rossz ha ismersz minnél többet. Ha bizonyos feladat előtt állsz akkor lehet hogy egy pattern a megfelelő arra hogy megold azt a feladatot. Persze ennek a véglete mikor csak valaki pár patternt ismer vagy helytelenül választ egyet és ráerőltei a kódra vagy pattern heggyel látja azt el. Így eléggé sok minden sérül illetve spagetti a vége más szóval élve azt mondanám hogy anarchia. 
    Úgy gondolom hogy a helyes sorrend az az lenne ha az alapvető programozói paradigmákat elsajátítja az ember, utána pár programozási alapelvet plö DRY vagy SOLID. Ezek után pedig pár fontosabb patternt. közben meg lehet néha olvasgatni a tisztakódról.
    A fontos hogy ne kutyafuttában tedd, hanem építsd be a szemléletet. Így sztem jó programozóvá válhat az ember.
    Így fogod tudni hogy például milyen változót használj, mi tartozhat egy fgv.-en belül és mi nem, mi legyen egy osztályban, mikor kell szétbontani egy interfacet vagy egy osztályt, milyen patternel lehetne a legjobban megoldani a feladatot, persze ha van rá ilyen.
    Sztem egy majmok voltak veled anno, hogy nem adtak esélyt illetve hogy nem mondták el a dolgokat és nem akarták hogy fejlődj.
    Egy példa mikor rossz patternt illetve rossz, nem tanult szemléletet használunk.Asztalira progi, wpf gui, több oem, 3db gép típusra. Két díszpinty senior fizuval, (elődeim), factory így - factory úgy, saját DI képződmény szexi reflectionel, ami bemappolja assemblyből az összes class-t és inicializálja, de mikor használja és újat initel akkor ehhez a map-hoz hozzáad egy újabbat és növeli, viewmodel szinten a bindingok folyamatosan növekedtek amíg kinem fagyorr nagy memó használat miatt, DI-ből eredeztetve félig függetlenül egy classba a singletonok amik ugyanúgy sw. induláskor inicializálódnak.  Úgy be volt betonba kötve minden, nem is beszélve a rétegek közötti átlépésről, viewmodellben db hívás, volt olyan hogy az entyti framework egy táblából lértehozott példányai voltak kikötve. Siralmas volt és nagyon visszaköszönt még sokáig ez a nagy spagetti kód. Ha tudták volna az alapvető dolgokat akkor sok munkaórát megtudtak volna spórolni nekünk.  

    Még most is sírok hogy hogy lehet ilyet, és mit ad isten utólag kiderült miután elmentek hogy senior fizuval csinálták ezt a szép kódot. 

    A lényeg sztem hogy nem szabad besüppedni és csak tengeni lengeni, fejleszteni mindig kell magad ebben a szakmában, illetve ha olyan a hely akkor a nagyoktól tanulni. egy jótanács amit anno kaptam, egy cégnél addig maradj amíg van kitől tanulni. Ha van nálad nagyobb tudású ember azonos területen az egyfajta inspirációt illetve akaratot ad arra hogy jobb akarj lenni. Ha nincs ilyen akkor inspiráló lehet ha a cégedet kéred meg hogy vigyen tanfolyamokra. Ha ezt nem értik meg akkor tovább kell állni mert besüppedsz és lemaradsz majd azon kapod magad hogy felvettek vkit aki nem is senior csak sima programozó akár még kevesebb bérért is és kenterbe ver téged. Persze az emberi tényezőt kihagytam, ha jó emberek között dolgozol akkor könnyebb besüppedni illetve könnyeb velük például közösen fejlődni. Ami a kis csapatot minden szempontból előre viheti, mivel szociális készség is fejlődik például a codereview-k alatt és a különböző megoldások megvitatása közben.
    Mutasd a teljes hozzászólást!
  • A saját függvények sokat segíthetnek. Tegyük fel, hogy írtál egy 40 soros blokkot, ami az adatbázist frissíti a megadott kritériumoktól függően. A program során 3-szor kell majd frissítened az adatbázist - nem lenne egyszerűbb 120 sor helyett 3-at írni: dbrefresh($kriterium1,$kriterium2); , a függvényt pedig egy másik fájlban letárolni?


    Egyszerűbbnek akkor és ott nem mondanám. Ügye a legegyszerűbb ott és akkor az, ha fogod és kijelölöd, majd copy és paste. Mit kell foglalkozni egy külön fájl létrehozásával, de akár egy függvény létrehozásával a fájlon belül?
    Mutasd a teljes hozzászólást!
  • ...és Windows'95 alatt
    Mutasd a teljes hozzászólást!
  • Leírom az én programozási alapelveimet:
    - érthető változónevek
    - tiszta kód
    - a lehető legegyszerűbb kivitelezés
    - saját függvények használata
    - megjegyzések a kódban, illetve dokumentáció, ha nagyobb projekt
    - nagyobb projekteknél emellett OOP muszáj lesz
    - továbbfejleszthetőség (na még ezt, meg azt így kéne, azt oda nem, inkább kicsit jobbra, stb.)

    A tiszta kód alatt pedig azt értem, hogy nem feltétlen kell besűríteni mindent egy 10e karakteres kódba, hanem lehet szépen feleolyan hosszú pár includeolt fájllal, emellett pl. tabulálhatod a szinteket az áttekinthetőség kedvéért. Itt arra kell törekedni, hogy az egyes szerkezeti egységek minél jobban elkülöníthetőek legyenek, és a megjegyzések megmutassák, hogy melyiknek mi a funkciója.

    A saját függvények sokat segíthetnek. Tegyük fel, hogy írtál egy 40 soros blokkot, ami az adatbázist frissíti a megadott kritériumoktól függően. A program során 3-szor kell majd frissítened az adatbázist - nem lenne egyszerűbb 120 sor helyett 3-at írni: dbrefresh($kriterium1,$kriterium2); , a függvényt pedig egy másik fájlban letárolni?
    Mutasd a teljes hozzászólást!

  • Targonca is létezik vagy 80 éve, bárki tudja kezelni fél óra beletanulás után, mégis szükség van még "dokkmunkásokra", talicskára, "békára" stb.

    A másik pedig... a legfontosabb... Fut majd Win XP alatt?
    Mutasd a teljes hozzászólást!
  • Aztán jön egy cég (vagy több). Előállnak egy önmagát "leprogramozó" eszközzel. Az IT manager úr csak megad pár kívánság szerű paramétert és kész, akkor ez az egész vita/fejtegetés okafogyottá válik. A programozó társadalom 90%-a meg kereshet magának más munkát.
    Utópisztikusan hangzik, de lehet hogy küszöbön áll és éppen most kopogtat valahol
    Mutasd a teljes hozzászólást!
  • Hát igen, tipikus.

    Ráadásul sokszor időhiány miatt van összecsapva a project, nem számít milyen minőségű, csak működjön. Ez is érthető, ha határidő van, akkor előfordul, hogy nincs idő refaktorálni.

    Pont ez az igazán nehéz ebben a szakmában, hogy a ma elkövetett hibák (hack-ek, copy/paste-ek, workaround-ok) nem nálad jelentkeznek (hiszen a progi működik), hanem majd egy másik szerencsétlen fejlesztőnél, akár 1-2 év múlva.

    Céges projecteknél fokozottan igaz ez.
    Mutasd a teljes hozzászólást!
  • Ha szoftverfejlesztőként akarsz dolgozni, azt mondom, hallgass arra amit erdeszt és nova76 írtak.

    Ha valódi terméket, szoftvert állítasz elő, akkor az, hogy működik a kódod, csak az első lépés. A fejlesztési életciklus nem az a néhány nap vagy hét amíg leprogramozol minden szükséges funkciót...

    Most kaptam egy WinForms alapú programot, hogy néhány hibát javítsak ki benne, meg a 3rd-party control-okat cseréljem ki egy másik 3rd-party control-családra. 5 formból áll az egész project, hát nem lehet olyan nagy meló ugye...
    A gond ott kezdődik, hogy 30 ezer sor kompletten, az 5 db formból az egyik 8 ezer (!!!) soros (egyetlen .cs fájlról van szó), van még kettő ami 6-7 ezer soros, és egy "Helper.cs" nevezetű fájl ami egyetlen class, és minden sz** bele van hányva, amire épp szüksége volt a "fejlesztőnek". OO-nak nyoma sincs, változók, metódusok nevei, láthatósága, statikus - nem statikus... minden ahogy épp sikerült, teljesen rendszertelenül.
    A lényeg, hogy az egész kezelhetetlen. Apróbb hibákat javítani többnapos munka, mert átláthatatlanok az összefüggések. Valamibe belenyúlsz, és összeomlik az egész. A vége az lesz, hogy mindent amit javítanom kell, újra fogok írni a nulláról, mert hamarabb megvan, és később nem lesz gondom vele.

    Ja, egyébként a program működik. Csak ugye bugmentes szoftver nincs, jönnek új igények stb. A "működik a kód" nem 97%, hanem inkább 5%. Ezt az 5%-ot bármelyik indiai "programozó" megcsinálja óránként 500 ft-ért, szerintem nem velük akarsz versenyezni.
    A kulcsszó a karbantarthatóság!

    Annyit még hozzáteszek, hogy neked kell mérlegelned, milyen pattern-eket érdemes alkalmaznod. Ha bele akarod nyomni az összes menő "buzzwordöt" egy projektbe, az se vezet semmi jóra.
    Mutasd a teljes hozzászólást!
  • Azaz: 'jozan paraszti ész' dolgok, amik kicsit tul vannak lihegve amiota modszertanokba csomagolják őket.


    Ezzel egyet tudok erteni, viszont nem gondolom, hogy ez a tulliheges felesleges lenne, elnezve pl ezt a topikot.
    Mutasd a teljes hozzászólást!
  • "kiss, separation of concerns, loose coupling, single responsibility principle"
    Na most csak utananeztem ezeknek a google-n, hogy ne erezzem magam maradi tuskonak. Mind fontos dolgok es egyszeruek is.
    Azaz: 'jozan paraszti ész' dolgok, amik kicsit tul vannak lihegve amiota modszertanokba csomagolják őket.
    Ezeket k...ra nem bemagolni kellene (majd szamonkeresen megfelelni, aztan elfelejteni), hanem beépíteni a gondolkodásmódba...

    Egy olyat viszont hianyolok*, hogy "redundancy is evil" principle :D Ezzel es a Common Sense technologiaval sok ilyen divatos modszertan lefedhető úgy, hogy nem azon gondolgozol, hogy most eppen melyik modszert huztad elo a fiokbol.

    *Update: Most talaltam meg a DRY jelenteset, most mar nem hianyolom

    (szégyen vagy nem, de a "divat patterns" kif. olvasasakor oblosen felrohogtem )
    Mutasd a teljes hozzászólást!
  • 1. Az eredeti kerdesben nem a te 20k soros project-edrol volt szo hanem arrol, hogy altalanossagban mik azok a dolgok amikell jobba teheto a kod.

    2. Ahhoz, hogy di-t hasznalhass nem kell egy di kontener(itt szerintem most te ertesz valamit felre). Egy 20k soros programban is van letjogosultsag a lent emlitett elveknek, mert soha nem tudhatod hogy meddig kell majd suppportolni es, hogy mikor jonnek olyan uj fejlesztesek amik miatt 40k-ra, majd meg nagyobbra hizik a dolog.
    Mutasd a teljes hozzászólást!
  • szerintem DI containert használni egy 20k soros projektben fölösleges túlbonyolítás, rossz technológiai döntés. Most akkor hülye vagyok?
    Mutasd a teljes hozzászólást!
  • (mellesleg ha a tdd, continuous integration, agilis módszertanok szted 88 előttiek akkor nem tudod miről beszélsz)

    Ezek nem az elso felsorolasban voltak.

    Nem mondtam, hogy hulye aki nem hasznalja, de kitartok amellett, hogy szerintem hulye aki ezeket bonyolult es felesleges dolognak tartja.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd