Mekkora a súlya egy új keretrendszerre átállásnak?
Minap Felhővel munkába menet találkozásom során nekem szegezte az és ti, Python–Django? kérdést, mire a válaszom az volt, hogy nem, azt csak önszorgalomból, a cégnél PHP alapú keretrendszert használunk – historikus okokból.
Derek Sivers két éve adta a fejét arra, hogy a PHP alapú CD Baby webszájtját teljesen újraírja a Rails szellemében, őt is megcsapta a RoR szele, most pedig épp olvasom az O'Reilly Ruby blogjában, hogy úgy döntött, visszalép. Két év fejlesztés után, az átállás felénél feltette magának a kérdést, hogy mi az, amit Ruby-val igen, PHP-vel viszont nem tud megcsinálni? A válasz nemleges tartalmát erősítette, hogy az eltelt idő közben a szájt funkcióját tekintve is új ötletekre szorul, számos figyelemre méltó elgondolás jelent meg hasonló témában, a versenytársak erősödtek.
Ha tavaly ilyenkor írnám ezeket a sorokat – mint a felvezetőben említett – minden bizonnyal Django alapokon gondolnék fejleszteni, karbantartani egy munkaeszközként használt keretrendszert, mai fejjel pedig inkább hajlanék egy főként LISP-es kódbázis felé.
Derek hét érvet emelt ki, miért tért vissza a PHP-hez. Noha egy új keretrendszer kihívásokkal, számos kényelmi funkcióval kecsegtethet, sokszor felesleges emiatt felrúgni egy jól átgondolt, kitapasztalt frameworköt. Az idő előrehaladtával, ismereteink mélyülésével, egyre klasszabb keretrendszerek, nyelvek felbukkanásával természetes velejárója, hogy ugyanazokra a problémákra már más megoldásokat adnánk, esetleg ugyanazok a problémák magasabb szintű fejlesztési módszertanunk miatt már nem is jelentkeznek. Mégis, nem árt fontolóra vennünk; érdemes-e energiát fektetni egy bevált szerszám leváltásába, ahelyett, hogy üzletünk tényleges profiljával foglalkoznánk, és új, kifinomultabb szolgáltatásokat nyújtanánk ügyfeleinknek.
■ Derek Sivers két éve adta a fejét arra, hogy a PHP alapú CD Baby webszájtját teljesen újraírja a Rails szellemében, őt is megcsapta a RoR szele, most pedig épp olvasom az O'Reilly Ruby blogjában, hogy úgy döntött, visszalép. Két év fejlesztés után, az átállás felénél feltette magának a kérdést, hogy mi az, amit Ruby-val igen, PHP-vel viszont nem tud megcsinálni? A válasz nemleges tartalmát erősítette, hogy az eltelt idő közben a szájt funkcióját tekintve is új ötletekre szorul, számos figyelemre méltó elgondolás jelent meg hasonló témában, a versenytársak erősödtek.
Ha tavaly ilyenkor írnám ezeket a sorokat – mint a felvezetőben említett – minden bizonnyal Django alapokon gondolnék fejleszteni, karbantartani egy munkaeszközként használt keretrendszert, mai fejjel pedig inkább hajlanék egy főként LISP-es kódbázis felé.
Programming languages are like girlfriends: the new one is better because *you* are better
Derek hét érvet emelt ki, miért tért vissza a PHP-hez. Noha egy új keretrendszer kihívásokkal, számos kényelmi funkcióval kecsegtethet, sokszor felesleges emiatt felrúgni egy jól átgondolt, kitapasztalt frameworköt. Az idő előrehaladtával, ismereteink mélyülésével, egyre klasszabb keretrendszerek, nyelvek felbukkanásával természetes velejárója, hogy ugyanazokra a problémákra már más megoldásokat adnánk, esetleg ugyanazok a problémák magasabb szintű fejlesztési módszertanunk miatt már nem is jelentkeznek. Mégis, nem árt fontolóra vennünk; érdemes-e energiát fektetni egy bevált szerszám leváltásába, ahelyett, hogy üzletünk tényleges profiljával foglalkoznánk, és új, kifinomultabb szolgáltatásokat nyújtanánk ügyfeleinknek.
tanulni
90.000-100.000!!!! kódsor volt a program amit 1-2 hónap alatt újraírt. Lett ~10.000. Ha nem tervezte meg csak elkezdte gépelni a vi-ben, akkor ha minden munkanap napi 4 órában (fél munkaidő) dolgozott rajta akkor percenként ~1 sor programkódot írt. Ha ebbe belevesszük, hogy az írás a legkevesebb idő (kb. a kódolás+tesztelés 1%-a) akkor képet kapunk arról, hogy nem is igazán kellett neki gondolkoznia azon mit írjon. Nem jut egy perc egy sor program tesztelésére, amit egyes egyedül írt meg. Ez olyan rutimunka jellegű dolog volt, a 2 év kemény tanulás után, plusz a tévutak kizárásának segítségével.
Kábé ugyanezeket írta le ő is amiket én, de a biztonság kedvéért én is leírtam ide, hogy elmondhassam a véleményemet.
Nem gondolta át a végeredményben felderített nehézségeket, ehhez 2 év-re volt szüksége. Nagy hiba szerintem. Majd levonta a konzekvenciákat, miután megtanult egy csomó technikát, tippet, trükköt és fogást, talán feleslegesen. Ezek után jogos a kérdés, hogy jó konzekvenciákat vont -e le. Miért írta meg a cikket? Hogy a többiek okuljanak belőle? Én azt éreztem a cikk végén, hogy elhibázott volt minden, csak az új tudásának örül. Valóban ez az igazság? Tényleg nem szabadott volna nekifognia? Másnak sem szabad? Szerintem ez mind-mind gazdasági/gazdaságossági kérdéseket feszeget. Érdekes téma, és érdemes lenne utánaolvasni a szakirodalomban. Ráadásul, mint a kommentelők közül sokan észrevételezték, fogalma sem volt az MVC paradigma mibenlétéről, az objektum orientált gondolkodásmódot sem tudhatta magáénak, nem tanult soha project tervezésről és ütemezésről, sőt nem is akar hallani erről soha életében (ezt vettem ki én). Ezek után lehet újra felvetni a költségeket és hasznosságot feszegető kérdéseket.
Szerintem amit fontos lett volna átgondolnia:
+ alapvetőleg mennyivel lesz nagyobb a látogatottság
- mennyi idő lesz a teljes átállást végrehajtania
- mennyi idő lesz a tudását kiterjesztenie
+ ennek hol veszi még a projecten kívül hasznát
- mennyibe kerül a munkabére -> mennyi munkát tudna végrehajtani, ha nem ezt csinálja
//+ = "bevétel" ; - = "költség" ; a pluszokból kell több :)
Ezek után már egész más jellegű a probléma. Vajon megéri -e olyan dolgokat csinálni, amit nem gondolunk át előre, mert kevés az ismeretünk hozzá. Hogyan kell felismerni, hogy valamilyen ismeretnek a hiányában vagyunk? Erről kéne írnia valakinek akinek nagy tapasztalata van(:
nem tudom erről van-e szó
Nem technikai kérdés
Nyilván egyértelmű válasz nem adható, az adott vállalat versenyképességét fenntartandó kell vállalható döntést hozni atekintetben, hogy az adott újdonság elsajátítása hordoz-e lehetőséget a vállalat számára további értéknövelt szolgáltatások kialakítására, vagy egyszerűen könnyíti-e a fejlesztők munkáját, amely közvetve szintén hatékonyságot eredményezhet sít.
A citált posztot (esettanulmány?) ellenpéldaként szerettem volna felhozni, hogy csak azért mert valami új, divatos, másoknak testreszabott eszköz, a saját életünket nem biztos, hogy könnyíti.