Hirdetés
- AMD Navi Radeon™ RX 9xxx sorozat
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen videókártyát?
- Milyen egeret válasszak?
- Mérlegeli a csúcstechnológiás chipgyártásból való kilépést is az Intel
- Azonnali notebookos kérdések órája
- VR topik (Oculus Rift, stb.)
- Bluetooth hangszórók
- DUNE médialejátszók topicja
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
Új hozzászólás Aktív témák
-
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. -
strogov
senior tag
Fejlesztési elvek elég lassan avulnak el, tervezési elvek pedig még lassabban. Technológiák relatív gyorsan váltják egymást, de pl. aki 20 éve nekiugrott a java-nak az 20 év múlva is jól fog keresni vele ... és már akkor sem volt új technológia. A scrum lassan 30 éves, és 20 éve már mi is használtuk. Attól, hogy mutációi jönnek létre az alap ugyanaz marad ... vagy pillanatok alatt megérted miért kellett mutálódnia.
Anno még középiskolás voltam, és nem értettük, hogy egy barátom apja (akit nagyon tiszteltem) hogyan tud 3 nap alatt megtanulni ~2 ezer oldalnyi anyagot egy pár hetes szakkönyvből. Azt mondta majd megértjük ha mi is 20+ éve csináljuk. Pár éve volt egy project amiben 12 ezer oldalnyi doksit kaptunk, hogy dolgozzuk fel, majd beszéljünk. 5-en voltunk senior-ok, hétfőn kaptuk az anyagot, csütörtökre mindenki feldolgozta, megbeszéltük, és mindenki még egy-egy prezentáció is belefért a saját a feladatáról, és a hogyanról.
"Üzleti igényeket kell kielégíteni. Ha az elképzelésed alapján készülne a szoftver, akkor"
Te arról beszélsz miért nem akarsz tervezni. Én meg arról, hogy a szakmunkások 99%-a nem is tud. Én is vettem részt sok-sok céltalan bolyongásban, csak tudom milyen az amikor értelmes PM-mel, értelmes BA-val dolgozok, és így láttam már, hogy lehet ezt jól is csinálni.
Azóta nem szeretek igen emberekkel együtt dolgozni, legfeljebb muszáj. Kimegy ügyfélhez és mindenre igent mond. Az ilyen traktort vezessen ne project-et ... vagy inkább azt se. -
bambano
titán
"Minden program tele van hibákkal, és egy csomót soha nem fognak kijavítani, mert nem éri meg.": erről beszéltem, azért vannak tele hibával a programok, mert a jelenlegi jogi helyzetben meg lehet oldani azt, hogy a költséget ne az fizesse, aki okozta.
például a windows10 tele van hibával, de ezért nem tudod az ms-t felelőssé tenni, hanem neked kell rakás pénzért víruskergetőt meg malware kergetőt meg tűzfalat meg határvédelmet meg hasonlókat üzemeltetni. te fizetsz azért, mert a törvény és a szokásjog hagyja, hogy az ms trehányul programozzon. itt az ms csak példa, más cégekre is igaz.
-
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. -
bambano
titán
"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.": ezen nagyon egyszerűen lehetne segíteni: a szoftver fejlesztési költségei közé be kellene sorolni azt is, amennyi kárt okoz. rögtön olcsóvá válna az 5x-ös fejlesztési költség. és azt a költséget le is kellene verni a fejlesztőn.
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"? én anno elolvastam a windows eula-t, nagyjából három dolog volt benne, ebből kettő vállalás, egy meg mosakodás:
1. az adathordozó olvasható, erre van garancia
2. egyszer láttak már egy gépet, amin egyszer működött a szoftver.
3. semmi másra nincs garancia, minden más a vevő sara.ekkora mocsokságot melyik másik iparágban engednek? ha leszakad alattad egy híd, még be is perel érte téged a hídépítő?
az egész szoftveripar arról szól, hogy tologatják jobbra-balra a költségeket, csak nehogy ki kelljen fizetni. pláne nehogy ki kelljen fizetnie annak, aki okozta.
"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": ez egy felfújt lufi, mert senki nem mer a sarkára állni ezügyben. azért változnak az üzleti igények, 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. a bolond szoftverfejlesztők például felkészültek arra, hogy másodpercek-percek alatt újrahúzzanak egy komplett enterprise rendszert, erre a hülye megrendelők elkezdték kihasználni ezt. ha a rendszer alkalmas arra, hogy tróger megrendelésekkel is működjön, akkor tróger megrendelések fognak érkezni. ha a megrendelőnél nem okoz jelentős költséget az, hogy lövése sincs arról, hogy mit akar megrendelni, akkor nem fogja erőltetni, hogy legyen lövése.
"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.": és ez jó lenne. azt lehetne garantálni, hogy a program megfelel a megrendelő által rendesen ledokumentált specifikációnak. Hogy a megrendelő által megrendelt cucc megfelel-e a megrendelő igényeinek, azt nem garantálná semmi, viszont pár méretes pofáraesés után a megrendelő is elgondolkodna azon, hogy az igényét ne sajtpapíron adja le. sokat tisztulna a szoftveripar, ha a megrendelői hülyeségeket csökkenteni lehetne.
"pl. űrhajók vagy atomerőművek vezérlő szoftverét le kell specifikálni. ": ja, a boeing is jól lespecifikált mindent, a 737max műszereitől kezdve az űrhajó óra funkcióján át a raptor dátumkezeléséig. és ez csak egy példa volt
-
bambano
titán
egyrészt az it gyors változása valóban probléma, be kellene húzni a kéziféket, és egy hosszabb időszakban újabb funkciók bevezetése nélkül ki kellene takarítani a hibákat. de debuggolni senki nem szeret, így inkább újabb dolgok kódolásával verik el az idejüket.
másrészt az it azért több részből és rétegből is áll. először ki kell találnod az algoritmust, valamilyen pszeudonyelven megfogalmazni, bizonyítani, majd utána valamilyen aktuális környezetben lekódolni. ebből az algoritmuselmélet rész egyáltalán nem változik olyan gyorsan, sőt, leginkább semennyire se. ennek a bizonyítása lenne a tudományos része az it fejlesztésnek. utána következik a favágó része, amikor kódgenerátorral meg kézzel favágó módjára krampácsolod befelé a metódusokat. ez gyorsan változik, de nem is erre készít fel az egyetem.
"Az egyetem feladata szerintem az lenne, hogy mérnököket képezzen.": melyik egyetem? mert a bme az pl. klasszikusan olyan egyetem, ami mérnököket képez. az elte meg nem. a mérnökök fölött is van még egy szint: az elte programtervező matematikusa.
-
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.
-
Ribi
nagyúr
Ezt a részt nem értem: "algoritmusokkal, definíciókkal bizonyíthatóan működő tervet készíteni"
Meg kellene tanulni valamit, de mire megtanulod már elavult, de úgy hogy még nem tanult meg semmit, tervezzen meg valamit. Erre jó a tapasztalat. Vagy akkor ennek hogy kellene működnie? -
strogov
senior tag
A probléma, hogy az IT gyors változása (nem csak fejlődés) nehezen összeegyeztethető az egyetemen állandóságával. Ráadásul az IT munkakörök 99%-a szakmunka amihez fölösleges egyetemre járni. Megjegyzem minden szakma 99%-a szakmunka, és a maradék 1% 99%-a is favágás.
A gyors változást az IT munkahelyek se tudják követni. Olyan feladatkörök jönnek létre amik korábban nem voltak, és nehéz megállapítani az alkalmasságot egy 20 éve ott dolgozónál ha nincs se képzés, se időszakos felmérés. Ha sikerült a ticket-et kipipálnia akkor ért ahhoz IS.
A felmenő rendszer képzés nélkül komoly anomáliákat szül. pl. Kiadnak valakinek API tervezést mert ő már 10 éve senior fejlesztő, és ő a legtapasztaltabb fejlesztő a cégnél. Eleve hülyeség, hogy fejlesztési tapasztalat alapján bíznak meg valaki tervezéssel. Egy senior kőműves se jó ha nekiáll házat tervezni ... mégis nap mint nap használunk (szidjuk mint a bokrot) fejlesztők által kitalált interface-eket, látunk fejlesztő által tervezett DB-t (mer' ahhoz IS ért), sőt ha elég "senior" akkor még az UX-be is bele akar szólni.Az egyetem feladata szerintem az lenne, hogy mérnököket képezzen. 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. Ötletelés van, meg "valószínű", "jó esetben" és persze a tapasztalat: "Ez XYZ cégnél már működik, úgyhogy ez jó." Sok esetben még a józan paraszti ész is hiányzik belőle nemhogy a terv. Nem csak sufni cégeknél, hanem a világ legnagyobb vállalatainál is.
-
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. -
A cégnek jó volt, az biztos. Egyhamar nem lesz kész a cucc, abban biztos lehetsz.
Engem speciel iszonyatosan frusztrált, hogy szándékosan kell fost kiadnom a kezeim közül.
Pláne, hogy ilyen téren idegesítő módon maximalista tudok lenni, abszolút nem ritka, hogy egy pull requestet többször visszadobok. Amíg nem felel meg a kollégák szerint is sokszor már elviselhetetlenül aprólékos, idegesítő szintnek amit elvárok, addig nem megy be a kódba és kész. Olyan szinten, hogy amikor a főnök (team leader) jött oda, hogy általában egyetért velem, de ez most rohadt sürgős lenne, neki is megmondtam, hogy akkor vagy segítsen az arcnak, vagy segítek én és akkor Ő merge-eli be, de én nem vagyok rá hajlandó.
Cserébe vissza is ezt várom, ha én küldök be valamit, az is legyen ilyen irritálóan aprólékosan átnézve, mert csak így lehet biztos, hogy nem megy be fos.
-
Mert meg nem lattal olyan szerzodest, mint ami az elozo melohelyemnek volt. Konkretumok nelkul az volt benne, hogy szallitanak X termeket, es kapnak ezert havi X osszeget, plusz havi Y osszeget az extra fejlesztesekert/optimalizalasokert, amig ilyenek erkeznek. Lejarati hatarido nelkul.
Tobbek kozott ezert is hagytam ott oket.cucka #70: Ennek megis mi koze van a waterfallhoz? Kevered a szezont a fazonnal. Az, hogy konkretan tudjuk, mit akarunk elerni, nem azt jelenti, hogy a munka modszertana waterfall. Kizartnak tartom, hogy ezt magyarazni kelljen, ugyhogy remelem csak trollkodsz.
-
"sokszor konkretan szandekosan keszul szar, hogy aztan el lehessen adni a javitast is"
Bevallom, nem ismerem teljesen a világot, de én ilyet még sohasem láttam. Volt már olyan, hogy nem jól mérték fel a feladatot, stb, és ez meglátszott az eredményen, de szándékosságot sohasem tapasztaltam. És nem látom az üzleti lehetőséget sem ebben, mert ha veled szerződtem, akkor a szerződés alapján neked kell javítani (plusz bevétel nincs), ha pedig bontjuk a szerződést, akkor ugyanúgy nincs további munka és bevétel sem.
-
Dr. Akula
félisten
-
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. -
#25954560
törölt tag
van megegy terulet, ahol erdekes az optimalizacio: amikor olyan szoftvert fejlesztesz, amilyiknek egy vagy tobb versenytarsa is van. ilyenkor mindig el kell dontenie a vezetesnek, hogy most ficsorokkel akarnak operalni v sebesseggel, illetve a ketto milyen mixevel.
egyebkent ugy latom sokmindenben egyezik a velemenyunk. remeltem h nem vagyok egyedul
-
bambano
titán
"Persze tisztaban vagyok vele, hogy sok cegnel eleve ugy kezdik, hogy nem tudjuk, hogy micsoda es mire lesz, de tegnapra kell.": ebből lettek az agilis módszertanok meg a "képesek legyünk rohadt gyorsan deployolni a szemetet a felhőbe" rendszerek (docker, kubernetes és társai).
-
"Ahol más cégnek fejlesztenek szoftvert, ott nem erre optimalizálnak."
Na, ez mondjuk annyira igaz, hogy sokszor konkretan szandekosan keszul szar, hogy aztan el lehessen adni a javitast is, ismerem a dolgot.
Adatbazis eleres: Erre kell kicsi PoC-ot irni, amivel szepen szenne tudod tesztelni a dolgot, aztan azt a kis kodot mar konnyu jora faragni. De azt alairom, hogy az atabazis tud trukkos lenni, idealis esetben van ra kulon ember, aki mar a specifikalasnal es a tervezesnel jelen van, sot, konkretan tervezi a db-t, illetve egyengeti a programozokat, hogy mit hogy merre kene hasznalni, hogy jo legyen. Azt is alairom, hogy ilyen viszont sajnos mar tenyleg ritkan van, pedig igeny az lenne ra.
-
CPT.Pirk
Jómunkásember
Nem az iskolai programozás tanítás a felesleges, hanem a heti 1 órában tanított programozás. Azzal aztán lófütyköst ér el az oktatási rendszer.
Nem tudom másnak mennyi volt, nekem szakközéptől fősuliig ennél több nem igen jutott a programozásból. Utána magamtól tanultam meg mindent, mert ebből a szempontból jó munkahelyre kerültem, jó kollégákkal. -
Dr. Akula
félisten
A BME már 25 éve is arról szólt hogy tétel-bizonyítás-tétel-bizonyítás-kicsöngettek. Az utolsó szint ahol még tanítanak is, nem csak darálják a ki tudja mit, az a főiskola. Viszont az egyetemi papír többet ér, mert magasabb tudásszintet bizonyít - csak hát azt magadtól kell megtanulni, mert órán a tanártól nem fogod.
-
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.
-
"akkor visszakérdeznék, hogy mennyi pénzt?"
Normalis cegeknel ismerik a technical debt fogalmat es tisztaban vannak vele, hogy az mit jelent es miert kell elkerulni.
Az En tapasztalatom az, hogy utolagos optimalizaciora nagyon ritkan van szukseg egy normalisan vegiggondolt, specifikalt es megirt programnal. Persze, evente 1-2 ilyen esettel talalkozunk mi is, amikor nem eleg a szep es jol tervezett es megirt kod, hanem konkretan neki kell allni szetoptizni a lelket, de egyreszt ritka, masreszt a modularitas miatt nem okoz nagy gondot.
Amiket felsoroltal, azok tipikusan olyan dolgok, amikkel vagy elore tisztaban vagy es mar a specifikacioban szamitasz ra, vagy tudsz rajuk irni kicsi, kulonallo proof of concept-eket, amikkel ki tudod merni, tesztelni, ott helyben megoldod a problemat, es amikor megvan a nyero modszer, azt kicsinositva szepen kulon modulkent be lehet kotni a projektbe. Raadasul ez a leirt procedura osszessegeben altalaban rovidebb ido, mint belehanyi valamit valami monolitikus borzadalyba, aztan utana izzadni rajta, hogy megfeleloen mukodjon.Persze tisztaban vagyok vele, hogy sok cegnel eleve ugy kezdik, hogy nem tudjuk, hogy micsoda es mire lesz, de tegnapra kell. Na, ott a letezo leghatekonyabb programozasi modszer a felmondolevel. Meg egeszseges is.
-
bambano
titán
annak a felmérésnek, hogy hol tanult az illető programozni, akkor lenne értelme, ha mellé tennék, hogy milyen minőségű kódot krampácsol.
másrészt meg ott van egy ordas nagy csalás a felmérésben, hogy mit jelent az, hogy egyetemen tanult valaki? értelemszerűen ha egy egyetem tulajdonában levő előadóba betette a fenekét úgy, hogy beiratkozott, befizette a tandíjat, az egyetem. de ha nem felvételizett egyetemre, nem jár oda, viszont megnézni a netre kirakott egyetemi előadás-videókat, akkor ő milyen képzést csinált?
-
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. -
Dr. Akula
félisten
Végülis Einsteinnek se tanította senki az E=mc2-t, tehát felesleges az oktatás.
A diploma lényege sose az volt hogy aki onnan kijön az mident tud, hanem hogy egy bizonyos tudásszint meglétét bizonyítja. Lehet enélkül is megszerezni ugyanazt a tudást, csak ki hiszi el neked? Bárki mondhatja magáról hogy mindent is tud. -
Nem ertek egyet.
"A gyors szoftver elsősorban skill és idő kérdése."
Helyett:
"A gyors szoftver elsősorban skill kérdése..." Meg vallalati kultura. Kell egy tokos, tapasztalt es jo vezeto, aki mellesleg minimum senior programozo, vagy legalabb az volt valaha. Az a helyzet, hogy szep es gyors kodot eredetileg megirni ugyanannyi ido, mint egy lassu fos spagettit, csak elobbi karbantarthato, utobbi meg nem, tehat igazabol a jo kod hosszu tavon kevesebb ido es olcsobb, mint a fos. Itt jon be a kepbe a vallalati kultura, hogy vajon felfogjak-e azt, hogy az elejen "a falnal alldogalo es beszelgeto programozohorda" (valos idezet egy regi, segghulye manageremtol) igazabol a cegnek idot, penzt es energiat sporol hosszutavon, sot, mar kozeptavon is, sot, igazabol konkretan az 1.0 utan azonnal, vagy nem.szerk: tisztanlatas kedveert, a "fal" olyan anyagbol volt, mint a tablak, amikre lehet irkalni filccel.
A jatekokat ne keverjuk ide, nagyon specialis terulet, ahol a lehetetlennel hataros rendesen elore tervezni. Tegyuk meg hozza, hogy a jatekfejlesztok iszonyatosan alul vannak fizetve, igy azt a par megszallottat kiveve nem eppen a programozas kremje dolgozik ott. Az meg, hogy pistike, aki meg programozot is csak kepen latott, az is javascript junior volt, aki azzal kezdi a hello world-ot, hogy behuzza a fel npm-et, panaszkodik, hogy valami nincs optimalizalva nem tudom, hogy jon ide, akkora baromsagokat irnak az emberek ilyen teren, hogy olvasni is faj. Regebben meg probalkoztam elmagyarazni, hogy mar magat a szot is rosszul hasznaljak az esetek 99%-ban, de egy ideje feladtam, inkabb csak atkattintok mashova.
-
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
. -
Graphics
Jómunkásember
Jaaa
bakker én már 33 évesen úgy érzem magam, a lóvé meg sehol... ![;]](//cdn.rios.hu/dl/s/v1.gif)
Nincs értelme hajtani, rámegy ( ment) az egészségem... Elcseszett világ ez amúgy, de ez más téma... Vagy tényleg végső állapotomban vagyok, de néha olyan levert szar mosott fos állapotot érzek... Nyugdíj... áh..
Pedig alapvetően én félreteszem, amit csak lehet... De a túloldalra nem lehet átvinni...
-
Danex
addikt
válasz
#25954560
#47
üzenetére
Gyakorlatban viszont azt tapasztalom, hogy lehetőleg minden hamar legyen kész.
Ergo az, hogy egy programrész 8 krumplistészta alatt végez a számítással vagy 9,5 krumplistészta alatt az kevésbé probléma, mint az, hogy utóbbihoz olyan fejlesztők kellenek akiknek a bérigénye messze magasabb és/vagy 2 hét helyett 1,5 hónap kell nekik, hogy elkészüljenek.
Egyszerűen olcsóbb és gyorsabb egy átlagosan jó kódot írni és venni alá jó hardvert, mintsem esetleg szarrá optimalizálni.
Persze itt is vannak olyan területek ahol bődületes mennyiségű adattal kell dolgozni és jelentős különbség jelentkezhet, de a valóságban ez nagyon kevés %-ot jelent.
Egyetemen annak meg nem látom sok értelmét, hogy gyakorlat hiányában magolnak / puskáznak/ bugdácsolnak a diákok. a 3.5 év helyett valamikor 5 év után kicsusszan a junior aki bár hallott valami ordóról de ugyan úgy rá kell gugliznia ,hogy hogyan is volt a képlet pontosan. Akkor már arra is ugyan úgy rá tud guglizni, hogy az adott szituációban milyen algoritmus a leghatékonyabb neki.
Tény, hogy kellenek az Msc-s fejlesztők, jók lesznek architechnek stb. De a gyakorlatban amíg 1 db kell belőlük addig 10-15 "kódoló" kell és az már teljesen mindegy, hogy egy tapasztalatlan Bsc 3-5év szopás után, vagy egy bootcampes kódoló 1.5 csapatban való munkatapasztalattal rendelkező emberke. -
#25954560
törölt tag
kinek mit jelent a programozo. ki milyen feladatokra hasznalja. ki milyen programnyelvet hasznal. ki milyen szintre akar eljutni.
teny, hogy nagyon sok mindent meg lehet tanulni magadtol. ujabb es ujabb programnyelveket is akar. viszont nem art, ha van valami jo alapja az embernek, azt viszont idealis esetben tanitottak neki
szisztematikusan es reszletesen, a szamitogepek mukodeset is beleertve. az is igaz, hogy a mindenfele keretrendszerek es konyvtarak sokszor lenyegesen konnyebbe es gyorsabba teszik egy program megirasat, szerintem minel jobban el van absztraktalva egy nyelv a hardvertol es kornyezettol, annal kevesebbet tudnak a hasznaloi arrol h igazibol mi is tortenik egy fuggveny hivasakor. ha ezt nem tanitjak meg az embernek, akkor a nagy tobbseg nem fog utanamenni es magatol megtanulni, mert legtobb esetben nem is erdekes.az en gondolkodasom elegge be van szukulve a hatekonysagra, programozas szempontjabol sokmindent ezen a szemuvegen keresztul nezek. az a sajat tapasztalatom, hogy az utolagos optimalizacio mint olyan hasznos, de messze nem olyan eredmenyes, mintha mar eleve a hatekonysagot tartanank szem elott a program irasakor. marpedig ehhez folyamatosan fejlodni, olvasgatni es kiserletezni/tesztelgetni kell, ami megintcsak feltetelez bizonyos szintu alapokat.
amikor mar minden szamitogepeken fut es egyre tobb energiat esznek meg a letfontossagu, de foleg a kenyelmi szolgaltatasokat nyujto honlapok, felho szolgaltatasok, stb, akkor megintcsak erdekes lesz egyszer a hatekonysag, mindegy h optimalizacionak hivjuk, mint mar otven eve, energiahatekonysagnak mint az utobbi tiz evben vagy valami masnak. tehat mindegy, hogy arra gyurunk, hogy minel gyorsabbak legyenek a programjaink ugyanazon a vason vagy a fokabebiket akarjuk megmenteni, a jo programozasnak resze kene legyen a 'mi is tortenik a hatterben?' tipusu tudas. na _azt_ szerintem tanitani kene.
-
Silεncε
őstag
Unit tesztelés nálunk olyan szinten volt, hogy volt külön tárgyunk, ami csak kifejezetten a tesztelés folyamatáról szólt és ott kellett többet között ezt is csinálni (egy opensource projektet kellett tesztelni). Ezen kívül kb semmi (meg egy másik csoportmunkás tárgyon volt minimális tesztelés, de azt nem mondanám unit tesztnek)
-
#04824576
törölt tag
Az informatikaoktatással ugyanaz a helyzet, mint az összes többi tárgy oktatásával. Magát a nyers anyagot jobb, ha magától tanulja az ember, mert úgy szerez olyan tudást, amit használ is, vagy ami érdekli. Az oktatásnak az lenne a dolga, hogy irányítottan bevezessen a témába, hogy ne az legyen, hogy kinyitsz egy könyvet, ami tele van parancsok leírásával, hogy mi mire való, te meg ülsz, és pislogsz, hogy akkor most mi van.
Szóval az oktatásnak az a része, amikor először ül le a gyerek az órán egy számítógép elé programozni, és megmutatják neki, hogyan épül fel a programozási nyelv szintaxisa, na meg maga a fordítóprogram, és milyen alapelveket kell követni, az nagyon hasznos. A többit viszont én is feleslegesnek érzem iskolai keretek között. Innen már bárki el tud indulni maga.
Na meg a másik, hogy hasznos lenne még, ha különböző technikákra, ügyes trükkökre tanítanák az embert, amit könyvekből nem nagyon lehet megtanulni, de ehhez meg olyan irányító tanár kellene, aki am aktívan programoz is. Abból meg nagyon kevés van.
-
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?
-
Silεncε
őstag
Erre (Szeged) sincs kódreview (legalábbis én nem találkoztam vele), ez különösen akkor volt jó, amikor csapatmunkában a másik odahányt spagettikódját kellett nekem javítgatni, hogy legalább működőképesre ki tudjuk kalapálni (nem egy olyan is volt, hogy inkább újraírtam/tuk, mert kevesebb munka volt).
A másik kedvencem, amikor mással csináltatjuk meg a kötprogot pénzért. Csak azt nem értem, hogy az ilyen ha már a kötprogot se akarja megcsinálni, mit fog csinálni a munkahelyén? Fizet valakinek, hogy megcsinálja helyette a munkát?
-
#30
secretgarden
aktív tag
secretgarden
#29
secretgarden
aktív tag
válasz
secretgarden
#29
üzenetére
Hozzatennem, hogy nyilvan vannak szakmak amit nem lehet otthon ulve elsajatitani, nem fekudnek egy csak internetes online tanfolyamot vegzett sebesz kese ala vagy nem ulnek egy csak Flight Simulator-on jatszasbol tanult pilota gepere. :-) Szoval nem mondom hogy foiskola/egyetem/szakiranyu kepzes felesleg minden esetben, hanem hogy bizonyos esetekben az. Pl. hogy programozonak felsofoku vegzetsseget kerjenek a munkaadok, vagy ne akarjanak szoba allni egy leendo bolti penztarossal mert nincs kereskedelmi vegzettsege az marhasag, szerintem...
-
#29
secretgarden
aktív tag
Create.
#9
-
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)
-
cog777
senior tag
"A felvetés, hogy nem kell egyetem, vagy főiskola, meglehetősen furcsa. A rendszerben gondolkodást ott sajátítják el a hallgatók.
Attol fugg. Kulfoldon mar altalanos iskolaban elkezdodik a csapatmunka, osszefuggesek keresese, megertese. Sokkal onallobbak.
A magyar oktatasi rendszer ettol fenyevekre el van maradva.
Lazan kapcsolodik hogy amikor rakerdeztem egyik ismeros lanyara, hogy megy neki a zeneiskola akkor azt a valaszt kaptam hogy annake ellenere hogy "elit" kozepfoku iskolarol van szo, meg mindig egyesevel jatszanak hangszeren, meg veletlenul sem csapatban.Ezzel szemben lanyom masik orszagban jar altalanos iskolaban es mar regen csapatban oldjak meg a feladatokat (es az IT csak eszkoz szamukra).
Bizonyos mernoki feladatok megoldasara jo az egyetem, de sokszor nincs ra szukseg terulettol fuggoen. -
#24
siposz
aktív tag
cinemazealot
#23
siposz
aktív tag
válasz
cinemazealot
#23
üzenetére
BMEn dobták vissza beadandómat emiatt. Ismerősnek csináltam beadandót (én ELTE), megkaptam a specit, tip-top megírtam, de a tanár objektum orientáltan várta, én meg full procedurálisan írtam.
-
#23
cinemazealot
addikt
cucka
#20
cinemazealot
addikt
-
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. -
Graphics
Jómunkásember
Na csak begépeltem, aztán elfelejtettem a küldésre nyomni
Szóval, én tanultam 10 éve programozást, algoritmust, és egyéb huncutságokat, C++, C#, .net, PHP, Java és hasonlók... Valahogy elvégeztem a főiskolát is, diplomáztam...
De sosem ment, sosem állt rá az agyam, fogékony voltam valamennyire ezekre, meg jó volt alkotni, meg vannak elképzeléseim mit mivel hogy lenne jó megvalósítani..
De nem vagyok programozói alkat...
Ellenpélda.: Egyik legjobb barátom ugyanabba a suliba járt két évig, ahová én is, majd féltávon váltott egy szakmai iskolába. Kitanult egy szakmát.
Sose tanult programozni ,ehhez képest Pesten helyezkedett el több éve programozóként, profin tanul bele bármelyik nyelvbe, jól használja az autodidakta módon megszerzett tudását.
Én sose lettem programozó, helyette autodidakta módon valamelyest professzionális szintem megtanultam Photoshopban dolgozni. ( persze lehetne továbbfejlődni mindig)
Szóval azt gondolom ,hogy a tanár ,a rendszer felelőssége lenne a diákokat a megfelelő, számára érdekelt szakmába terelni, és ott hagyni kibontakozni...
Hozzáteszem, tanári pályára is léptem, de 1 év után elengedtem, mert 0 szabadidővel egyszerűen nem tudtam véghezvinni azt a tanítási módot, amit a diákok megérdemelnének...
Sok dologba belefogtam, mindhez egy kicsit... De programozáshoz kell egy olyan agy
-
#18
cinemazealot
addikt
bhonti
#1
cinemazealot
addikt
Azért, mert ha nem tanítják meg a programozni vágyót rendszerben gondolkozni (lásd (#10) sh4d0w hozzászólását), illetve hogy egy-egy többféleképpen implementálható megoldás közül melyik erőforrás igényesebb a másiknál, akkor bizony hardver kell ahhoz, hogy a szoftver akadás nélkül elfusson.
Egyetemen villamosmérnöki szakon nem olyan kifinomult és elmélyült módon tanultuk a programozást, mint informatika szakon. Egyszer egy infós sráccal közös fejlesztési projektben a srác lépten-nyomon átírta a kódomat mindenféle flancos megoldásokra, amiket akkor én még nem igazán ismertem, és ez rendesen piszkálta a büszkeségemet. Később jöttem rá, mennyire igaza volt, mert erőforrásigény szempontjából az ő változata bizony sokkal optimálisabban futott, mint az enyém.
Szóval tény, hogy sok mindent el lehet sajátítani autodidakta módon, de az ínyencségekre is érdemes odafigyelni, mert sokszor azokon áll vagy bukik egy megoldás működőképessége. És ha ezeknek a felismerésére nem fordítunk időt és energiát, akkor bizony jönnek a több gigabájt memóriás mobil eszközök és a rajtuk ennek ellenére akadozva futó szemetek, amikre gyógyír csak a következő évben kiadott dupla annyiba kerülő és még több erőforrással felszerelt modell lesz... ami ugyanolyan gyorsan el fog évülni, mert manapság gyorsan kell szoftver fejleszteni és nem alaposan.
Némileg kapcsolódik: Kisfogyasztású számítógépek nyomában
-
Nyilván ez nem jelenti azt, hogy a felsőoktatás felesleges lenne, hiszen a felmérésben résztvevők közel fele, konkrétan 42,7%-a azért egyetemen tanult, és 28,2%-a MSc szintig jutott.
Ez pontosan azt jelenti, ami ide van írva. Nem pedig azt, hogy az ott tanultakat tudták volna érdemben alkalmazni. -
Ribi
nagyúr
Ezek szerint nem tűnt fel, hogy "enyhe" trollkodás volt, pedig próbáltam jelezni.
Mindig agyfaszt kapok amikor bárhol bármikor bármivel kapcsolatban megemlítik, hogy lám lám pár ember aki elhagyta az egyetemet, vagy nem is járt oda és mégis milyen gazdag.
Kb semmi köze a 2 dolgonak egymáshoz. És a cikk második részéhez még annyira sincs köze.
-
#14
DraXoN
addikt
Cyberboy42
#13
DraXoN
addikt
válasz
Cyberboy42
#13
üzenetére
Erről ez a film részlet jutott eszembe:
"Te olvasol? B*zi vagy?" -
#13
Cyberboy42
senior tag
Cyberboy42
senior tag
Ugyan már. Minek nekünk ész. Az a gyengék fegyvere!
-
Az egyik tanárom mondta, hogy ezt a tantárgyat nem is érti, hogy minek, talán ha 1000-ból egy ember ha fog találkozni vele, de erre kapja a suli a pénzt, így ezt kell visszakérni is.
És igen, ha magadtól nem foglalkozol vele napi szinten legalább egy órát éveken át, akkor kb sose leszel junior se.
-
dokanin
aktív tag
Info egyetemmel az a legnagyobb probléma, hogy 5 év alatt elavul az az ismeretanyag, ami programozáshoz szükséges. Én most 40 felett vagyok, de már legalább háromszor kellett ezalatt technológiát váltanom és szinte mindent újratanulni.
Saját bőrömön érzem, hogy van az a kor ami felett már nem esik ez olyan jól.
Az egyetemi tanárokra is igaz lehet ez, mivel azok is 40 felett szoktak lenni.
Így már amikor az ember megtanulja az egyetemen, már akkor elavult a tudás.
Szóval aki nem tanul meg magától tanulni, ebben a szakmában nincs jövője. -
#9
Create.
addikt
CptAdamica
#6
válasz
CptAdamica
#6
üzenetére
Levelezőn vagyok programtervező infón. Mindent magadnak kell kiszenvedni, tele olyan dolgokkal, amik már 5-10éve nem is olyan formában vannak. Egy valamire jó a diploma, hogy látják rajtad, hogy kitartóan kiseggelted. Ráadásul olyan kedvesek, hogy szinte minden óra, vizsga pénteken van... mert levelezőre természetes a munkanélküliek járnak. Teljes mértékben az oktatási rendszer a sz*r.
-
Tehat egy olyan ceg, ami abbol el, hogy ott tudod magad jatekosan programozasban onkepezni arra jutott a sajat felmereseben, hogy amugy nem kell semmi, csak jatekosan onkepezni magad es minden fasza lesz?
Wow. Teljesen ledobbentem. Azt tudtatok, hogy a pekek szerint ha sok kenyeret eszel, az jo neked? -
#7
aprokaroka87
nagyúr
CptAdamica
#6
aprokaroka87
nagyúr
válasz
CptAdamica
#6
üzenetére
Szerintem az IT terület alapvetően is áll egyfajta őnképzésből.
-
#6
CptAdamica
veterán
CptAdamica
veterán
Nem tudom külföldön milyen a helyzet, de itthon inkább az oktatási rendszerrel és a tananyaggal van a gond. Én is jártam ilyen szakra, de semmit sem ért, mert minden hülyeséget tanítottak, csak azt nem, amit kellett volna. Plusz elég nagy terület, az iskola jobb esetben elvisz egy kezdő szintre, ha tovább akarsz fejlődni, akkor muszáj magadat képezni.
-
Bármely szakmát meg lehet tanulni autodidakta. Csak amíg a programozáshoz elegendő egy számítógép, a többi szakma jóval bonyolultabb lehet, mert a tanuláshoz szükséges fizikai eszközöket és alapanyagokat otthoni szinten nem feltétlenül lehet vagy nem éri meg beszerezni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- sziku69: Fűzzük össze a szavakat :)
- Mindenki Z Fold7-et akar
- OFF TOPIC 44 - Te mondd, hogy offtopic, a te hangod mélyebb!
- AMD Navi Radeon™ RX 9xxx sorozat
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Star Trek Online -=MMORPG=-
- EAFC 25
- További aktív témák...
- Motorola G72 128GB, Kártyafüggetlen, 1 Év Garanciával
- Akció! Újra Gamer EGEREK! Glorious , Endgamer XM1R , Nibio
- Új MSI Katana 15 Gamer FHD IPS 144Hz i7-13620H 10mag 16GB 512GB Nvidia RTX 4060 8GB Win11 Garancia
- Tablet felvásárlás! Samsung Galaxy Tab S10+, Samsung Galaxy Tab S10 Ultra, Samsung Galaxy Tab S10 FE
- 12 GB-os RTX 4070Ti - garanciával
Állásajánlatok
Cég: FOTC
Város: Budapest