Azt a dolgozót, aki csak a kódminőség javításán dolgozik (nem ad hozzá a termékhez új képességeket), a többi dolgozónál …

Programozás

…alacsonyabb fizetésért foglalkoztatnám.
1% (6 szavazat)
…egyenrangú fizetésért foglalkoztatnám.
32% (158 szavazat)
…magasabb fizetésért foglalkoztatnám.
8% (40 szavazat)
Nem hagynám, hogy egy dolgozó kizárólag ilyen munkát végezzen.
43% (209 szavazat)
Csak az eredmény érdekel.
15% (74 szavazat)
Összes szavazat: 487

( szotsaki | 2016. 11. 30., sze – 09:45 )

- Ez a kérdés olyan cégekre/csapatokra vonatkozik, akik vannak már olyan nagyok, hogy egy ilyen „munkakört” megengedhessék maguknak.
- A kódminőség javításába beletartozik a fordítói figyelmeztetések javítása, statikus és futásidejű analizátorok futtatása és a jelzett hibáik javítása, új tesztesetek írása, teljesítményoptimalizálás, illetve kis mértékben a kívülről jelentett hibák javítása (nem problem management a fő feladata).

Arra ixeltem, hogy "Nem hagynám, hogy egy dolgozó kizárólag ilyen munkát végezzen.", de rajottem, hogy egy QA csapat, vagy az E2E tesztelok pontosan ilyen munkat vegeznek, bar csak attetelesen, hiszen nem kozvetlenul javitjak a kodot, de bug-ok felderitesevel vagy kulonbozo reportokkal (test coverage). Mondjuk az a gyanum, hogy nem rajuk gondoltal...

( sarkanyolo v | 2016. 12. 01., cs – 08:45 )

Inkább mindenkiben tudatosítanám az elvárt minőségi sztenderdet és ellenőrizném annak betartását.

Mindig azzal kell dolgozni ami van es minden a kicsinel nagyobb projekt az "atvett" mert a kollegak fele mar reg nincs ott akik a kodot irtak.

Az lehet kerdeses, hogy ebben az esetben neki kell-e allni az oncelu kodtisztitasnak (tehat nem bug javitas, funkcionalitas nem valtozik), vagy minden uj funkcio hozzaadasakor kell az erintett reszeket tisztabba tenni. Szerintem az utobbi.

Valahol a ketto kozt lehet az igazsag. Atlathatatlan kodbazisban pl estimalni se tudsz rendesen, hiszen fogalmad sincs, hogy mit es hol is kene implementalni - max egy kodos elkepzelesed lehet rola -, hogy ne zuhanjon magaba az egesz kartyavar. Tehat aktivan is kell tisztogatni, meg feature implemetalasa kozben is.

Tegye fel a kezét, aki még nem írt gányolt kódot! (Jó, le lehet rakni, én sem szeretek fél kézzel gépelni.) Egész egyszerűn van az a helyzet, amikor szükség van rá, ezt el kéne fogadni. És szerintem addig nincs is vele gond, amíg tudod róla, hogy gányolt kód, és ha eljön az ideje, rendbe rakod (vagy kukázod).

+1

Tapasztaltom szerint a rossz kodot min. 3-szor kell refaktoralni ahhoz, hogy az utolso maradvany elbaltazas is kiirtodjon belole. Tehat egyetlen ertelmes megoldas van: elsore a leheto legjobb minosegu kodot kell irni. A problema inkabb az, hogy meg mindig ott tartunk, hogy a szoftverfejlesztes = kodolas, ja igen kell majd a vegen valami design dokumentacio is, de azt majd masvalaki megirja a kod alapjan. Hat olyan is lesz.

Szoval a jo kod a jo designnal kezdodik. Egy jo designt mar nagyon nehez rosszul lekodolni (persze van akiknek sikerul), de egy nem letezo vagy rossz designt csak rosszul lehet lekodolni.

( Breaknet | 2016. 12. 01., cs – 08:52 )

A kódminőség javítása manapság sokkal fontosabb, mint az új funkciók. Optimalizálatlan, bugos kóddal lassú és sebezhető lesz a rendszer.

Te dolgoztal mar olyan projekten ahol az volt a feladat, hogy "ne valtozzon semmi, csak legyen jobb?" azaz, hogy nem kellenek uj funkciok, most csak a kodminoseget javitjuk fel evig?

A kodminoseg persze fontos, de semmikepp nem allitanam ellentetbe az uj funkciokkal. Szerintem hulyeseg osszehasonlitani oket (lasd: az egyik sokkal fontosabb a masiknal).

Fontos a kódminőség, van amikor csak azzal kell foglalkozni. Akár hosszú percekig.

17h-ig tart a munkaidő, 18.30h-ig fakultatív program a kód javítása. Minél többen bent maradnak, annál kevesebb hónapig tart a túlóra "lehetősége".

Programozótól napi 6 óra produktív munkát várunk el (12h-t számlázunk az ügyfélnek), abba belefér, hogy 6:45h alatt minőségibbé is tegye a kódot...

Igen, és ez hamar átértékelődik, amikor arról van szó, hogy ha nem működik egy funkció, akkor bukjátok az egész projektet. Hiába van szép kódod (ami egyébként igencsak szubjektív), ha nincs munka, mert semmit nem tudtok időre teljesíteni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( GerzSonka | 2016. 12. 01., cs – 09:32 )

A maintenance és refactoring munka hosszú távon elég idegőrlő. Én mindenképpen rotálnám az embereket. A feladat fontos, de nem hagynám, hogy valaki kizárólag ezzel foglalkozzon.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

+1 volt már szerencsém olyan kódhoz ahol más szarát kellett lapátolni, 3 napig tartott de már két óra után nagyon elegem volt belőle. Olyanok voltak benne, hogy öröklődés helyett lemásolta a classt és átírt egy-két dolgot.
A másik ilyen a kínai androidos tv box input stackje volt amibe belehekkelt valami kínai idióta, ennek eredménye, hogy billentyűzetek, egerek és usb érintő kijelzők nem működtek, csak az ő IR-os távirányító szerűségük...

Ez elméletben szép és jó, csak gyakorlatban sokszor megesik, hogy a már tisztázott specifikáció alapján megtervezett, és már félig implementált alkalmazásba új feature-t, és a betervezett helyett teljesen más architektúrát kérnek. A management belemegy a megkérdezésed nélkül, mert biznyic, és abból jön a pénz, te pedig cseszheted, felül vagy bírálva, de ki nem dobhatod amit eddig csináltál, mert akkor az sokáig tart.
És akkor jön az instrukció: patkold meg!

Ha nemet mondasz, akkor hoznak helyetted mást, aki még nincs olyan tapasztalt, hogy féljen keresztbe húzni mindent.
Ha igent mondasz, akkor a te nevedet fogják egy tákolt fos alá vésni, pedig te mindent megtettél.

A management elárulja a szakmát, így is, úgy is.

:/

--
Where do you want to go today?
[nobody@salcay:~]$_

Ez szép és jó, de itt konkrétan Activity-kről van szó androidon, amik nagyjából az ablakok megfelelői. Ilyet is szoktam csinálni ahova kell, de ide öröklődés kellett már csak azért is, hogy meg tudd hívni az adott Activity-t. Illetve azért azt mondani, hogy ez minden esetben jobb mint az öröklődés tévedés, viszont pl. multiple inheritance helyett egy sokkal jobb megoldás.

( gelei v | 2016. 12. 01., cs – 10:06 )

Szerintem ez egy teljesen más role, így kb annyira értelmezhető a kérdés, minthogy a tanár vagy az orvos kapjon-e több fizetést.

Meg amúgy is #define többi_dolgozó :)

Szerintem meg nem szabad, hogy külön role legyen, mert annak az lesz az eredménye, hogy a normál fejlesztők továbbra is ontják magukból a szar kódot, a takarítók pedig az alkohol felé fordulnak...

Viszont ha valakinek folyamatosan a saját szarját kell lapátolnia (mert pl 4x dobják vissza code-review közben), akkor vagy megtanul rendes kódot produkálni, vagy elmegy. Mindkettő jó irány...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

+1 szerintem is ez működik. Persze ettől még van QA department meg management, de nem ők lapátolnak, hanem ők csak előírják és betartatják.

