Page 1 of 2 1 2 LastLast
Results 1 to 15 of 30

Thread: Zwaar dilemma

  1. #1

    Zwaar dilemma

    Hallo iedereen,

    Ik zit al vele maanden met een zwaar dilemma zoals de titel het al zegt. De meesten kennen de situatie wel: een applicatie die al 20 jaar in ontwikkeling is, ERP pakket, ongeveer 300 klanten, er wordt nog steeds nieuwe functionaliteit bij geprogrammeerd, enz...
    Probleem dat zich stelt is een veel voorkomend iets. Er hebben hier al wat programmeurs gewerkt. De ene werkte al meer netjes dan de andere. Sommigen waren een echte ramp. "Fast en dirty" code overal rond. Zo krijg je op termijn en zeker na al die jaren een vuil boeltje. Idem wat de database betreft. Sommige mensen maakten niet eens een primary key aan, wat tabelnamen/veldnamen betreft, iedereen had zijn eigen stijl en deed maar zijn zin. NULL / NOT NULL, maakte allemaal niet uit, Foreign Keys?? Wat is dat, was het voor velen?? En zo gaat het zootje maar door. Lang verhaal kort: zowel de applicatie als de DB zijn op vele plaatsen echt niet ok. En wat me nog het meeste stoort is dat vele programmeurs niet eens bereid zijn om code te schrijven die mooi uitgelijnd is, die netjes is en leesbaar. Als de form er maar mooi uitziet, de rest is niet belangrijk.

    Om ter zake te komen: Ik zit al een hele tijd erover na te denken om zowel de applicatie als de DB te her-ontwerpen. Ik zou afstappen van Firebird en PostgreSQL gaan gebruiken. (Met FB hebben we nogal wat corrupties de laatste jaren. Is dat een goed idee? Enige kritiek hierrond is zeker welkom). En ook een rewrite van de applicatie. Om even toe te lichten, er zitten veel 'kleine forms' in die snel om te bouwen zijn, maar er zitten ook heel wat forms in met heel wat meer werk aan (20.000 - 30.000 regels code per form). Heel wat forms, heel wat datamodules. Het is een uitgebreid ERP pakket. Ik vraag me af of ik me daarmee niet op zeer glad ijs zal begeven? Want je mag nog zo goed je best doen en geconcentreerd werken, we weten allemaal dat bij een rewrite er bugs zullen geïntroduceerd worden. Ik weet niet zo goed wat ermee gedaan, laten zoals het is, of....

    Geen idee of er mensen zijn die zich herkennen in deze situatie?

    Dank en groeten !
    Last edited by stevedeclerck; 12-Feb-19 at 16:08.

  2. #2
    *+E13818MU01F0F* Norrit's Avatar
    Join Date
    Aug 2001
    Location
    Landgraaf
    Posts
    967
    Het is eigenlijk een simpele kosten-baten analyse

    Hoe lang kost het je om dit opnieuw op te zetten (inclusief testtijd enz...). Dan, krijg je de tijd van de baas hiervoor?
    Hangt er dus vanaf of de opbrengsten van dit pakket dit rechtvaardigen.
    Zo nee, dan is en blijft het pleistertjes plakken.

    En ja, rewrite is altijd glad ijs. Heb je wel mooi de mogelijkheid meteen unit-testing in te bouwen (om er maar een positieve draai aan te geven, maar ook dat kost tijd)
    Verder vind ik de keuze voor PostgreSQL een heel bijzondere, maar dat laat ik in het midden. Je zal er wel ervaring mee hebben de keuze goed weten te motiveren/verantwoorden.
    En schermen met 30.000 regels code? Denk dat iemand hier toch ergens de plank mis geslagen heeft. Een scherm is een scherm, 30.000 regels code om dat scherm goed te laten werken is wel heel erg veel. Ik kan me alleen maar voorstellen dat daar iemand business logica in de schermen aan het stoppen geweest is.

    Wat ik in dit geval eerder zou doen is per functionaliteit kijken of het niet herschreven moet worden. Dus als je weer een bug ergens moet oplossen dit gewoon op de correcte manier oplossen (begin dan meteen met unit-testjes te schrijven). Zo kost bugs oplossen wel meer tijd, maar uiteindelijk wordt het product weer beheersbaar. Dit is veel beter te verantwoorden dan een heel jaar (om maar iets te noemen) te werken aan iets waarvan de eindgebruiker niet eens ziet dat je daar je tijd in gestoken hebt.
    En het is dat hele jaar dubbelop je werk doen, want de bugs zullen nog steeds in je oude pakket eruit gehaald moeten worden.

    En als je dan toch besluit om een rewrite te doen zou ik eerst een functionele eisenlijst opstellen. En op basis daarvan gaan bouwen. In ieder geval niet blind een kopie van je oude applicatie, want dat is vrij zinloos (je raakt blind en neemt dezelfde krommiteiten over). Dus op basis van de functionele eisen je database model opbouwen en daar je applicatie omheen bouwen. Dat kan per functionele eis, dus je hoeft niet in 1 keer je complete database model klaar te zetten.
    Objective reality is a delirium caused by lack of alcohol in blood

  3. #3
    Welkom op het NLDelphi forum.

    Quote Originally Posted by stevedeclerck View Post
    Ik zou afstappen van Firebird en PostgreSQL gaan gebruiken. (Met FB hebben we nogal wat corrupties de laatste jaren. Is dat een goed idee? Enige kritiek hierrond is zeker welkom).
    Ik werk met heel wat Firebird installaties en heb eigenlijk nooit corruptie. In de afgelopen 15 jaar is dat alleen 2 of 3 keer voorgekomen toen ook de harde schrijf echt gecrasht was. Maar dat zul je dan met PostgreSQL ook wel hebben.

    Als je geleidelijk gaat herschrijven zul je versie-beheer in de database aan moeten brengen (als dat nog niet het geval is). Als er dan een update geladen wordt, moet gezien worden welke aanpassingen je aan de bestaande database moet doen. Bij een complete rewrite en/of overstap naar PostgreSQL (of iets anders) is dat niet nodig maar dan moet je een eenmalige conversie-tool schrijven.

    Bij het geleidelijk herschrijven kun je natuurlijk beginnen met het aanleggen van Foreign keys, opkuisen van NULL/NOT NULL en wijzigen van velden e.d. Ook kun je de 'simpele' forms al aanpakken. Als het mogelijk is zou je dit dan al in productie kunnen nemen bij gebruikers d.m.v. een update.

    Ja, er zullen bugs introduceert worden. Maar dat zal ook gebeuren bij een complete rewrite.

    Een complete rewrite zal ook de nodige tijd in beslag nemen (zonder dat je wat van je wijzigingen ziet). Het voordeel van geleidelijk herschrijven is dat je die wijzigingen dus ook geleidelijk kunt introduceren en dat ze dan ook gelijk getest worden. Dat zal met een complete rewrite niet lukken en dan moet je wachten tot de functionaliteit hetzelfde is als in het oude pakket zit/zat.

  4. #4
    Beste,

    Dank u voor de reacties. Met aandacht gelezen.

    Tja, het meeste zal in mijn eigen tijd moeten gebeuren, geen resources genoeg voor, wat op zich al idioot kan klinken.
    En inderdaad, er zit heel wat logica in de forms zelf.
    Vreemd dat er heel wat minder corrupties zijn. Wij ondervinden het vaak bij DB's > 1-2 Gig.

    Wat me nog opvalt is dat Postgres een bijzondere keuze zou zijn. Ik heb het gebasseerd op het feit dat het een DB is die heel robust zou zijn, ook al heel wat jaren in omloop, heel actieve ontwikkeling nog steeds. Zijn er eventueel bedenkingen bij Postgres die ik misschien over het hoofd zie? (zonder af te dwalen van het topic).

    Dank en groeten

  5. #5
    Ik denk dat het verstandig is om voordat je gaat herschrijven is zorgt dat de zaken op orde zijn, anders ben je binnen de kortste keren weer terug bij af. Robert C. Martin heeft wat boeken/video's gemaakt over clean code, clean architecture e.d. misschien dat je er al mee bekend bent, maar als dat niet het geval is dan is het zeker een aanrader. Er komen zaken aan bod zoals naamgeving, commentaar schrijven, pair programming, code reviews, het schrijven van goede unit tests e.d.

    Zelf gebruik ik al een jaar of 6 Postgres en ik vind het ontzettend fijn werken. Voorheen heb ik ook Firebird gebruikt, maar daar zaten toen nog weinig data types in en was volgens mij niet ACID (Als ik het goed begrijp is dat nu wel het geval)

    Uit je verhaal kan ik niet opmaken wat je relatie is tot het pakket. Als je eigenaar bent dan is het kosten/baten verhaal, als je een werknemer bent dan zou ik zeker niet het initiatief nemen om het te herschrijven. Je moet ook incalculeren dat je voor de 300 klanten een conversie moet gaan uitvoeren van je oude naar je nieuwe database, de helpdesk wat vaker gebeld gaat worden e.d. Een uitgebreid ERP pakket schrijf je niet in een paar honderd uur, tenminste ik niet Ik zou mijn vingers er niet aan branden. Ook lijkt het alsof het nooit prioriteit heeft gehad om de code op te schonen, dus het lijkt me dan ook lastig om zieltjes te winnen binnen het bedrijf.

  6. #6
    Meeste databases zijn tussen de 500MB en 1GB.
    Maar er zijn er toch ook (zeker 10 of 15) die tussen de 1GB en 2GB zitten (met een paar uitschieters daar ver boven).
    En zelf werk ik met een develop-database van 1,9GB.

    Je moet een database natuurlijk wel 'netjes' behandelen. Niet zomaar programma uit de lucht knikkeren (hoewel dat eigenlijk ook geen probleem is) maar zeker ook niet de machine waar het op staat koud uitzetten (terwijl er nog gebruikers in de database zitten).

    Ik neem ook aan dat we het echt hebben over de Firebird Server (in server stand, dus via TCP hostname) en niet over Firebird Embedded. Of dat de database door Firebird Embedded wordt gebruikt op één systeem en als server op de ander. Want dan kun je ook leuke onverwachte resultaten krijgen.

    Zeker als je het in je eigen tijd moet doen dan is een complete rewrite waarschijnlijk buiten bereik. Want daar gaat echt veel werk in zitten (als het om een compleet ERP systeem gaat).

  7. #7
    Hallo,

    Dank opnieuw voor de replies. Ja, het is inderdaad zo, zieltjes winnen binnen het bedrijf is al moeilijk. Hebben het er al vaak over gehad. Het heeft geen prioriteit, klopt, form is mooi, klant ziet de code toch niet, ziet ook de DB niet. Ok, is ook wel waar, maar toch.
    Ik ben geen eigenaar, gewoon teamleader van de programmatie. (programma dateert al van voor mijn tijd). En ja, conversies, helpdesk met problemen. Ik heb ook de indruk dat het vingers branden zal zijn.

    Wat de DB betreft, dat is iets wat soms gebeurt, je moet een update doen bij een klant, sommige gebruikers sluiten niet af op tijd en dan wordt gewoon de firebird service gestopt om ze eruit te 'gooien'. Doe je natuurlijk beter niet, vooral met lopende transacties. Is inderdaad niet de embedded.

    Ah, ik laat het idee maar varen, bedankt voor de reacties en het inzicht.

    Groetjes !

  8. #8
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Is het product ontwikkeld in de tijd van de werkgever. Wat vind deze ervan? Er komt een einde aan de ontwikkeling, omdat er door de bomen geen structuele code gemaakt kan worden.
    Er zijn genoeg kapers aan de kust. Als je wilt dat die 300 klanten nog steeds geld in het laadje gaan stoppen, zal ik kiezen voor een rewrite.
    Echter zal je problemen oplopen met de database. Deze ga je opnieuw opbouwen, wat niet in je huidige programma past.Een nieuwe database is ook een nieuw programma.
    Voordeel van een rewrite is; gebruik maken van nieuwe technologieën. Benno en Luigi zouden je goed kunnen helpen door een n-tier app. op te zetten. Groot voordeel: wijzigen van een database is makkelijker.

    Ik zal het raar vinden om dit in je eigen tijd te doen.
    Delphi is great. Lazarus is more powerfull

  9. #9
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Klinkt me bekend allemaal.
    Herschrijven is geen optie in mijn geval, daar niemand geinteresseerd is in een goede database of goede code.

  10. #10
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Dat is nu het grootste probleem.

    Het werkt, dus waarom zouden we iets veranderen?
    Delphi is great. Lazarus is more powerfull

  11. #11
    Hallo,

    Heb hetzelfde meegemaakt. Oud pakket (begonnen met DOS versie), omgezet naar Windows 16, 32 bits, Web......
    Verschillende trajecten geprobeerd en verschillende uitkomsten gehad.

    Het te lopen risico is in mijn ogen het belangrijkste.
    Een applicatie volledig nieuw schrijven op basis van bestaande functionaliteit levert geen extra omzet op en waarschijnlijk veel problemen.

    Mijn persoonlijke voorkeur gaat uit naar gefaseerde vervanging, zoals Norrit heeft beschreven.
    Gebaseerd op risico minimalisering.
    Klanten zien vrij weinig van je goede bedoelingen. Intern(helpdesk, bouw, ondersteuning) merken veel meer van deze aanpak.
    Wel is het handig om alles in een lijn te krijgen.

    Zelfs de database en het gebruik ervan staat ter discussie.
    Wil je een goed ontworpen database waarbij het model strak in de database vastligt en later moeilijk te wijzigen is.
    - voordeel: veel wordt door de database afgehandeld, applicatie hoeft minder te doen.
    - nadeel: wijzigen van het model wordt op een later tijdstip moeilijker.

    Of is de database alleen een bak waarin je je data opslaat.
    De business logica zorgt voor de juiste verwerking van de data.
    - nadeel: alle regels moeten door de businesslogica worden vastgelegd ipv het database model
    - voordeel: de business logica is later makkelijker te wijzigen dan het datamodel.

    Je keuze wordt voornamelijk bepaald door je database opvoeding en je visie op data.


    Probeer je verbeterpunten zo smart mogelijk te maken. Hierdoor kun je er ook andere meetbare gegevens aan koppelen
    -aantal bugs per release.
    -tijd die nodig voor het oplossen van bugs.
    - hoe snel een klant geholpen kan worden.
    enz...

    Het feit dat je erover nadenkt is een goede zaak. Teveel projecten worden vanuit een leuk ideetje gestart zonder plan met alle gevolgen van dien.
    Helaas is er geen easy fix voor dit verhaal. Elke route is mogelijk en elke route heeft zijn voor en nadelen.

    Alles wat je wilt doen kan ter discussie staan. Zolang je maar voor en tegens afweegt kom je vast tot een goed eind oordeel.
    Met andere woorden ik kan je veel vertellen maar of je er wijzer van wordt is een tweede.

    Succes.
    Software ontwikkelen is en blijft erg leuk!

    Groeten,
    Jos

  12. #12
    Senior Member Wok's Avatar
    Join Date
    Dec 2002
    Location
    Alkmaar
    Posts
    2,085
    Ik blaas regelmatig nieuw leven in een jaren oude applicatie's, domweg omdat ze nauwelijks meer werken in een moderne omgeving.
    Het enige wat de eigenaren willen is dat de applicatie nog door kan werken zonder al te dure investeringen.
    Hoe het er verder uitziet (code, database) is voor hun niet zo interessant, totdat er foutmeldingen gaan komen.
    Dan ineens kan er van alles, want zo stelt men: stel je voor dat we niet verder kunnen en er stagnatie optreed.
    De meeste bazen zijn hetzelfde...... zo lang het weinig kost kan er veel..

    Maar een compleet pakket herschrijven, wow.... denk het niet

    Gr.Peter
    10.4.2, Delphi2010, of Lazarus 2.2.0

  13. #13
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Maar een compleet pakket herschrijven, wow.... denk het niet
    En waarom niet. Als er wordt aangegeven dat de database niet deugt en dat 80% van de code crap is, is het meest zinvolle om opnieuw vanaf het begin te beginnen.
    Het functioneel ontwerp is er. Als je van plan bent de je database structuur in zijn geheel opnieuw wilt herindelen, dan werkt het oude programma niet meer. En helemaal niet als deze volledig is gebouwd op basis van Firebird. Progress is geen firebird, reageert ook anders rn wordt anders benaderd.
    Je wilt niet 'tussen de wal en schip' komen.
    Stevedeclerk heeft al aangegeven om te gaan werken op een andere basis, die van logica.
    Quote Originally Posted by nummer8
    Teveel projecten worden vanuit een leuk ideetje gestart zonder plan met alle gevolgen van dien.
    En dat is hier nu niet het geval. Het ontwerp is er al. Het moet alleen worden verbeterd en dat kan niet op basis van fases.

    Bij de laatste bijeenkomst van Coolblue wilde men ook een andere weg inslaan. Dat is ook gebeurd, maar die logica zat met het werken van het systeem al goed. Er kwam alleen een extra laag er tussen, die de communicatie regelt tussen database en client. Daardoor kunnen zij met de bestaande schermen al heel gouw iets nieuws bouwen (Jos, verbeter mij als ik het niet goed heb gesnapt ).
    Delphi is great. Lazarus is more powerfull

  14. #14
    Senior Member Wok's Avatar
    Join Date
    Dec 2002
    Location
    Alkmaar
    Posts
    2,085
    John, ben ik het wel mee eens.
    Maar de hoeveelheid werk die het genereert is enorm veel, ik ben er van overtuigd dat het resultaat gaat opleveren.
    Maar als ik het goed gelezen komt het meeste werk op de schouders van Steve te rusten, dat is de 'wow' in het herschrijven.
    Maar een goed doordacht plan en ga van start,....

    Peter
    10.4.2, Delphi2010, of Lazarus 2.2.0

  15. #15
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Ik denk dat het verstandigste is zoveel mogelijk binnen de bestaande codebase opruimen en verbeteren. Meestal wordt onderschat wat er met oude codebases mogelijk is. Nieuwe codebases zijn vaak een hele tijd niet productie gereed, en kosten alleen geld , terwijl opruimen in de oude codebases direct lucht kan bieden.

    En zelfs als je later toch besluit aan een nieuwe codebase te beginnen, dan is dat veel concreter, en kan je veel meer van de opgeschoonde oude applicatie overnemen.

    Wat betreft problemen met postgres, er loopt toevallig nu een thread waar ik het enige mij bekende probleem uitgelegd heb:

    https://www.nldelphi.com/showthread....tal-connecties
    Last edited by marcov; 13-Feb-19 at 10:28.

Page 1 of 2 1 2 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •