Toon posts:

[Alg] Van scratch programmeren of niet?*

Pagina: 1
Acties:

Verwijderd

Topicstarter
Ik zou hier graag een vraag/stelling willen deponeren.

Stel: Je wordt gevraagd om een bestaande applicatie uit te breiden.

Wanneer, maar vooral hoe, maak je de keuze om de applicatie van de grond af aan opnieuw op te bouwen of om de bestaande code te gebruiken en deze uit te breiden?

Beide opties hebben hun voors en hun tegens. Bestaande code kan lastig zijn om te lezen, of slecht opgezet... Van scratch kan betekenen dat je langer bezig bent... Of niet?

  • X-Lars
  • Registratie: Januari 2004
  • Niet online

X-Lars

Just GoT it.

Dat ligt helemaal aan de situatie. Heb je de bestaande applicatie zelf geschreven? Staan er veel dingen in de bestaande applicatie die niet meer nodig zijn? Hoe groot is de bestaande applicatie? Zit de bestaande applicatie al goed in elkaar? etc. etc.

  • sjroorda
  • Registratie: December 2001
  • Laatst online: 08:33
Dit zal onder andere te maken hebben met factoren als grootte, documentatie, complexiteit van het programma, etc.. Daarnaast is het natuurlijk ook heel belangrijk of het originele programma 'uitbreidbaar' is opgezet of dat het zo slecht in elkaar hangt dat elk lettertje erbij een onherroepelijke crash betekent (eigen ervaring, ben tegenwoordig gelukkig een stuk gestructureerder bezig >:))

@X-Lars: wow, da's wel heel letterlijk 2 zielen 1 gedachte ;)

[ Voor 10% gewijzigd door sjroorda op 29-01-2004 10:53 ]


  • P_de_B
  • Registratie: Juli 2003
  • Niet online
Things you should never do van Joel Spolsky

Oops! Google Chrome could not find www.rijks%20museum.nl


  • ripexx
  • Registratie: Juli 2002
  • Laatst online: 00:04

ripexx

bibs

Verwijderd schreef op 29 januari 2004 @ 10:49:
Ik zou hier graag een vraag/stelling willen deponeren.

Stel: Je wordt gevraagd om een bestaande applicatie uit te breiden.

Wanneer, maar vooral hoe, maak je de keuze om de applicatie van de grond af aan opnieuw op te bouwen of om de bestaande code te gebruiken en deze uit te breiden?

Beide opties hebben hun voors en hun tegens. Bestaande code kan lastig zijn om te lezen, of slecht opgezet... Van scratch kan betekenen dat je langer bezig bent... Of niet?
Het is natuurlijk compleet afhankelijk van wat je moet doen. Als je een module of onderdeel moet aanpassen dan begin je niet van scratch, maar als je een complete make over moet doen en dingen in de core moet aanpassen, dan is het soms handiger om van scratch te beginnen.

Het blijft een inschatting en je moet gewoon goed afwegen wat het beste is. Voor mijn CMS heb ik ook besloten dat een uitbreiding niet handig was. Een ander rechtensysteem was vereist en de verschillende modules zijn ook verder ontwikkeld. Gevolg gewoon van scratch beginnen. :)

buit is binnen sukkel


  • Reptile209
  • Registratie: Juni 2001
  • Laatst online: 09:25

Reptile209

- gers -

Ja, precies :).
Bestaande code gebruiken:
Tegen
* Lastiger inlezen
* Geen/onduidelijk commentaar
* Geen keuze in de programmeertaal
* Wellicht conflicten tussen de nieuwe en de bestaande code
Voor:
* Gebruikers zijn er aan gewend
* Specificaties zijn al geimplementeerd
* Minder tijd nodig voor een uitbreiding (als je mazzel hebt)

Nieuwe code schrijven from scratch:
Tegen:
* Specificaties formuleren
* Ontwerp maken
* Gebruikers opnieuw inwerken
* Documentatie maken
* Taal kiezen
* Waarschijnlijk (veel) meer werk
* etc.
Voor:
* Taal kiezen :)
* De goeie ouwe fouten er eindelijk uithalen (en nieuwe maken...)
* Beter overzicht

Dus je kan opnieuw beginnen, of niet. Het hangt volgens mij van serieus veel factoren af. En dat is dan ook precies de reden waarom bijvoorbeeld in controle-ruimtes van chemische installaties echt serieus oude software + hardware wordt gebruikt. Het is er eenmaal, en dan is onderhouden met de middelen die je hebt vaak de weg van de minste weerstand.

Zo scherp als een voetbal!


  • OZ-Gump
  • Registratie: November 2002
  • Laatst online: 14-05-2024

OZ-Gump

terug van weggeweest

Er zijn mijns inziens wel een aantal criteria die je los kunt laten op het project waardoor je de keuze kunt verdedigen:
  1. Is de basis van het systeem breed genoeg om de uitbreidingen te dragen*
  2. Is de bestaande code leesbaar, bruikbaar en natuurlijk, uitbreidbaar
  3. Is de coding style van de vorige programmeur duidelijk te begrijpen
  4. Heeft het huidige systeem veel bugs/verbeterpunten
  5. Wat zegt je gevoel ;)
Volgens mij moet je met deze punten en een beetje gut-feeling een heel eind kunnen komen ;)

Good luck! (en laat ons even weten wat het geworden is ;) )

* Hiermee bedoel ik dat, wanneer je een muur gaat bouwen, je niet de onderste laag drie stenen breed moet maken, om vervolgens per laag twee stenen breder te willen. Je muur wordt dan uiteindelijk topzwaar en zal bij het minste of gerinste omvallen. Zo moet je ook naar je software kijken: is de basis vanhet systeem breed genoeg om deze uitbreidingen te dragen?

My personal website


Verwijderd

En dan is er nog de menselijke factor: JIJ wilt het dolgraag opnieuw bouwen, en geen van de fouten die de vorige programmeur gemaakt heeft zelf maken (integendeel, jij wilt juist je eigen fouten maken!), maar je projectleider zal altijd denken dat uitbreiding goedkoper is dan opnieuwbouw. Ook als het echt beter is.

  • pkouwer
  • Registratie: November 2001
  • Laatst online: 07-10-2025
hangt ook een beetje af wat de opdrachtgever er van zou vinden als je opnieuw zou gaan beginnen. Hij/zij moet tijd/geld investeren. Ik zou ook met hun overleggen

Verwijderd

Topicstarter
Ok... Een kleine uitbreiding op het verhaal.

* De applicatie is geschreven in JAVA (Ook taal van keuze bij van scratch proggen).
* De code ziet er netjes uit...
* De NIAM objecten in de hierarchie (het gaat om een NIAM Editor) zijn tekentechnisch opgezet en niet naar de NIAM hierarchie.

Wat te doen? Consistentie controles toevoegen voor het tekenen van ISD's.

Verwijderd

Topicstarter
OZ-Gump schreef op 29 januari 2004 @ 10:57:
Er zijn mijns inziens wel een aantal criteria die je los kunt laten op het project waardoor je de keuze kunt verdedigen:
  1. Is de basis van het systeem breed genoeg om de uitbreidingen te dragen*
  2. Is de bestaande code leesbaar, bruikbaar en natuurlijk, uitbreidbaar
  3. Is de coding style van de vorige programmeur duidelijk te begrijpen
  4. Heeft het huidige systeem veel bugs/verbeterpunten
  5. Wat zegt je gevoel ;)
Volgens mij moet je met deze punten en een beetje gut-feeling een heel eind kunnen komen ;)

Good luck! (en laat ons even weten wat het geworden is ;) )

* Hiermee bedoel ik dat, wanneer je een muur gaat bouwen, je niet de onderste laag drie stenen breed moet maken, om vervolgens per laag twee stenen breder te willen. Je muur wordt dan uiteindelijk topzwaar en zal bij het minste of gerinste omvallen. Zo moet je ook naar je software kijken: is de basis vanhet systeem breed genoeg om deze uitbreidingen te dragen?
De opdracht hebben we opzich al gedaan. We hebben de bestaande code gebruikt, maar we zijn er op een gegeven moment achter gekomen dat we wel heel veel moesten veranderen. Nu moeten we voor school een presentatie geven. Een van de punten die we willen bespreken is wanneer je de keuze maakt om opnieuw te beginnen... We willen daarbij kritisch stilstaan ten opzichte van onze eigen keuze en kijken of we wel de goede keuze gemaakt hebben.

  • OZ-Gump
  • Registratie: November 2002
  • Laatst online: 14-05-2024

OZ-Gump

terug van weggeweest

Dan lijkt het me verstandig om eens naar je beslissing te kijken, en te kijken naar de verschilende punten die hier zijn aangegeven, en die nu nog eens los te laten op het project (met in je achterhoofd alles wat je bent tegengekomen). Welke beslissing zou je nemen als je die nu opnieuw werd voorgelegd...?

My personal website


Verwijderd

