Fejlesztés állandó "túllövése"

 ( dotnetlinux | 2015. április 17., péntek - 17:41 )

Ma megint megkaptam a munkahelyemen, hogy mindig túllövöm a projekteket. Kíváncsi lennék, hogy csak én érzem-e azt, hogy ez nem bűn?

Olvasom a külföldi témájú fórumokat, cikkeket. Lépést tartok a technikákkal, technológiával. És igen, szeretném meghonosítani a modern dolgokat. Hogy mit értek modern alatt? Mondjuk a nyomtatványok származtatását: egyen fejléce lábléce legyen, de copy-paste készüljenek el, hanem legyen egy ősosztály. Ez így szép. Majd amikor kiderül, hogy az alkalmazott technika nem teszi lehetővé, hogy Pistike 1 óra alatt elő tudjon állítani egy A5-ös nyomtatványt, akkor jön a lecseszés. A korábbi gyors fejlesztés előnye mint érv elveszik, helyette jön a mondat: "Delphi5-ben ezt egy pályakezdő 2 óra alatt megcsinálja egy DataModule-lal..."

Ha már Unix Portál, akkor arra is mondok egy példát: Szépen felépített Apache+PHP-fpm rendszerek, automatikus mentéssel, multi-tenant DB-kkel. Minden szépen megy, mindez évek óta (!). Automatikus scriptek, frissítés, stb.

Majd egy délutáni ötlettől vezérelve, hogy hogy nem tudunk beletenni teljesen egyedi ügyfél igényeket, amikor egy 100e Ft-os PHP fejlesztő (hol láttál ilyet?) bele tudná dobni, ha nem lenne keretrendszer. De azt elfelejtik, hogy ha nem lenne, akkor széthullott volna a projekt a 3. hónapban.

Szóval Ti mennyire meritek alkalmazni a modern-kori dolgokat, amelyek néha túlmutatnak a magyar valóságon?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"Majd amikor kiderül, hogy az alkalmazott technika nem teszi lehetővé, hogy Pistike 1 óra alatt elő tudjon állítani egy A5-ös nyomtatványt, akkor jön a lecseszés. "

Hat meg is erdemled, ha nem egy olyan eszkozt hasznaltal, amivel !fejleszto felhasznalo is konnyeden osszedob egy uj reportot valami WYSIWYG feluleten...

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

Mondjuk igen abban van igazsag hogy ne az vezerelje a programozot hogy vegre kiprobalhatta az uj kodsort/featuret akarmit es ennek oltaran mondjuk felaldozta azt hogy hasznalhato legyen amit alkotott...

+1

Azt már meg sem merem említeni, hogy aki 2015-ben nyomós indok nélkül kezd el saját űrlapkezelő szoftvert írni, az sem normális. Vagy csak túl sok a felesleges pénze/ideje.

Ezt azert tulzasnak erzem, a CMS-ek limitacioi azert meg mindig visszatarto erok ebben.

Na igen, de ez azt jelenti, hogy a nulláról kell összehányni valamit? :)

Fura, én pont azt tapasztaltam, hogy kész libekkel sokszor el lehet jutni a kitűzött cél 90%-ig rövid idő alatt, aztán a 100% elérhetetlen, vagy akkora hekkelés, hogy a vége az, hogy 0-ról (nem szó szerint, de alacsonyabb szintű libekkel) előbb kész lett volna a 100%. Gondolom a topic nyitó is erre célzott, és akkor egyet értek vele, saját tapasztalatból. Irigylem azokat, akiknek a kész megoldások 100%-ig megfelelnek, vagy a megrendelő tudomásul veszi, ha csak 90%, és elég az (és akkor tényleg hamar megvan.)

Hasznos mondás a cégekre, hogy belül legyél minél szabványosabb és egyszerűbb, kifelé mutasd, hogy speciális vagy, mert ebből lesznek elégedett vevőid. Ha a belső működésed speciális és kifelé azt mutatod, hogy átlagos vagy, akkor az csak a hatékonyságon ront, ellenben remek statisztikák lesznek arról, hogy amúgy mennyire jó és különleges a cég.

nvm

> Gondolom a topic nyitó is erre célzott

