WebHU - Programozási kérdések és válaszok

Gondolatok a szabadalmaztatott keretrendszer elhagyásáról egy nagyobb nyílt forráskódú projekthez

Mostanában sokat jártunk oda-vissza az irodánkban arról, hogy felhagyunk egy szabadalmaztatott keretrendszerrel, amelyet néhány éve fejlesztettek ki itt, és áttérünk valami nagyobb és közösségi támogatásra.

A jelenlegi megoldásunk úgy készült, hogy csak azokat a dolgokat tartalmazza, amelyekre szükségünk van, és nagyon rugalmas, a rugalmas alatt azt értem, hogy laza, és a fejlesztők, akik az évek során webhelyeket építettek vele, megengedik maguknak, így sok webhelyet kezelünk. és egyáltalán nem bármilyen színvonalon építettek. Itt az irodában valamennyire használom a keretrendszert, de inkább más eszközöket használok. Az évek során rengeteg PHP keretrendszert használtam, a Code Ignitertől a CakePHP-ig, és nagy rajongója voltam a Zend Frameworknek minden személyes projektemhez, ezért erősen elfogult vagyok, és ezért kérek itt tanácsot olyan emberektől, akik tudjon nekem tárgyilagosabb véleményt mondani. Az irodában rengeteget dolgoztak a keretrendszerünkön, így megértem, hogy egyesek miért haboznak feladni, de én ezt így látom:

  • Jelenleg nem töltünk sok időt azzal, hogy a keretrendszerünket naprakészen tartsuk, és újra és újra ellenőrizzük a hibákat, amint megtaláljuk, kijavítjuk őket. Amit tennünk kellene
  • A keretünk fejlesztése érdekében végzett minden munka közvetlenül a rezsioszlopunkba kerül
  • Van egy, a keretrendszerünkre épülő alkalmazásunk, amely előfizetéses és zárt forráskódú, és amelyet értékesítünk, és úgy gondolom, hogy jobb lenne, ha jobb szabványt alkalmaznánk egy népszerű, közösségvezérelt keretrendszer használatával, amely megköveteli vagy ösztönzi ezeket a dolgokat.

Kerestem és találtam ezt a témaszálat: Miért kell használnom egy népszerű keretrendszer?, ez hasonló volt ahhoz, amit kérdezek, de nem egészen. Arról kérek véleményt, hogy miért tenne egyiket vagy másikat, nem igazán akarok arról beszélni, hogy melyik keret jobb, ez lesz a következő lépés számunkra, ha a váltás mellett döntünk.

Íme néhány ok, amiért úgy látom, hogy a támogatott, nyílt forráskódú keretrendszerre való váltás hosszú távon segít nekünk:

  • Ahogy a PHP új verziókat ad ki, a keretrendszer magja frissül, hogy kihasználhassa ezeket a dolgokat anélkül, hogy nekünk kellene elvégeznünk a munkát.
  • A könyvtárakkal kapcsolatos biztonsági aggályokat a közösség megkeresi, és a kódbázisunk aktuális verzióra való frissítésén kívül a mi közreműködésünk nélkül is kijavítja.
  • Rengeteg információ az interneten és a meglévő kód, amely referenciaként használható
  • Lehetőség arra, hogy külső programozókat alkalmazzanak, akik már ismerik a keretrendszert, ahelyett, hogy embereket vennének fel, és azt várnák el tőlük, hogy meg kell tanulniuk használni a saját fejlesztésünket.
  • Képes visszaadni a közösségnek javítások, bővítmények, segédprogramok és támogatás révén.

Íme a negatívumok, amiket találtam:

  • Az egyéni alkalmazásunkban található összes kódot át kell majd portolnunk az új rendszerre
  • Alkalmazottainknak bizonyos időt kell hagynunk, hogy megtanuljanak egy új keretrendszert és annak csínját-bínját
  • A jelenlegi keretrendszerünk nagyon rugalmas és laza, ami lehetővé teszi számunkra, hogy úgy építsük fel a dolgokat, ahogy csak akarjuk, és ez megakadályozza, hogy fejlesztőink kövessék és engedelmeskedjenek a konvencióknak, amelyeket egyes fejlesztők úgy tűnik, utálnak. Én személy szerint szeretem a konvenciókat

