Werkwijze internet bedrijven

[Verwijderd]

Ik ben vanochtend al een tijdje aan het googlen geweest over de werkwijzes van internet bedrijven.
Maar kan niet tot een duidelijk antwoord komen.

Hoe pakken internet bedrijven met 5> man personeel een groot project aan?
Niet elke programmeur(PHP/Javascript bijv.) is programmeert op dezelfde manier.
Hoe los je dit op? Door gebruik te maken van een Framework bijv? Zo ja, welk framework?

Of zul je de 'programmeer-wijze' op elkaar af moeten stemmen?
Maar wat te doen met nieuwe collega(s) ? Moet je die deze werkwijze ook weer aanleren?

Ik zou hier graag meer inzicht in krijgen.

Wat zijn jullie ervaringen op dit gebied?

[Verwijderd]

Zodra ook maar één collega hebt waarmee je aan hetzelfde project werkt heb je baat bij:
- Subversion(SVN) aka versie beheer. Zodat als je perongeluk elkaars werk overschrijft je het terug kunt halen.
- Documentatie(PHP documentor), de meest simpele en basale vorm van documentatie. Hierbij kun je inline documentatie laten parsen in een webinterface.
- Testing protocollen (PHPUNIT), functioneel testen.
- Tja project technieken? Prince, SDM weet ik veel. Dit is iets wat per bedrijf verschilt.
- Afspraken(protocollen is zo'n duur woord), Coding standards en wie is verantwoordelijk voor wat.

Qua frameworks verschilt ook per project, alhoewel ik wel graag standaarden zet. Drupal voor simpele CMSen en ZendFramework voor uitgebreide applicaties. Standaarden zijn goed voor de efficieëntie maar ze moeten uiteraard wel met de trends mee gaan!

Hoop dat je hier wat aan hebt.

[ Voor 5% gewijzigd door Verwijderd op 10-04-2008 12:06 ]

[LuCarD]

Verwijderd schreef op donderdag 10 april 2008 @ 11:59:
Ik ben vanochtend al een tijdje aan het googlen geweest over de werkwijzes van internet bedrijven.
Maar kan niet tot een duidelijk antwoord komen.

Hoe pakken internet bedrijven met 5> man personeel een groot project aan?
Niet elke programmeur(PHP/Javascript bijv.) is programmeert op dezelfde manier.
Hoe los je dit op? Door gebruik te maken van een Framework bijv? Zo ja, welk framework?

Of zul je de 'programmeer-wijze' op elkaar af moeten stemmen?
Maar wat te doen met nieuwe collega(s) ? Moet je die deze werkwijze ook weer aanleren?

Ik zou hier graag meer inzicht in krijgen.

Wat zijn jullie ervaringen op dit gebied?

Meeste grootte bedrijven maken gebruik van "een" framework afhankelijk van het project , welke dat is word meestal beslist door de Senior developer en als het goed is in samenspraak met het gehele team.

Daarnaast worden er duidelijke afspraken gemaakt mbt programmeerstylen, en die afspraken kunnen best ver gaan. ( denk aan hoofdletter gebruik, spaties of tabs, for of foreach gebruik )
En nieuwe collega's krijgen eerst instructie of de regels, en als het goed is ook een handboek. En worden ook geacht deze stijl te leren.

[Niemand_Anders]

Nou, je hebt een development manager welke de taken coordineerd. Daarnaast bestaan er design patterns voor vrijwel alle denkbare situaties. Beschrijving (en C# voorbeeld code) van Design patterns kun je onder andere vinden bij www.dofactory.com.

Om ervoor te zorgen dat iedereen op dezelfde manier code schrijft bestaan coding standards. Voor PHP raad ik eigenlijk aan om de PEAR coding standaards aan te houden.

Maar project management is niet iets wat je in 10 regels uitlegt.

[Verwijderd]

Waar we nu vaak tegen aan lopen is het volgende bijv. bij ontwikkeling van website:

De ontwikkeling een eigen CMS is 3 jaar geleden begonnen.
Elke maand wordt er wel een kleine aanpassing doorgevoerd etc, maar de code is niet echt goed meer. Het is niet OOP gescrheven en maakt geen gebruik van een Framework.
Het CMS bestaat inmiddels uit 7 verschillende modules(pagina beheer,nieuwsbrief beheer etc.)

Op dit moment is er in het bedrijf eigenlijk 1 iemand die een website kan koppelen aan dit CMS, en dat is diegene die het CMS gemaakt heeft. Hoe kan dit het beste opgelost worden?
CMS dusdanis aanpassen dat OOP geschreven is of gebruik maken van een framework.
Zodat andere (nieuwe) collega's dit aan kunnen leren?

Ik neem aan dat elk jong internet bedrijf hier vroeg of laat tegen aan is gelopen..

ben erg benieuwd.

[Verwijderd]

In ieder geval zorgen dat er meer mensen zijn die weten hoe het CMS werkt, het kunnen koppelen en het ook kunnen veranderen als dat nodig is.

Jij hebt nu last van het "hit by a bus" syndroom :
als die ene persoon vandaag overreden wordt door een bus, is je hele bedrijf weg.
Daardoor rust er te veel verantwoordelijkheid bij 1 iemand, en dat wil je niet hebben. (En niet alleen omdat die persoon nu simpelweg 3x zo veel salaris kan eisen, omdat je zonder hem/haar niks kunt)

Kortom, haal die ene persoon maar af van z'n werk, en laat 'm wat andere mensen instrueren totdat zij zijn werk ook kunnen doen.
Pas daarna mag ie weer aan de slag.

(Een handige tip : je kunt de uitleg op video opnemen, zodat als er nieuwe mensen komen werken je ze eerst 4 uur op hun pc even die video kunt laten kijken, scheelt je 4 uur uitleg elke keer dat er iemand aangenomen wordt)


Vervolgens ga je zorgen dat er goede documentatie is over wat julle hebben liggen (je eigen CMS),
en - als je die nog niet hebt - ga je een coding-guideline opstellen met de regels waar iedereen zich vanaf nu aan moet houden.

Hoe ver je daarin wilt gaan moet je zelf weten, het gaat er alleen om dat het in principe niet merkbaar moet zijn wie welke code geschreven heeft - zodat als er iets moet veranderen, iedereen ook met die code kan werken ongeacht of zij/hij die code zelf geschreven heeft.

[ Voor 35% gewijzigd door Verwijderd op 10-04-2008 13:17 ]

[Verwijderd]

Verwijderd schreef op donderdag 10 april 2008 @ 13:10:
In ieder geval zorgen dat er meer mensen zijn die weten hoe het CMS werkt, het kunnen koppelen en het ook kunnen veranderen als dat nodig is.

Jij hebt nu last van het "hit by a bus" syndroom :
als die ene persoon vandaag overreden wordt door een bus, is je hele bedrijf weg.
Daardoor rust er te veel verantwoordelijkheid bij 1 iemand, en dat wil je niet hebben. (En niet alleen omdat die persoon nu simpelweg 3x zo veel salaris kan eisen, omdat je zonder hem/haar niks kunt)

Kortom, haal die ene persoon maar af van z'n werk, en laat 'm wat andere mensen instrueren totdat zij zijn werk ook kunnen doen.
Pas daarna mag ie weer aan de slag.

(Een handige tip : je kunt de uitleg op video opnemen, zodat als er nieuwe mensen komen werken je ze eerst 4 uur op hun pc even die video kunt laten kijken, scheelt je 4 uur uitleg elke keer dat er iemand aangenomen wordt)


Vervolgens ga je zorgen dat er goede documentatie is over wat julle hebben liggen (je eigen CMS),
en - als je die nog niet hebt - ga je een coding-guideline opstellen met de regels waar iedereen zich vanaf nu aan moet houden.

Hoe ver je daarin wilt gaan moet je zelf weten, het gaat er alleen om dat het in principe niet merkbaar moet zijn wie welke code geschreven heeft - zodat als er iets moet veranderen, iedereen ook met die code kan werken ongeacht of zij/hij die code zelf geschreven heeft.

Inderdaad last van 'hit by a bus' syndroom.
Maar ook met oog op de toekomst, wanneer we extra personeel/freelancers aantrekken etc.
Ook deze mensen moeten zonder al teveel werk een project kunnen koppelen aan het CMS.

Zelf denk ik dat het beter is om het CMS volledig opnieuw te schrijven met behulp van een Framework.
Probleem daarbij is ook dat bestaande websites aangepast moeten worden om gekoppeld te worden aan vernieuwde CMS/Database.

Maar ook wanneer ik vandaag een framework zou kiezen om te gebruiken, dat over een half jaar weer een betere is. BLijft lastig..

[Janoz]

Een framework gaat je probleem niet oplossen en een rewrite is waarschijnlijk veel te duur en daarnaast los je daarmee het probleem van de bestaande sites helemaal niet op. Het belangrijkste op dit moment is om te documenteren. Zorg dat er duidelijke specificaties komen van wat elk onderdeel nu eigenlijk doet en hoe dit te implementeren. Zorg daarnaast voor coding standaarden. Pas hierna zou je kunnen overwegen om een rewrite te doen, maar ik zou eerder een refactor van de bestaande code aanraden.

[Creepy]

Eeh,, waarom zou het opzetten van een volledig nieuw CMS helpen voor het bekend krijgen van de werking en het kunnen opzetten van een CMS door andere mensen? Als het CMS werkt en onderhoudbaar is win je echt veel meer door de huidige mensen mee te laten ontwikkelen aan het huidige CMS en ze er sites mee op te leren zetten. Scheelt je enorm veel tijd en kosten met het opzetten van een volledig nieuw CMS. Waarschijnlijk heeft het oude CMS ondertussen al een eigen framework. Wat zou minder tijd kosten: het huidige CMS leren of een nieuwe framework leren, daar een CMS mee gaan bouwen en dan vervolgens dat CMS weer gaan uitleggen aan nieuwe medewerkers.....

Als het huidige CMS een onderhoudsnachtmerrie is en moeilijk uitbreidbaar dan loont op de lange duur het om een nieuwe CMS te gaan schrijven ja. Maar de boel opnieuw gaan schrijven omdat maar 1 persoon het huidige systeem kent is echt een non-argument.

Edit: * Creepy mept Janoz, doe eens niet sn snel

[Verwijderd]

Grote Fout #1 (c) :
Te snel opnieuw willen beginnen.
Leer eerst eens van je fouten (dus zorg dat je eerst door hebt wat het probleem uberhaupt is), en verhelp ze.
Alles weggooien en opnieuw beginnen zorgt er waarschijnlijk voor dat je over 4 maanden met hetzelfde probleem zit, alleen met een andere codebase.


Analyseer nou eerst eens 2 dagen wat er allemaal mis is, en waardoor het mis is gegaan.
Maak eens een lijst met dingen die beter gedaan hadden kunnen/moeten worden had je het willen voorkomen.
Maak vervolgens een lijst met kleine, planmatige acties die je kunt ondernemen om stap voor stap de problemen op te lossen.

Ik denk dat het eerste punt op je lijst nu zou moeten zijn : "te weinig mensen met kennis over het CMS, de toepassing en de implementatie ervan".

[Verwijderd]

Creepy schreef op donderdag 10 april 2008 @ 13:30:
Eeh,, waarom zou het opzetten van een volledig nieuw CMS helpen voor het bekend krijgen van de werking en het kunnen opzetten van een CMS door andere mensen? Als het CMS werkt en onderhoudbaar is win je echt veel meer door de huidige mensen mee te laten ontwikkelen aan het huidige CMS en ze er sites mee op te leren zetten. Scheelt je enorm veel tijd en kosten met het opzetten van een volledig nieuw CMS. Waarschijnlijk heeft het oude CMS ondertussen al een eigen framework. Wat zou minder tijd kosten: het huidige CMS leren of een nieuwe framework leren, daar een CMS mee gaan bouwen en dan vervolgens dat CMS weer gaan uitleggen aan nieuwe medewerkers.....

Als het huidige CMS een onderhoudsnachtmerrie is en moeilijk uitbreidbaar dan loont op de lange duur het om een nieuwe CMS te gaan schrijven ja. Maar de boel opnieuw gaan schrijven omdat maar 1 persoon het huidige systeem kent is echt een non-argument.

Edit: * Creepy mept Janoz, doe eens niet sn snel

Oke dat is duidelijk.
Maar het toevoegen van een nieuwe module aan het huidige CMS is niet echt simpel te noemen.
Ook zou ik bepaalde werkingen van het CMS anders zien. Dit omdat het voor de eindgebruiker vaak te omslachtig gemaakt is.(gebruiksvriendelijkheid..)
Wellicht is het een idee om module voor module het CMS aan te passen en gebruik te maken van OOP en verrvolgens dit goed te documenteren.?

[Verwijderd]

Ik zie sowiezo het nut niet van een "eigen" CMS. Er zijn zoveel CMS'en waar letterlijk duizenden mensen aan werken en actief in zijn, de feedback is enorm. Bij deze pakketten hoef je zelf ook niet bijvoorbeeld de security in de gaten te houden (behalve bij eigen modules). Het nadeel is dat de "core" van je CMS publiekelijk toegankelijk is, dus je moet wel goede update procedures hebben.

Dit vind ik persoonlijk een veel makkelijkere manier van werken.

Zodra een klant specefieke eisen heeft waar een framework niet aan voldoet betalen zij jou om het bestaande framework te extenden. De krenten in de pap, welke is nu duurder denk je?

[Verwijderd]

Verwijderd schreef op donderdag 10 april 2008 @ 14:00:
Ik zie sowiezo het nut niet van een "eigen" CMS. Er zijn zoveel CMS'en waar letterlijk duizenden mensen aan werken en actief in zijn, de feedback is enorm. Bij deze pakketten hoef je zelf ook niet bijvoorbeeld de security in de gaten te houden (behalve bij eigen modules). Het nadeel is dat de "core" van je CMS publiekelijk toegankelijk is, dus je moet wel goede update procedures hebben.

Dit vind ik persoonlijk een veel makkelijkere manier van werken.

Zodra een klant specefieke eisen heeft waar een framework niet aan voldoet betalen zij jou om het bestaande framework te extenden. De krenten in de pap, welke is nu duurder denk je?

Het voordeel van een eigen CMS vind..is dat het altijd maatwerk is.
Voor elke klant/website kunnen er dus aanpassingen gemaakt worden in het CMS.
Met een opensource CMS is dit moeilijker denk ik.

[Verwijderd]

Het voordeel van een eigen CMS is dat je niet meer troep mee zeult dan nodig is,
en dat je zelf controle hebt over de richting waarin het zich ontwikkelt.
Het nadeel is dat je het zelf zult moeten maken en onderhouden.

[Verwijderd]

Verwijderd schreef op donderdag 10 april 2008 @ 14:16:
Het voordeel van een eigen CMS is dat je niet meer troep mee zeult dan nodig is,
en dat je zelf controle hebt over de richting waarin het zich ontwikkelt.
Het nadeel is dat je het zelf zult moeten maken en onderhouden.

100% mee eens..

[LuCarD]

Verwijderd schreef op donderdag 10 april 2008 @ 14:13:
[...]


Het voordeel van een eigen CMS vind..is dat het altijd maatwerk is.
Voor elke klant/website kunnen er dus aanpassingen gemaakt worden in het CMS.
Met een opensource CMS is dit moeilijker denk ik.

Het voordeel van een opensource CMS is dat een klant niet perse vast zit aan jouw als bedrijf. Dit gebruik ik als een verkoop argument. Ter voorkoming van de "hit by a bus" ( leuke omschrijving ) syndroom .

Daarnaast is word een Opensource CMS door ontwikkeld zelfs als jij het niet meer doet. En je kan dus makkelijk onderhouds contract aanbieden om het CMS up-to-date houden.

Ik vertel er wel altijd bij dat ik een Opensource CMS gebruik en waarom ik specifiek die gebruik. Eigen geschreven modules maak ik op zo'n manier dat ze geen last hebben van normale update trajecten.

[Kettrick]

Verwijderd schreef op donderdag 10 april 2008 @ 14:16:
Het voordeel van een eigen CMS is dat je niet meer troep mee zeult dan nodig is,
en dat je zelf controle hebt over de richting waarin het zich ontwikkelt.
Het nadeel is dat je het zelf zult moeten maken en onderhouden.

Klopt, ik heb de afgelopen jaren behoorlijk wat sites opgeleverd met een CMS wat ik als aanvulling op Adobe Contribute gebruikte. Veel projecten deed ik samen met een vriend, hij was vooral bezig met de contribute templates, ik regelde de verdere CMS kant.

Op die manier heb je trouwens een strakke scheiding van werk, waardoor ingewikkelde procedures etc. overbodig zijn

[Verwijderd]

*right*

[ Voor 105% gewijzigd door Creepy op 10-04-2008 14:42 ]

[Voutloos]

RoeLz schreef op donderdag 10 april 2008 @ 14:22:
Op die manier heb je trouwens een strakke scheiding van werk, waardoor ingewikkelde procedures etc. overbodig zijn

Ingewikkelde procedures? SVN en weten wie welke bug/feature afhandeld does the trick.

offtopic:
Het is hier geen werving forum, dus laat die semi-grappige opmerkingen over contracten maar.

[ Voor 14% gewijzigd door Voutloos op 10-04-2008 14:31 ]

[Verwijderd]

Voutloos schreef op donderdag 10 april 2008 @ 14:26:
[...]
Ingewikkelde procedures? SVN en weten wie welke bug/feature afhandeld does the trick.

SVN en Trac ofzo, klaar

[Verwijderd]

tsjah het is toch wel zo dat ik me eigen erger aan ons CMS zoals die nu opgebouwd is.
ook de werking van bepaalde dingen. Ik heb al een hele waslijst aan functies/handeling in het CMs die simpel verbeterd kunnen worden.

Ik kies er denk ik toch voor om deze per module aan te passen en dan meteen OOP in te voeren.
Is dat mogelijk? OOP invoeren in huidige modules die niet-OOP geschreven zijn?

Is inline documentatie voldoende? of zal er ook documentatie los moeten in map vorm zeg maar?

[Verwijderd]

Hoe veel ervaring heb je zelf uberhaupt in developen als ik vragen mag ?

Gefaseerd invoeren zou geen probleem moeten zijn.
Documentatie hangt af van de eisen die je er aan stelt.
Voor nieuwe mensen is het in ieder geval handig als er een soort overzicht is,
zodat ze snappen hoe het systeem globaal een beetje werkt en wat de ideeeen erachter zijn.

Documentatie van specifieke stukken code is prima inline, zolang mensen maar weten waar ze bepaalde functionaliteit kunnen vinden kunnen ze daar ter plekke dan lezen hoe de details in elkaar steken.

[ Voor 76% gewijzigd door Verwijderd op 10-04-2008 14:46 ]

[Voutloos]

Verwijderd schreef op donderdag 10 april 2008 @ 14:36:
Ik heb al een hele waslijst aan functies/handeling in het CMs die simpel verbeterd kunnen worden.

Stel, de huidige software is inderdaad een gedrocht. Zou dat dan echt beter worden als iedereen blindelings zijn simpele verbeteringen door gaat voeren?

Ik kies er denk ik toch voor om deze per module aan te passen en dan meteen OOP in te voeren.
Is dat mogelijk? OOP invoeren in huidige modules die niet-OOP geschreven zijn?

Waarom niet? Als je maar goed over je aanpak nadenkt, zodat mettertijd de modulus een consistente structuur hebben.

Is inline documentatie voldoende? of zal er ook documentatie los moeten in map vorm zeg maar?

Er is meer dan enkel regeltjes code uitleggen. Grote brokken functionaliteit wil je wellicht ook gewoon toelichten.

Maar goed, documenteer eerst wat je hebt en ga team tools als SVN (alhoewel ook in je eentje handig ) gebruiken.

[ Voor 6% gewijzigd door Voutloos op 10-04-2008 14:47 ]

[Verwijderd]

Even een kleine kanttekening: Ga nu niet OOP gebruiken omdat het de "hype" van tegenwoordig is.

Ik ben het er mee eens dat het wel de elegantste oplossing is maar er gaat ook een (aanzienlijk) langer ontwikkel traject aan vooraf. Voor mij is de kracht van OOP dat het ontwikkel proces los is gemaakt van het programeren. Met behulp van bijvoorbeeld UML kun je de structuur van je applicatie al afhebben voor je ook maar één regel code hebt staan. Als je UML af is hoef je het alleen nog maar te implementeren.

Het mooie is dat bij OOP meestal alleen de instapkosten hoog zijn. Zodra de initieële ontwikkeling klaar is houd je een hele berg documentatie, unittests en UML diagrammen over. Hierdoor word updaten, bugfixing en uitbreiden vele male efficiënter.

Een goede OOP(+UML uiteraard) procedure, SVN(versie beheer), PHPUNIT(functionaliteit testing, early bug detection) en een trac/bugzilla heb je een krachtformule waar je zeker efficieënt en makkelijk mee zult werken.

[Creepy]

j.ostie: Ook voor niet OOP zijn er methodes en technieken om te documenteren voordat je code gaat kloppen. Je opmerking dat programmeren los is gemaakt van het ontwikkel proces snap ik niet helemaal. Programmeren is een onderdeel van het onwikkelproces en dat kan je echt niet lostrekken of je nu OOP gebruikt of niet.

[Kettrick]

Voutloos schreef op donderdag 10 april 2008 @ 14:26:
[...]
Ingewikkelde procedures? SVN en weten wie welke bug/feature afhandeld does the trick.

offtopic:
Het is hier geen werving forum, dus laat die semi-grappige opmerkingen over contracten maar.

Ik doel dan vooral op prince2 en andere methodieken, binnen een kleine club heb je vaak meer aan een dosis gezond verstand

SVN gebruik ik zelfs voor projecten waar ik alleen aan werk, puur als backup/archivering

[kenneth]

Verwijderd schreef op donderdag 10 april 2008 @ 15:04:
Voor mij is de kracht van OOP dat het ontwikkel proces los is gemaakt van het programeren. Met behulp van bijvoorbeeld UML kun je de structuur van je applicatie al afhebben voor je ook maar één regel code hebt staan. Als je UML af is hoef je het alleen nog maar te implementeren.

Ik heb nog nooit meegemaakt dat dit zo is. Wel regelmatig meegemaakt dat mensen denken dat het ontwerp af is, maar zodra er begonnen wordt met programmeren, zodra er deelproducten aan de klant worden getoond, dan blijkt dat er her en der nog wat schort. Je kan niet altijd alles vooraf weten, ook ontwerp is een voortdurend proces.

[Verwijderd]

Creepy schreef op donderdag 10 april 2008 @ 15:09:
j.ostie: Ook voor niet OOP zijn er methodes en technieken om te documenteren voordat je code gaat kloppen. Je opmerking dat programmeren los is gemaakt van het ontwikkel proces snap ik niet helemaal. Programmeren is een onderdeel van het onwikkelproces en dat kan je echt niet lostrekken of je nu OOP gebruikt of niet.

Wat ik probeer uit te leggen is dat je voor OOP software ontwikkeling niet echt hoeft te kunnen programeren omdat je met "natuurlijke" objecten en relaties werkt. Het is eigenlijk meer een verhaaltje.

Ik weet dat programeren deel is van het ontwikkel proces maar bij OOP is er een redelijke abstractie als je begrijpt wat ik bedoel. Hierdoor kunnen nieuwe medewerkers of collega's makkelijk je software begrijpen.Bij de andere methodes heb ik altijd het iedee dat het een soort van pseudo-code is.

[Verwijderd]

ik heb tot nu toe veel tips gekregen..dankjewel hiervoor.
ik ben zelf zo'n 4 jaar met php bezig. Veel geleerd en vind het leuk werk.

Echter wanneer ik nu stukken code zie die bijv. destijds gemaakt zijn.
denk ik toch; tsjah dat kan tegenwoordig(met m'n huidige php kennis) echt veel beter.
Maar ook dit is iets wat elke php'er zal tegenkomen.

Ik zal komende tijd goed nadenken over hoe het zal moeten.

Wanneer jullie aan een project beginnen, brengen jullie dan elke class/functie van het project van te voren in beeld?

Bijv.:

Class PaginaBeheer:
- functie pagina toevoegen
- functie pagina verwijderen
- functie pagina aanpassen
- functie pagina in menu verschuiven(hoger of lager in menu plaatsen.)
- functie pagina als subpagina maken

[Verwijderd]

Verwijderd schreef op donderdag 10 april 2008 @ 15:20:
[...]


....

Ik weet dat programeren deel is van het ontwikkel proces maar bij OOP is er een redelijke abstractie als je begrijpt wat ik bedoel. Hierdoor kunnen nieuwe medewerkers of collega's makkelijk je software begrijpen.Bij de andere methodes heb ik altijd het iedee dat het een soort van pseudo-code is.

Dit ben ik met je eens..Daarom kies wil ik nu dan oo kgebruik maken van OOP.

[Verwijderd]

Verwijderd schreef op donderdag 10 april 2008 @ 15:29:
ik heb tot nu toe veel tips gekregen..dankjewel hiervoor.
ik ben zelf zo'n 4 jaar met php bezig. Veel geleerd en vind het leuk werk.

Echter wanneer ik nu stukken code zie die bijv. destijds gemaakt zijn.
denk ik toch; tsjah dat kan tegenwoordig(met m'n huidige php kennis) echt veel beter.
Maar ook dit is iets wat elke php'er zal tegenkomen.

Ik zal komende tijd goed nadenken over hoe het zal moeten.

Wanneer jullie aan een project beginnen, brengen jullie dan elke class/functie van het project van te voren in beeld?

Bijv.:

Class PaginaBeheer:
- functie pagina toevoegen
- functie pagina verwijderen
- functie pagina aanpassen
- functie pagina in menu verschuiven(hoger of lager in menu plaatsen.)
- functie pagina als subpagina maken

Van tevoren maak ik een top-down opzet :

Wat is de hoofdfunctionaliteit van het geheel ?
In welke delen kunnen we dat weer opsplitsen ?
Etc.

Zou krijg je vanzelf een modulaire aanpak, en hou je vanzelf je classes over.
Maar je hoeft je classes niet helemaal tot op het functieniveau uit te werken,
want tijdens het coden verandert er nog wel eens wat, of blijkt dat je ergens overeen gekeken hebt.

Het gaat er voornamelijk om dat je een logische verdeling van functionaliteit gebruikt,
en terwijl je bezig bent de code die je schrijft ook documenteert zodat voor iedereen duidelijk is wat die code doet, en waarom ie daar staat.

[Hydra]

Verwijderd schreef op donderdag 10 april 2008 @ 15:37:
Het gaat er voornamelijk om dat je een logische verdeling van functionaliteit gebruikt,
en terwijl je bezig bent de code die je schrijft ook documenteert zodat voor iedereen duidelijk is wat die code doet, en waarom ie daar staat.

Precies. Ik heb ook regelmatig in code moeten duiken die niet door mij geschreven was, en het grootste probleem is vooral uitvogelen wat het systeem doet, en waar dat precies gebeurt. Codedocumentatie is dan een eerste stap, maar gewoon een tekening met (en al maak je het in paint, als er maar iets is) welke routes welke data door welke subsystemen neemt en wat daar in grote lijnen mee gebeurt is het allerbelangrijkste. Als je dat in je hoofd hebt, is de code voor een groot deel al zelfdocumenterend.

Ik heb overigens vroegah bij een webdesignbedrijf gewerkt met een soortgelijk probleem. Een PHP CMS (wel voor een groot deel OO) geschreven door een autodidact. Een goedbedoelende Elektrotechniek student die d'r een behoorlijk zooitje van had gemaakt. Ben daar maanden bezig geweest met een refactoringslag waar ik alle klantspecifieke meuk uit het systeem gesloopt heb.

[Verwijderd]

Hydra schreef op donderdag 10 april 2008 @ 16:10:
[...]


Precies. Ik heb ook regelmatig in code moeten duiken die niet door mij geschreven was, en het grootste probleem is vooral uitvogelen wat het systeem doet, en waar dat precies gebeurt. Codedocumentatie is dan een eerste stap, maar gewoon een tekening met (en al maak je het in paint, als er maar iets is) welke routes welke data door welke subsystemen neemt en wat daar in grote lijnen mee gebeurt is het allerbelangrijkste. Als je dat in je hoofd hebt, is de code voor een groot deel al zelfdocumenterend.

Ik heb overigens vroegah bij een webdesignbedrijf gewerkt met een soortgelijk probleem. Een PHP CMS (wel voor een groot deel OO) geschreven door een autodidact. Een goedbedoelende Elektrotechniek student die d'r een behoorlijk zooitje van had gemaakt. Ben daar maanden bezig geweest met een refactoringslag waar ik alle klantspecifieke meuk uit het systeem gesloopt heb.

Wat bedoel je precies met klant specifieke meuk?

[TeeDee]

Denk aan hardcoded settings/variables voor klant naam ipv een generieke oplossing waarbij de settings / variables bijvoorbeeld uit een db komen.
gok ik

[Verwijderd]

TeeDee schreef op donderdag 10 april 2008 @ 16:43:
Denk aan hardcoded settings/variables voor klant naam ipv een generieke oplossing waarbij de settings / variables bijvoorbeeld uit een db komen.
gok ik

Okej.
Je gaat hierbij uit van 1 centraal CMS dus, waar al je klanten aan gekoppeld zijn?
Dit is namelijk wat ik nu ook heb.

[Voutloos]

Lees je uberhaupt wel?

TeeDee refereert naar magic numbers en settings in de code. Of misschien wel gecombineerd tot de ergste klantspecifieke trucs als "if ($site_id==42) $color = 'red'; else if($site_id=1337) $color = 'blue';" midden in de main CMS code.
Of je CMS dan op 1 of meerdere plekken draait is helemaal niet relevant.

Begin maar met documentatie.
Of doe eens als los project een (gedeeltelijke) refactorslag van een van je modules. Wellicht is dat eigenlijk niet de eerste actie om nu te ondernemen, maar ik heb het idee dat je wel een keer ervaring met het (al dan niet succesvol) aanpassen van oude code mag opdoen (nofi ) en bovendien kan je misschien dan beter de tijd schatten die het helemaal herschrijven kost.

[Hydra]

Verwijderd schreef op donderdag 10 april 2008 @ 16:40:
Wat bedoel je precies met klant specifieke meuk?

if ($item_id = 245323)
doCustomerXStuff();

Er zaten 'hacks' ingebouwd in de code om functionaliteit aan te bieden. Niet alleen was het klantspecifiek, er werd ook nog in de code naar record IDs in de database gewezen. Magic numbers zag je overal in de code.

Verwijderd schreef op donderdag 10 april 2008 @ 17:15:
Okej.
Je gaat hierbij uit van 1 centraal CMS dus, waar al je klanten aan gekoppeld zijn?
Dit is namelijk wat ik nu ook heb.

In mijn geval had iedere klant z'n eigen CMS, met eigen backend. Het vervelende was dat de layout enorm met de code verweven was, je voor iedere klant dus een branch (ik was diegene die met CVS aan kwam zetten, daarvoor maakten ze gewoon kopieen) had, en je fixes in iedere branch door moest voeren.

Redenen genoeg in ieder geval om een mooi open source CMS te gebruiken in plaats van eigen gebakken spul.

[creator1988]

Verwijderd schreef op donderdag 10 april 2008 @ 15:29:
ik heb tot nu toe veel tips gekregen..dankjewel hiervoor.
ik ben zelf zo'n 4 jaar met php bezig. Veel geleerd en vind het leuk werk.

Echter wanneer ik nu stukken code zie die bijv. destijds gemaakt zijn.
denk ik toch; tsjah dat kan tegenwoordig(met m'n huidige php kennis) echt veel beter.
Maar ook dit is iets wat elke php'er zal tegenkomen.

Ik zal komende tijd goed nadenken over hoe het zal moeten.

Wanneer jullie aan een project beginnen, brengen jullie dan elke class/functie van het project van te voren in beeld?

Bijv.:

Class PaginaBeheer:
- functie pagina toevoegen
- functie pagina verwijderen
- functie pagina aanpassen
- functie pagina in menu verschuiven(hoger of lager in menu plaatsen.)
- functie pagina als subpagina maken

Okee, wat hieronder komt is waarschijnlijk voor de meesten van jullie bekend, maar omdat ik het idee heb dat TS het nog niet helemaal snapt, hieronder even mijn visie op bovenstaande.

Bij ons werken we gewoon volgens een vast stramien (wat ik meestal bij de wat grotere ontwikkelbureau's vind) en ook een methodiek die volgens mij iedere zelfrespecterende programmeur zou moeten gebruiken als ze bezig gaan met OO.

BusinessEntityLayer <-> Managementlayer <-> Presentation layer

Als je dat aanhoudt, kan je de helft van wat je nu vooraf zou willen bedenken al weglaten. Omdat een groot deel van je code direct duidelijk is.

Wij starten met het databasemodel (na functioneel en technisch ontwerp), daarna ontwerpen we de business-entity-layer: hierin staan je objecten (classes) zoals Page, User, Newsitem, whatever. Deze objecten zijn in 95% van de gevallen rechstreekse afspiegelingen van je datatables (je tabel tblPages heeft als cellen 'Name', 'Description' dan heeft je entity Page ook Name en Description als Property).

Vervolgens schrijf je in je managementlayer je translatie van entity naar database en andersom. Dus functies als PersistPage, RetrievePages, RetrievePageByID; deze retouneren altijd objecten van het type Page en verwachten dat ook altijd als input; een set translation classes kan deze dan weer omzetten naar datarow's etc. Hou dit altijd generiek, en ga geen dubbele functies schrijven (zoals PaginaToevoegen, en PaginaBijwerken; laat dat in je Managementlayer uitzoeken; je wilt namelijk zo min mogelijk businesslogic aan de frontend).

Ook moet je niet andere objecten gaan afhandelen in je PageManagement; dingen als omhoog/omlaag verschuiven in je menu moet je gaan doen in je MenuManagement; (met een tree als input/output ofzo en een PersistMenu functie om de wijzigingen weg te schrijven). De items in de tree zou je dan wel weer met functies als MoveUp en MoveDown kunnen uitrusten. Gebruik ook geen functie om een pagina een subpagina van een andere te maken; dat is namelijk geen eigenschap van een Page; gebruik hier dan je menu voor, of een andere business-entity.

Hierna kan je de presentatielaag schrijven, dus bijvoorbeeld je CMS; hierin zit geen (nauwelijks) logic, maar bevat alleen maar dingen als PersistPage(depagedieikaanhetbewerkenben) en RetrieveAllPages etc. Logic en database-afhandeling zitten dus nooit in je frontend.

My 2 cents; let op waar je verschillende dingen neerzet. Ga niet twee types door elkaar halen door menuhandling in je pagemanagement af te gaan vangen, etcetera. Hou het simpel en generiek; dan hoef je over 50% van je code niet meer na te denken!