[PHP] project management (dbase structuur, files, classes)

[BikkelZ]

Ik krijg op mijn werk de kans om een redelijk groot systeem vanaf de grond af aan opnieuw op te bouwen, wat voor mij een unieke kans is om eens een wat groter project helemaal *goed* vanaf nul gestructureerd op te bouwen (itt sommige dingen die hier draaien, buiten het feit of ze wel of niet goed geschreven zijn).

Omdat ik niet helemaal alleen er aan ga werken, en omdat ik of degene die het ooit over gaat namen er achteraf weer makkelijk in moeten kunnen duiken, moet het allemaal gewoon netjes 'op papier staan' en gedocumenteerd zijn.

Ik zoek een of een aantal programma's die het volgende kunnen voor PHP/MySQL:

- Overzicht maken van de MySQL databasestructuur
- Overzicht van de PHP files, classes en functies en het commentaar daar bij
- Een ToDo lijst mede aan de hand van het vorige punt
- Waar meerdere personen tegelijk aan kunnen werken
- (als het kan) makkelijk een testparcour maken adhv de functies

Ik heb even gezocht, kon zo gauw nog geen topic een vinden met deze strekking. Ik weet wel dat er voor andere talen tools of combinaties van tools zijn om dit soort dingen te doen.

[Michali]

Ik zou dan sowieso aan een versioning systeem gaan denken, zoals CVS of Subversion. Daarnaast is het ook aan te raden om eens naar PHPDoc te kijken. Zend Studio (een IDE voor php) heeft daar ook standaard support voor en bestaan ook tools om zo een overzicht van alle classes en functie uit de source te trekken.

Verder kwa werkwijze enzo kan ik je weinig tips geven. Je zou kunnen denken aan een bepaald proces (zoals het Relational Unified Process), maar het ligt er maar aan hoe ver je daar in wilt gaan en of het goed bij het project past.

[NMe]

BikkelZ schreef op zondag 27 november 2005 @ 12:57:
- Overzicht maken van de MySQL databasestructuur

Dat behoor je zelf te doen, vòòr je die structuur daadwerkelijk in MySQL implementeert. Even een ERD-tje, een LGS-je en een eventueel data dictionary maken vooraf en je bent er al. Als je eerst een database gaat implementeren en daarna pas gaat documenteren dan ben je verkeerd om bezig en loop je geheid tegen dingen aan waar je van tevoren niet over nagedacht hebt.

- Overzicht van de PHP files, classes en functies en het commentaar daar bij

Zend Encoder kan dit inderdaad. PHPDoc weet ik niet, die ken ik niet. Maar ook hier geldt weer: je classes hoor je van tevoren te ontwerpen. Teken voordat je begint eerst een klassendiagram, en loop goed na of wat je wil ook te implementeren valt in PHP. Doe het andersom en je loopt gegarandeerd weer tegen dingen aan die je niet voorzien had.

- Een ToDo lijst mede aan de hand van het vorige punt

Zend Studio weer.

- Waar meerdere personen tegelijk aan kunnen werken

Versiecontrole. Subversion is een pakket waar ik zelf redelijk ervaring mee heb inmiddels, maar er zijn vele andere pakketten die je kan gebruiken.

- (als het kan) makkelijk een testparcour maken adhv de functies

Testplannen maken kun je toch echt beter zelf doen. Een programma kan niet voor je debuggen, en een programma weet niet wat je al dan niet met die functie wil gaan doen. Een deel van de fouten zou je er wel op zo'n manier uit kunnen halen, maar achteraf moet je toch nog steeds je eigen testplan doorlopen.

[Verwijderd]

Ik gebruik deze tegenwoordig voor DB design (kan ook reverse engineren),
is gratis (wordt wel niet meer onderhouden, maker is aangenomen om commercieele versie te bouwen).

http://www.fabforce.net/dbdesigner4/

[Johnny]

Er bestaan al een heleboel project management oplossingen voor PHP. Een bestaand systeem gebruiken is vaak van betere kwaliteit, sneller, goedkoper en makkelijker om met meerdere aan te werken.

[BikkelZ]

-NMe- schreef op zondag 27 november 2005 @ 13:35:

Dat behoor je zelf te doen, vòòr je die structuur daadwerkelijk in MySQL implementeert. Even een ERD-tje, een LGS-je en een eventueel data dictionary maken vooraf en je bent er al. Als je eerst een database gaat implementeren en daarna pas gaat documenteren dan ben je verkeerd om bezig en loop je geheid tegen dingen aan waar je van tevoren niet over nagedacht hebt.

Natuurlijk wordt de hele database eerst ontworpen voordat ik hem ga maken, niet omgekeerd. Anders zou ik het ook niet over planmatig werken hebben Er staat al een database met gegevens, maar die wil ik eigenlijk compleet negeren bij het ontwerp, en pas later kijken hoe ik die over ga zetten, omdat ik anders altijd fouten uit die database mee ga nemen.

Ik kan hem wel gaan tekenen, maar in principe is een grafische tool veel beter, makkelijker te reproduceren, beter te lezen, ga zo maar door. Eventueel zelfs in staat om van dit diagram een database(structuur) aan te maken, scheelt weer een hoop klik en typwerk. Daar duidde ik eigenlijk op met mijn vraag.

-NMe- schreef op zondag 27 november 2005 @ 13:35:
Zend Encoder kan dit inderdaad. PHPDoc weet ik niet, die ken ik niet. Maar ook hier geldt weer: je classes hoor je van tevoren te ontwerpen. Teken voordat je begint eerst een klassendiagram, en loop goed na of wat je wil ook te implementeren valt in PHP. Doe het andersom en je loopt gegarandeerd weer tegen dingen aan die je niet voorzien had.

Zend Studio weer.

Versiecontrole. Subversion is een pakket waar ik zelf redelijk ervaring mee heb inmiddels, maar er zijn vele andere pakketten die je kan gebruiken.

Ik zie dat Zend nu adverteert op de voorpagina met Subversion integratie, dus dat komt helemaal goed Maar is het ook een oplossing om van een UML-achtig diagram naar 'lege' files, classes en functies te gaan? (ik weet dat ik beter eerst even alles goed op de Zend pagina door kan lezen )

-NMe- schreef op zondag 27 november 2005 @ 13:35:Testplannen maken kun je toch echt beter zelf doen. Een programma kan niet voor je debuggen, en een programma weet niet wat je al dan niet met die functie wil gaan doen. Een deel van de fouten zou je er wel op zo'n manier uit kunnen halen, maar achteraf moet je toch nog steeds je eigen testplan doorlopen.

Nee maar aan de andere kant is het wel weer makkelijk om een overzicht van functies te hebben, en aan de hand van wat je zelf weet, daar per functie een of meerdere testcases voor te kunnen bedenken. Maar dat is nog wel te doen in de gewone documentatie, an sich.

(het klinkt misschien alsof ik een beetje lui ben, maar door overzicht te maken en vanuit dat overzicht direct weer het een en ander te genereren, weet je wel zeker dat je niets over slaat)