De az is fontos, hogy ne az fogadja el a kódot, aki írta, ezért kell keresztbe review-zni, illetve objektív formai kritériumokat megállapítani.

"Szerintem meg nem szabad, hogy külön role legyen, mert annak az lesz az eredménye, hogy a normál fejlesztők továbbra is ontják magukból a szar kódot, a takarítók pedig az alkohol felé fordulnak..."

+sok, azt a fejlesztot, aki kodminosegre specializalodik, inkabb konzultanskent kepzelnem el, aki egy ideig csatlakozik a csapathoz, megtanitja az embereket normalis kodot irni (pl. clean code, unit testing, egyeb best practice-ek).

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

( dejo v | 2016. 12. 01., cs – 11:34 )

Elgondolkodnék azon, hogy ki az aki ezt firtatja és mi lehet ennek az oka?
Egyáltalán megéri-e őt tovább foglalkoztatni! :D
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Mióta bevezettük, hogy minden kódot valakinek review-olni kell, nőtt a minőség.

Leszoktunk az egyszerű gyors és frappáns megoldásokról, helyette megírjuk érthetően és rendesen. Meg teszteljük is, mert úgyis repül a review-n ha nincsenek tesztek.

Többször szerettem volna már magamat agyonverni néhány kódom miatt (csak később jutott eszembe hogy én írtam), szóval azóta több türelem van bennem az emberekkel szemben. Nagyon sokat tud segíteni, ha olyan szabályokat alkalmaz a cég, amik a szar kód bejutásának valószínűségét drámaian lecsökkentik.

Csak azért még nem rakod be a kódot, mert sürget a határidő. Vagy rendesen megcsinálod, vagy sehogy. Szar kódot írni elméletileg kevesebb idő, viszont gyakorlatban a karbantartás többe kerül. Egyszer rendesen, érthetően meg kell írni, ez addig tart, ameddig. Nem kellenek ügyes kis megoldások, amiről 1 év múlva már senki sem tudja, hogy mi a frászkarikát csinál és miért.

( _Franko_ v | 2016. 12. 01., cs – 13:01 )

A többiek fizetéséből le lehet vonni pont annyit? :)

( laja | 2016. 12. 01., cs – 13:27 )

Ez nagyon rossz ötlet. A kódminőségjavító ember elveszti a kapcsolatot a valódi világ valós igényeivel, és elkezd nagyon szép légvárakat összehozni. Továbbá ahogy már előttem is mondták: ez nem egy ember felelőssége, hanem a csapaté. Az jó, ha felismeritek a problémát, hogy valamit kéne kezdeni a kódbázissal, de hogy erre egy dedikált ember legyen, az csak egyemberes projektekben működhet.

Vagy mi az elképzelés egyáltalán? Van 4 fejlesztő, akikből 3 írja az új feature-öket, 1 meg takarít utánuk? Két nyugdíjas role lesz ebből. Aztán leválik mégegy fejlesztő, aki meg csak automatizált teszteket ír? És ha elmegy 3 hét szabadságra a kódminőségjavító kolléga, akkor összecsapnak a hullámok?

Vigyázz, ez fordítva is igaz: az az ügyfél, akinek a légbőlkapott igényei maradéktalanul teljesítve vannak, további légbőlkapott igényekkel fog jönni, és egyszer a lufi kipukkad, a kártyavár összedől, és nem lesz orvos, aki az erszényes tűzköpő nyúlcápát megpatkolja. Ez pedig szolgáltatás kieséshez és pénzóceánok elúszásához vezet.

--
Where do you want to go today?
[nobody@salcay:~]$_

Vannak problémás ügyfelek.

Cégen belül valaki kitalál valamit, az tovább adja másnak, az meg egy harmadiknak, aki már nem ért semmit az egészből, a tudása annyi, hogy megkérdezi, hogy mikorra lesz kész.
Konkrétan megtörtént:
- szállíts le egy kódot, ami összehasonlítja az XY rendszer kimenetét
- mivel hasonlítom össze?
- az XY rendszer kimenetét kell összehasonlítani. Mikorra lesz kész?
- még nem jutottam el odáig, hogy mit mivel kellene összehasonlítani
- jön a következő csávó, akinek megint financiája sincs a problémáról: mikorra lesz kész?
- még nem tudom, hogy mit mivel kellene összehasonlítani
- az XY rendszer logjait itt találod meg...

A projekt tele volt kreténekkel, senkinek a leghalványabb fogalma sem volt róla, hogy minek van ott, semmihez sem értett, csak addig jutott el, hogy határidő. Csinálja meg más helyette, ők semmihez sem értettek, a többi emberen akartak mindent bevasalni. Klasszikus példa, hogy ha fingod nincs semmiről rendezz hatalmas meeting-et és hívj meg még 50 embert, akinek szintén fingja nincs semmiről. És beszélgess a határidőről.

Te meg állsz és nézel, mint a moziban. Kód nincs, röpködnek az eszkalációk, menedszerek menedzserének a menedzserei kezdik a főnökömet piszkálni, hogy miattunk csúszik minden.

A főnök mondja:
- felesleges dumálni, tessék leszállítani, amit a megrendelő rendelt
- mivel hasonlítsam össze XY kimenetét?
- amivel jólesik. Mondjuk a felhasználó beküldhet egy CSV fájlt.
- legyen kész a meló, mert én belefáradtam, fizetnek, minket meg tovább nem érdekel a dolog

Kész is lett, leszállítottuk, menedzserek és almenedzserek, szárnysegédek örültek, minden rendben volt.
Kb. másfél év kellett, míg eljutottak odáig, hogy valami értelmes került a csapatba, aki rájött, hogy használhatatlan a kód és érdeklődni kezdett.

Viszont nem is tudták ránk verni a balhét, hogy miattunk csúszott a projekt. Ők fizettek, mi meg leszállítottuk. A menedzser menedzserének menedzsere meg a papíron behúzta az X-et. Nagyvállalati kultúra.

( Sea-you | 2016. 12. 01., cs – 14:13 )

Az egyik legjobban mukodo quality assurance, ha a kod megy a GitHubra public repoba :) Mar ha eppen olyan, hogy lehet. De az esetleg a projektnek irt komponensek mindenfelekeppen.

Amugy meg szigorunak kell lenni es megbeszelni, hogy melyik megoldas miert nem jo es addig nyomni amig kijavitasra nem kerul. Ehhez persze kell egyfajta erettseg is, hogy ne vegye senki szemelyeskedesnek a "kotekedest".

Erre kulon embert tartani oriasi hulyeseg. Kieg aztan elmegy.

( joco01 v | 2016. 12. 01., cs – 14:21 )

Mindenki egyformán jó minőségű kódot ír, ennyi. Az már régen rossz, ha erre külön ember kellene, de az is gáz, ha akár csak egy ember rossz kódot ír.

--

( the_manni | 2016. 12. 01., cs – 18:27 )

Szerintem ha valaki csak kódminőséget javít, akkor valszeg ez a mániája, különben önszámtából foglalkozna mással is néha. Az ilyen emberektől meg nem biztos, h javul a kód, inkább csak az ő szájíze szerintire változik.

Úgyhogy kirúgnám. :)

Hozzad se megyek dolgozni akkor :)

Viccet felreteve, ha a sajat szajiz tenyeken alapul, akkor nincs gond vele. Ha csak "mert en igy szeretem", ugy igazad van.

Pl. nekem nagyon sok gondom van a stateful kodbazis megertesevel, mert a memoriam annyira nem jo, hogy mindent fejben tartsak, en jobb szeretem, ha a kod beszedes, olvashato es bejarhato, megismerheto. Nem akarom megjegyezni, hogy 20 package-dzsel arrebb mi settel be mit, es milyen logika alapjan azon az osztalyon, amit epp hasznalnek, majd utana fel evig fejben tartani. Ezert en tolnam a stateless es funkcionalis paradigmakra epulo fejlesztest. Nyilvan ez a sajat szajizem, de szerintem a tobbieknek is jobban atlathato lenne a kod, a fentebb elmondottak miatt.

Amíg a szépítés nem akadályozza a fejlesztést, addig akár hasznos is lehet. Viszont, ha valaki például szabadidejében elkezdi refaktorálni a kódot, amin közben munkaidőben dolgoznak, akkor jelentős plusz fejfájást tud okozni a feature fejesztőknek, mert állandóan variálja alattuk a kódot és így gyakorlatilag minden nap fele arra tud elmenni, hogy az előző éjjeli módosításokhoz adaptálják a saját módosításaikat, mivel persze képtelenség a verziókövető rendszer követni, ha mindennek más a neve és máshová kerül minden éjjel :D

( saxus | 2016. 12. 02., p – 01:09 )

Tl;dr: akkor lesz kódminőség, ha egyszer kőbe vésődik majd a szakma az alkalmazott módszereket illetően azzal lesz egy egységes kritériumrendszer, ami be van hajtatva a fejlesztőkön. És aki ezt nem képes megugrani, az nem fog a szakmában dolgozni.

Addig ameddig a kódminőség sokszor valakinek a szájízét és nem valami egzakt szabályrendszert és mérőszámot jelent vicc az egész téma.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( hnsz2002 v | 2016. 12. 02., p – 09:12 )

1. Baromira idegörlő hosszú távon másnak a szarját takarítani. Bármiben, nem csak programozásban.
2. Azt büntetném, aki a szart előállítja (a normál programozó 10Ft, a szart előállító 7Ft, a takarító meg 13Ft). Nyilván nem arról van szó, hogy egyszer-kétszer gyorsan kell, mert akkor nem is kéne tisztításra ember. Arról, amikor valaki állandóan ilyet produkál.
3. A mai rettentő komplex rendszereknél, programoknál baromi fontos a jó minőségű kód, mert másképp borzasztó debuggolni, hibát keresni és javítani.
4. Pont a komplexitás miatt nem lehet egyetlen emberre bízni a kódot. Ahhoz meg hogy más is átlássa, jónak kell lennie.
--
"Sose a gép a hülye."

Büntetnéd aki szart állít elő...
Nem találnak a cégek képzett munkaerőt, ezért kénytelenek felvenni alulképzett, a szakma iránt nem érdeklődő embereket.
Ezek az emberek ha 2x annyi időt kapnak a munkára, akkor sem tudnak sokkal jobbat csinálni. És ez kb minden szakmára igaz.
... kirúgni nem nagyon lehet őket, mert nincs jobb helyettük.

( sigellef | 2016. 12. 02., p – 19:35 )

Azzal lehet még fűszerezni a témát, hogy amikor már szépen meg van tisztítva a kód, és kitalálják, hogy változtatni kell a progi valamely funkcióján ( új verzió, új ötlet, stb...). Ugy 2 lehetőség van:

1.
- a tisztított kódot adjuk a programozónak módosításra. ( ilyenkor előfordulhat, hogy a programozó azt mondja, hogy "mijez?" )
- módosítás után ismét kódtisztítás ( ha csak néhány függvényről/objektumról van szó, akkor így hamar megvan ez a munka )

2.
- a programozó folytatja azt a kódot, amit eredetileg ő írt saját maga. (mert ismeri, mert átlátja, ígyhát jobban megy a munka, hamarabb, jobb eredmény)
- vissza a kódtisztítóhoz ( "óóó, hát a fele majdnem ugyanaz, mint a multkor!")

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Én alapvetően arra hajlok, hogy legyenek dedikált feature időszakok és dedikált refactor időszakok a fejlesztés során.

Ha feature fejlesztésnél vagy prototípus gyártásnál azzal törődsz, hogy feleljen meg mindenféle clean coding szabályoknak a létrejövő kód, akkor egy csomó időt elvesztesz azzal, hogy a kidobandó kódot polírozod, amikor elég lenne a nagyját lereszelni az illesztési hézagoknak, mert a stackoverflow válaszban a kód nem illeszkedik pontosan. :)

Ugyanakkor odafigyelve is lesznek olyan változások a kódban, amelyek könyörögnek egy mélyebb refactor munka után, ezeket is meg kell csinálni időnként. Néha át kell nevezni, össze kell vonni, szét kell választani mezőket, osztályokat, metódusokat... és ezeket akkor lehet csinálni, amikor nincs feature fejlesztés tegnapi határidővel.

Kb. ezt vallom avval a kiegészítéssel, hogy a prototípus egy külön, nem production mappába menjen, mindenféle korlátozás nélkül. Production mappába pedig csak tiszta kód mehet be, code review, tesztek, stb. Ha productionbe engedsz szar kódot, az már gáz. Így viszont ez nem fordulhat elő.

--

Néha kell prod szintre is gányt engedni, mert megtérül... szoktam mondani, hogy ha egy feature hoz két üzemeltetőnyi pénzt, cserébe elvisz egy üzemeltetőt az életben tartása, akkor ki fog menni élesbe, mert megtérül. Csak legyen mellétéve refactor ciklus, amikor stabilizálni lehet a kódot. Ha ez utóbbi nincs, az a szívás.

Itt visszaköszön a unit teszt vs kódjavítás problémája.
Ha nincs idő mind a kettőre, akkor melyik is a jobb választás.

Illetve az ebből fakadó másik probléma:
1) ha van unit teszt, akkor könnyebb refaktorálni
vs
2) ha jó minőségű a kód, akkor könnyebb, kevesebb idő unit tesztet írni, illetve kevesebbszer kell.

Ha hozza a pénzt, akkor senkit nem kellene érdekeljen, mert fognak jönni további üzleti igények, amelyek hátán kell legyen idő és pénz arra, hogy refaktoráljunk. Abból van gond, ha egy üzleti igény nem hozza a pénzt, de belső hatalmi játszmák miatt van csak határideje és amint kiment, marad úgy, ahogy kiment. Na, ilyenből sokkal többet láttam, mint abból, amelyik hozza a pénzt.

Pénzügyben dolgozom, nehéz megmondani, hogy mi hozza a pénzt, mi viszi.

A szar kód általában viszi. A nagy pénzek eldugott részek apró bugjaiban úsznak el.

Amit 10.000-szer használnak, az stabil. Amit évente 1-szer, az kevésbé, viszont talicskázni lehet vele a pénzt a kukába.

Amit sűrűn használnak, nem feltétlen jelent nagy zsetont is, kis bugon is repülhet rózsadombi villa a levesbe.

Mérhető, hogy mi hozza és mi viszi a pénzt. Mondjuk ritkán van korszakalkotó ötletük, ahol számít a leszállítás ideje, de néha előfordul, hogy az viszi a piac egy szegmensét, amelyik előbb tud piacra lépni. Az, hogy sok helyen egymás másoló balfaszok vannak csak a pénzügyi szektorban, az nem befolyásolja ezt.

Igen, gyorsabbnak kell lenni a konkurenciánál, ezzel megnyered az új ügyfeleket.

Ha viszont a régiek elmennek, akkor simán negatívba csúszhatsz.
Ha veszel egy ABC bankot, annak az az érdeke, hogy a jól fizetős, sokat kereső ügyfeleket megszerezze, mert azon van a nagy haszon.

Viszont ha elveszti a nyugdíjasokat (sok kevés haszonnal), nem fog pozitívan kijönni a buliból. A torony eldől, ha nem elég stabilak az alapok. Az alapozás meg nem ingyér van.

Általánosságban így van, de se általánosságban, se a konkrét esetben nem a Te dolgod megmondani, hogy egy feature vagy bugfix milyen minőségben készüljön el és mikor menjen élesbe. A Te feladatod az, hogy meghatározd a feature vagy bugfix kockázatát, hogy ha az üzlet dönteni akar, akkor legyen elegendő információja. És majd az üzlet dönt a kockázatok és mellékhatások ismeretében. Néha úgy dönt, hogy nem megy ki akkor se, ha teljesen készen van és biztonságos... néha úgy dönt, hogy akkor is kimegy, ha a fél IT támasztja hátulról a díszleteket, mert még úgy is megéri. Néha balfaszok, néha nem. Utólag derül ki.

Igen, de az a helyzet, hogy ha egyszer üzleti okok miatt beraktad a szemetet, az nagy valószínűséggel 5 év múlva is ott lesz.

Legalábbis még nem volt olyan tapasztalatom, hogy most gyorsan szarul megcsináljuk valamit, utána alaposan kitesztelve javítsuk. Nem jellemző. Ha már egyszer kinn van a szar és úgy ahogy megy, onnantól már az "inkább ne piszkáld" elv válik fontossá.

Szépen lassan átalakul a fejlesztési modell is:
- gyorsan lapátoljuk kifelé a szart, minden azonnal megvalósul
- a karbantartásra meg lehetőleg semmit se áldozzunk, ha nem megy, módosítasz 2 három sort, azt szevasz

