Új hozzászólás Aktív témák
-
buherton
őstag
Persze a programozó írja a kódot, de ugyanezt a programozót kérik meg a legacy hibajavításra, induló porjekt támogatásba és a mostani kifutó pátyolgatásba. Akkor még nem beszéltünk arról, hogy kik azok akik kapják a prémiumot meg az előléptetést? Akik időre tudnak szállítani, még ha kétséges annak minősége.
Megfordítom a kérdést. Cégen belül kinek az érdeke a jó minsőgéű kód? Nem a programozóé
. (Ez a kérdés vonatkozik a #24-es hszedre is.)[ Szerkesztve ]
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
cog777
senior tag
Marpedig Bicinek igaza van. A fejlesztes menetet jobb-komolyabb helyeken megtervezik.
A vezetosegnek, product owner-nek, vezetoprogramozonak ra kell bolintani az adott funkcio implementalasara.
Barmikor mondhatjak hogy bocsi, de a 24 oras tesz framework-nek most alacsony a prioritasa.
Ergo, a tisztelt programozo azt csinalja amit mondanak neki. Marmint a legtobb helyen (kiveve az 1 fos bt ofc)
Ausztral kollegak viszont sokszor meglepnek hogy ott ennyire nincs ez, es tenyleg jo featureket raknak a termekbe.HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian
-
Vinrael
tag
Nem érted. Adott egy idő, az alatt el KELL készülnie. Az idő általában kevés, ezért úgy oldja meg a programozó, ahogy belefér az időben. Ha lenne több idő, és szempont lenne a kód minősége, akkor nyilván megoldaná: lásd a fent említett példák.
Vagy úgy gondolod, hogy te majd kioktatod a vezetőséget, hogy te nem tudod megoldani ennyi idő alatt? Ok, majd jön más a helyedre, aki megírja a kívánt szar kódot annyi idő alatt amennyi alatt kérik.https://www.youtube.com/channel/UCGzkAM74dJ_Vo2r73Y1tv2Q
-
Reverend
tag
Nem értünk egyet. Jön egy új funckió, széttolja az eddigi kódot. 2 út van:
1. refaktor. Eredmény szép, gyors kód, ráfordítás: 1 hónap
2. gány. Eredmény ronda bugos kód, ráfordítás: 1 hét.
Szerinted a főnök / megrendelő melyiket fogja választani? Ha nem tudod a választ, akkor félek, Te nem dolgoztál fejlesztő cégnél. Alternatív lefutás: ha nálatok az 1-es megoldást választják, akkor jól becsüld meg a helyet! -
dabadab
titán
"te dolgoztál már komolyabb szoftverfejlesztő cégnél?
a vezetőség ült a géped előtt és döfködte a klavit, vagy te?"Mivel én - veled ellentétben - tényleg szoftverfejlesztő vagyok és a pályafutásom nagy részét határozottan komoly cégeknél töltöttem, elmagyarázom: a kód optimailzálása plusz fejlesztési idő, amit a vezetőségnek kell megadnia.
És ez tényleg csak az eleje, mert az optimalizálásnak a komplett munkafolyamat részévé kell válnia: meg kell határozni az optimalizálási célokat (hogy pl. az optimalizálásnak számít-e, hogy ha a memóriahasználat a felére csökken úgy, hogy a futási sebesség kb 10%-kal lassul), optimalizálási scenariokat (nem mindegy, hogy arra optimalizálunk, hogy a rendszerben van egymillió foo meg egymillió bar, vagy arra, hogy van kétmillió foo meg harminc bar), elérendő követelményeket, a tesztrendszerbe be kell vezetni a non-feautre requirementeket (vagyi olyasmiket, hogy ebből a műveletből mondjuk másodpercenként hárommilliónak kell lefutnia úgy, hogy a memóriahasználat ne menjen 50 MB föle), ezekre teszt szcenáriókat alkotni és berakni a release requirementek köze, a fejelsztőknek rendes profile-ozó toolokat kell adni megfelelő tesztkörnyezettel ésatöbbi (és persze mindez baromi sok pénzbe kerül).Szóval a dolog sokkal inkább múlik a management döntésein, mint bármi máson.
DRM is theft
-
floatr
veterán
-
Igen, én dolgoztam, de nem fejlesztőként.
Szerintem nincs igazad.A vezetőség az, aki az utolsó pillanatban meggondolja magát, hogy máshogy kéne, de több időt nem ad a rendes átalakításra.
A felsőbb vezetőség várja el, hogy a fejlesztés közben már rögtön az elejétől legyen demo, hogy hol tartanak a dev-ek, és a középvezető ba*sztatja a fejlesztőket, hogy legyen minél színesebb, szagosabb a demo mutatható funckinalitással, és ha a fejlesztőnek emiatt össze kell csapnia valamit, akkor utána nem kap időt rendesen megcsinálni, mert "dehát láttuk, hogy működik".
Szintén a vezetőség erőlteti azt, hogy a cégen belül egyszer már lefejlesztett komponenst minél több projecten használjanak fel, még akkor is, ha nem alkalmas mindenre, és ezért a fejlesztőnek rusnya kényszermegoldásokat kell alkalmaznia. Utána meg a vezető mutogatja a slide-okon, hogy milyen "smart" volt a cég, hogy "egyszer dolgoztak, többször kaszáltak".
Van még pár ilyen pontom, de azokból már kiderülne a cég is.Egyébként én főleg a webes szolgáltatások piacán tapasztalom ezt, de sok ex-kolléga meséli, hogy máshol is ez van kisebb-nagyobb mértékben.
[ Szerkesztve ]
Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
. (Ez a kérdés vonatkozik a #24-es hszedre is.)
Új hozzászólás Aktív témák
it A Linux atyja két hardveres problémát lát kicsúcsosodni a DevOps csapatok előtt.
- Steam Deck
- Villanyszerelés
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- VR topik (Oculus Rift, stb.)
- Napelem - 100%-os támogatású pályázat
- gban: Ingyen kellene, de tegnapra
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Toyota topik
- Milyen cserélhető objektíves gépet?
- Kertészet, mezőgazdaság topik
- További aktív témák...