Valószínűleg ismét nyilvánvaló, hogy elfogult vagyok, és ez az oka annak, hogy itt kérdezek, nyitott vagyok arra, hogy bárki mit mondjon.

02.12.2009

  • A „gondolatok” szóval kezdődő címnek közösségi wikinek kell lennie... 03.12.2009
  • Nem tettem, mert úgy éreztem, hogy erre a kérdésre élesen meg lehet válaszolni. Véleményeket kértem, de ezek valóban választ adnak a kérdésre számomra és mások számára. 03.12.2009

Válaszok:


1

Az én cégem is hasonló helyzetben van. Van egy egyedi fejlesztésű Perl-keretrendszerünk, amely úgy tűnik, soha nem fordít annyi figyelmet az új funkciók fejlesztésére és a hibák kijavítására, mint a nyílt forráskódú keretrendszerekre. Én és a legtöbb más fejlesztő szívesen váltanánk valami nyílt forráskódot az Ön által említett előnyökért, de senkinek nincs annyi költségvetése, hogy a kódhordozással töltse az időt. Jelenlegi tervünk az, hogy nyílt forráskódú keretrendszert használunk, ha kis, új projektek merülnek fel, és ha ez sikeres, fontolja meg a régebbi alkalmazások áthelyezését.

Leginkább Perl-lel és Ruby-val dolgoztam, de manapság egyre inkább azt tapasztalom, hogy a keretrendszerek lehetővé teszik a keretrendszer alapvető összetevőinek keverését és párosítását. Például fontolgatjuk egyéni keretrendszerünk egyes részeinek integrálását a Catalyst szolgáltatásba. Így továbbra is használhatjuk néhány egyedi fejlesztésű kódösszetevőnket (saját DBI osztályunkat és néhány Mason sablonunkat), és alkalmazásaink portolása nem lesz olyan nehéz. A Ruby on Rails szintén költözik abban az irányban, hogy modulárisabb legyen.

Talán van egy PHP-keretrendszer, amely lehetővé teheti a kód egy részének használatát, vagy legalábbis megkönnyíti, hogy a kód egy részét beépítsd a keretrendszerbe, ahelyett, hogy a nulláról kezdenéd. Googlálva azt látom, hogy a PHP keretrendszerek többsége modulárisnak vallja magát, de néhányan úgy tűnik, hogy csak kiegészítők fejlesztését teszik lehetővé, nem pedig az alapvető összetevők kicserélését.

Úgy tűnik, jó elemzéseket végez, és sok sikert kívánok a kereséshez.