Ez a modell a kényelmes, ami végeredményként hulladékgyártást eredményez. Minden azonnal kell, a karbantartásra semmit nem akarunk áldozni.
Egyre költségesebbé válik a fejlesztés, egyre több részt kell alapjairól újraírni, egyre kevésbé tudsz a support miatt haladni, az emberek demotiválttá válnak és lelépnek, szépen lassan meg elvesztesz mindent, ami versenyelőnyöd volt. Ezután eljutsz odáig, hogy talán nem akarsz mindent azonnal kitenni, mert nem bírod elviselni a környezetszennyezést, amit a fejlesztési modell eredményez.

"Legalábbis még nem volt olyan tapasztalatom, hogy most gyorsan szarul megcsináljuk valamit, utána alaposan kitesztelve javítsuk. Nem jellemző."

Ez is egy kockázat, amit mindig mondani kell. És ha ez miatt volt bármilyen probléma, akkor is azonnal kommunikálni kell. A kommunikáción és az együttműködésen múlik minden...

...és azon, hogy ne akard a hátadon vinni a céget, ha nem vagy részvényes. Ha folyton azért sírsz, mert nincs elegendő erőforrás, ugyanakkor minden határidőre elkészül, mert mindenki megkettőzött erővel dolgozik és megoldja okosban, akkor hiteltelen a sírás. Nincs pénz rendes mentésre? Akkor nem csinálunk fusiban desktop gépekre mentést a szerverekről. Megdöglött és nem volt mentés? Hát... én szóltam, nem?

VSP és MVP... :)

Védd a Segged Papírral: mindenről legyen írás.
MásValaki Problémája: mindig dobd tovább a forró krumplit.

Ha asz'ondja a főnök, hogy csinálj mentést, de szarul, akkor nem biztos, hogy örül neki, ha nemet mondasz. Szerencsére munkaerőhiány van az IT-ban, és az ilyen helyről gyorsan dobbantani kellene. De amíg nem terjed el ez a mentalitás, addig lesznek hülye vezetők, hülye utasításokkal, és dolgozók, akik meg is csinálják ezeket. Amúgy meg jobb helyeken is vannak gondok, és ha valaki tényleg MVP szinten oldja meg a problémákat, az hamar az utcán találja magát.

--

"Ha asz'ondja a főnök, hogy csinálj mentést, de szarul, akkor nem biztos, hogy örül neki, ha nemet mondasz."

Háde, baszki.

Üzletnek gond nélkül azt mondod, hogy a világ minden pénzéért nem tesszük ki az új fejlesztést, hozzon akármennyi pénzt, mert most még nincs olyan állapotban, majd ha tökéletes lesz, gyertek vissza két hónap múlva, ugyan akkor se lesz kész, de már többet tudunk, hogy kész lesz-e egyáltalán.

Ugyanakkor meg féltjük a munkahelyünket a morcos főnökkel szemben, ezért aztán magunkat szopatjuk azzal, hogy minden szart körbeácsolunk és kifelé azt mutatjuk, hogy minden a legnagyobb rendben van, a disznó tizennégyet fialt.

Nincs itt egy pici kis ellentmondás? :)

"Amúgy meg jobb helyeken is vannak gondok, és ha valaki tényleg MVP szinten oldja meg a problémákat, az hamar az utcán találja magát."

Az MVP alapvetően azt jelenti, hogy ne vállalj magadra olyan munkát, ami tulajdonképpen nem a Te feladatod. Nem csinálunk mentéseket a szerverekről az asztali gépekre, mert ott van hely vagy egyáltalán nincs backup megoldás, hanem
1, VSP: főnök, nincs elég hely a mentésre
2, MVP: főnök, venni kellene egy backup megoldás, mert nagy szopás lesz.

És addig eszkalálni, amíg valaki azt nem mondja, hogy akkor nem lesz mentés. Aztán ha tényleg szopás van, akkor ez a valaki majd felvállalja. Ha ehelyett kuss van és asztali gépekre megy a mentés, akkor sose lesz több hely vagy backup megoldás. Szóval szólni kell (VSP) és eszkalálni (MVP).