[PHP/algmeen] Ontwerptips/-tools t.a.v. overzichtelijkheid

[Tomatensoep]

Dag mede-Tweakers,

Het probleem waar ik mee zit is als volgt:

Op amateuristische basis tracht ik zo nu en dan websites te ontwikkelen (voor de fun). Maar steeds loop ik naarmate de tijd vordert meer aan tegen onoverzichtelijkheid van mijn code..

Zelf gebruik ik momenteel het CakePHP-framework voor het ontwikkelen van websites.

Zo'n MVC-design is prima in het begin. Maar naarmate de tijd vordert is zo'n MVC-insteek ook al niet meer voldoende om de ergernis die ik van de groeiende complexiteit van code krijg te doen verminderen.

Al is het voor velen vast prima te doen, zelf roept het bij mij ergernis op, waardoor ik vaak weer opnieuw begin met hetzelfde project of een ander amateuristisch project. En dat vind ik jammer.

Ik ben daarom op zoek naar tips om overzichtelijkheid te vergroten. Heeft iemand bijvoorbeeld hetzelfde probleem leren overkomen? Of zijn er mensen die weet hebben van handige ontwikkeltools? Of een ander framework?

Met vriendelijke groet,
Tomatensoep ;-)

[HaTe]

Zelf gebruik ik sinds een paar jaar Smarty. HTML/output in templates en de rest in php pagina's.
Ik maak dan altijd een index.tpl voor het deel dat niet veel veranderd en voor de variabele content dan elk weer een aparte template als dat nodig is. In de index.tpl heb ik dan dus een variabele $content zitten en in de php pagina kan ik een content toewijzen aan de $content variabele, wat ook weer een template kan zijn:

PHP:

$smarty->assign('content', $smarty->fetch('listview.tpl'));
$smarty->display('index.tpl');

Als ik echt een grote website maak, dan gebruik ik CMS Made Simple, welke ook op Smarty gebaseerd is.

Verder ken ik CakePHP niet, ik weet ook niet wat het doet..

[ Voor 69% gewijzigd door HaTe op 25-11-2012 17:35 ]

[Tomatensoep]

Dank je, HaTe, voor je inbreng.

CakePHP is één van de vele web frameworks die volgens het MVC (Model-View-Controller) principe werkt.

[HaTe]

Ah ik heb het even opgezocht. Het is zelfs mogelijk om CakePHP in combinatie met Smarty te gebruiken, waardoor je HTML ook al weer een stuk simpeler wordt.

[Tomatensoep]

Ik heb eerder met XSLT gewerkt omdat ik heel graag code en uiterlijk gescheiden wou houden. Ik kon dan server-side XML-data er aan koppelen en het naar HTML transformeren.

Met Smarty heb ik nog niet gewerkt.

Maar XSLT werd mij te ingewikkeld als templatetaal. In CakePHP wordt het uiterlijk wel heel duidelijk gescheiden in zogenaamde Views. Een View gebruikt gewone PHP-code om data naar de browser te sturen.

Het punt is alleen dat alles in zijn totaliteit - de code die steeds naar views verwijst en de views die met links weer naar andere views verwijzen - dat me dat tegenstaat.

Om het anders te zeggen:
Ik wil alles gelijk in m'n hoofd hebben zitten. Ik wil overzien wat er nog allemaal moet komen, wat ik nog allemaal moet implementeren. Als er onzekerheid is - geen einde in zicht - roept dat bij mij ergernis op.

Ik heb een poosje voor het ontwerp Illustrator gebruikt. Dat beviel me uiteindelijk nog het best. Maar is er misschien een betere manier?

[ Voor 24% gewijzigd door Tomatensoep op 25-11-2012 17:54 ]

[Webgnome]

Tomatensoep schreef op zondag 25 november 2012 @ 17:47:

Om het anders te zeggen:
Ik wil alles gelijk in m'n hoofd hebben zitten. Ik wil overzien wat er nog allemaal moet komen, wat ik nog allemaal moet implementeren. Als er onzekerheid is - geen einde in zicht - roept dat bij mij ergernis op.

Helaas gaat je dat op een gegeven moment gewoon niet meer lukken. Het probleem waar jij mee te maken krijgt op een gegeven moment is dat je waarschijnlijk van te voren niet goed opschrijft / ontwerpt wat je wil gaan maken en wat je einddoel is. Dus welke functies wil je hebben, welke functies moet het hebben en welke functies zijn leuk om te hebben maar hebben (zeer) lage prio.

Ik zou eens gaan verdiepen in het voortraject van het ontwikkelen van een applicatie. Dingen als UML, Technisch ontwerp, functioneel ontwerp dat soort dingen. Zodat je, hoe klein ook, van te voren op papier hebt staan wat je gaat maken, waar het aan moet voldoen en hoe je het gaat maken. Dan kom je dus vanzelf tegen dingen aan als UML en dergelijke.

Een goed ontwerp is het halve werk is niet voor niets een veel gebruikt gezegde. Je kunt een goede php web applicatie in elkaar steken en daar dan smarty , framework x of iets voor gebruiken maar als je niet duidelijk / helder hebt wat je nou eigenlijk aan het doen bent en wat je einddoel is dan wordt het vanzelf.. tomatensoep met sliertjes spagheti.

Frameworks helpen je met veel gebruikte onderdelen makkelijk te implementeren maar helpen je niet met het overzichtelijk maken en houden van je applicatie. Als jij een framework gebruikt maar alles alsnog in 2 classen ( objecten/ models) propt is je overzicht ook foetsie. Of misschien doe je het weer andersom dat je alles in losse classen stopt en ja dan wordt het zo groot , en dus onnodig complex, dat je door de bomen het bos ook niet meer ziet en als je helemaal pech hebt je performance om te huilen is.

[ Voor 30% gewijzigd door Webgnome op 25-11-2012 19:35 . Reden: verduidelijking van stelling ]

[pachacuti]

Waar in je (MVC) code wordt het onoverzichtelijk dan?

In de View en Controller zou in principe weinig code mogen staan. De Model kan je mooi opdelen in services/entities/...

[Y0ur1]

Om wat voor een soort websites gaat het? Als het sites zijn waar veel business logica bij komt kijken, dus niet een veredelde CRUD-applicatie kun je nadenken over een domain model. Zoals pachacuti al aangaf ga je je app dan veel beter stuctureren met entities, business services, events, repositories, factories etc. Opzich zegt MVC nog helemaal niks, ja dat je je model van je view scheidt, maar hoe je je model invult is sterk afhankelijk van de complexiteit van je app.

[Tomatensoep]

@Webgnome:
Je hebt gelijk! Ik moet meer aan het ontwerpen besteden. Duidelijk stellen wat mijn prioriteiten qua functionaliteit zijn. Heb ik ook al wel geprobeerd eerder maar dat vind ik helaas wel lastig. Want als ik ergens mee bezig ben zie ik steeds meer vertakkingen van doelen en subdoelen, zodanig dat er geen eind aan lijkt te komen.

Dat er geen eind aan lijkt te komen is omdat ik heel veel dingen misschien te veel belang toeken. Onderscheid maken tussen belangrijke en minder belangrijke zaken is mogelijk moeilijk voor mij.

[Tomatensoep]

@parachuti, @Y0ur1:
MVC zegt op zich niet veel, daar ben ik achter inderdaad.

Webgnome bracht goed onder woorden waar het bij mij aan schort. Ik moet doelen stellen, zaken begrenzen. En zelfdiscipline zal ik ook meer van nodig hebben...

[Y0ur1]

Tomatensoep schreef op zondag 25 november 2012 @ 21:35:
@Webgnome:
Je hebt gelijk! Ik moet meer aan het ontwerpen besteden. Duidelijk stellen wat mijn prioriteiten qua functionaliteit zijn. Heb ik ook al wel geprobeerd eerder maar dat vind ik helaas wel lastig. Want als ik ergens mee bezig ben zie ik steeds meer vertakkingen van doelen en subdoelen, zodanig dat er geen eind aan lijkt te komen.

Dat er geen eind aan lijkt te komen is omdat ik heel veel dingen misschien te veel belang toeken. Onderscheid maken tussen belangrijke en minder belangrijke zaken is mogelijk moeilijk voor mij.

Dat is ook een van de kunsten van het bouwen van software: het onderscheiden wat belangrijk is en wat minder belangrijk is. Begin b.v. eens met om je functionaliteit MoSCoW te prioriteren. Je zou ook eens Getting Real kunnen lezen ter inspiratie.
Houd je code simpel maar niet simplistisch. Een klant is vaak blijer met een app die op tijd af is dan een die bol staat van de features en te laat af is. Release often en release early.

[Tomatensoep]

Ja. Ik zal mij eens gaan verdiepen in prioriteiten stellen. Dank jullie voor de info :-)

[Patriot]

pachacuti schreef op zondag 25 november 2012 @ 20:59:
Waar in je (MVC) code wordt het onoverzichtelijk dan?

In de View en Controller zou in principe weinig code mogen staan. De Model kan je mooi opdelen in services/entities/...

Dat is niet helemaal hoe CakePHP is ingericht. Over het algemeen houdt CakePHP wel van een lekker dikke controller. Er zal vast wel het eea naar het model verplaatst kunnen worden in de code van de TS, maar puur door de manier waarop CakePHP in elkaar steekt moet je niet al te veel verwachten.

[Donderpoes]

Kijk eens naar phpdocumentor http://www.phpdoc.org/. Het is geen ontwikkeltool, maar je kan comments in je code schrijven die je met behulp van phpdoc kan uitlezen. Ook kan je todo en dergelijke commenten. Heb je uiteindelijk een handig overzicht waar je snel in kan zien wat er nog moet gebeuren bijvoorbeeld.

[Webgnome]

Patriot schreef op zondag 25 november 2012 @ 23:01:
[...]


Dat is niet helemaal hoe CakePHP is ingericht. Over het algemeen houdt CakePHP wel van een lekker dikke controller. Er zal vast wel het eea naar het model verplaatst kunnen worden in de code van de TS, maar puur door de manier waarop CakePHP in elkaar steekt moet je niet al te veel verwachten.

een dikke controller hoeft geen probleem te zijn / worden. Als het maar duidelijk is waar de code van de controller uiteindelijk zijn verantwoordelijkheden naar toe gooit en waar de data vandaan komt. Een controller is en mag nooit meer zijn dan een simpel doorgeefluik naar andere classes die het echte werk verrichten. Dit zou je idealiter uit een model moeten toveren.. dit hangt natuurlijk allemaal af van hoe groot de applicatie / website is etc. Een dikke controller betekend denk ik in dit verhaal een controller met erg veel methodes.. deze methodes zelf zouden geen 100den regels code moeten bevatten..

[ Voor 15% gewijzigd door Webgnome op 26-11-2012 10:39 ]

[djluc]

Patriot schreef op zondag 25 november 2012 @ 23:01:
[...]
Dat is niet helemaal hoe CakePHP is ingericht. Over het algemeen houdt CakePHP wel van een lekker dikke controller. Er zal vast wel het eea naar het model verplaatst kunnen worden in de code van de TS, maar puur door de manier waarop CakePHP in elkaar steekt moet je niet al te veel verwachten.

Waarop baseer je dit? In het algemeen proberen we controllers basis te houden, beetje zoals de scaffolding ze maakt. Zonder enige business logica. We proberen zoveel mogelijk te structureren op REST logica zodat we ook geen aparte actions hebben maar gewoon de standaard actions. De slimmigheden kunnen we vaak prima kwijt in de models uiteindelijk.

Als je controllers wel vol komen te zitten met business logic moet je echt een review gaan doen waarom dat zo is want het wordt enorm onbeheersbaar. Zeker met het gebruik van o.a. behaviours kan je in de models vrijwel alles goed structureren waardoor de controllers niet veel meer doen.

[Patriot]

djluc schreef op maandag 26 november 2012 @ 10:35:
[...]

Waarop baseer je dit? In het algemeen proberen we controllers basis te houden, beetje zoals de scaffolding ze maakt. Zonder enige business logica. We proberen zoveel mogelijk te structureren op REST logica zodat we ook geen aparte actions hebben maar gewoon de standaard actions. De slimmigheden kunnen we vaak prima kwijt in de models uiteindelijk.

Als je controllers wel vol komen te zitten met business logic moet je echt een review gaan doen waarom dat zo is want het wordt enorm onbeheersbaar. Zeker met het gebruik van o.a. behaviours kan je in de models vrijwel alles goed structureren waardoor de controllers niet veel meer doen.

Ik was niet duidelijk. Ik bedoelde niet dat je je controllers in CakePHP maar vol moest trappen met businesslogica, ik vind gewoon dat de controllers in CakePHP nogal lomp zijn. Over het algemeen hebben we geen enkel probleem om code te reusen (en dan bedoel ik niet simpelweg dezelfde code copy/pasten natuurlijk ), maar ik heb soms wel het idee dat er teveel code in m'n controller staat. Er staat verder, voor zover ik het herken, geen business logica in, maar toch heb je soms redelijk grote actions.

[doltishDuke]

Voor mij werkt het uittekenen, met pen en papier, van de basis classes nog altijd het beste.

Trouwens, als je moeite hebt met het gebruik van een framework en je bent een beetje handig, zou ik je aanraden zelf eens een framework te gaan bouwen. Lees wat over het MVC model, geef er desnoods je eigen draai aan, bedenkt welke features je wilt en teken de handel uit. Daarna ga je dat opbouwen en ga je tegen heel veel problemen aanlopen. In feite dezelfde problemen die je hebt bij het gebruik van het framework, maar mijn ervaring is dat het, wanneer je de truc kent, dan meteen een stuk helderder is.

Ik heb dit zelf ook gedaan en zo ben ik een jaar of vijf geleden begonnen aan mijn eerste framework, Sealand. Dit klopte van geen kant en toen ik de eerste webapp ermee wilde gaan maken heb ik het in de kast gezet. Toen ben ik begonnen aan versie twee, Blackwater geheten. Stukken beter al maar ook niet echt bruikbaar. Inmiddels is het twee jaar geleden dat ik Decoro geschreven heb en ik kan nu zeggen dat ik er goed mee om kan gaan. Ook met andere frameworks, maar het goed begrijpen van zo'n framework en weten hoe het onder de motorkap werkt is zo handig dat ik eigenlijk alleen maar Decoro gebruik. Tot grote ergernis van collega's overigens, dus ik zou je niet aan willen raden dat in grote producties toe te passen. Maar om wat meer inzicht te krijgen in de werking is het een enorme aanrader.


Edit: Overigens is Decoro ook op basis van XSLT. Niet helemaal schoon qua code in de HTML dus, maar mijn insteek was dat alles wat betreft sorteren op visueel gebied thuis hoort bij de weergave van de data, en dus bij de HTML. Heb overigens wel weer een wrapper geschreven voor XSLT zodat ik geen belachelijk lange syntaxes nodig heb. Wanneer ik de handel uitvoer wordt dit omgezet naar XSLT en dat wordt gecached.

[ Voor 12% gewijzigd door doltishDuke op 26-11-2012 19:07 ]

[Webgnome]

doltishDuke schreef op maandag 26 november 2012 @ 19:02:
Voor mij werkt het uittekenen, met pen en papier, van de basis classes nog altijd het beste. Trouwens, als je moeite hebt met het gebruik van een framework en je bent een beetje handig, zou ik je aanraden zelf eens een framework te gaan bouwen.

offtopic:
Nee.. heel simpel.. nee. Als je een website in elkaar wil zetten en je eigen framework in elkaar wil zetten.. gewoon niet aan beginnen. Voor je het weet heb je een mooie website gemaakt , leuk frameworkje maar is het zo lek als een mandje.. en dat wil je echt niet.

[Patriot]

Wat hij vooral lijkt te willen zeggen is dat het misschien een goed idee is om zo'n framework te bouwen om kennis te maken met de problemen die je moet oplossen bij het bouwen van zo'n framework. Daar zit op zich best wel wat in, zo'n framework is één grote abstractie (en die lekken) dus is het helemaal niet slecht om te weten wat er wordt verborgen. Gewoon puur om te leren, niet om te gebruiken dus.

Wat dan weer een beetje jammer is, is dat hij wel zijn eigen advies in de wind slaat door de boel in gebruik te nemen voor serieuze projecten

[ Voor 7% gewijzigd door Patriot op 26-11-2012 20:01 ]

[doltishDuke]

Hehe, inderdaad met lekken moet je oppassen. Overigens wordt mij wat betreft lekken al vrij veel duidelijk door je ongelofelijk streng te houden aan wat al dan niet private of public is. Moet je toch wel natuurlijk, maar goed. Niet dat je dan geen lekken krijgt, absoluut niet, maar als ik vanuit de basis class van mijn core bij een POST variabele moest komen had ik toch wel een probleem. Geeft net wat meer inzicht in waarom het zo is dat bepaalde data niet overal hoeft te komen.

Ik gebruik het overigens niet voor projecten waar beveiliging echt van belang is hoor Zodra er persoonsgegevens of dergelijken aan te pas komen blijft Decoro in de kast. Heb het bijvoorbeeld wel gebruikt voor een verenigingswebsite, daar moet dat wel kunnen. Edit: Ledenadministratie was dus wel apart gedaan

[ Voor 7% gewijzigd door doltishDuke op 26-11-2012 20:13 ]

[johnkeates]

Je kan ook naar een framework migreren wat het wat strakker aanpakt dan CakePHP. Cake is leuk om mee te beginnen, maar mist de structuur die je bij grotere projecten nodig gaat hebben. Je hebt bijvoorbeeld Symfony 2 en Zend Framework 2, beiden prima te gebruiken in de wat betere projecten. CodeIgniter schijnt met SF2 en ZF2 vergelijkbaar te zijn qua kwaliteit, maar ik heb met dat specifieke framework geen ervaring.

[Gomez12]

Patriot schreef op maandag 26 november 2012 @ 20:01:
Wat hij vooral lijkt te willen zeggen is dat het misschien een goed idee is om zo'n framework te bouwen om kennis te maken met de problemen die je moet oplossen bij het bouwen van zo'n framework. Daar zit op zich best wel wat in, zo'n framework is één grote abstractie (en die lekken) dus is het helemaal niet slecht om te weten wat er wordt verborgen. Gewoon puur om te leren, niet om te gebruiken dus.

Tja, qua leerschool kan ik wel iets nuttigers bedenken als een framework bouwen wat je nooit moet gaan gebruiken.

Voordat je ook maar enigszins tegen de problemen die je wil begrijpen aan gaat lopen ben je al maanden verder. Dat is leuk als je nog op school zit en de tijd daarvoor hebt, maar als je die tijd niet hebt gaat het al heel snel hopeloos worden...

[doltishDuke]

Gomez12 schreef op maandag 26 november 2012 @ 20:18:
[...]

Tja, qua leerschool kan ik wel iets nuttigers bedenken als een framework bouwen wat je nooit moet gaan gebruiken.

Voordat je ook maar enigszins tegen de problemen die je wil begrijpen aan gaat lopen ben je al maanden verder. Dat is leuk als je nog op school zit en de tijd daarvoor hebt, maar als je die tijd niet hebt gaat het al heel snel hopeloos worden...

Als je je werk niet leuk vind moet je het ook niet doen. Ik gebruik mijn framework trouwens wél veel, maar goed. En zoveel werk is het nou ook weer niet hoor. Je hoeft natuurlijk niet meteen iets te bouwen dat zich qua functionaliteit kan meten met bijvoorbeeld Symfony. Dat heb ik ook niet gedaan en dat is ook absoluut niet wat ik bedoel. De basis van zoiets zelf eens opzetten kan je veel van leren. Dat is hetzelfde als dat je net begint met PHP, en het beter werkt om gewoon maar wat te gaan maken en op te zoeken wat je wilt weten, dan eindeloos theorie leren en niks doen.

Daarnaast, inderdaad, leuk als je er tijd voor hebt. De TS zegt dan ook dat hij op hobby basis werkt. Doe ik ook trouwens, al wil ik nog wel eens een opdracht van mijn eigen bedrijfje erbij pakken als we geen zin hebben om iemand in te huren die wil programmeren.

[ Voor 10% gewijzigd door doltishDuke op 26-11-2012 21:17 ]

[djluc]

Patriot schreef op maandag 26 november 2012 @ 17:34:
[...]


Ik was niet duidelijk. Ik bedoelde niet dat je je controllers in CakePHP maar vol moest trappen met businesslogica, ik vind gewoon dat de controllers in CakePHP nogal lomp zijn. Over het algemeen hebben we geen enkel probleem om code te reusen (en dan bedoel ik niet simpelweg dezelfde code copy/pasten natuurlijk ), maar ik heb soms wel het idee dat er teveel code in m'n controller staat. Er staat verder, voor zover ik het herken, geen business logica in, maar toch heb je soms redelijk grote actions.

Toch is dat apart, geen idee waarom je het precies nodig hebt maar ik zie het eigenlijk nooit meer. Alleen wat standaard actions er in en klaar. Houd je wel het REST pattern aan? Geeft wat meer controllers maar meer overzicht.

Wat betreft de problemen die de topicstarter tegenkomt:

Zo'n MVC-design is prima in het begin. Maar naarmate de tijd vordert is zo'n MVC-insteek ook al niet meer voldoende om de ergernis die ik van de groeiende complexiteit van code krijg te doen verminderen.

Je zal absoluut meer code krijgen maar probeer de onderdelen zelf simpel te houden. Voor herhalende zaken kan je een oplossing vinden middels components, helpers of via bijvoorbeeld de appcontroller.

In basis in CakePHP is het sterk aan te raden alleen de vaste actions te gebruiken tenzij je niet anders kan.

Al is het voor velen vast prima te doen, zelf roept het bij mij ergernis op, waardoor ik vaak weer opnieuw begin met hetzelfde project of een ander amateuristisch project. En dat vind ik jammer.

Als een project te groot wordt, wat absoluut kan, zou het verstandig kunnen zijn om er meerdere kleine projecten van te maken. Bijvoorbeeld: Als je ingewikkelde code hebt die je in meerdere models nodig hebt kan je deze in een behaviour plaatsen.

Veel generieke delen kan je tevens in plugins plaatsen. Ik weet niet wat voor applicatie je maakt maar er zijn genoeg oplossingen denkbaar die je apart kan houden. Als het over websites gaat kan je bijvoorbeeld aan een twitter feed, een fotoalbum of een cms deel denken. Door dit in een aparte plugin te zetten en te verwerken kan je prima een grote applicatie bouwen zonder vast te lopen omdat je de individuele delen het werk laat doen en deze tevens op simpele wijze kunt koppelen.

Testing
Op een gegeven moment kom je toch weer op het punt waarop je gaat vastlopen. Vooral omdat je veel afhankelijkheden hebt op een website, een pagina kan vele onderdelen bevatten. Om zeker te weten dat alles blijft werken bij wijzigingen kan testing erg te adviseren zijn. Het geeft je meer grip op het geheel. Als je vooraf al weet dat het een groot project gaat worden zou je dit vooraf al in kunnen gaan zetten maar als je een lopend project hebt kan het ook altijd nog toegevoegd worden.