03.12.2009
  • Egyre inkább úgy érzem, hogy sok egyéni kódunkkal ezt kell használnunk, és szerencsére a modelljeink jó része jó és szilárd felépítésű, így meg kell tudnunk tenni azt, amit említettél, és talán használhatjuk a Zend Framework-et. stb..., és csak a legnagyobb részeinket helyezzük át rá, majd a semmiből építsük újra a kisebb részeket. Egy ilyen kompromisszum megkötése jó ötlet lehet, nem tudom, miért nem jutott eszembe, hogy így egy kicsit könnyebben megússzuk. 03.12.2009

  • 2

    A kérdésed valóban ördögien elfogult, mert minden profi hosszú távú, minden kontra rövid távú fejlődési fájdalom. :) De ha csak feleannyi a helyzet, mint amit leírsz, akkor a váltás a helyes, és hosszú távon sok pénzt megspórolsz.

    03.12.2009
  • Egyetértek, borzasztóan elfogult. Legtöbbször, ahogy mondod, már kitaláltam a fejemben, hogy meg kell váltanunk a kódot, és ez a helyes dolog, de szerettem volna olyan válaszokat kapni, amilyeneket mondasz, megnyugtatásul és arra az esetre, ha igen. csak az egyszerű dolgokat elfelejtve. Remek visszajelzéseket kaptam már ezzel kapcsolatban, és azt hiszem, mások is a helyünkben vannak, akik szintén sokat kapnak ettől a kérdéstől. 03.12.2009

  • 3

    Szerintem a legfontosabb pontokat, amelyeket itt kiemeltél. A döntésnek most számokon kell alapulnia. Technikailag az elemzése tökéletes. Amit most kérdeznék: Mennyibe kerülne az Ön cégének, hogy:

    * Tartsa meg az alkalmazást, hogy kihasználhassa az új php fejlesztéseket anélkül, hogy megtörné a régi kódot (ez azt jelenti: architektúra elemzés, fejlesztés és tesztelés, teszt, teszt).

    * Van olyan fejlesztője/elemzője, aki a biztonságfejlesztéssel foglalkozik? (ez azt jelenti: biztonságfejlesztési életciklus, teszt, teszt, teszt).

    * Van fejlesztési módszertana? Általában ezeket a keretrendszereket egy jó elosztott fejlesztési módszertan szerint tartják.

    Ugyanaz a kérdésem volt valamikor, mint ön, és a cégem úgy döntött, hogy keretrendszert választ, áttelepíti a kódunkat, és heti 1 napon 2 fejlesztőt oszt ki, hogy dolgozzanak a keretrendszeren. Jó volt, hogy csapatunkat a keretrendszer fejlesztőcsapatával együtt dolgoztattuk, mert többet megtudtunk a keretrendszerről, segítettük a közösséget (demagógia :-)) és néhány üzleti követelményt is beilleszthettünk a keretrendszer jellemzőinek ütemtervébe ;-)

    02.12.2009
  • Ami a portolást illeti, egyetértek azzal, hogy ugyanannyi időt tölthetünk a kódunk karbantartásával, hogy visszaadjuk másoknak. Ez olyan dolog lenne, amit igazán kielégítőnek találnék, és azt hiszem, a csapatunk is. Mind a segítségnyújtás, mind a híresség miatt! :) Nehéz felismerni, ha soha senki nem látja a kódot! 03.12.2009
  • A kérdés, amire csak Ön fog tudni válaszolni: mennyi időbe telik a kódbázis átírása. Még egy fontos dolog a keretekkel kapcsolatban. Találhatsz olyan szakembereket, akik ezt már tudják. Hatalmas előny egy házilag készített – dokumentálatlan – kerettel összehasonlítva. 03.12.2009

  • 4

    Én és a csapatom a végéhez közeledünk egy meglévő alkalmazás áthordásához, hogy a Zend Framework rendszeren futhasson, és az egész jól sikerült.

    A régi alkalmazásban sok olyan probléma volt, amelyeket nagy problémákkal kellett megoldani, ezért úgy döntöttünk, hogy belevágunk, és újjáépítettük a ZF-ben.

    A portolás azonban sok időt vett igénybe, becslésem szerint a mi alkalmazásunknál jó 4-5 hónapba telt a fejlesztő, hogy mindent átvigyünk (megragadtuk az alkalmat az adatbázis és a rendszer egyéb területeinek újraindítására).

    Ha mégis rászánja magát, akkor készüljön fel arra, hogy elmagyarázza főnökeinek, hogy miért kell sok időt töltenie a portolással, ahelyett, hogy jövedelemtermelő munkával dolgozna. Szerencsések voltunk, hogy egy új projektet használhattunk lendületként ennek a munkának az elvégzéséhez.

    03.12.2009
  • Köszönöm a választ, úgy gondolja, hogy a ZF újraépítése a problémák megoldásán túl megérte a ráfordított időt? Azt hiszem, több hónapos fejlesztést is várunk a konvertálás érdekében. Megvan az a luxus, hogy megtesszük, miközben továbbra is támogatjuk a másik kódbázist. 03.12.2009
  • Nekünk azt mondanám, hogy megérte, az alkalmazásunk nyikorgott a saját súlya alatt, és rendkívül törékennyé vált. Az alapoktól való újjáépítés minden szinten csavarozott egységteszttel sokkal szebbé teszi a későbbi fejlesztést. Az eredeti alkalmazást is php 4.0-ban készítettük egyedi adatbázis burkolókkal és sok beágyazott sql-lel, ami elég gagyi. 04.12.2009

  • 5

    Látok pár hátrányt az átállásnak.

    Először természetesen ott van:

    Az egyéni alkalmazásunkban található összes kódot át kell majd portolnunk az új rendszerre

    Ezt követi:

    Az egyéni alkalmazásunkban található összes kódot át kell majd portolnunk az új rendszerre

    és végül de nem utolsó sorban:

    Az egyéni alkalmazásunkban található összes kódot át kell majd portolnunk az új rendszerre

    Ön a "pénz a rezsioszlopban" beszélt, és a működő tesztelt kód átírása új működő tesztelt kódra nem ad sok értéket.

    Ha egy új keretrendszer bevezetéséről beszél egy vadonatúj, nem kapcsolódó projekthez, vagy egy olyanhoz, amely keveset használ a meglévő kódbázisból, akkor természetesen üsse ki magát. Ez remek lehetőség a keretrendszerek, platformok, nyelvek stb. váltására.

    De egy meglévő, szállított, kiforrott kódbázis, amelyen meglévő hozzáértő emberek dolgoznak?

    Ezt személy szerint nehéz lenyelni.

    Ha azt szeretné, hogy az emberek kövessék a szabványokat és a konvenciókat, akkor... kövessenek szabványokat és konvenciókat. Mivel egy olyan rendszerrel rendelkezik, amely lehetővé teszi az emberek számára, hogy „szabadságot kapjanak, amit akarnak”, tegyen valamit a „szabványok és konvenciók követése” érdekében, amit akarnak.

    Mindig jobb fokozatosan átállítani egy rendszert, amely az egész babát, a fürdővizet, a szappant, a mosdót és a törölközőket kidobja az ablakon, csak hogy visszamenjen, és újra megismételje ugyanazt a dolgot.

    Mindenki át akarja írni a kódot, én meg akarom csinálni. A keretünknek itt "át kell tennie". De akkor megyünk "igen, de..." és mit kapunk a végén? N hónapos erőfeszítés, hogy visszatérjünk oda, ahol most vagyunk. Ez nem sokat ér egy olyan világban, ahol a piacra jutás ideje számít.

    03.12.2009
  • Nagyjából én is így érzem magam, sok mindent újra akarok csinálni, de aztán elkezdek gondolkodni a szükséges időn. Az a rossz abban, hogy akarom a korlátozást, hogy tudom, hogy ez sokszor mennyit akadályoz, mint például a Railsben. Azt hiszem, megpróbálhatunk érvényt szerezni a konvencióknak a kódunkban, de úgy érzem, hogy az ezt érvényre juttató keretrendszer nélkül is előfordulhat, hogy az emberek elkerülik a dolgokat, utálják, ha valakire ingerültek kell lenniük ilyesmi miatt, pedig ez nagy dolog nekem. Köszönöm a választ, és egyetértek azzal, hogy az erőfeszítés nem biztos, hogy megéri a befektetést 03.12.2009
  • Új anyagok

    A rádiógomb ellenőrzött eseményének használata a jQueryben
    Ebben a cikkben látni fogjuk, hogyan kell dolgozni a jquery választógombbal ellenőrzött eseményeivel. A választógombok HTML gombok, amelyek segítenek kiválasztani egyetlen értéket egy csoportból...

    Körkörös függőségek megoldása terraformban adatforrásokkal – lépésről lépésre
    Mi az a körkörös függőségek Dolgozzunk egy egyszerű eseten, amikor az SQS-sor és az S3-vödör közötti körkörös függőség problémája van egy egymástól függő címkeérték miatt. provider..

    Miért érdemes elkezdeni a kódolást 2023-ban?
    01100011 01101111 01100100 01100101 — beep boop beep boop Világunk folyamatosan fejlődik a technológia körül, és naponta fejlesztenek új technológiákat a valós problémák megoldására. Amint..

    🎙 Random Noise #2  – Örökbefogadás és hit
    az analitika íratlan világának gondozása Szeretné, hogy ezek a frissítések a postaládájába kerüljenek? Iratkozzon fel itt . "Ha önvezető autókat gyártanak, akkor mi miért ne..

    A legrosszabb politika és prediktív modellek májátültetésre jelöltek számára az Egyesült Államokban
    A máj (vagy óangolul lifer) az emberi test legnehezebb belső szervére utal, amely csendesen működik a nap 24 órájában. Mit csinál a máj? 500 feladatot hajt végre a szervezet egészségének..

    5 webhely, amely 2022-ben fejleszti front-end fejlesztői készségeit
    Frontendmentor.io A tényleges projektek létrehozásával a Frontendmentor.io segítséget nyújt a front-end kódolási képességeinek fejlesztésében. A kódolást azután kezdheti meg, hogy..

    Mikor kell használni a Type-t az interfészhez képest a TypeScriptben?
    A TypeScript a JavaScript gépelt szuperkészlete, amely statikus gépelést ad a nyelvhez. Ez megkönnyíti a robusztus és karbantartható kód írását azáltal, hogy a hibákat a fordítási időben..