Topicstarter
OZ-Gump schreef op 29 januari 2004 @ 11:08:
Dan lijkt het me verstandig om eens naar je beslissing te kijken, en te kijken naar de verschilende punten die hier zijn aangegeven, en die nu nog eens los te laten op het project (met in je achterhoofd alles wat je bent tegengekomen). Welke beslissing zou je nemen als je die nu opnieuw werd voorgelegd...?
We zijn zelf tot de conclusie gekomen dat het misschien handiger was geweest om van scratch te beginnen. Maar in de presentatie willen niet alleen kijken naar ons eigen probleem, maar ook naar de keuze in het algemeen.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Als de code echt slecht is opgezet, te slecht om gerefactored te worden, dan zit er volgens mij niet veel anders op. Maar volgens mij kan je in de slechtste systemen nog wel weer structuur aanbrengen, de vraag is natuurlijk hoeveel tijd het gaat kosten tov from scratch alles opzetten.

Als je alleen een paar features hoeft toe te voegen, dan zou ik persoonlijk gaan voor het aanpassen en niet voor from scratch alles opnieuw opzetten. De gebruiker is alleen maar geinteresseerd of het werkt, en niet of alles met ductape en pritt in elkaar is gezet.

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Het hangt er vanaf hoe die applicatie opgezet is. Als de applicatie goed is opgezet, betekent dit dat het eigenlijk een systeem van op zichzelfde staan componenten/tools zijn die allemaal slechts 1 ding doen. Al deze componenten moeten redelijk overzichtelijk geimplementeerd zijn: als 1 menselijk brein het niet meer kan bevatten is het geen goed componenten. Als een systeem zo opgezet is, is er een regel die voortkomt uit de klassieke Unix flosofie uit de jaren 70:
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
The Art of Unix Programming, Basics of the Unix Philosophy.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


  • freezer
  • Registratie: Augustus 2000
  • Laatst online: 08-02 20:00

freezer

er komt geen end 'an

Alvorens te beginnen zul je inderdaad moet beoordelen of het uitbreiden cq aanpassen mogelijk is.

Maak voor beide opties een projectplanning waardoor je opdrachtgever weet wat hem te wachten staat.

Een zorgvuldige projectplanning dwingt je namelijk ook om beide alternatieven goed te onderzoeken waardoor je meteen een goede start maakt. Voordenken is namelijk beter dan nadenken.

Veel succes.

;)

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:40
Een applicatie herschrijven met als argument dat de taal waarin die applicatie is geschreven je niet aanstaat, is wmb een non-argument.

Een aantal belangrijke punten die moeten overwogen worden zijn, IMO:

- in hoeverre voldoet de bestaande applicatie qua functionaliteit aan de gebruikerseisen, is de huidige logica nog juist? Hoe complex is de bestaande / reeds geimplementeerde Business Logic?
Als de applicatie in tiers is opgebouwd, en de business logica laag voldoet aan de eisen, dan zou je gek zijn als je die code volledig herschrijft ipv ze uit te breiden.
- hoe 'buggy' is de applicatie
- Wat is de kost (in tijd en geld) om van scratch opnieuw te beginnen?

Als de code echt bagger is, kan je ook kijken of je de bestaande code niet beter stap voor stap kunt refactoren ipv helemaal opnieuw te beginnen.

https://fgheysels.github.io/


  • riezebosch
  • Registratie: Oktober 2001
  • Laatst online: 21-05 20:13
Erg leuk artikel :9 Heb zelf keer meegemaakt dat door installatie van Windows ME over Windows XP heen (C was NTFS), hij ook gelijk al m'n partities even weggooide. Ik was toen bezig met een projectje, en had in no-time deze weer helemaal opgebouwd en dan nog beter dan de eerste keer. Omdat ik alles als in m'n hoofd had zitten, er nu opnieuw over na moest denken en opeen logischer kon rangschikken.

Maar ik moet toegeven, ik zie in dat artikel wel in dat herstructuren vaak een goede oplossing zal zijn.

[ Voor 64% gewijzigd door riezebosch op 29-01-2004 12:08 ]

Canon EOS 400D + 18-55mm F3.5-5.6 + 50mm F1.8 II + 24-105 F4L + 430EX Speedlite + Crumpler Pretty Boy Back Pack


  • riezebosch
  • Registratie: Oktober 2001
  • Laatst online: 21-05 20:13
edit:

shit, quote ipv edit

[ Voor 96% gewijzigd door riezebosch op 29-01-2004 12:07 ]

Canon EOS 400D + 18-55mm F3.5-5.6 + 50mm F1.8 II + 24-105 F4L + 430EX Speedlite + Crumpler Pretty Boy Back Pack

Pagina: 1