- Milyen videókártyát?
- DUNE médialejátszók topicja
- Milyen SSD-t vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Philips LCD és LED TV-k
- Apple asztali gépek
- Vélemény: nem úgy tűnik, de Lip-Bu Tan most menti meg az Intelt
- Bluetooth hangszórók
- Milyen processzort vegyek?
- Nem tetszik a Procon-SP-nek, hogy a Nintendo távolról kivégezheti a Switch 2-t
Új hozzászólás Aktív témák
-
#191
borbastomi
csendes tag
Danex
#50
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.
-
Ispy
nagyúr
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.
-
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.
-
opr
nagyúr
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. -
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. -
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.
-
#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. -
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. -
Dr. Akula
félisten
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.
-
#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.
-
#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.
-
Dr. Akula
félisten
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.
-
Dr. Akula
félisten
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.
-
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.
-
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ő.
-
cucka
addikt
válasz
samujózsi
#166
üzenetére
Nem az újrafelhasználhatóságról szól, hanem a módosíthatóságról.
Az egy következmény, hogy így könnyű újra felhasználni a kódodat. Nem cél.Mit nem lehet érteni azon, hogy csinálsz valamit valamilyen céllal (módosíthatóság), aminek vannak egyéb pozitív következményei (újrafelhasználhatóság)?
Ha írsz valamit ami könnyen módosítható, akkor azt újra felhasználni is könnyű. Ha írsz valamit, ami újrafelhasználható, akkor az jó eséllyel nem lesz sem könnyen módosítható, sem könnyen újrafelhasználható. így érthető?
-
cucka
addikt
válasz
samujózsi
#161
üzenetére
Igen, akkor nem ment át a lényeg, kifejtem.
Amikor újrafelhasználható kódot írsz, akkor arra gondolsz, hogy a kódodat hogyan lehet majd később máshol használni. Például olyan absztrakciókat vezetsz be, amelyek a későbbiekben lehetővé teszik, hogy azt a darab kódot máshol is felhasználd. Ez totális tévút, többnyire hibás feltételezések alapján rossz absztrakciókat fog eredményezni.
A SOLID szabályai sokkal szűkebben vannak értelmezve, és egyáltalán nem az újrafelhasználhatóság miatt találták ki őket, hanem a szoftver karbantarthatósága miatt. A cél mindig az, hogy a forráskódban könnyű legyen a meglévő fícsöröket módosítani és új fícsöröket hozzáadni.Ha belegondolsz, a kódbázisod újrafelhasználható része framework-ökben és library-kban található, ráadásul a többsége nem is a saját kódod, hanem 3rd party.
Ahogy fejlődik a kódbázis, rájösz, hogy bizonyos részeket érdemes lenne újra felhasználni. Ha az említett betűszavakat betartva fejlesztetted, akkor könnyű lesz azokat a kód-darabokat kiemelni egy librarybe és pikk pakk újra felhasználtad a kódodat.
Ha előre próbálod kitalálni, hogy mit fogsz majd a jövőben újra felhasználni, akkor beviszed magad az erdőbe, haszontalan, túlbonyolított absztrakciókat fogsz kitalálni, és amikor valóban eljön az idő, hogy újra felhasználd a kódod, akkor rájösz, hogy az előre okoskodással pont ellentétes hatást értél el, és nem hogy megkönnyítetted az újrafelhasználhatóságot, hanem nehezebbé tetted.Ezt az egész a YAGNI betűszó kifejtése, ez az elv pont erről szól, hogy nem próbálj meg előre, kitalált feltételezések mentén okos lenni, mert az a tapasztalat, hogy nem szokott bejönni.
-
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...
-
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.
-
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. -
samujózsi
senior 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.
-
-
Dr. Akula
félisten
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
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. -
Dr. Akula
félisten
Örülök hogy ennyi naív lelkes kezdő programozó van itt, de hidd el, idővel majd ti is be fogtok állni a sorba, megunva a felesleges, megfizetetlen melót. Mert fizut emelni csak nagyon ritkán szoktak, ebben az országban szinte csak úgy lehet szintet lépni ha munkahelyet is váltasz, ezét panaszkodnak a cégek itt hogy állandóan dobbant a munkaerő. Persze, mert másképp nem lehet több pénzhez jutni. Arra meg hogy "ügyes voltál, csak így tovább!" nem kapsz több kenyeret a boltban. Ha nem lehet feljebb lépni, akkor kevesebbet kell belefektetni hogy megérje, ilyenkor jön a csendes elszabotálás. Örülök hogy te még nem láttál sose ilyet, de ha elég sokáig fogsz dolgozni, hidd el, fogsz. A kezdők naív lelkesedése ez a "dolgozzunk szépen és jól, akkor minden jó lesz", a valóság nem így működik.
(#146) samujózsi: "felhívták a figyelmet arra, hogy amit lehet, úgy kéyzítsünk el, hogy lehetőleg később ne kelljen újra megírni, ha másnak is szüksége lesz hasonló funkciókra"
És ez mozgatott bárkit is? Hogy másnak milyen nehéz lesz, ha őt kirúgják? Én inkább az ellenkezőjét látom, ha megkövetelik a dokumentációt, kommentelést, akkor is csak valami "nesze bazmeg, te akartad..." szintűt adnak. Így belegondolva nem is jut eszembe 1 olyan se amit pozitív példaként tudnék felidézni a melóból. Ez része a "remélem legközelebb is engem hívtok, nem a konkurrenciát" játéknak.
-
arn
félisten
válasz
Dr. Akula
#145
üzenetére
Egy altalanos nyelvi alap kell, mittomen a c, mint szintaktika, ehhez kapcsolodan vmi objektum orientalt nyelv - ennel tobbet nem is kellene tanitani, a gondolkodasmod a lenyeg. Az iskolaban ugyse tudjak, hogy mi lesz 10 ev mulva, sot igazabol azt se, hogy aktualisan mi van... a tobbire majd specializalodik az illeto, ugyis felszedi. Webnel nem csak a nyelvek, nepszeru frameworkok valtoznak folyamatosan, hanem a szemleletmodok is (szerver, kliens oldali render, stb). 18 eve csinalom, egy egyetemi kepzessel kitorolheti mindenki a feneket, alapnak jo max... csak rajta mulik. Radasul akik komolyan gondoljak, mar iskolaba is tapasztalattal mennek.
Amugy amit irsz - kb ez kulonbozteti meg a jo programozot a rossztol. Ez egy hivatas, aki megelhetesi programozo, erdeklodes nelkul, ott az eredmeny is olyan lesz. Mondom ezt ugy, hogy mindig azt mondom, hogy a programozas egy eszkoz, nem cel, nem a tegla a lenyeg, hanem a haz, amit epitesz belole. Ez sok munkaltatonak sem tiszta, leragadnak annal, hogy tudsz egy iskolai feladatot megoldani, aztan a komplexebb gondolkodas meg hianyzik.Es vhol ez a mi generacionk szerencseje, mert nalunk a gep meg az erdeklodes kozpontjaban volt, nem csak egy targy a lakasban, mint a hutoszekreny. Korabban azt hittem, hogy mire 40-50 leszek, nagy gaz lesz, mert nem tudom felvenni a versenyt a friss koponyakkal. Most pont forditva gondolom, sokkal versenykepesebbek vagyunk a gyer felhozatal es az elkotelezettseg hianya miatt.
-
Goose-T
veterán
válasz
Dr. Akula
#145
üzenetére
Elképesztően nem vagy képben a mai szoftveripar működésével kapcsolatban. Ha ennek ellenére mégis szoftverfejlesztőként dolgozol, akkor azt tudom csak tanácsolni, hogy válts munkahelyet minél hamarabb. Ha nem, akkor ne írj többet róla, mert egyrészt fájdalmas olvasni, másrészt - és ez az igazi probléma - félrevezetsz más embereket, akik szintén nincsenek képben.
-
samujózsi
senior tag
válasz
Dr. Akula
#144
üzenetére
Ugye te nem ebből élsz?
Régen valóban nem volt gyakori jelenség az újrahasznosítás. De már amikor én tanultam, már akkor is felhívták a figyelmet arra, hogy amit lehet, úgy kéyzítsünk el, hogy lehetőleg később ne kelljen újra megírni, ha másnak is szüksége lesz hasonló funkciókra. -
Dr. Akula
félisten
Mondjuk az is hasznos lenne ha nem fél év Pascal, majd fél év C(++) után jönne egy 3. nyelv, hanem inkább egyet vinnének végig az elejétől, mindjárt 3x annyira értene hozzá az áldozat. Nem baj az ha programozási nyelvet is tanítanak, legalább egyet lásson az a diák aki elvileg programozó lesz, csak ne ész nélkül, mindenbe belekezdünk, de semmit se fejezünk be.
"webnel kb haromevente megujul egy csomo minden, ki erre nem kepes, sose lesz belole programozo"
Ez így nem igaz, max nem olyan lesz amilyet épp aktuálisan megálmodott a góré, hogy most ilyen kéne. Nemrég volt itt a PH-n vita hogy a játék enginek még mindig régi alapokra épülnek, nem nagyon használják ki a többszálúságot, a régi alapokat foltozgatják. Na ugyanígy egy új programnyelv se megy át azonnal használatba, max ha új a csapat, mindenki most esett ki a suliból, ahol épp azt tanulták, vagy hobbiból azt nézegették, és hát miben is kezdjünk programozni, legyen mondjuk az. És nem is biztos hogy jobb mint az előzőek, az hogy újabb még nem jelent semmit, rengeteg felsült dolgot találtak már ki.
A többség a világ összes más szakmájában is a kötelező minimumra fog hajtani, mert a munk a pénzkeresés eszköze számukra, nem művészi önkifejezés. Ez emberi alaptulajdonság, tudomásul kell venni hogy megváltoztathatatlan. Ha fel kell menni az 5.-re, és van lépcső meg lift, akkor te se a lépcsőt választod, gondolom - más se. Lehet válogatni a jobbak közül, amíg van miből, és van mivel megfizetni, de ha nincs, akkor meg bele kell törődni. Kis pénz, kis foci. Itt jellemzően Trabant áron akar mindenki Ferrarihoz jutni, és sír hogy nem sikerült, Trabantot ugyan kapna, de az meg nem jó neki. Majd 2-3 év múlva belátja hogy jó lesz.
-
Dr. Akula
félisten
Kerül mondjuk X idővel többe jó kódot generálni a fosnál, Y meg kijavítani. Ha X > Y, főleg ha Y = 0, mert kit érdekel, jó az úgy is (működik a kód, csak úgy ahogy), akkor puszta időveszteség. Az újrahasznosítható kódot sokszor senki se fogja újrahasznosítani. Főleg ha más írta. Ha más kódját kell átnézni és folytatni, az 2x annyi idő és 2x annyiba fog kerülni, mint írni egy újat 0-ról. Persze nyilván van ahol muszáj, mert mondjuk egy banki rendszert nem fognak mindig újraírni, de ott meg ezzel kell számolni.
-
arn
félisten
nekem is van diplomam, de szart se tanitottak ott... plane olyat nem, amit hasznosithatni tudtam volna. magamtol tanultam mindent, amit hasznalok a munkahelyen.
amugy nem programozasi nyelveket kellene tanitani, hanem gondolkodasmodot, es hogyan tudjak elsajatitatni maguktol az uj dolgokat. webnel kb haromevente megujul egy csomo minden, ki erre nem kepes, sose lesz belole programozo.
ez sajnos latszik is a szinvonalon, keves igazan jo szinten dolgozo embert ismerek. tobbnyire osszedobalt kodokat csinalnak, es jo egy adott problemat meg tudnak oldani, nem hogy egy komplex rendszert megtervezzenek. sokukbol hianyzik az ujdonsagok iranti nyitottsag, csak sodrodnak az arral.
-
bambano
titán
válasz
Dr. Akula
#127
üzenetére
"Ennyi erővel a péknek is garanciát kéne vállalnia hogy nem lesz belesütve légy vagy hajszál...": és a pék garanciát is vállal.
haccp-nek hívják.
"Mit is nyerünk vele?": hogy ti mit nyertek vele, azt nem tudom. én időt. minél rendesebben végzem el első körben a melót, annál több szabadidőm marad. és mivel vállalkozóként feladatra szerződtem, nem a munkaidőmet adtam el, ezért ha egy cuccom működik, akkor nekem szabadidő van.szoktam mondani, olyan vagyok, mint a körzeti orvos. addig jó, míg nem látsz. először mindenki röhög...
-
cucka
addikt
válasz
Dr. Akula
#139
üzenetére
A helyesírás rész arról szól, hogy vannak emberek, akik leszarják, hogy mit adnak ki a kezük közül. Akinek tele van elgépeléssel a CV-je, mert arra sem vette a fáradságot, hogy a Word-ben bekapcsolja a helyesírás-ellenőrzést, arra kár időt pocsékolni. (Nem elvből, pusztán csak alacsony a valószínűsége, hogy ilyen hozzáállással emberünk jó fejlesztő legyen)
Az agilis fejlesztésnek van értelme, valós problémákra ad valós választ. Erre ráépült egy ipar, akik Agile trainingeket meg certifikátokat adnak ki, az elég haszontalan, mert ha ráépítesz egy merev framework-öt és szabályrendszert, akkor pont az agilitás lényegét ölöd ki.
Ha hozzátok is jött valami Agile certifikátos bohóc előadni, hogy milyen szabályokat kell betartani, akkor nem vagytok agilisek, egyszerűen csak beetették a menedzsmentet a púderrel, és most ti isszátok a levét. -
-
Dr. Akula
félisten
Hát, nálunk a legjobb emberünknek nem erőssége a helyesírás, pont őt lőnéd ki vele (pedig diplomás).
Az ilyen papír arra való hogy whiteboardozás előtt is legyen szelekció látatlanba, ne kelljen 1000 "hákeziccsókolomfőnökúristenbizony mindetistudok"-ot behívni és pazarolni rájuk az idődet.
Mindenféle módszertant kritikusan szemlélek, nálunk a fejlesztők pl. röhögnek az "agilis"-en, ez kb. a "fogalmam sincs, majd lesz valahogy" szinonímája.
Ha csak Józsi ért hozzá, akkor hogy fog más is? Józsitól biztos nem fogja senki megkapni a tudást, arról Józsi gondoskodni fog.
-
#138
samujózsi
senior tag
aprokaroka87
#134
samujózsi
senior tag
válasz
aprokaroka87
#134
üzenetére
Igen, de ettől még egy gány a kód, amit összekókányolok.
-
cucka
addikt
válasz
Dr. Akula
#135
üzenetére
Ha jön 3 jelölt, egyik BME, másik Gábor Dénes, a 3. semmilyen "de kisdobosbecsszóra tudok olyat is" papírral, akkor azért tudsz köztük felállítani egy minőségi sorrendet?
Ha CV alapján kell dönteni, hogy kit kell behívni, akkor a következőket nézem:
1. munkatapasztalat
2. karrierív
3. igénytelenül szerkesztett CV, helyesírási hibák (akkor jó, ha ezek nincsenek, nyilván )
Interjún egy 15 perces whiteboardozás alatt kiderül, hogy van-e miről beszélgetni vagy sem.Példa: mondjuk ITIL (jó, nem tervezési, hanem üzemeltetési hablaty, de a példa szempontjából ugyanaz)
Hát eddig szoftverfejlesztési módszertanról beszéltünk, arra mondtad, hogy haszontalan.
Szóval ilyen it management framework-öket meg iso szabványokat ne keverd ide.Lehet hogy Fejlesztő Józsit így bármikor ki lehetne rúgni, de ennek bevezetésére pont nem Józsi lesz a legnagyobb vevő ...
Nem a dokumentáció a probléma, mert az mindig, minden esetben, minden cégnél szar.
Az a probléma, hogy van egy spagetti rendszer, amihez csak a Józsi ért, és hatalmas időbefektetés külső embernek megérteni, üzemeltetni és továbbfejleszteni. (Az idő pedig pénz, szóval ezért rossz a kis cégnek ha ilyen helyzetben van) -
Dr. Akula
félisten
Igen, az ilyen igények vágyként mindig megjelennek egy munkáltatónál (nem csak a szoftveriparban), de aztán az évek múlásával rájönnek hogy nem fognak találni wc-s nénit 3 diplomával, 2 felsőfokú nyelvvizsgával. Ha addig várunk egy projekttel amíg össze nem gyűlik hozzá az ideális csapat, akkor lehet hogy örökké várni fogunk. Szerintem egy hibás szoftver is jobb mint a semmilyen.
-
Dr. Akula
félisten
Ha jön 3 jelölt, egyik BME, másik Gábor Dénes, a 3. semmilyen "de kisdobosbecsszóra tudok olyat is" papírral, akkor azért tudsz köztük felállítani egy minőségi sorrendet?
Ennek ellenére lehet hogy a papír nélküli a legjobb, de ki hiszi azt el? Messziről jött ember azt mond amit akar, ahogy a mondás tartja.Példa: mondjuk ITIL (jó, nem tervezési, hanem üzemeltetési hablaty, de a példa szempontjából ugyanaz). Még azt se tudják megfogalmazni mire jó, csak segít olyan izékben, amik olyan hogyhívjákok hogy na. Már a megfogalmazása se érthető, akkor nagyjából borítékolható a sikertörténet is ("ez meg WTF?"), az általa felkeltett érdeklődés, aminek az eredménye az hogy 100 beiskolázott emberből 99 ugyanúgy jön ki ahogy bement, csak kicsit álmosabban, 1 meg tud pár szlogent idézni, de hogy mire jó, azt már ő se tudja. Igazán sikertörténet lesz ezt alkalmazni is. Ahelyett hogy csak 1-2 rövid fogást, a lényeget, a bevált és valódi példákkal alátámaszthatóan működő dolgokat lezavarnák fél óra alatt, és akkor mondjuk a 100-ból 50 ember 10%-kal termelékenyebb lenne tőle (a maradék meg akkor se, ezt le kell írni üzemi veszteségként), így a nyereség átlagosan 5% lenne, ami egész potosan 5%-kal jobb a semminél.
Általában ami úgy kezdődik hogy módszertan, arról ránézés nélkül is tudni lehet hogy ez doksigenerálásban biztos emelkedést fog jelenteni, másban ki tudja. A papírozás papírozása a munka halála.Lehet hogy Fejlesztő Józsit így bármikor ki lehetne rúgni, de ennek bevezetésére pont nem Józsi lesz a legnagyobb vevő. Ki az aki szépen ledokumentálna mindent maga után hogy bármikor kirúghassák, vagy fenyegethessék bércsökkentéssel, mert bármikor felvehetnek a helyére valakit? Ha az ilyesmi kezdeti követelmény is, akkor is el lehet szabotálni (és szokták is), lehet csinálni úgy is dokumentációt hogy az semmire nem jó, de attól még látványos, átpörgetve egész mutatós, el lehet hinni hogy jó lesz ez, csak amikor dolgozni kéne belőle, akkor derül ki hogy semmire nem elég. Fejlesztő Józsi biztos ilyet fog gyártani.
-
opr
nagyúr
válasz
Dr. Akula
#131
üzenetére
Hibak vannak, voltak es lesznek is, de ez egy konkretan masik tema, mint hogy alapvetoen szepen dolgozol-e, vagy ganyul. Annyi, hogy a szebben dolgozol, kevesebb hiba lesz, amit konnyebben megtalalsz egy gyorsabban javitasz.
A supermenek meg nem elfogynak, hanem mar felvenni se szabad oket, a kettonek semmi koze egymashoz. Egy junior is tud szep es karbantarthato kodot irni, ha a megfelelo akarat es tamogatas megvan hozza. Sot, ha a mentalitas jo, nemhogy supermenbol, de meg seniorbol is eleg csapatonkent egy. Csaka qz tenyleg legyen senior, ne csak a munkaevek szama alapjan. (lasd meg: junior, 10 ev munkatapasztalattal... Tudjatok, mirol beszelek...)
Bevallom regebben En is ugy gondolkodtam, mint amit most irsz, talan meg itt a forumon is meg tudod talalni azokat a hsz-eket. Azota tudom, hogy nagyon nem volt igazam. Se abban, hogy elfogadhato bizonyos korulmenyek kozott a "gyorsan megirt" kod a "jo" koddal szemben, se abban, hogy tovabb tart jo kodot irni, mint gyorsan ganyolni. Elobbi hosszutavon mindeig gyorsabb. Igazabol meg rovid / kozeptavon is, az egyetlen kivetel talan a projekt elso par hete.
-
samujózsi
senior tag
Szerencsére nem vagyok programozó, bár annak tanultam.
Én azt látom, hogy nagyon kevesen képesek autodidakta módon rendszerezett tudást felszedni. Az meg katasztrofális eredménnyel jàr, amit én is követtem, amikor úgy gondoltam, hogy hobbinak megtartom a tanult szakmát.
Szóval szerintem az alapokat mindenképpen olyan helyen kellene tanulni, ahol rendszerezve, a kapcsolódó alapokat is megtanulva tanítanak.
Hosszú távon az assembly alapok elsajátítása is sokat segít, ha pl C-ben (is) akarsz programozni és debuggolni. Ilyesmi... hogy a hardveres alapokat már ne is említsem. -
Dr. Akula
félisten
Ez addig igaz, ameddig kis létszámú a csapat, kis projekteket visztek. Ha sok ember kell hozzá, akkor előbb-utóbb elfogynak a szupermenek, be kell vonnia kevésbé jókat is. Vagy várni a sültgalambot, hátha jön egy kamion szupermen arrafelé, és pont előttetek robban le a buszuk.
De szerintem minden így működik nagy tételben. Nyilván az ember szeretné ha csak szép és jó lenne az életben, de ebben az életben ez a legritkább esetben van így. Együtt kell tudni élni a hibákkal, ez a kulcs, és inkább ezek kezelésére kidolgozni használható módszereket, a maradékot meg betudni járulékos veszteségnek. -
opr
nagyúr
válasz
Dr. Akula
#127
üzenetére
Hatalmas tevedes. Nem azert nem irok gany kodot, mert erdekel mas mit gondol rolam, vagy mert az jobb lesz a megrendelonek. Azert irok jo kodot, mert nem akarom szivatni magamat. Meg a kollegakat. Ja, meg igazabol de, mar kozeptavon is tobb penzed lesz, ha jo minosegu munkat csinalsz, mintha fost.
Nem terezanya itt senki, csak tudjuk, hogy eri meg dolgozni kozep / hosszutavon. -
cucka
addikt
válasz
Dr. Akula
#125
üzenetére
Persze, annyit állítok, hogy ha látok egy ELTE vagy BME diplomát egy önéletrajzban, az alapvetően nem jelent semmit. Ezek nem messze földön híres minőségi képzések. Nem baj, ha van a jelöltnek innen diplomája, de az se baj, ha nincs.
(#127) Dr. Akula
A sok programozási módszertanból én csak azt látom hogy szép és jó, de leginkább arra való hogy az írójának nevet szerezzen. Amúgy meg kuka.
Mondj már egy-két példát erre, miről érzed azt, hogy a módszertan szerint hasznos de valójában kuka?
Szerintem van egy kis kavarodás itt, a módszertan arra jó, hogy a kódod olvasható, karbantartható, refaktorálható és integrálható legyen, plusz azt hozza magával, hogy a programozók lecserélhetőek legyenek. (Ez utóbbi nem szemétség, hanem komoly probléma sok kis cégnél, ahol valami amatőr Józsi 20 éve tákolja a szoftverüket, és emiatt a Józsitól nem lehet megszabadulni, akármennyire is visszaél a helyzetével) -
cucka
addikt
Hát korábban azt írtad, hogy ha az ügyfél nem hoz teljes specifikációt, visszazavarod az anyjába. Most azt írod, hogy leülsz vele és tisztázzátok a helyzetet. Nagyon nem ugyanaz, előbbiből az látszik, hogy laikus vagy, utóbbiból meg nem.
A matematikai bizonyítás részhez - az elgondolásod addig működik, amíg pure function-ökről beszélünk. Ahogy bejönnek a képbe a mellékhatások, az integráció a külvilággal és a futtatókörnyezet alsóbb rétegei, ott vége az okosságnak.
Sajnos, teszem hozzá, pure function-ökkel megfogalmazni egy megoldást nagyon tiszta, száraz és biztonságos érzés, de ilyenkor a fenti problémás részeket nem tudod megoldani, csak arrébb tolni időben, vagy eltenni szem elől. -
Dr. Akula
félisten
Ennyi erővel a péknek is garanciát kéne vállalnia hogy nem lesz belesütve légy vagy hajszál... Egyszerűen tudomásul kéne venni hogy nem lesz semmi tökéletes, itt emberek dolgoznak, és SZÁMOLNI vele, nem pedig feltételezni hogy amit kapunk az csak jó lehet. Arra kell módszereket kidolgozni hogy lehet együttélni a félig szarral. Kb. mint a RAID: bármikor beszarhat a vinyó, de attól még megmarad az adat.
Meg úgy általánosan az előző hsz-ekre: Úgy látom itt mindenki perfekcionista, mindenki utálja a gány kódot, persze ő maga sosem szokott olyat... Tegyük fel hogy igaz. Mit is nyerünk vele? Elismerő buksisimogatást? Pénzt csak akkor ha valami pénzes dologra tudjuk váltani (előbb lesz kész mert gyorsabban kódol, kevesebb idő alatt lemegy a tesztelés), amúgy meg semmire se jó. Lehet nevet szerezni a demoscenen, de melóban teljesen mások a prioritások. Jobb híján el kell fogadni hogy az egyetlen mérőszám a piac, a megrendelő. Nem magadnak kell szép kódot írni, hanem a megrendelő igényét kiszolgálni. Azért jön a fizetés. Ha erre jobb a gány kód, mert gyorsabban kész van, és kb. senkit nem érdekel hogy hogy, csak fusson, akkor az a jó megoldás.
A sok programozási módszertanból én csak azt látom hogy szép és jó, de leginkább arra való hogy az írójának nevet szerezzen. Amúgy meg kuka. Bizonyára van 1-2 jó ötlet mindegyikben, csak épp szépen eltemetve egy halom rizsa között, és kb. senki nem fogja elolvasni, nem hogy használni, úgy meg a haszna kereken 0. Ezekből is kell egy "MMA"-t csinálni, mint a harcművészetekből, hogy csak a legfontosabb, leghasznosabb pár dolgot összegyúrni és azt oktatni, mert sokkal hasznosabb ha kevés (és hasznos) apróságot tud az ember, mintha sok hosszú kitudjamit nem. És ki kell mondani hogy eddig működik, a továbbiak erőltetése teljesen felesleges, ebből ennyit lehet kihozni, mert nagy tételben nem szupermeneket lehet felvenni dolgozni, hanem átlagembereket, akikből ennyit lehet kihozni.
-
Dr. Akula
félisten
Ma már kb. minden nagyobb városban van legalább 1 egyetem, szal az a 300 nem olyan rossz helyezés az egész világra nézve. 7 milliárd ember nem járhat MIT-ra és Ofxordba. Nem a te figyelmedet kell vele felkelteni, hanem a munkaadókét. Azok meg hiába várják hogy majd a Google csúcsfizetésekből átülnek a pesti minimálbér + borítékba. Ha csak a legjobb 10 ember programozna a világon, még mindig a Windows 3.1-et fejlesztenék, és még Notepad se lenne rajta. Szükség van a kevésbé jókra is, erről szól az emberiség történelme úgy 1 millió éve. Ha a programozós témát nem tudod átérezni, gondolj bele mit ennél ha az egész világra csak 10 pék jutna, de az Michelin csillagos lenne.
-
opr
nagyúr
Ah, ne is mondd, a csovezetek->pipeline, kemenylemez->harddrive meg stb-ktol a mai napig kiver a viz.
Ha vannak tanarok, akik probaljak ezt, azt meg kell becsulni, nagy kincs, illetve enyhen szolva nem trivialis. Aki amiatt bukik ki, mert gondolkodni is kell, azzal meg igazabol semmi gond nincs, konkretan szivesseget tett neki a tanar, roszabbul jarna, ha nem bukna ki es utana derulne ki, hogy teljesen alkalmatlan a szakmaban barmire. Mint ahogy az amugy nem egy diplomas interjuzonknal anno latszott is. Menjen valamilyen bolcsesznek, ott is lehet jol keresni es ott csak magolni kell.
-
Silεncε
őstag
Nálunk volt olyan tanár, aki a session bean-t fordította viszonypaszulyra és ez konkrétan benne volt a jegyzetben
A második gondolat: nálunk vannak olyan tanárok akik próbálják ezt, általában ennek az az eredménye, hogy az ilyen tárgyak a közvélekedés szerint a legnehezebbek és legrosszabbak. Ahol nem a bemagolt anyagot kell visszaadni, hanem gondolkozni. És nem akarok itt álszenteskedni, nekem is van ami ezek közül éppen kettessel lett meg, mert nem volt kedvem előadásra járni meg értelmezni az anyagot, de így visszanézve kicsit már bánom. Nekem annyi szerencsém van, hogy az egyetem kezdete óta dolgozok, így egy csomó mindent láttam a gyakorlatban hogyan is működik hogyan alkalmazzák, meg beszélgettem csomót a már X éve fejlesztő kollégákkal.
-
#122
FoxiestFox
félisten
Remek topik.
Ha már itthon agonizálok valami nyamvedt vírussal, legalább van mit olvasgatni.
Engem nem érdekel az it szoftveres oldala, nem is tudok róla sokat, de érdekeseket írtok.
-
-
-
opr
nagyúr
válasz
#25954560
#116
üzenetére
Sarokdoboz.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Amugy nem ertem, miert kene magyarul irni. Sot, meg anno az egekbe magasztalt progmaton is agyfaszt kaptam tole, hogy egyes profok meg gyakvezek eroltettek azt, hogy magyar kifejezeseket hasznaljunk programozassal kapcsolatban. Sot, igy utolag mar azert is merges vagyok, hogy a matematikai kifejezeseket csak magyarul tanultuk.
Szoval, nem kell a forditas, mert aki erti, igy is erti, aki meg nem, az meg magyarul se fogja.Amugy mar csak annyival, hogy mielott hozzavagja az ujjbegyeit a billentyuzethez, minden kollega vegiggondolna, hogy miket akar elvarni es megigerni (aka contract) a fosaval, es mik a type invariant-ok, es ennek megfeleloen irna a kodot meg a tesztet is, mar annyival jobb minosegu programok keszulnenek, hogy ihaj. Sajnos ez az a resz, amit a magasztalt progmaton borzalmasan tanitottak, mashol, az ilyen koderkepzokben meg sehogy (tobbi egyetemet meg majd megmondja, aki oda jart). Az egyetem hatalmas elonye az volt, hogy miutan a gyakvez meg a prof kibeszelte magabol azt, amit es amihez nem ert, de tanitja, utana oda tudtal menni olyan emberekhez, akik ezen egyszer mar atmentek, ES dolgoznak ES volt olyan senior fejleszto aki elmondta nekik, hogy a valosagban mi az elmelet es miert jo. Na, amikor ez kiderult, akkor hirtelen ertelmet nyert a tananyag is. Tegyuk hozza, amikor megkerdeztem neha, hogy ertem en, ertem mit mondasz, a matematikai levezetest is ertem, meg minden fasza, de "ez mire valo?! Mikor, hogyan es hol hasznaljuk a VALOSAGBAN?!" Akkor jobb esetben kaptam egy nem tudomot, roszabb esetben meg egy csunya nezest egy voros feju embertol, es mentunk tovabb. Rohadt idegesito volt. Szoval, a tananyaga a progmatnak zsenialis lett volna, ha oktat olyan is, aki tudja is mirol beszel, a gyakorlatban, sot, mondjuk akar meg is tudja irni ertelmesen es mondjuk megmutatni.
Amugy letezik meg progmat egyaltalan? Azt hittem, mar megszunt es csak proginf van.
-
#118
Ribi
nagyúr
aprokaroka87
#117
Ribi
nagyúr
válasz
aprokaroka87
#117
üzenetére
1.0 user kb 1:1000000, általában ez már az admin. Jó esetben. Rossz esetben onnan is csak szar, nem működik jön.
Pont ebböl lesz az a pár elhíresült nevetségesen egyszerűen feltörhető weboldal, hogy csak arra mennek, hogy működjön. Felveszik érte a pénzt, aztán ha valaki fel meri törni, majd jól lecsukják. Őket meg úgyse kéri számon senki. Ki volt pipálva, hogy megy. Akkor onnantól mosom kezeim oszt csá.
-
#117
aprokaroka87
nagyúr
aprokaroka87
nagyúr
0.5 ( béta ) szintű User jelzése a témával kapcsolatban.
Sz*r, nem mükődik, f*s....
1.0 szintű user jelzése.
Nem jó, de ha tudok segítek abban hogy mi okazhatja a gondot.
Vajon programozoi oldalról nézve melyik a jobb visszajelzés az user felől?
van egy sejtésem
-
Ribi
nagyúr
válasz
#25954560
#114
üzenetére
Ezt én tudom, ne nekem mond
Csak szerintem bambano kicsit keveri a szar a program és még csak nem is működik és a szar a program, mert fel lehet törni dolgot.
Erre írtam, hogy nincs feltörhetetlen program. Az, hogy valami 100%-ban elláítja feladatát "ideális" esetben, az fényévekre van a kártékony kódoktól is védve van esettől."corner case"-re fingom sincs, de részben ezen segítenek az etikus hekkerek.
-
#25954560
törölt tag
nagyon sok helyen a szoftverek fejlesztese es tesztelese csak a pozitiv esetekre megy. ha azt tudja, akkor mukodonek lesz nyilvanitva.
ezzel szemben tesztelni kene a negativ esetekre is, amit mar kicsit kevesebben csinalnak meg, pedig ott mar johetnek ki vicces bugok. ami viszont gond a negativ esetekkel, hogy jol kell kitalalni mit adsz vissza hiba eseten. elsosorban nyilvanos API-knal jol kell kitalalni, mert ahogy az API-t hasznalo programozot segiti egy reszletes, mittomen hasznalhato bemeneti tartomanyokkal visszatero hibauzenet, ugy a tamadokat is.
a harmadik eset pedig amit szinten sokszor hanyagolnak, a 'corner case' tesztek (bocs, nemtom mi az elfogadott magyar kifejezes ra). ezeket az eseteket a legnehezebb egyaltalan kitalalni is, nem csak tesztelni. na ide kell fantazia es tipikusan a rosszfiuknak sokkal jobban raall erre az agya
egy-egy biztonsagi res hardverben vagy szoftverben nem feltetlenul azt jelenti, hogy akik terveztek vagy csinaltak hulyek voltak, hanem esetleg azt is, hogy 'upsz, erre nem gondoltunk'. ami nem feltetlenul hanyagsag, hanem mar-mar a talalmanyok szintje is.
-
bambano
titán
"Látod, megfogalmaztad a lényeget, csak nem akarod elfogadni.": vagy te nem érted, hogy mit írtam.
te ezt írtad:
"De hadd kérdezzem meg, részt vettél már szoftvergyártási folyamatban akár beszállítói, akár megrendelői oldalon? Mert a hozzászólásodból az süt, hogy nem, csak lököd itt a saját feltételezéseidet meg fantáziáidat arról, hogy mi hogy kéne legyen."ebből két feltételezést lehet kiolvasni:
1. szerinted fogalmam sincs arról, hogy megy a megrendelés és a szoftverfejlesztés az üzleti életben
2. szerinted irreális az, és nekem nincs vele kapcsolatban tapasztalatom, hogy a fejlesztő feleljen a szoftverért.1. van fogalmam. egy csomó projektet végighajtottam eddigi karrierem során, megrendelői és teljesítői oldalról is.
1a. most is teljesítői oldalon dolgozom.
2. az ms megteheti, hogy ráírja a szoftverre, hogy as-is. így az ms-t soha nem meszelik el, ha pocsék kódot ad ki. én nem tehetem meg, engem seggbe rúgnak, ha azért rohad meg a szolgáltatás, mert a szoftverem hibázik. tehát én pont az ellentéte vagyok az ms-nek ebben a kérdésben (meg minden másban is), mert nekem van anyagi felelősségem a kezemből kiadott kódért. ráadásul mivel nem programra szerződök, hanem szolgáltatásra, így folyamatosan felelek a dolgaimért, nem csak garis időben."De azt elvárni, hogy a megrendelő komplett funkcionális speckót tesz le az asztalra, meg kifizeti, hogy te matematikailag igazolod a kód helyességét, ez teljesen a fantázia birodalmában van.": nálam ez úgy megy, hogy addig zaklatom a megrendelőt, amíg nincs rendes speckó. ugyanis ha nincs rendes speckó, akkor én sem tudom eldönteni, hogy mit írjak az editorba. az a modern programozói felfogás, hogy ha a megrendelő nem tudja, hogy mit akar, akkor majd írunk valami szemetet a programba, és átadjuk, és meglátjuk, mit szólnak hozzá, engem nem érdekel. a szervezési munkákat is el kell végezni. ha a megrendelő végzi el, szuper, ha én, akkor én, de a végén komplett speckó van, mielőtt elindítom az editort. ha a megrendelő nem tudja, hogy mit akar, akkor beülök a leendő júzer székébe, és kiderítem. ha interjúztatni kell a júzert, akkor interjúztatom. ha döntésre kell kényszeríteni, akkor rákényszerítem.
a matematikai bizonyítás meg úgy működik, hogy tudom, hogy hogyan kellene bebizonyítani, és úgy írom meg a kódot, ahogy a programhelyesség bizonyításhoz kellene, és akkor tudom, hogy ha akarnám, bebizonyíthatnám, illetve nem formálisan be is bizonyítom. akár megfizetik, akár nem. ehhez kell az egyetemi oktatás, hogy tudd, hogy mi az, hogy programhelyesség bizonyítás, és tudd, hogy adott kódon meg tudnád csinálni, ha kellene. már ettől a tudattól jobb lesz a kód akkor is, ha nem végzed el papíron a bizonyítást.
-
cucka
addikt
Garanciát szokás vállalni, aminek keretében kijavítottátok azokat a hibákat, amiket a megrendelő észrevett, és amelyek a szerződés szerint is hibának tekinthetőek. Itt eddig matematikai helyesség-bizonyításokról volt szó, ez nagyon távol áll attól. Plusz garantált, hogy a garanciális hibák mellett volt még százszor annyi hiba és hibásan működő edge case, amit az ügyfél nem vett észre, vagy nem terjedt ki rá a szerződés, és ezért ott van most is benne a kódban.
Worfklow diagramokat, meg egyebeket is szokás készíteni, ha ezt pszeudokódnak tekinted, akkor igen, van pszeudokód.
Amire ott utaltam, az a feltételezés, hogy bárki bárhol fejlesztés előtt kitalálná az algoritmust és leírná pszeudokódban. Ez nem szokott megtörténni, az említett diagramok ennél sokkal magasabb szintű absztrakciót képviselnek. -
Ribi
nagyúr
Nincs feltörhetetlen software pont ahogy zár sem.
Nincs olyan, hogy az OS fejlesztője hibát tesz bele. Szimplán nem lehet megoldani, hogy minden ellen védve legyen. Ez így ebben a formában igen naív gondolkodás, hogy csak azért nem írnak tökéletes programot, mert nem akarnak/pénz/idő kérdése. -
siposz
aktív tag
Én az ELTE programtervező matematikus szakán végeztem:
Nem vagyunk a BMEs mérnökök fölött, nincs ilyen hierarchia. Egészen más a képzés, van amelyik ebben jobb, van ami abban. Hogy ki lesz architect 10 év után az nem attól függ, hogy az ELTEn vagy a BMEn végzett.
Másrészt nálunk volt pszeudonyelv, meg bizonyítás is. Meg elmondták, hogy a veló életben soha senki nem csinál ilyet, ÉS nem is kéne. Algoritmusokat se találunk ki (mármint olyan értelemben, hogy kitalálok valami új kriptográfiai vagy rendező algoritmust)
" és ez jó lenne. azt lehetne garantálni, hogy a program megfelel a megrendelő által rendesen ledokumentált specifikációnak"
Senki sem ír matematikai specifikációt. Tipikusan azért nem mert aki ilyet tud írni, az könnyedén meg is tudja írni a programot.* Nem mellesleg egy rendesen magyarul vagy angolul megírt specifikáció esetén is a seggünket verdessük a földhöz örömünkben. Hadd ne meséljek az átadás UTÁN véglegesített specifikációkról.
*Ez sajnos elég gyakran visszatérő probléma a megfigyelésem szerint, hogy bármennyire próbáljuk kikerülni, hogy valaminek a megoldásához ne kelljen programozó, ha a probléma algoritmikus gondolkodást és absztrakciót igényel, akkor az a vége hogy de programozó kell.
-
cucka
addikt
senki nem foglalkozik azzal, hogy maga a szoftver milyen. azzal foglalkozunk, hogy az általa menedzselt szolgáltatások minősége eléri-e a szerződéses célértékeket.
Látod, megfogalmaztad a lényeget, csak nem akarod elfogadni.
A megrendelő, aki rettentő sok pénzt fizet, és amiből neked fizetésed lesz, neki nincs szüksége forráskódra. Neki arra van szüksége, hogy működjön a levelezése, elérjék a fileokat a felhasználók, menjenek a rendelések a webshopban, működjön a bi rendszere, meg hasonlók.Ettől még fontos az, hogy milyen a szoftver, a bugokat számon kell tartani, a risket menedzselni kell, a specifikációt hozzá meg kell írni (néha futtatható kódként, lásd BDD).
De azt elvárni, hogy a megrendelő komplett funkcionális speckót tesz le az asztalra, meg kifizeti, hogy te matematikailag igazolod a kód helyességét, ez teljesen a fantázia birodalmában van. És pont úgy vágyhatsz rá, mint ahogy én arra vágyom, hogy 2 méteres kigyúrt vizilabdázó legyek, de egyik sem fog megtörténni, tehát érdemesebb a mentális energiákat másra fordítani. -
strogov
senior tag
"meg lehet oldani, lehet olyan szerződést kötni, amiben a hibákért kötbért fizet a beszállító, szoftveriparban is. Két dolog miatt nem teszik"
Én az elmúlt 20 évben mindig olyan cégnél dolgoztam amelyik bizonyos ideig garanciában javította a hibákat. Volt olyan project ahol 3 hónapig, volt ahol 2 évig. Mindegyik üzleti szoftver, nem űrrakéta.
És mindegyik cégnél pszeudo kódban is kommunikáltunk. Volt amikor ügyfélel is. Folyamatábra nélkül meg elég nehéz workflow-t fejleszteni. Ha nem triviális a folyamat akkor mindig egyeztetek ügyfélel is folyamatot, és eddig mindenki megértette a folyamatábrát.
-
bambano
titán
provisioning rendszert fejlesztek, ami szolgáltatásokat menedzsel.
senki nem foglalkozik azzal, hogy maga a szoftver milyen. azzal foglalkozunk, hogy az általa menedzselt szolgáltatások minősége eléri-e a szerződéses célértékeket.légyszíves ez alapján válaszold meg a saját kérdésed.
"Mert a hozzászólásodból az süt, hogy nem, csak lököd itt a saját feltételezéseidet meg fantáziáidat arról, hogy mi hogy kéne legyen.": mindig ez szokott következni, mikor kiderül, hogy másképp látom a dolgokat, mint a hivtatalos kánon, és sosem az, hogy érvelnek amellett, hogy tévedek.
-
-
cucka
addikt
-
-
-
cucka
addikt
De basszus, meg lehet oldani, lehet olyan szerződést kötni, amiben a hibákért kötbért fizet a beszállító, szoftveriparban is. Két dolog miatt nem teszik
- egyáltalán nem triviális definiálni, hogy mit jelent a hibás teljesítés, és egyáltalán nem triviális bizonyítani sem
- a kötbér kockázata benne lesz az árban, és azt se te, sem más nem fogja tudni/akarni kifizetniDe hadd kérdezzem meg, részt vettél már szoftvergyártási folyamatban akár beszállítói, akár megrendelői oldalon? Mert a hozzászólásodból az süt, hogy nem, csak lököd itt a saját feltételezéseidet meg fantáziáidat arról, hogy mi hogy kéne legyen.
-
cucka
addikt
szerinted lenne ennyi vírus meg szemét a hálózaton, ha a microsoftnak nem engedték volna meg azt a világraszóló disznóságot, hogy a szoftver "as-is"?
Nem engedték meg nekik, mert nem is kellett erre engedélyt kérjenek.
De hajrá, próbálj úgy dobozos szoftvert árulni, hogy kötbért vállalsz a bugokért, biztos remekül fog menni az üzlet.mert egy szoftverfejlesztő se meri azt mondani, hogy elmész anyádba, majd akkor gyere vissza, ha már konkrétan tudod, hogy mit akarsz
Igen, gondolom te is szívesen fizetnél egy ilyen szolgáltatásért rengeteg pénzt.
Halkan jegyzem meg, léteznek emberek, akiknek az a dolguk, hogy felmérjék az üzleti igényeket és ezekből funkcionális specifikációt írjanak.
Matematikai specifikációt meg a legtöbb esetben azért nem írnak, mert nem tudnak, egyszerűen túl nagy a komplexitás és túl sok az ismeretlen. Akkor se tudnának, ha 100x annyi idejük lenne rá.és ez jó lenne. azt lehetne garantálni, hogy a program megfelel a megrendelő által rendesen ledokumentált specifikációnak
Megint a fantázia birodalmában jársz, ahol a nem-tech iparági megrendelő pontosan le tudja specifikálni, hogy mire van szüksége.
De jó ötlet, tényleg jó lenne. Az is jó lenne, ha 2 méteres kigyúrt jóképű vizilabdázó lennék, de hát nem vagyok az.ja, a boeing is jól lespecifikált mindent, a 737max műszereitől kezdve ...
Mondjuk a 737max-nál tudtak a hibáról, és direkt a szőnyeg alá söpörték a piaci előny érdekében. Nem a specifikáció hiánya volt a probléma. A többi esetet nem vágom, lehet, ott igen. -
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. -
opr
nagyúr
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. -
opr
nagyúr
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).
-
opr
nagyúr
"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.
-
opr
nagyúr
"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. -
opr
nagyúr
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
. -
Jaaa
bakker én már 33 évesen úgy érzem magam, a lóvé meg sehol... 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
őstag
"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. -
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.
-
opr
nagyú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.
mindenki azt csinalja, amihez jobban ert.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Az ASUS TUF Gaming B550-Plus csak rád vár! Kamatmentes rèszletre is!!
- Csere-Beszámítás! RGB Számítógép PC játékra! R5 5600X / RTX 3060Ti 8GB / 32GB DDR4 / 500GB SSD
- Konzol felvásárlás!! Nintendo Switch
- IPhone 15 Pro 128GB Szép Állapot! Akku:88% Jótállás: 2026.04.09.-ig
- Xiaomi Redmi 12 Pro 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest