Verbeteringsproject, hoe aanpakken?

[Lantash]

Ik ben bezig met een project waarbij ik een bestaand systeem moet aanpassen.
Mijn voorganger heeft alles niet zo netjes gedocumenteerd en het is een beetje snel en slordig opgezet, omdat hij maar een half jaar had voor een vrij fors systeem. Het bedrijf waar ik zit is redelijk groot en internationaal, dus het moet wel een beetje onderbouwd zijn, voordat het wordt gebruikt buiten deze locatie.

Nu ben ik dus (1 persoon) gevraagd om het systeem bugvrij te maken en uit te breiden. Maar mijn vraag is:
- Hoe documenteer je zoiets?
- Wat voor ontwikkelmethode kan je hiervoor het best gebruiken? Ik dacht aan een agile methode, aangezien dat niet focust op die-hard programmeren, maar welke specifieke is dan het best?
- Is het handig om opnieuw requirements op te stellen? Of is het slimmer om change requests oid. te maken?
- Hoe kan je een systeem testen waarvoor amper (10 van de +- 1000 functies) unit tests zijn geschreven?

Graag ook vermelden of je zoiets zelf eerder hebt gedaan

[labee]

Je kan prima testen zonder Unit tests.
Is het de bedoeling dat jij gaat testen? Of moet je de gevonden bugs oplossen.

- Stap 0 maak je opdrachtgever ervan bewust dat documentatie schrijven tijd kost (en noodzakelijk is).
- Stap 1 wordt functioneel bekend met het systeem. (Domein kennis)
- Stap 2 wordt op hooflijnen bekend met het systeem. (weet welke modules, classes etc.) En documenteer dat ook voor jezelf en de toekomst.

- Stap 3 Begin, vraag om duidelijke issues / bugs. Waar ze zitten en hoe ze te reproduceren zijn. En los alvast een aantal ("eenvoudige") punten op.

- Stap 4 Nu je een beter bekend met de applicatie bent weet je waar de pijnpunten zitten en kun je ingrijpendere wijzigingen doorvoeren.

[Rutal]

Ik heb afgelopen kwartaal juist een vak op de universiteit afgesloten wat hier over ging: software re-engineering.

Daarbij werd verwezen naar een handig boek dat je kan helpen bij je taak:
Object-Oriented Reengineering Patterns van Serge Demeyer, Stéphane Ducasse en Oscar Nierstrasz.
Het boek is beschikbaar onder de Creative Commons Attribution-ShareAlike 3.0 license en te vinden op http://scg.unibe.ch/download/oorp/.
Het is best een fors boek met goede guidelines die je zullen helpen met het re-engineren.

• Part I van het boek is een goede introductie.
• Part II beschrijft het reverse engineering proces: Hoe raak je bekend met het systeem? Wat is belangrijk om te weten voordat je daadwerkelijk code gaat kloppen? En hoe beslis je nu welke problemen echt belangrijk zijn om aan te pakken?
• Part III beschrijft het daadwerkelijk re-engineeren. Tests schrijven die de functionaliteit vastleggen die je wilt behouden bij het refactoren. Hoe krijg je de users zover dat ze jouw werk willen testen.

Ik (en het boek) wil graag benadrukken dat juist het schrijven van unit-tests een MUST is! Hiermee garandeer je dat er geen functionaliteit verloren gaat en uiteindelijk een betere applicatie aflevert!
Natuurlijk zitten er wel wat haken en ogen aan omdat je waarschijnlijk niet oneindig lang hieraan mag werken... Het kiezen van de prioriteiten wordt besproken in Part II.

Afhankelijke van de programeer taal die je gebruikt zijn er een hoop tools te vinden die je code checken op potentiele bugs, duplicate code blocks en andere mis-designs.

[GSteven]

Ook handig: Bewijs iedere bug die je wilt fixen met een unit test. :-)

[MaxxMark]

Misschien ietwat buiten je scope... Maar waar ik meestal mee begin is kijken naar hoe men werkt en dit vastleggen. Een coding standaard vastleggen als die er (nog) niet is. En de diverse procesgangen beschrijven die van toepassing zijn.

Uiteraard is het hier misschien iets minder van toepassing (omdat er maar 1 persoon aan gewerkt heeft). Maar het vastleggen van een coding standard is in mijn ogen erg belangrijk. Zeker als er op termijn meerdere of andere mensen aan gaan werken.

Verder kan het best zijn dat de procesgangen niet zo heel erg groot zijn (denk aan: hoe worden veranderingen opgeslagen? Is er een repository? wanneer maak je tags? branches? hoe wordt er een versie gereleased? is er verschil tussen development en productie omgeving?). Dan nog zou ik het vast leggen. Al is het maar 3 regels die zeggen "Als je released stuur je een mailtje naar persoon X en Y".

Door deze 2 stappen te doen heb je al een aardig idee van hoe de code in het algemeen in elkaar zit.

Daarna pas echt de code in duiken. Kijken hoe het werkt, waar zitten de knelpunten, wat zijn mogelijke oplossingen voor deze knelpunten, wat zijn concrete eisen van gebruikers/belanghebbenden mbt de code/functionaliteit, hoe hebben deze invloed op het systeem.

Probeer ook bij het verbeteren van het gehele systeem de problemen op te delen in kleinere stukken. Maak niet 1 grote lijst van bugs/features/etc die opgelost moeten worden, want dan word je gillend gek. Bepaal wat je in een nieuwe release gaat oplossen. Probeer dan in eerste instantie te richten op een release die je in 1 week denkt te kunnen releasen (bijv een lijst (of de eerste 10 van die lijst) van de meest kritieke bugs). Mocht je meer tijd nodig hebben, maak de lijst dan kleiner, mocht het minder zijn, maak hem groter. Uiteraard kan (moet?) je soms spelen met de tijd want een bepaalde feature zou minimaal 2 weken kunnen duren. Maar zorg in ieder geval dat het afgebakend is. Hiermee zorg je dat je voor jezelf ziet dat je voortgang maakt (of juist niet). Plan vooruit (al zal dat misschien niet zo ver kunnen omdat je het systeem niet kent) en laat de mensen om je heen weten wat je doet en dat ze op tijd weten dat er een release is waar eventueel iets mee gedaan moet worden (testen?).

In ieder geval: Heel veel succes

[Verwijderd]

Lantash schreef op vrijdag 30 oktober 2009 @ 14:21:
- Hoe documenteer je zoiets?

Ik vind literate programming een mooie manier van documenteren. Ik heb er alleen geen ervaring mee in samenhang met grote projecten of in een professionele omgeving. (Hobbyist, he )

[Valkske]

Ik denk niet dat er veel verschil zit tussen een verbeteringsproject en een nieuw project wat betreft documentatie, versiecontrole, project management,...

Je zegt dat je als 1 persoon het hele systeem moet bugvrij maken en uitbreiden? Dat kan toch niet. Je moet je opdrachtgever of de gebruikers van het systeem toch betrekken bij het project? Vraag hen vooraf om duidelijke requirements en laat hen functionele specificaties goedkeuren. Vraag ook aan hen om voldoende tijd te nemen om beta releases te testen en duidelijke en gedetailleerde bug reports (laten) opmaken van gekende bugs.