Eigen framework vs bestaande frameworks in het bedrijfsleven

[Verwijderd]

Hoi Tweakers!

Ik werk bij een bedrijf waar we uitgebreide applicaties onderhouden met een eigen PHP framework.

In de loop van de tijd hebben we het discussie punt, of we niet een bestaand framework kunnen gebruiken. (Laravel, Zend, Symphony).

de vragen die we dan hebben:

1. Moeten we dan alles weer opnieuw schijven.
2. Wat zijn de voor- en nadelen van beide keuzes?
3. Hoe kunnen we dit het beste aanpakken, aangezien elke dag wel wat wordt toegevoegd/gewijzigd.

Alvast bedankt!

[Ultimation]

Binnen ons bedrijf hebben we hetzelfde. We hebben een eigen PHP framework die onderhand wel aan vernieuwing toe is. Hiertoe heb ik een opzet gemaakt die nog verder uitgewerkt moet worden.

Binnen ons bedrijf zijn bestaande frameworks totaal niet aan de orde. We willen niet afhankelijk zijn van externe bedrijven op een applicatie die onze core-bussiness voed. De ideeën achter Laravel, Zend en Symphony zijn goed. Maar omdat ze een dusdanig grote markt moeten bedienen ook te abstract of zit er teveel dingen in die je niet of nooit gebruikt.

Zo kan je daadwerkelijk alles met Zend doen, zelfs (html) formulieren aanmaken met PHP. Ik vraag mij altijd af waarom je dat zou doen. HTML voor HTML, PHP voor PHP en Javascript voor Javascript.

Ik vind het mooi om te zien dat bedrijven zelf hun software maken en daar zelf over nadenken, ook al zijn er zoveel bestaande producten in de markt. Men zegt altijd dat je het wiel niet opnieuw moet uitvinden, maar menig auto fabrikant doet dat. Daarnaast waar is de innovatie dan? Je kan zeggen dat innovatie komt wanneer je actief mee gaat werken en denken in de community van dit soort frameworks. Maar dan kan je ook net zo goed die tijd en moeite in je eigen framework stoppen.

[ Voor 11% gewijzigd door Ultimation op 03-03-2015 11:28 ]

[Spinal]

Ultimation schreef op dinsdag 03 maart 2015 @ 11:26:
Zo kan je daadwerkelijk alles met Zend doen, zelfs (html) formulieren aanmaken met PHP. Ik vraag mij altijd af waarom je dat zou doen.

Eenvoudige automatische validatie, bijvoorbeeld. Je hoeft dan niet zelf elk veld te controleren of dat wel correct is ingevuld, maar laat Zend dat doen.
Keerzijde is wel dat je redelijk vast zit aan de opmaak die Zend gebruikt voor de formulieren, als je een keer wat anders wilt moet je dáár weer extra moeite voor doen.

Dit geldt iig voor ZF1, ik weet niet hoe met ZF2 en ZF3 zit

[InZane]

Verwijderd schreef op dinsdag 03 maart 2015 @ 11:16:
de vragen die we dan hebben:

1. Moeten we dan alles weer opnieuw schijven.
2. Wat zijn de voor- en nadelen van beide keuzes?
3. Hoe kunnen we dit het beste aanpakken, aangezien elke dag wel wat wordt toegevoegd/gewijzigd.

Dat is leuk en aardig, maar je gaat mij niet vertellen dat jullie geen enkel antwoord weten op bovenstaande vragen.
Verder: Wat verwacht je van een ander framework? Wat zijn de eisen en wat is wenselijk?

[ Voor 3% gewijzigd door InZane op 03-03-2015 12:03 ]

[BtM909]

Verwijderd schreef op dinsdag 03 maart 2015 @ 11:16:
Hoi Tweakers!

Ik werk bij een bedrijf waar we uitgebreide applicaties onderhouden met een eigen PHP framework.

In de loop van de tijd hebben we het discussie punt, of we niet een bestaand framework kunnen gebruiken. (Laravel, Zend, Symphony).

de vragen die we dan hebben:

1. Moeten we dan alles weer opnieuw schijven.
2. Wat zijn de voor- en nadelen van beide keuzes?
3. Hoe kunnen we dit het beste aanpakken, aangezien elke dag wel wat wordt toegevoegd/gewijzigd.

Alvast bedankt!

Wat is het doel van dit topic? Ben je stagiair die dit moet uitzoeken of zijn jullie bedrijfsbreed hierover aan het nadenken?

Want in alle gevallen zijn we toch echt benieuwd hoe jij hierover denkt. Wat jij al hebt uitgezocht. Welke voorlopige conclusies jij hebt getrokken. Waar jij specifiek tegenaan loopt.

Als je drie antwoorden op je drie vragen verwacht, dan ga ik je heel snel verrassen

[PatrickH89]

Ultimation schreef op dinsdag 03 maart 2015 @ 11:26:
Binnen ons bedrijf hebben we hetzelfde. We hebben een eigen PHP framework die onderhand wel aan vernieuwing toe is. Hiertoe heb ik een opzet gemaakt die nog verder uitgewerkt moet worden.

Binnen ons bedrijf zijn bestaande frameworks totaal niet aan de orde. We willen niet afhankelijk zijn van externe bedrijven op een applicatie die onze core-bussiness voed. De ideeën achter Laravel, Zend en Symphony zijn goed. Maar omdat ze een dusdanig grote markt moeten bedienen ook te abstract of zit er teveel dingen in die je niet of nooit gebruikt.

Zo kan je daadwerkelijk alles met Zend doen, zelfs (html) formulieren aanmaken met PHP. Ik vraag mij altijd af waarom je dat zou doen. HTML voor HTML, PHP voor PHP en Javascript voor Javascript.

Ik vind het mooi om te zien dat bedrijven zelf hun software maken en daar zelf over nadenken, ook al zijn er zoveel bestaande producten in de markt. Men zegt altijd dat je het wiel niet opnieuw moet uitvinden, maar menig auto fabrikant doet dat. Daarnaast waar is de innovatie dan? Je kan zeggen dat innovatie komt wanneer je actief mee gaat werken en denken in de community van dit soort frameworks. Maar dan kan je ook net zo goed die tijd en moeite in je eigen framework stoppen.

Je moet niet zelf bouwen om zelf te bouwen, zie Not Invented Here Syndrome. In het verhaal wat je nu schetst zie ik nergens een reden om een framework zelf te bouwen (hooguit subjectief). Als je geen HTML wilt opbouwen met het framework dan doe je dat lekker niet, de enige bloat die je dan hebt is een paar regels code die de applicatie nergens vertragen omdat ze toch nooit worden aangeroepen.

De valkuil waar je met dit idee ongetwijfeld in gaat vallen (of al gevallen bent) is dat je iets maakt wat niet kan concurreren met de andere frameworks omdat je er nooit dezelfde hoeveelheid tijd in kunt steken als een grote community (en voor bedrijven die dit wil kunnen is dat het meestal niet waard). Erg slecht idee om zelf iets te bouwen alleen om het zelf in beheer te hebben (wat je met die andere frameworks in feite toch ook gewoon hebt?).

[Kettrick]

Verwijderd schreef op dinsdag 03 maart 2015 @ 11:16:
Hoi Tweakers!

• Moeten we dan alles weer opnieuw schijven.

Nee, omdat je bestaande code gebruikt kan je je focussen op code die waarde heeft voor je bedrijf. Als ik iemand interview die vandaag de dag nog een eigen CMS of SQL library kan hij bij wijze van spreke zijn spullen pakken. Bekend zijn met, en het gebruiken van, bibliotheken hoort bij het vak tegenwoordig.

• Wat zijn de voor- en nadelen van beide keuzes?

Het grote nadeel van complete pakketen is dat je er aan vast zit, zelf software ontwikkelen op basis van bestaande componenten heeft weinig nadelen, als een bibliotheek niet doet wat je wil voeg je het toe.

• Hoe kunnen we dit het beste aanpakken, aangezien elke dag wel wat wordt toegevoegd/gewijzigd.

Dit zal je toch echt zelf moeten onderzoeken, heb je een applicatie die redelijk gelaagd is kan je je eigen db/web/whatever laag vervangen door een standaard oplossing. Heb je een grote brei random php scripts... sterkte

[Rmg]

Ultimation schreef op dinsdag 03 maart 2015 @ 11:26:
Binnen ons bedrijf hebben we hetzelfde. We hebben een eigen PHP framework die onderhand wel aan vernieuwing toe is. Hiertoe heb ik een opzet gemaakt die nog verder uitgewerkt moet worden.

Voordeel van een bestaand framework is dat je minder tijd in het onderhouden/up-to-date houden van je framework hoeft te steken en je dus meer kan focussen op de toepassing dan het framework.

Ik vind het mooi om te zien dat bedrijven zelf hun software maken en daar zelf over nadenken, ook al zijn er zoveel bestaande producten in de markt. Men zegt altijd dat je het wiel niet opnieuw moet uitvinden, maar menig auto fabrikant doet dat.

Ja en de innovatie van menig autofabrikant is dan ook een nieuw chassis op een oud frame of een net iets zuinigere versie van een bestaande motor.

Daarnaast waar is de innovatie dan? Je kan zeggen dat innovatie komt wanneer je actief mee gaat werken en denken in de community van dit soort frameworks. Maar dan kan je ook net zo goed die tijd en moeite in je eigen framework stoppen.

Sowieso is innovatie iets wat je m.i. in je toepassing moet zoeken en niet in je framework.

[Kettrick]

Rmg schreef op dinsdag 03 maart 2015 @ 12:31:
Sowieso is innovatie iets wat je m.i. in je toepassing moet zoeken en niet in je framework.

Dat idd, hoewel het actief mee ontwikkelen van frameworks ontzettend goede PR voor je bedrijf kan zijn. Het releases van je eigen framework waar vervolgens niemand op zit te wachten en dus geen community heeft is minder goede PR .

[Barryvdh]

Verwijderd schreef op dinsdag 03 maart 2015 @ 11:16:

1. Moeten we dan alles weer opnieuw schijven.
2. Wat zijn de voor- en nadelen van beide keuzes?
3. Hoe kunnen we dit het beste aanpakken, aangezien elke dag wel wat wordt toegevoegd/gewijzigd.

Je moet een framework pakken dat flexibel genoeg is. En Zend/Symfony/Laravel zijn echt wel flexibel genoeg om mee vooruit te kunnen, tenzij je als bedrijf hele raar dingen doet.

Sowieso kan je in een goed framework zelf bepalen welke dingen je wel/niet gebruikt of vervangt door andere componenten. Vind je Laravel's ORM niet fijn? Pak je gewoon Doctrine. Blade irritant? Gebruik Twig. Etc etc.

Je zal natuurlijk wel wat zaken opnieuw moeten schrijven, maar dat is je laag op het framework. Bijvoorbeeld een eigen CMS systeem of modules. Maar dat was eerst ook.
Je hoeft natuurlijk niet al je applicaties over te zetten naar het nieuwe systeem direct, als het nu goed draait.
Het ligt ook aan hoe je je huidige framework gebruikt. Een standaard framework biedt meestal wat mogelijkheden voor je routing/controlles, views/templates, database abstractie, events etc.
Je 'echte' logica zit waarschijnlijk redelijk gescheiden van je framework zelf, dus hoef je niet opnieuw te schrijven.

Voordeel is dat je niet alles zelf hoeft te schrijven. Veel wordt door de community gedaan en bespaart je dus werk. Nadeel is dat je dan wel afhankelijk bent van de community voor bugfixes ed. Maar het is allemaal Open Source dus je kan gewoon zelf pull requests maken of desnoods forken en zelf gaan bijhouden.

[Ultimation]

PatrickH89 schreef op dinsdag 03 maart 2015 @ 12:10:
[...]


Je moet niet zelf bouwen om zelf te bouwen, zie Not Invented Here Syndrome. In het verhaal wat je nu schetst zie ik nergens een reden om een framework zelf te bouwen (hooguit subjectief). Als je geen HTML wilt opbouwen met het framework dan doe je dat lekker niet, de enige bloat die je dan hebt is een paar regels code die de applicatie nergens vertragen omdat ze toch nooit worden aangeroepen.

De valkuil waar je met dit idee ongetwijfeld in gaat vallen (of al gevallen bent) is dat je iets maakt wat niet kan concurreren met de andere frameworks omdat je er nooit dezelfde hoeveelheid tijd in kunt steken als een grote community (en voor bedrijven die dit wil kunnen is dat het meestal niet waard). Erg slecht idee om zelf iets te bouwen alleen om het zelf in beheer te hebben (wat je met die andere frameworks in feite toch ook gewoon hebt?).

Beetje jammer dat iedereen hetzelfde reageert. Je bent alleen slim, goed of geef het een ander naampje bezig wanneer je bestaande oplossingen implementeert.

[Kettrick]

Ultimation schreef op dinsdag 03 maart 2015 @ 12:45:
[...]


Beetje jammer dat iedereen hetzelfde reageert. Je bent alleen slim, goed of geef het een ander naampje bezig wanneer je bestaande oplossingen implementeert.

Het punt is meer dat het vaak niet slim is om je eigen frameworks te bouwen, omdat dat vaak niet je business case is. Neem bijvoorbeeld een webshop, voor de gemiddelde winkel is het bouwen van een eigen shop een ontzettend slecht idee, er zijn er al zo veel.

Heb je echter een geweldig idee waarmee je alle webwinkels van de troon gaat stoten vanwege een straat enorm hippe features moet je dat vooral doen, maar dat zijn twee totaal verschillende scenario's.

En zelfs in het laatste scenario zou je gebruik maken van bestaande projecten om bepaalde zaken in je project op te lossen.

TL;DR; het is gewoon niet echt slim/goed om iets te bouwen wat al 10x gedaan is, omdat het domweg arrogant is te denken dat je het beter kan.

[Barryvdh]

Ultimation schreef op dinsdag 03 maart 2015 @ 12:45:
[...]


Beetje jammer dat iedereen hetzelfde reageert. Je bent alleen slim, goed of geef het een ander naampje bezig wanneer je bestaande oplossingen implementeert.

De mensen die beter zelf een framework kunnen schrijven, hoeven niet hier te vragen wat beter is

Ik zou op zijn minst eerst de standaard oplossingen proberen en pas zelf gaan doen als je er van overtuigd bent dat het veel beter kan (en dat niet aangepast kan worden in de huidige library)

Maar ik ken wel wat bedrijven met eigen frameworks, vraag me ook altijd af waarom dat beter zou zijn. Het kan natuurlijk prima, maar vraag me af of je dan niet op een gegeven vast blijft zitten omdat 'het werkt'.

Sprak laatst iemand van een bedrijf met custom framework, maar die kende dus ook Composer helemaal niet. Die gebruikten gewoon allemaal hun eigen libraries. Kan, maar lijkt me niet heel efficiënt..

[Ultimation]

Kettrick schreef op dinsdag 03 maart 2015 @ 12:53:
[...]

TL;DR; het is gewoon niet echt slim/goed om iets te bouwen wat al 10x gedaan is, omdat het domweg arrogant is te denken dat je het beter kan.

Hoe ontstaat innovatie volgens jou? Waarom is het arrogant om te denken dat je het beter kan? Ik vind jou mening tamelijk arrogant. Het enige wat goed lijkt in jou ogen is het aan elkaar knopen van bestaande oplossingen.

Dat iets bestaat wil niet zeggen dat het verkeerd is om iets zelf te doen.

Als iedereen zoals jou zou denken dan had Laravel, noch Symphony of Zend niet bestaan.

[ Voor 40% gewijzigd door Ultimation op 03-03-2015 13:21 ]

[PatrickH89]

Ultimation schreef op dinsdag 03 maart 2015 @ 13:13:
[...]


Hoe ontstaat innovatie volgens jou? Waarom is het arrogant om te denken dat je het beter kan? Ik vind jou mening tamelijk arrogant. Het enige wat goed lijkt in jou ogen is het aan elkaar knopen van bestaande oplossingen.

Dat iets bestaat wil niet zeggen dat het verkeerd is om iets zelf te doen.

Ik waarschuw voor het 'not invented here' syndroom. Dat houdt niet in dat je nooit iets zelf van de grond af moet bouwen, maar dat je alleen iets van de grond af moet bouwen als een bestaand product niet aan je wensen kan voldoen.

Het is eerder arrogant om te denken dat je het beter kunt dan een bestaand framework met minder resources (en waarschijnlijk je hele doel niet is om een framework te bouwen en te onderhouden).

Ik zeg dan ook niet dat je nooit moet innoveren, als je wilt innoveren op framework gebied dan betekent dat dat je een goed plan hebt en dat de huidige frameworks dus ook echt niet voldoen. Veruit de meeste mensen willen dit helemaal niet, die willen innoveren op applicatieniveau.

Nogmaals, het is niet verkeerd om iets zelf te doen, maar zorg dat je straks niet met een minder product zit waar je niet meer vanaf kunt puur omdat je zo arrogant bent geweest om het zelf te bouwen. Met legitieme redenen is het een prima idee om een eigen framework te bouwen.

[Rmg]

Ultimation schreef op dinsdag 03 maart 2015 @ 13:13:
[...]


Hoe ontstaat innovatie volgens jou? Waarom is het arrogant om te denken dat je het beter kan? Ik vind jou mening tamelijk arrogant. Het enige wat goed lijkt in jou ogen is het aan elkaar knopen van bestaande oplossingen.

Een framework gebruik om te zorgen dat je repeterende taken zoals het aanmaken van een nieuw component of invoer checken niet elke keer opnieuw hoeft te doen. Waarom denk je dat jullie innovatie zit in jullie framework en niet in jullie business logic?

[Standeman]

Soms kunnen goede redenen zijn om een framework niet te kiezen. Maar als het voldoet, voldoet het en ben je gek om te gaan investeren in een eigen framework (en zelfs dan kan je vaak beter een fork maken van bestaand framework en aanpassen zodat het wel aan de eisen voldoet).

Anders kan je ook net zo goed je eigen hardware, OS en programmeertaal gaan ontwikkelen.

[Kettrick]

Ultimation schreef op dinsdag 03 maart 2015 @ 13:13:
Hoe ontstaat innovatie volgens jou? Waarom is het arrogant om te denken dat je het beter kan? Ik vind jou mening tamelijk arrogant. Het enige wat goed lijkt in jou ogen is het aan elkaar knopen van bestaande oplossingen.

Dat iets bestaat wil niet zeggen dat het verkeerd is om iets zelf te doen.

Als iedereen zoals jou zou denken dan had Laravel, noch Symphony of Zend niet bestaan.

Zoals ik in mijn post aangaf, als je echt een goed plan hebt om een nieuw framework te bouwen wat daadwerkelijk meerwaarde biedt moet je dat zeker doen, er is altijd ruimte voor innovatie. Mijn punt is dat er maar weinig situaties zijn waar het creëren van waarde voor je baas hand in hand gaat met het ontwikkelen van een goed framework.

[downtime]

Ultimation schreef op dinsdag 03 maart 2015 @ 11:26:
Binnen ons bedrijf zijn bestaande frameworks totaal niet aan de orde. We willen niet afhankelijk zijn van externe bedrijven op een applicatie die onze core-bussiness voed.

Schrijven jullie ook je eigen programmeertalen? Je eigen webserver? Eigen OS? etc.

In mijn optiek gebruik je een bestaand framework zodat je je op je core business kunt richten. En dat is meestal het bouwen van applicaties en niet het bouwen van frameworks (of programmeertalen, etc). Kijk, als je je core business echt versterken kunt met een nieuw framework dat unieke en innovatieve features heeft, dan moet je dat vooral doen. Maar als je uit de voeten kunt met iets wat een ander al gemaakt heeft, dan moet je zelf dat wiel niet opnieuw uitvinden. Zelfs de grote jongens doen dat meestal niet.

Iemand noemde het voorbeeld van autofabrikanten: Zoek eens uit hoeveel "unieke" automodellen er nog zijn. Heel veel types van verschillende fabrikanten zijn tegenwoordig gebaseerd op een standaard onderstel wat door meerdere fabrikanten gebruikt wordt.
Dat fenomeen zie je in veel bedrijfstakken. Bedrijven focussen zich op activiteiten waarmee ze zich van de concurrentie kunnen onderscheiden en dat wat niet onderscheidend is kopen ze in, want de leverancier voor wie dat onderdeel wel core business is, kan het beter en goedkoper.

[Verwijderd]

Bedankt voor de snelle reacties.

Al zijn de mening erover verdeeld, lijkt mij een bestaand framework in ons geval een goede oplossing.

Alleen blijft mijn laatste vraag nog staan:

Hoe kunnen we dit het beste aanpakken, aangezien elke dag wel wat wordt toegevoegd/gewijzigd.

Het probleem waar ik tegen aanloop is dat we te maken hebben met een rijdende trein.
Stukje voor Stukje wordt lastig aangezien je te maken hebt met (voorraad,bestellingen,crons, enz.enz.)

Hoe kan je dit het beste onderzoeken, en hoe kan je bepalen hoeveel tijd dit gaat kosten?

[Kettrick]

Verwijderd schreef op dinsdag 03 maart 2015 @ 14:08:
Het probleem waar ik tegen aanloop is dat we te maken hebben met een rijdende trein.
Stukje voor Stukje wordt lastig aangezien je te maken hebt met (voorraad,bestellingen,crons, enz.enz.)

Als al je applicatie logica in één groot project zit zou het opsplitsen een goede eerste stap kunnen zijn. Een klein specifiek stuk uit het project halen en in een nieuwe vorm neerzetten, en op die manier beetje bij beetje je applicatie herbouwen. Maar zonder inzicht in de code kan je daar eigenlijk weinig nuttigs over zeggen.

En hoe kan je bepalen hoeveel tijd dit gaat kosten?

Laat het ons even weten als je daar achter bent . Dit soort projecten zijn ontzettend moeilijk in te schatten, zonder inzicht in de code kan niemand daar iets over zeggen.

[BtM909]

Verwijderd schreef op dinsdag 03 maart 2015 @ 14:08:

Hoe kan je dit het beste onderzoeken, en hoe kan je bepalen hoeveel tijd dit gaat kosten?

Dude, lees mijn reactie nog even goed door. Als je nog 1 keer een vraag stelt zonder enige vorm van zelfinzet, dan gaat dit topic gewoon op slot.

[Verwijderd]

BtM909 schreef op dinsdag 03 maart 2015 @ 11:58:
Wat is het doel van dit topic? Ben je stagiair die dit moet uitzoeken of zijn jullie bedrijfsbreed hierover aan het nadenken?

Aangezien ik dit onderwerp zelf op tafel gegooid heb, mag ik er ook zelf nadenken hoe we dit gaan doen en waarom we dit zouden doen.

Want in alle gevallen zijn we toch echt benieuwd hoe jij hierover denkt. Wat jij al hebt uitgezocht. Welke voorlopige conclusies jij hebt getrokken.

Waarom ik in ons geval voor een framework zou kiezen, is met name omdat we dan met een schone lei kunnen beginnen. en het belangrijkste dat alles gedocumenteerd is, zodat iedereen zelfstandig alles kan uitzoeken.

[mbr]Dude, lees mijn reactie nog even goed door. Als je nog 1 keer een vraag stelt zonder enige vorm van zelfinzet, dan gaat dit topic gewoon op slot.[/]

Ik het onderwerp misschien verkeerd formuleert, ik had namelijk ook niet verwacht dat zo snel zou gaan
Verder is het Framework verhaal wel duidelijk.

Als je nog 1 keer een vraag stelt zonder enige vorm van zelfinzet
Voor mij is het ook de eerste keer dat een applicatie omgezet moeten worden naar iets nieuws.
En als je dan de vragen krijgt hoe je dit wil gaan aanpakken, stond ik ook met een mond vol tanden.

Het liefst zouden we alles willen herschrijven.
Maar de manuren, kosten en risico;s wat dat met zich meebrengt is niet echt haalbaar. aangezien we genoeg andere dingen hebben te doen.

Wat ik weten hoe kan je een beslissing maken om een nieuwe start te maken.

en zoals Kettrick al formuleerde heb ik dan veel sterkte nodig

Dit zal je toch echt zelf moeten onderzoeken, heb je een applicatie die redelijk gelaagd is kan je je eigen db/web/whatever laag vervangen door een standaard oplossing. Heb je een grote brei random php scripts... sterkte

[Kettrick]

Verwijderd schreef op dinsdag 03 maart 2015 @ 15:41:
Waarom ik in ons geval voor een framework zou kiezen, is met name omdat we dan met een schone lei kunnen beginnen. en het belangrijkste dat alles gedocumenteerd is, zodat iedereen zelfstandig alles kan uitzoeken.

Dit komt met een nog veel groter voordeel dat nog niet echt genoemd is, recruitment. Het is eenvoudig om nieuwe mensen te vinden die Laravel ( of zend, whatever ) begrijpen. Het is zonde om mensen eerst een maand lang aan te laten kloten in je eigen framework.

Het liefst zouden we alles willen herschrijven.

Dit is overigens vaak niet de juiste aanpak, omdat je vaak ontzettend veel kleine business rules vergeet over te zetten en moet achterhalen wat mensen vandaag de dag nog gebruiken en verwachten van je applicatie.

Voorzichtig herbouwen van specifieke lagen, en eventueel afsplitsen in eigen testbase units, is vaak de beste manier van werken. Alles hangt af van de kwaliteit van de code, er zijn nogal wat php applicaties geschreven die sub-optimaal gelaagd zijn

[DirkZzZ]

Kettrick schreef op dinsdag 03 maart 2015 @ 15:53:
[...]
Dit komt met een nog veel groter voordeel dat nog niet echt genoemd is, recruitment. Het is eenvoudig om nieuwe mensen te vinden die Laravel ( of zend, whatever ) begrijpen. Het is zonde om mensen eerst een maand lang aan te laten kloten in je eigen framework.

Dit is overigens vaak niet de juiste aanpak, omdat je vaak ontzettend veel kleine business rules vergeet over te zetten en moet achterhalen wat mensen vandaag de dag nog gebruiken en verwachten van je applicatie.

Voorzichtig herbouwen van specifieke lagen, en eventueel afsplitsen in eigen testbase units, is vaak de beste manier van werken. Alles hangt af van de kwaliteit van de code, er zijn nogal wat php applicaties geschreven die sub-optimaal gelaagd zijn

Vraag me af wanneer het wel de juiste aanpak is, recentelijk erdoor gekregen dat wij wél alles vanaf de grond af aan opnieuw gaan bouwen. Maar het is inderdaad een beetje tricky mede door de door jou genoemde punten wat betreft kleine business rules en randeffecten van de applicatie.

Maar om de ts een klein beetje een idee te geven waardoor wij tot deze conclusie zijn gekomen en waar hij zijn situatie misschien aan kan spiegelen;
Het gaat om een PHP applicatie.

Veel van de code dateert van nog van 2001 en is destijds ook gemaakt met de normen van die tijd, op een relatief slordige manier. Deze code bevat natuurlijk geen enkele documentatie, en de manier waarop de code in elkaar is gezet zorgt ook veel problemen en het is erg fout gevoelig.

Alles loopt via 1 index.php bestand welke gebaseerd op een $_GET parameter een bestand required welke vervolgens ingeladen wordt. In deze bestanden worden vaak ook nog meerdere andere bestanden gerequired. Vaak wordt er afhankelijk van bepaalde extra $_GET parameters die wel of niet gezet zijn met een bepaalde waarde nog meer bestanden ingeladen.

Deze get waardes worden vaak nog aangeroepen met superglobals, ik kom nog regelmatig tegen dat in een los bestand vanuit het niets een $id variabele wordt gebruikt waarmee wordt bedoeld $_GET['id'].

Verder worden functionaliteiten die vaker worden gebruikt soms wel in een losse functies bestand gezet, deze wordt echter niet overal door de code heen consequent gebruikt en het komt voor dat er voor 1 doel soms meerdere functies bestaan of dat er on the fly in het desbetreffende bestand nog nieuwe code is geschreven.

Deze code is voor de rest standaard spaghetti code waarbij queries,html en logica kris kras door elkaar staan. En deze queries gebruiken natuurlijk nog het oude vertrouwde mysql_ welke binnenkort geschrapt wordt.

Door de jaren heen zijn de bedrijfswensen natuurlijk veranderd, en hiervoor is altijd een nieuw stukje code bij naast geplakt waarbij dan naar een aantal condities werd gekeken om te bepalen wat van toepassing was. Deze condities kunnen echter, heel zwaar conflicteren met elkaar waardoor er regelmatig onverwachte resultaten uitkomen.

Ook staat sommige code verspreidt over meerdere servers.

En als finale is helaas mijn collega vertrokken welke dit proces heeft meegemaakt en vaak sneller dan ik wist waar een bepaalde bug aan kon liggen.

Ik zal het hier maar bij laten, anders wordt dit wel een heel lang verhaal.

Dit in combinatie met de wensen die op dit moment open staan en welke in een nieuw systeem direct meegenomen kunnen worden heeft ons doen besluiten dat het sneller en veiliger is om het systeem opnieuw op te zetten. Dit gaan wij doen in Laravel.

Als de chaos niet zo gigantisch was zou ik zelf persoonlijk ook liever kiezen voor een aanpak waarbij bedrijfsprocessen worden afgekaderd door testen en deze te refactoren in een nieuw systeem.

En met opnieuw maken bedoelen we dan ook dat we per onderdeel met de eindgebruiker(s) in gesprek gaan en de wensen overnieuw gaan vastleggen.

[Douweegbertje]

Om maar even een heel simpel antwoord te geven op je eerste 3 vragen:
Huur iemand in die wel verstand van zaken heeft om je de antwoorden te geven. Klinkt misschien nogal lullig, maar als het zo'n enorme 'core' vraag is die beantwoord moet worden, laat het dan ook doen door iemand die veel verstand van heeft. In feite wil je hier antwoord hebben op een haast bedrijfskritisch vraagstuk, en IMO slaat dat nergens op.

Goed, qua informatie. Probeer niet het wiel opnieuw uit te vinden. Er zijn weinig legitieme redenen te bedenken om zelf aan de bak te gaan, terwijl vrijwel alles al wel bestaat. Uiteindelijk boeit het soms ook niet wat jij denkt, of wat goed is maar wordt het een simpel kosten/baten verhaaltje. "Ja ik kan het net iets beter maken, maar dat kost dan xx-uur" VS "het is er al, maar is het net niet". Tja leuk, maar dan wordt het 9 van de 10x dus een bestaande oplossing.

Wij hebben zelf een geheel eigen code-base. O.a. vanwege het feit dat toen wij begonnen, er domweg geen enkel framework was en dat er altijd hard is doorgewerkt. Ja, we zitten nu eigenlijk in een situatie dat ik het liefst alles naar dev/null wil tieven, een framework uit de kast wil pakken en het opnieuw wil opzetten. Feit is: dat gaat niet.
Simpele reden: Mocht ik uberhaupt de tijd krijgen, meer mensen, meer geld om op een side-project ALLES opnieuw te maken, dan ben ik zo lang bezig dat als het klaar is, dat het weer oud is.
Dat komt omdat er 10-duizenden bestanden zijn, miljoenen lijnen aan code, duizenden functionaliteiten en vervolgens staat niets stil en blijft er aan gewerkt worden.
De enige manier is om het gefaseerd netjes over te zetten naar een enige vorm van 'huidige techniek' waarbij je zowel oude meuk ondersteund en al het nieuwe daadwerkelijk goed en 'nieuw' neerzet.

Over de jaren heen is de gehele code-base wel vernieuwd, in vergelijking met wat het was 4 jaar geleden. En zo is het volgend jaar weer iets nieuwer maar je loopt vrijwel altijd achter wat feiten aan.
Stel, je hebt ooit gekozen om voor CodeIgniter als framework te gaan, dan ben je nu de lul omdat het project zo goed als dood is. Wie garandeert dat Symfony er over 6 jaar nog is, of op zijn minst backwards compatible? Niemand.

Wij, en dat is dan specifiek ons, en niemand anders... hebben dus gekozen om het op onze manier doen. Niet omdat wij slimmer zijn, of het wiel opnieuw willen uitvinden, maar omdat het vrijwel de enige manier is om het voor elkaar te krijgen. En ja, geef mij 1 miljoen aan investeringen en ik kan het in een framework maken maar dat gaat hem niet worden.

Dus wat ik ongeveer nog wilde aangeven met dit verhaal: Niemand hier kan je een antwoord geven omdat het je eigen meuk is. Zet anders je source maar op github, inclusief al het FTE wat je hebt, en wat financiële planningen dan kan ik je direct een antwoord geven wat je precies moet doen. Overigens krijg je dan wel een factuur van me, en vraag ik nog even aan je waarom je geen manager IT hebt.

Voor mij is het ook de eerste keer dat een applicatie omgezet moeten worden naar iets nieuws.
En als je dan de vragen krijgt hoe je dit wil gaan aanpakken, stond ik ook met een mond vol tanden.

Het liefst zouden we alles willen herschrijven.
Maar de manuren, kosten en risico;s wat dat met zich meebrengt is niet echt haalbaar. aangezien we genoeg andere dingen hebben te doen.

Wat ik weten hoe kan je een beslissing maken om een nieuwe start te maken.

Ben jij manager? Nee? Ok, dan hoef JIJ dat niet te beantwoorden c.q. te beslissen. Het enige wat jij hoeft te doen is een plan te maken.
Wil je het herschrijven? Prima, dan kost dat xxxx-uur. Wil je ook nog continuïteit in je huidige product? Prima, dan moet er nog xx-FTE bij, en kost het nog eens xxx-uur extra. Dan zoek je de consequenties uit, wat voor product krijg je dan en wat levert dat dan op? Als je het niet kan verkopen dat je xxxx-uur er aan gaat werken om vervolgens maar x-uur per maand profijt er van te hebben dan lukt het dus nooit.

Je kunt ook gewoon als antwoord geven: sorry, ik weet het niet. Want laten we eerlijk zijn; je weet het niet. Prima om hier informatie te vergaren voor een vraagstuk, of als je hier een stelling wilt neer zetten. Iedereen is wel bereid om informatie te delen, maar jouw vragen zijn nog zo globaal dat dat weinig zin heeft.

[PatrickH89]

Douweegbertje schreef op dinsdag 03 maart 2015 @ 19:44:

Over de jaren heen is de gehele code-base wel vernieuwd, in vergelijking met wat het was 4 jaar geleden. En zo is het volgend jaar weer iets nieuwer maar je loopt vrijwel altijd achter wat feiten aan.
Stel, je hebt ooit gekozen om voor CodeIgniter als framework te gaan, dan ben je nu de lul omdat het project zo goed als dood is. Wie garandeert dat Symfony er over 6 jaar nog is, of op zijn minst backwards compatible? Niemand.

Dit is nogal een dooddoener. Wie garandeert dat PHP nog bestaat over 6 jaar of nog toereikend is.

Om hier wat zinvols over te zeggen. Streef er naar om je code Framework agnostic te maken. Dependency injection (met interfaces!) is een goede manier om dit zoveel mogelijk te bereiken. Uiteraard kun je niet 100% framework agnostic code schrijven, want dat zou betekenen dat het geen framework features meer gebruikt, maar hou je code redelijk portable.

Verder zou het zo kunnen zijndat TS niet eenzelfde (kritische) codebase hebt als jijzelf en is het een prima idee om dit lerenderwijs om te bouwen (alleen is dit topic waarschijnlijk niet echt de beste manier).

[Douweegbertje]

PatrickH89 schreef op dinsdag 03 maart 2015 @ 19:55:
[...]


Dit is nogal een dooddoener. Wie garandeert dat PHP nog bestaat over 6 jaar of nog toereikend is.

Om hier wat zinvols over te zeggen. Streef er naar om je code Framework agnostic te maken. Dependency injection (met interfaces!) is een goede manier om dit zoveel mogelijk te bereiken. Uiteraard kun je niet 100% framework agnostic code schrijven, want dat zou betekenen dat het geen framework features meer gebruikt, maar hou je code redelijk portable.

Verder zou het zo kunnen zijndat TS niet eenzelfde (kritische) codebase hebt als jijzelf en is het een prima idee om dit lerenderwijs om te bouwen (alleen is dit topic waarschijnlijk niet echt de beste manier).

Je interpreteert het alleen verkeerd. Het is juist het argument dat je eigen codebase niet compatible genoeg is en misschien wel achterloopt. Dit terwijl het juist ook nog eens andersom kan zijn. Ik las hier ergens over 'afhankelijk van 3e' en dat was een kul argument echter is het een zeer valide argument afhankelijk wat je codebase is.

[Verwijderd]

Douweegbertje schreef op dinsdag 03 maart 2015 @ 19:44:
Ben jij manager? Nee? Ok, dan hoef JIJ dat niet te beantwoorden c.q. te beslissen. Het enige wat jij hoeft te doen is een plan te maken.
Wil je het herschrijven? Prima, dan kost dat xxxx-uur. Wil je ook nog continuïteit in je huidige product? Prima, dan moet er nog xx-FTE bij, en kost het nog eens xxx-uur extra. Dan zoek je de consequenties uit, wat voor product krijg je dan en wat levert dat dan op? Als je het niet kan verkopen dat je xxxx-uur er aan gaat werken om vervolgens maar x-uur per maand profijt er van te hebben dan lukt het dus nooit.

Je kunt ook gewoon als antwoord geven: sorry, ik weet het niet. Want laten we eerlijk zijn; je weet het niet. Prima om hier informatie te vergaren voor een vraagstuk, of als je hier een stelling wilt neer zetten. Iedereen is wel bereid om informatie te delen, maar jouw vragen zijn nog zo globaal dat dat weinig zin heeft.

Dit is eigelijks wel het antwoord wat ik nodig had ;-)
Ik weet inderdaad niet hoe we dit op moeten lossen, al is het soms wel frustrerend.

Simpele reden: Mocht ik uberhaupt de tijd krijgen, meer mensen, meer geld om op een side-project ALLES opnieuw te maken, dan ben ik zo lang bezig dat als het klaar is, dat het weer oud is.
Dat komt omdat er 10-duizenden bestanden zijn, miljoenen lijnen aan code, duizenden functionaliteiten en vervolgens staat niets stil en blijft er aan gewerkt worden.

Met name de duizende functionaliteiten, die continue worden bijgewerkt.

Al ben ik wel van mening dat je een keer moet beginnen, want het wordt met de jaren steeds lastiger.

[ Voor 14% gewijzigd door Verwijderd op 03-03-2015 20:13 ]

[Barryvdh]

Verwijderd schreef op dinsdag 03 maart 2015 @ 20:03:

Met name de duizende functionaliteiten, die continue worden bijgewerkt.

Al ben ik wel van mening dat je een keer moet beginnen, want het wordt met de jaren steeds lastiger.

Je zou ook kunnen proberen bepaalde dingen te vervangen doorlopend.

Maar heb je het nu over 1 groot project wat je opnieuw wil opbouwen, of een framework dat je gebruikt als basis voor je lopende projecten, waar veel extra functionaliteit in zit?

Want als het voor nieuwe projecten is, kan je natuurlijk gewoon daar een keer in beginnen en de oude projecten in het huidige framework laten.

Als het 1 groot project is, kan je proberen bepaalde onderdelen stap voor stap te vervangen voor open source libraries en er dan meteen voor te zorgen dat het 'decoupled' is van de rest van het framework.

Heb je bijvoorbeeld een database abstractie laag die je makkelijk kan uitwisselen? Je zou kunnen kijken of je de implementatie daarvan kan vervangen door bijv. Doctrine of Eloquent, terwijl je jouw abstractielaag daarboven op houdt, zodat je niet alle code hoeft te vervangen.

[Verwijderd]

Dan kom ik toch weer terug op de punten die Douweegbertje aangeeft.

Het is het veel belangrijker om te kijken hoe we dit mogelijk kunnen maken.
En misschien is het inderdaad verstandiger om hier iemand naar te laten kijken die hier ervaring mee heeft.

al komt dat weer uit op een nieuw discussie punt en wil hier ook het topic mee sluiten.

Bedankt voor alle tips en ervaringen

[ Voor 30% gewijzigd door Verwijderd op 03-03-2015 20:46 ]

[Cartman!]

Eigen framework bouwen, totaal kansloos wat mij betreft.

Toen ik bijna 10 jaar geleden begon bij m'n werkgever was er ook een eigen framework maar toen was er ook weinig. Dat gaf elke keer problemen met nieuwe features ontwikkelen want daar was geen tijd voor, dan was er weer een bug die veel tijd kostte en dan kwam er weer een hack voor een specifieke situatie. Tot daar Zend Framework kwam en we dat zijn gaan gebruiken, mensen aannemen was makkelijker want ze hoefden alleen het smaakje van onze projecten te kennen en klaar was je. Nu gebruiken de meesten projecten sinds een ruim jaar Silex (wat werkt op Symfony componenten) wat heerlijk snel ontwikkelt. De volgende stap is iedereen overzetten naar Symfony. Waarom? Grote community, een ander denkt alles voor je uit, een ander schrijft weer plugins/bundles/providers en nog weer anderen maken er tutorials/pull requests en issues voor aan.

Net als Doctrine, briljant! Dat ga je echt niet zomaar evenaren, laat staan overtreffen. Zulke dingen moet je gewoon niet opnieuw willen maken.

Not Invented Here blijft een enorme slechte eigenschap van veel PHP developers, echt zonde. Dankzij de komst van Composer kun je zo snel packages van anderen laden zonder gedoe met autoloaders.

[RobIII]

Lees Invented here syndrome eens voor een nuance m.b.t. Not invented here syndrome. Het is helemaal niet (zo) zwart-wit als sommigen hier willen doen geloven. Ja, soms ben je gewoon kostbare ontwikkeltijd en geld aan 't verstoken met 't opnieuw uitvinden van 't wiel. En soms, ja, moet 't wiel gewoon opnieuw uitgevonden worden. Soms is 't zo simpel als dat het "über-framework dat heel de wereld gebruikt" gewoon niet gebruikt kan worden in jouw project omdat 't qua licenties botst en soms is hetgeen je zoekt er nog helemaal niet of voldoet 't niet aan je eisen. En soms zijn de bestaande frameworks bagger en soms juist een gift sent from heaven en alles daartussenin. Gebruik gewoon je common sense en bekijk of 't de investering (qua tijd, geld, resources etc.) waard is of dat je beter een bestaand iets kunt gebruiken (of beter: aan bijdragen als 't OSS is) en maak de afweging (in je achterhoofd houdend dat bestaande zaken vaak al breder getest zijn, langer bestaan en dus de nodige kinderziektes (mogelijk) ontberen etc. etc. En daarmee is 't dus niet meer zwart-wit maar 50 tinten grijs Basta.

[ Voor 45% gewijzigd door RobIII op 03-03-2015 21:06 ]

[Cartman!]

Voor specialistisch spul kan het zeker het geval zijn maar voor 99% van de gevallen gaan bestaande frameworks, zeker bij PHP waar het om gaat in dit topic, gewoon voldoende zijn. Legacy is een groot probleem en bij een product/groot project kan dat heel vervelend zijn.

[Verwijderd]

Cartman! schreef op dinsdag 03 maart 2015 @ 20:51:
Eigen framework bouwen, totaal kansloos wat mij betreft.

Toen ik bijna 10 jaar geleden begon bij m'n werkgever was er ook een eigen framework maar toen was er ook weinig. Dat gaf elke keer problemen met nieuwe features ontwikkelen want daar was geen tijd voor, dan was er weer een bug die veel tijd kostte en dan kwam er weer een hack voor een specifieke situatie. Tot daar Zend Framework kwam en we dat zijn gaan gebruiken, mensen aannemen was makkelijker want ze hoefden alleen het smaakje van onze projecten te kennen en klaar was je. Nu gebruiken de meesten projecten sinds een ruim jaar Silex (wat werkt op Symfony componenten) wat heerlijk snel ontwikkelt. De volgende stap is iedereen overzetten naar Symfony. Waarom? Grote community, een ander denkt alles voor je uit, een ander schrijft weer plugins/bundles/providers en nog weer anderen maken er tutorials/pull requests en issues voor aan.

Net als Doctrine, briljant! Dat ga je echt niet zomaar evenaren, laat staan overtreffen. Zulke dingen moet je gewoon niet opnieuw willen maken.

Not Invented Here blijft een enorme slechte eigenschap van veel PHP developers, echt zonde. Dankzij de komst van Composer kun je zo snel packages van anderen laden zonder gedoe met autoloaders.

Ik droom ervan om in de zelfde situatie als jou te komen

Alleen is dit makkelijker gezegd dan gedaan, ik blijf te maken hebben met de werkelijkheid

En deze is gewoon lastig te veranderen, ik zal dus ook onder de programmeurs een dicussie opgooien hoe we dit zouden kunnen veranderen. En wat framework bedreft is me dat wel duidelijk, dat willen we hopelijk allemaal

[Cartman!]

Uiteindelijk is er iemand die moet opstaan en met een plan komt met "dit is wat we gaan doen" of "ik stel dit voor, wie heeft er een beter idee". Zoek een collega met wie je goed overweg kunt en ga samen op onderzoek uit of start simpelweg je volgende project met dat framework. Als niemand iets doet blijf je vaak voortborduren op oude meuk waar iedereen zich aan gaat irriteren.

Ik hoop dat bij ons de overstap van Silex naar Symfony zorgt voor het niet meer hoeven onderhouden van enkele van onze eigen composer packages.

[PrisonerOfPain]

Cartman! schreef op dinsdag 03 maart 2015 @ 20:51:
Grote community, een ander denkt alles voor je uit, een ander schrijft weer plugins/bundles/providers en nog weer anderen maken er tutorials/pull requests en issues voor aan.

Wat ik eigenlijk mis aan je betoog zijn dingen als zelf als bedrijf een commitment maken om terug te contributen aan dergelijke project. Op die manier garandeer je de continuiteit van het project, school je tegelijkertijd je werknemers en heb je een veel grotere invloed op de richting van het project. Door actief deel te nemen aan dergelijke open-source projecten kun je naast leunen op 100en andere developers ook nog eens (een deel van) de controle behouden die je zou hebben met een in-house ontwikkeld platform.

[Cartman!]

PrisonerOfPain schreef op woensdag 04 maart 2015 @ 12:05:
[...]


Wat ik eigenlijk mis aan je betoog zijn dingen als zelf als bedrijf een commitment maken om terug te contributen aan dergelijke project. Op die manier garandeer je de continuiteit van het project, school je tegelijkertijd je werknemers en heb je een veel grotere invloed op de richting van het project. Door actief deel te nemen aan dergelijke open-source projecten kun je naast leunen op 100en andere developers ook nog eens (een deel van) de controle behouden die je zou hebben met een in-house ontwikkeld platform.

Dat is een ideale situatie ja waar ik enorm voor ben ja

Persoonlijk maak ik ook PR's aan en reageer ik op issues met mogelijke fixes.

[ Voor 5% gewijzigd door Cartman! op 04-03-2015 12:07 ]