Hirdetés
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- A béka átlép a szarvasbogáron
- Samsung Galaxy Z Fold5 - toldozás-foldozás
- Samsung Galaxy S23 Ultra - non plus ultra
- Ilyen lehet az S25 Ultra fogyókúra után
- Telekom mobilszolgáltatások
- Milyen okostelefont vegyek?
- Dobhatják a mozis képarányt az idei Sony Xperiák
- DIGI Mobil
- Kipróbálunk valami újat, az iPhone-os kolléga kinyitható Androidra vált
Új hozzászólás Aktív témák
-
Graphics
Jómunkásember
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...
[ Szerkesztve ]
EAGET 1TB SSD review - https://logout.hu/bejegyzes/graphics/eaget_s600_1tb-os_ssd_aliexpressrol_kihagyhatatlan.html
-
opr
veterán
Azt tudod, hogy most gyakorlatilag megerositetted azt, amit &rew irt? Mashogy mondva leirtad ugyanazt, mashogy, azaz hogy a jo, gyors, stabil es modularis kod inkabb "szokas" kerdese, mint utolagos optimalizalase.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
cucka
addikt
A 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 .
[ Szerkesztve ]
-
opr
veterán
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.
[ Szerkesztve ]
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
Dr. Akula
nagyúr
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.
-
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. -
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?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
cog777
senior tag
-
opr
veterán
"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.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
-
-
cucka
addikt
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.
[ Szerkesztve ]
-
Dr. Akula
nagyúr
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.
-
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.Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
opr
veterán
"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."Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
"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).
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#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
-
opr
veterán
Na igen. Mondjuk az agilis modszertan nem feltetlen ordogtol valo, csak tudni kell esszel hasznalni. Sajnos ez az, ami altalaban nem sikerul.
&rew #68:
[ Szerkesztve ]
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
cucka
addikt
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. -
Dr. Akula
nagyúr
-
Korrektor
"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.
-
opr
veterán
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.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
opr
veterán
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."Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
cucka
addikt
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. -
DjFlanker
aktív tag
Most hogy már én is fejlesztők között mozgok, egyre tanulságosabbak ezeket a threadeket olvasnom.
Jó pilóta alagútban nem katapultál
-
-
-
hogy ne üljön le a topic 85 hsz után:
szerintem rendesen programozni csak rendes egyetemi diplomával lehet.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.
-
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? -
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.
-
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
"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
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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. -
"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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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. -
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.