Ehhez nem tudok érdemben hozzátenni, az OP-ben egy olyan problémáról volt szó, amit állítólag egy pályakezdő meg tud oldani két órában, létező eszközökkel. Ha ez tényleg így van, akkor felmerül a kérdés, hogy miért érdemes több időt rászánni?

Ehhez a threadhez lazán kapcsolódik egy másik ;) http://hup.hu/node/139928

"amit állítólag egy pályakezdő meg tud oldani két órában, létező eszközökkel" LÁTSZÓLAG jól, és egyáltalán nem biztos, hogy karbantarthatóan. Ezekkel a kitételekkel teljesen másról beszélünk. Ha kell valami hirtelen problémára gyors megoldás, és soha többet nem kell hozzányúlni, akkor nyilván a nettó ráfordított erőforrás minimalizálása az egyetlen szempont.

"Ehhez a threadhez lazán kapcsolódik egy másik ;) http://hup.hu/node/139928 "

Nekem is eszembe jutott, velhetoen egy "A" tipusu fejleszto a topik nyito. ;)

Mi az "A"?

Köszi :)

Itt nem egy reportról van szó, hanem egy komoly ügyviteli rendszer teljesen egyedi bizonylat nyomtatványairól. Például a gyári számokat, megjeleníteni intervallumokra bontva (1,2,3,4,6,7,8,11 -> 1..4, 6..8, 11). Ez nem egy user feladat, hanem mögöttes fejlesztői.

És ez nem egy egyedi projekt, hanem egy sok felhasználós rendszer. Ami legyen szép, gyorsan fejleszthető és ne legyenek korlátai :)

Nyugi en is megkapom a kulonbozo requesteknel hogy hat ez nem lehet gond hiszen olvastak a neten hogy azt ez meg az megcsinalta meg nezzem meg a masik projectet a cegnel ott is meg van csinalva... Az persze mar nem zavarja oket hogy a ket project koszono viszonyban sincs egymassal nem is ugyanaz az alapjuk ( hajtepes )

Ilyenkor szoktam mondani hogy hat persze zongorazni is mindenki tud csak a fekete es feher billentyuket meg a harom pedalt kell nyomkodni a megfelelo utemben...

A cél az, hogy a feladatot "megfelelően" tudd megoldani. Nem szabad se alultervezni (mert akkor copy-paste lesz, és nagyon hamar karbantarthatatlan kód) sem pedig túltervezni (mert akkor a 27 réteggel küzd az ember, ahelyett, hogy a feladatot oldaná meg). Ehhez kell egy jó adag szakmai tapasztalat, hogy ki tudd választani, hogy egy adott feladatnál mi az az absztrakciós szint, amire szükség van, ami megoldja a feladatot.

A fejlesztőnek az is feladata, hogy meg tudja indokolni, hogy miért azt a megoldást választotta, amit. Én pl. most refactoráltam egy DAO frameworköt, mert a projektünk elején úgy gondoltuk, hogy erre lesz szükség, és igazából nagyon hasznos volt, hogy adatbázis nélkül is össze tudtuk rakni a saját kódunkat, amíg a srácok még a PLSQL függvényeket hegesztették. Most, az első release után már lett annyi tapasztalatunk, hogy rájöttünk, hogy erre nagyjából semmi szükség, csak felesleges absztrakciós szint, úgyhogy refactoráltam az egészet, és kb. 50-60 osztállyal kevesebb van, az egész kód sokkal szebb, átláthatóbb, és sokkal könyebb debuggolni. Az akkori helyzetet és requirementeket ismerve ez egy jó döntés volt, a release-t meg lehetett csinálni, a dolgát megtette, viszont most már sokkal több projekt specifikus tapasztalatunk van, és szerencsére van idő arra, hogy szépen megcsináljuk a dolgokat, és a termékünk fejlődjön, még könyebben kiegészíthető legyen.

Ha a főnökség ilyen okosságokkal jön, akkor viszont elgondolkoznék a helyedben, hogy jó helyen vagyok-e.

Nem kell ezeket felvenni, nem ertenek hozza, a lenyeg hogy a vegeredmenyt kifizessek, te meg mindent meg tudj indokolni ket percben hogy mi miert volt annyi ido es mi miert mukodik ugy, ahogy. Ha mar ez a kommunikacio sem mukodik sokadik attemptre sem, akkor irany a masik munkaltato/megrendelo, kiveve ha valojaban ez meg tudja, hogy amugy o miert is akar fizetni, csak jatssza a hulyet. Vitakultura innentol, nem szabad tulsagosan felvenni ezeket. Foleg hogy nagyon konnyu uj megrendelot talalni (hosszutavon szinte egyik se lesz nromalis, de azert van egy hatar, amit sokan nem lepnek at).

Erre emlitettem egy masik topikban:

Ha nincs ssh a szerverre, es nincs egy verziokezelo a projekthez amihez nyulnom kell, el se vallalom a dolgot. Az azt jelenti, hogy ott mar legalabb egyszer kozgazdasz vezeto olcsojanoskodasa nyert a jozan esszel szemben. Nem kell ilyenekkel szoba se allni, kap az ember jobbaktol is feladatot.

http://c2.com/cgi/wiki?GoldPlating

--
NetBSD - Simplicity is prerequisite for reliability

Csak bólogatni tudok arra, hogy növeszteni kell azt a mérnöki hasat, amely segít megtippelni, hogy meddig lesz érdemes általánosítani a megoldást és hol már nem, vagy csak (mert azért van az emberben tartás) lehetővé tenni a későbbi általánosítás lehetőségét.

Ettől függetlenül, és ezt kiegészítve azt el kell fogadni - és ez minden munkakörben igaz -, hogy aki nem tudja, annak minden egyszerű, aki abszolúte nem tudja, annak abszolúte egyszerű (nősülj meg, és megtudod!). Ezért felesleges gyomorvérzéssel nyugovóra térni: ha megéri a sóhajtozást hallgatni, koncentrálj a zsére, és éld ki mással az egódat; ha nem éri meg, akkor úgyis tudod, mi a teendő.

"nem tudunk beletenni teljesen egyedi ügyfél igényeket"
Valahogy nem értem. A keretrendszer miért akadálya, hogy bármit is bele lehessen fejleszteni? Ha normálisan van használva a keretrendszer, az pont hogy lehetővé teszi az újabb modulok fejlesztését. Vagy nagyon félreértem ezt a részt?

Ha nem is a keretrendszer, de sokszor a program logikája jelenthet akadályt. Mondok egy példát: van egy CRUD alkalmazásunk, SMARTGWT kliens oldalon, postgresql a háttérben. Táblák, tárolt eljárások, view-k, stb.

Erre kitalálja a felhasználó, hogy ő olyat akar, hogy tudjon saját oszlopokat felvenni a táblákhoz. Az mondjuk nem zavarja, hogy ha kér egy változatást, akkor azt másnapra megkapja. Ez remek új requirement, mert ugye ez adatbázis módosítás, esetenként view módosítás, valamint kliens kód módosítást is jelent (a rest interface-en azért nem, mert most már transzparensen megy át az adat kliensbe). Hát, még nem sikerült kitalálni, hogy anélkül, hogy újraírnánk az egész alkalmazást, hogyan tudnánk megoldani a problémát.

Na várj, ha tényleg ez az igény, akkor ott már architekturálisan van valami eltolva.

Az, hogy mondjuk egy entitás az alkalmazáson belül új tulajdonságokat kaphasson futásidőben, nem megoldhatatlan, de ehhez nem kell minden lehetséges property-t adatbázisszinten mezőként felvenni. Ilyenkor vissza kell kérdezni, hogy pontosan mit akar elérni magas szinten, nem az implementációba kell rögtön belemenni.

+1


// Happy debugging, suckers
#define true (rand() > 10)

Az a helyzet, hogy vannak gridjeink, és ők akarnak plusz mezőket ezekhez a gridekhez, illetve ugyanezeket a mezőket szerkesztésnél a megfelelő portletben is szeretnék látni. Ez a requirement. Igazából nem tudom, mi van eltolva architektúrálisan, a kívánalom teljesen új, az architektúra (adatbázis tábla, CRUD felület) pontosan az eddigi igényeknek megfelelő, pont úgy van, ahogy mindenki más csinálja. (vagy legalábbis nagyon hasonlóan)

Az entitás az alkalmazáson belül új tulajdonságot kapjon akkor lenne megoldható, ha mondjuk memóriában tárolnánk adatokat (hogy ez most objektum, vagy map, az lényegtelen), nem pedig egy SQL adatbázis lenne az egész rendszer mögött, amiben az üzleti logika PLPGSQL-ben van lefejlesztve. Ráadásul kliens oldalon fixen be van kódolva, hogy milyen oszlopok vannak az egyes portleteken, ráadásul az egész kliens felület java-ból fordítódik javascript-be, nem pedig szerver oldalon generálódik (ugye modern webalkalmazás)

Na, ilyenkor legyen okos az ember.

Kiegészítés: és minden változtatást le KELL menteni az adatbázisba, mert más rendszerek is használják ezt az adatbázist.

Nem triviális és nem karbantartható ha egy 100 cég által használt rendszer egyik listájába szeretne új mezőket látni egy ügyfél. "Beletehető", de a generikusság oltárán sokat áldoznak fel vele. És a karbantartásáért elég sokat kellene kérni, amit általában nem fizetnek ki.

Lightweight es full-featured frameworkok is vannak.. utobbi eseteben nem biztos h olyan egyszer a fw lelkivilagatol tavol eso dolgot beepiteni. Persze attol meg megoldhato kell hogy legyen. :-)

El kell mondani háromszor, hogy mi az értelme a keretrendszernek, a szabványnak, a refactor-nak és az automatikus teszteknek. Ha nem értik meg, akkor ott kell hagyni őket, nem ér annyit az egész, hogy ezen pörögj.

Magadhoz és az elveidhez legyél lojális, ne a céghez alkalmazkodj.

Önmagában azzal nincs baj, hogy alapos tervezés nélkül, karbantarthatatlan formában összehány valaki valamit gyorsan 2 óra alatt abban az esetben, ha egy üzleti igényt gyorsan kell kiszolgálni és lényegében csak próbára kell, az sem baj ha nyúl csak röfögjön. Csak nem szabad elfelejteni azt, hogy ha beválik és hosszútávon támogatni/fejlesztgetni kell akkor egy refaktorálással vagy rosszabb esetben újraírással kell kezdeni... A magyar valóság az, hogy a vezetők látszólag igyekeznek elfelejteni hogy az eredetileg egy tákolt cucc volt, valójában meg ők felfelé előadták gyorsan abszolvált fényes sikerként ami KÉSZ van, több időt/pénzt már nem kell beletenni. Ezért amikor hozzányúlnál akkor a vezető a kezedre csap "dehát működik! ugyan minek foglalkoznál még vele?!? ott egy másik projekt csináld azt...". Nem derülhet ki, hogy azzal még lenne dolog... Közben elkezdik élesben használni egyre nagyobb terhelés alatt, majd N hónappal később előjön egy súlyos hiba, a rendszer akkor persze már 10 perc leállást sem tűr el és a gányolt katyvaszban majd azonnal kell a megoldás, sőt akár egyúttal egy új feature is, ami a spagettibe pont belefejleszthetetlen. A fejlesztők ilyenkor "nem boldogok", egy ilyen folyamat a legjobb kollégák körében akár felmondásokat is eredményezhet. Máshol meg szabadidőben/hétvégén csinálja meg a fejlesztő titokban ugyanezt, hogy amikor majd eljön a felvázolt pillanat ne akkor kelljen szopni vele vagy felmondani, addigra már kitekeri a spagettit valamennyire, csak hát ez így is szopás ugye. Magyarországon általában a kényszerek miatt a top-down tervezés a legnépszerűbb és ez pont akkor szívás leginkább ha valaki kreatívkodni akarna, nem fog menni. Ráadásul ha a top-down tervezés felső szinten még kompetenciahiánnyal is társul az meg hamarosan frissülő CV-t jelent, ilyenkor csak idő kérdése mikor jön az, hogy "tegyük mérhetővé" ki mit csinál... :) Egyébként a mérhetővé tétel sem feltétlenül rossz, attól függ mi a célja.

Hali!

Ez a mérhetővé tétel nálam eddig egyszer merült fel komolyan: megérkezett az akkori munkahelyemre a "tanácsadó ember". Rögtön az első pillanatokban kifejtette, hogy MINDENKI teljesítmény alapján lesz bérezve, mert olyan aztán nem létezik a világban, hogy valaki "csak úgy" kapjon fizetést. Mindezt fejtegette a bemutatkozó "előadása" alatt vagy 30 percig. Aztán elkövetkezett a: Van valakinek kérdése? Én voltam az egyetlen (nyilván a többiek még fel sem ocsúdtak a döbbenetből, hogy miféle zöldségeket hordott össze a 8 általános + autószerelő + x év szcientológia képzéssel bíró IQ fighter) aki megkérdezte: Mégis milyen alapon szeretné mérni a rendszergazda teljesítményét? Ugyanis az elmúlt évben munkaidőben volt egyszer 4 perc kiesés céges szinten egy reboot miatt... tehát akár úgy is tűnhet, mintha ott sem lennék... de ha az szükséges a magasabb fizetéshez, hogy folyton engem lásson a cég többi alkalmazottja, akkor naponta 3x fog lerohadni a rendszer és Én minden alkalommal előadom a megmentő szerepét és el fog indulni az ügyviteli rendszer. Nagyon halkan közölte, hogy üljek le, majd később megbeszéljük :-D aztán maradtam "fixbéres" :-D

Üdv:
Feri

hahaha, ez jó volt :)

Az üzemeltetés és a fejlesztés két külön dolog. Egyébként ha már üzemeltetés mérése: a rendelkezésre állási idő mérhető. Vidéki verzióban 99.999 esetén kapsz teljes bért, innen minden század százalék kiesés lefelé 300 forint levonás. :) Ha adott évben mondjuk csak 98%-ot sikerül összehozni, akkor havi 50 ezerrel csökken a béred a következő évre. Ha mondjuk összejön 99.8 akkor csak 5 ezerrel csökken havonta. :) A városi verzióban mondjuk 99.9 a nulla, felette plusz, alatta mínusz, de a kiesésbe beleszámít az is ha mondjuk spam listára kerül a céges IP, stb. A kihívás faktor meg az, hogy pénz nincs megfelelő eszközökre, abból kell várat építeni ami van... :)

Gondolom munkahelytől is függ, de az nem opció, hogy mielőtt belekezdesz egy olyan munkába, ami ennyivel több időt vesz igénybe, rákérdezel, hogy belefér-e hogy ezt kifaszázod vagy inkább nagyon gyorsan kell és akkor majd később kell időt szakítani a kifaszázásra?

--
HUP Firefox extension

"Delphi5-ben ezt egy pályakezdő 2 óra alatt megcsinálja egy DataModule-lal..."

Ebben a pillanatban nyújtod be a felmondást. Alkalmazzanak pályakezdőket nyugodtan.

A témához még hozzátartozik, hogy ez egy sokfelhasználós (több száz cég) generikus rendszere, amely 5 éves. Ennyi idő alatt többször kellett volna újraírni az architektúrális dolgok miatt, mondjuk webre. De 5 év is kevés volt, hogy minden belekerüljön, ami a tervek között szerepelt.

Szóval még van benne potenciál (években mérve), de nem biztos, hogy megfelel a mai kor követelményeinek, ha ilyen spéci egyedi igényekről van szó...

Na emiatt a dilemma....

Ha a feletted lévő azt mondja hogy Delphi5-kell nem pedig saját Cloudout építeni, a hajó süllyed. Nagyjából 2 nap alatt találsz másik munkát.

"Ma megint megkaptam a munkahelyemen, hogy mindig túllövöm a projekteket. Kíváncsi lennék, hogy csak én érzem-e azt, hogy ez nem bűn?"

Ez helyzet függő. Én is általában túllövőm, de általában be is jön... Mivel a megrendelő olyan állatfajta, hogy a következő fejlesztésben azt fogja kérni, amire korábban megesküdött, hogy sosem lesz rá szükség, így ez az egyedüli járható út.

Persze, mint mindent, ezt is túl lehet pörgetni, de néhány év tapasztalat után az ember már úgy tudja szervezni a dolgait, hogy ha nem is fejleszti ki a dolgokat, legalább ne vágja el a hozzá vezető lehetséges utakat.

A baj az, hogy ha bejön a előre gondolkodás, azt természetesnek veszik, ha meg nem úgy ment a dolog, akkor már utólag senki sem emlékszik, hogy anno a legfőbb követelmény a gyorsan/hamar hackelés volt.