Page 2 of 2 FirstFirst 1 2
Results 16 to 30 of 30

Thread: Zwaar dilemma

  1. #16
    Dat is waarschijnlijk geen Postgres probleem , maar een Devart Unidac/Kbmmw probleem.

  2. #17
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Wat ik als mogelijkheid aandroeg was wel een postgres probleem. Je loopt in geval van netwerk problemen bij hoge connectie counts (ruwe rekensom : 40000 sockets / 8*60 seconden, dus bij ongeveer 80 transacties/connecties/s) dat je server geen socket meer kan openen.

    Maar goed, de freepascal wereld gebruikt relatief veel postgres, en het staat goed bekend. Ik ben er ooit mee begonnen omdat ik niet x86 (PowerPC) servers had, en firebird toen nog 32-bit x86 only was.

  3. #18
    Ik sluit me helemaal aan bij Norrit. Als ik het zo hoor, zal er geen breed draagvlak voor zijn binnen de organisatie, en er gaat enorm veel werk in zitten. Ik neem aan dat je niet tot je pensioen in je avonduren wilt zitten bouwen aan iets dat nooit live komt.

    Gefaseerd vervangen lijkt me inderdaad het beste. Het klinkt alsof er veel logica in de schermen zelf zit. Dat zal waarschijnlijk ook betekenen dat er veel gekopiëerde functionaliteit is, en dat er mogelijk veel herhaalde logica is (gekopiëerd naar elk scherm dat ongeveer hetzelfde doet). Het lostrekken en (later) centraliseren van die logica is het grootste deel van je uitdaging.

    Wij hebben wat werk en onderzoek gestoken in de mogelijkheid om een lossere koppeling te hebben tussen de database, de logica, en het scherm. Daarmee is nog lang niet de applicatie herschreven, maar in ieder geval hebben we de mogelijkheid om dingen op een betere manier te doen, met gebruikmaking van unit tests, en in het algemeen het hebben van meer gescheiden code die beter te onderhouden is. Die manier van werken kunnen we nu toepassen op nieuwe ontwikkelingen, en af en toe kunnen we ook bestaande schermen aanpakken.

    Dat laatste is niet zomaar een blinde actie. We pakken met name de schermen aan waar veel logica in zit, en waar regelmatig werk aan plaatsvindt. Als je toch iets aan moet passen, is dat een mooi moment om het een stukje beter te maken. Op die manier hebben we misschien een paar procent van onze applicatie herschreven, maar gelukkig wel op zo'n manier dat het niet enorm botst met de oude manier van werken, en vooral die procenten waar het ook direct meerwaarde had, omdat er regelmatig onderhoud op plaatsvindt en/of omdat het belangrijke functionaliteit is. En dat gaat dan ook direct live, zodat eventuele kleine bugs direct kunnen worden opgemerkt en gefikst.

    En het is direct live, dus geen grote release na een jaar met honderden bugs.
    Last edited by GolezTrol; 13-Feb-19 at 09:42.
    1+1=b

  4. #19
    Quote Originally Posted by jkuiper View Post
    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.
    John, je begrijpt het prima. We verschillen alleen van mening. Het woord 'alleen' in bovenstaande quote klinkt volgens mij echt als een under-statement. Verbetering kun je volgens mij prima doen op basis van fases.
    Mijn voorkeur gaat echt uit naar de strategie van Norrit, Marcov, Wok, GolezTrol, enz.

    Maar zoals gezegd je kunt hier dagen over discussieren. (leuk, iets voor de volgende lazarus meet-up).
    Er zijn teveel factoren waar je rekening mee kunt/ moet houden.

    Groeten,
    Jos

  5. #20
    Hallo,

    Het herschrijven van een applicatie kan voor een ondernemer een hel zijn. Als men kijkt naar wat het kan kosten en wat het misschien maar opbrengt dan gebeurd het vaak niet.
    Het mag ook niet onderschat worden wat extra druk dit zal creëren op de programmeurs binnen het bedrijf.
    Het oude pakket zal ongetwijfeld nog ondersteund moeten worden om inkomsten te garanderen. Dit betekent dat de werk druk zelf dubbel zo hoog kan komen te liggen.

    Bij mijn bedrijf zitten we in het zelfde probleem. Het pakket is slecht ontworpen, te veel spaghetti code, noem maar op. Langs de andere kant, het pakket doet wat het moet.
    Toch hebben we als bedrijf besloten om de volledige applicatie van 0 af te herontwerpen. inclusief markt onderzoek/business analyse/...

    Hier onder vind u een opsomming van punten die doorslag gaven om een nieuwe applicatie te schrijven.
    1)Os compatibiliteit.(gebruik van oude componenten, door slechte implementatie bijna onmogelijk te vervangen)
    2)Performance issues db(geen indexen, verkeerde indexen,meer kolomen dan in 1 tabel dan je kunt tellen,..)
    3)schaalbaarheid(door db ontwerp, maar ook door applicatie opzet hebben we enorme resources nodig om slechts een 200 tal bedrijven te kunnen bedienen)
    3.1)Opstart van een bedrijf is altijd een heus karwij.
    4)localisatie(er is geen rekening gehouden met de globale markt. we ondersteunen meerdere talen maar echte localisatie kan je dit niet noemen)
    5)Any device support.(gsm,tablet,..(gebonden aan windows), niet responsive)

    deze 5 zorgen er onbewust voor dat onze afzetmarkt naar de toekomst niet veel meer zal groeien. Misschien zelf zal verkleinen(maar dan is het al te laat).

    mvg,
    jonas

  6. #21
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Dus kiezen jullie voor het stoppen van het bedrijf omdat het pakket niet meer kan groeien en geen mogelijkheid meer is voor continuïteit.
    Is het ondernemen niet risico nemen en groeien zodat je na 20 jaar nog kan zeggen: dat hebben we goed gedaan en onze klanten zijn nog steeds tevreden.

    Ik snap het wel. En dan hebben jullie nog meerdere personen in dienst.
    Delphi is great. Lazarus is more powerfull

  7. #22
    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.
    Hier kunnen we een discussie op zich over starten .

    Een goed ontworpen database is key naar mijn mening, zaken als relaties die vastliggen in FK's horen daar gewoon bij. Business logica hoort imho NIET in een database. Het is iets wat enorm uit de klauwen kan lopen en bijna altijd zal leiden tot schaalbaarheids issues en problemen in onderhoud. Ik zou business logica onderbrengen in een middleware laag.

  8. #23
    Quote Originally Posted by jkuiper View Post
    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.
    Mijn ervaring is dat bij dit soort applicaties juist geen functioneel ontwerp beschikbaar is. Gebruikers documentatie meestal ook niet, om van keuzes in het datamodel maar helemaal te zwijgen. Als onderhouds ontwikkelaar kom ik helaas teveel van dit soort voorbeelden tegen.

    Werk nu toevallig ook voor een club die in hetzelfde schuitje zitten. Daar moet een oude grote applicatie onderhouden worden, soms nieuwe functionaliteit erbij met alle risico's van dien. Functionaliteit (hoe zou het moeten werken) moet deels afgeleid worden uit reviews van de code.

    Deze club heeft de keuze gemaakt om een nieuw pakket te gaan ontwikkelen. Daar zetten ze naar mijn mening de juiste stappen door eerst eens een short list te maken wat het pakket functioneel moet doen. Dat communiceren ze ook met een aantal key klanten. Vanuit dat verhaal kun je dan een specificatie maken voor een nieuw pakket dat op termijn het oude moet vervangen.

    Maar ook met dat nieuwe pakket zal de situatie over 10 jaar hetzelfde zijn, de praktijk is nu eenmaal dat een pakket in de onderhoudsfase minder goed wordt bijgehouden dan tijdens de bouw.

  9. #24
    Quote Originally Posted by jkuiper View Post
    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.
    Als er wordt aangegeven dat 80% van de code crap is, dan duidt dat meestal op ontwikkelaars die zich niet willen of kunnen verplaatsen in de bestaande code en de ontstaansgeschiedenis ervan. Volgens mij is dat een enorme valkuil, want die mensen zullen bij de herbouw geneigd zijn dezelfde (of vergelijkbare) fouten te maken. Volgens mij is dit de beste manier om een meerjarig watervalproject te krijgen, waar je uiteindelijk een waardeloos stuk software hebt.

    Door kleine stukjes te herontwikkelen, goed in code te modeleren, en er desnoods een dikke adapter-laag tussen te bouwen zodat het met de rest van de applicatie en database kan praten, beperk je het risico enorm. En het stelt je in staat om alleen energie te steken in onderdelen waar het nuttig voor is.
    1+1=b

  10. #25
    Beste mensen,

    Sorry voor het late antwoord. Alvast vele dank voor alle antwoorden. Het doet goed om de vele meningen van anderen te lezen. Het lijkt me inderdaad beter om bestaande code wat op te ruimen/verbeteren/optimaliseren. Bedankt ook voor de postgres link.

    Thx en groetjes!

  11. #26
    Klinkt echt als een rampzalige situatie.
    Vooral de instelling "De klant ziet de code toch niet"....

    Wij hebben hier de regel dat er totaal geen logica in de forms mag zitten.
    In de forms zitten alleen de definities van de controls en mogelijk het één en ander aan events maar daar is dan ook alles mee gezegd.

    Ons grootste form heeft 5379 regels, en dat is het main form van de applicatie met enorm veel controls en uiteraard best wat events.

    Ik schreef zelf ook altijd veel code in mijn forms maar dat ben ik ook snel afgeleerd.
    Classes definiëren in aparte units, per bepaald doel een aparte unit.
    Gebruik van Utility units is ook aan te raden voor dingen die niet in een class thuis horen maar ook geen plek hebben in een form.

    Ik zou proberen de directie te overtuigen dat dit de juiste richting is voor het pakket.

    Dingen die je kan roepen om ze hopelijk te overtuigen:
    Voorbeeld 1:
    Als je alle logica van je applicaties uit je forms haalt in onder brengt in units voor utility code, class definities, gemeenschappelijke functies etc etc.
    Het aantal units van je project gaat enorm groeien en dat lijkt misschien overkill.

    Stel nou dat je 6 programmeurs hebt.
    Jullie stappen over van Delphi versie waardoor het hele product er onderuit gaat, oftewel. Je moet het pakket door om de boel weer te kunnen compileren.

    Ga nou maar eens een unit van 30k regels doen.
    Als je dat alleen moet doen duurt dat veel langer dan wanneer je met z'n zessen zeg 30 bestanden door moet lopen van allemaal 1000 regels.

    Voorbeeld 2:
    Als er een nieuwe programmeur komt werken dan gaat inwerken in het pakket een stuk makkelijker als de code allemaal goed gestructureerd is.

    Mocht het allemaal niet baten en krijg je ze niet overtuigt dan zou ik het volgende voorstel doen.
    Codeer richtlijnen

    Stel richtlijnen op waar iedereen zich aan gaat houden
    Delphi heeft zelf ook style guides: http://edn.embarcadero.com/article/10280
    Bij mijn werk hebben we ook gewoon regels, lokale variabelen krijgen de prefix L, parameters de prefix A, private fields de prefix F
    Gebruik van "with TMyObject.Create do" is niet toegestaan, omdat het de code niet veel leesbaarder maakt.
    Variabelen moeten een nuttige naam hebben, simpele tellertjes mogen heus wel I, J, K zijn. Maar is het een string die een naam bevat noem je hem LNaam: string;

    • Bepaal best practices (gebruik van with..do bijvoorbeeld, of globale variablen wel/niet)
      Als je er niet uit komt, ga in discussie met elkaar weeg de voor/tegens af, of sta allebei toe.
    • Voer code reviews uit
      Super handig. Ja het kost wat tijd maar vaak kan je door de code te bekijken al bugs spotten. Dit beperkt uiteindelijk de doorlooptijd van features.
      Daarnaast kan je zo de kwaliteit van je codebase waarborgen. Voldoet het niet aan de standaarden kan je dit opmerken en aanpassen voor uitlevering.
    • Doe stiekem toch de rewrite door code langzaam aan te verplaatsen naar losse units.
      Wanneer je een bepaalde functie aan moet passen in een form, kijk of er een unit is waar deze beter past of voeg een unit toe.
      De forms zullen dan steeds kleiner worden. Het duurt wel langer maar resultaat zal er uiteindelijk wel zijn


    Iets langere post dan ik in eerste instantie had bedacht

  12. #27
    Hallo,

    Bedankt voor de aanvullingen. Het is inderdaad een instelling wat je wel vaker ziet 'fast en dirty', klant ziet geen code. Ik vind het ook beter om aparte units te hebben per doel zoals je zegt. Thx voor de style guides, is interessant ook.
    Het valt ook wel op hoe programmeurs soms vast zitten aan hun eigen stijl en daar niet willen van af stappen. Misschien ligt dat aan de 'Belgische norse' mentaliteit. Ik ben inderdaad aan een stiekeme review begonnen en wat rewrite, zoals code die herhaald wordt centraal in een functie bibliotheek onder te brengen, ipv zelfde stukken code te verspreiden op verschillende plaatsen die dan moeilijk onderhoudbaar is.

    Ik vroeg me nog af wat een invloed een DataModule heeft in vergelijking met gewone .pas files. Performantie dan. Ik bedoel ik kan een query ook gewoon definiëren in een pas file zonder die op een DataModule te plaatsen. Met andere woorden, zit er veel overhead aan het laden van een datamodule? Ik heb de indruk dat code in gewone pas files toch sneller laadt, maar ik kan ook mis zijn. Er is ook wel een en ander mis ondertussen met de performantie (hoe kan het ook anders)...

    Bedankt en groeten !

  13. #28
    Weinig tot geen performance-verschil. Een datamodule is geen zichtbaar ding, zoals een form, al wordt vaak gedacht van wel. Een datamodule is simpelweg een TComponent.

    Components hebben owners, en zodoende kan je een hierarchie opbouwen van componentjes. Deze kan je makkelijk lezen en schrijven (TStream.ReadComponent/WriteComponent). Het resultaat is dan in basis een soort DFM. De IDE geeft je een design time editor om componentjes te maken en in te richten. Het resultaat van dat design wordt (net als voor je form) in een DFM opgeslagen. Die DFM wordt eigenlijk gewoon als string resource meegecompileerd met je applicatie.

    En dat is precies wat TDataModule doet. Bij het runnen maak je een instantie van de datamodule, en die instantie gaat zelf op zoek naar de resource, en bouwt daaruit al z'n componentjes weer op. Is dat trager dan in code? Ja, waarschijnlijk wel, er wat parsing bij aan te pas komt. Maar dat zal verwaarloosbaar zijn ten opzichte van het uitvoeren van de eerste query die je opent.

    Kijk maar eens in TDataModule, je ziet dat die direct afgeleid is van TComponent, en maar weinig code bevat. Het meeste werk gebeurt in de constructor Create, waarin die resource wordt gelezen. De rest is een beetje voor dat design-time werk, maar dat is verwaarloosbaar.
    Last edited by GolezTrol; 06-Mar-19 at 12:48.
    1+1=b

  14. #29
    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)
    We hebben diverse Firebird databases draaien van verschillende grootte, maar corruptie heb ik nog maar zeer zelden meegemaakt. 1 keer meegemaakt met een te verklaren defecte HD schijf.


    Quote Originally Posted by stevedeclerck View Post
    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,
    ----8<------

    Geen idee of er mensen zijn die zich herkennen in deze situatie?
    Ja hoor, gelijkwaardige situatie.
    Mijn voorkeur was fris en fruitig van de grond af aan opnieuw beginnen, maar het grote probleem was tijd/resource/geld. Gewoon niet haalbaar eigenlijk.
    Dus uiteindelijk hebben we gekozen om de oude applicatie telkens op verschillende vlakken te vernieuwen. Wij zijn eerst begonnen met een nieuw basis DB ontwerp waar we uiteindelijk naartoe willen.
    Bij de applicatie is als eerste grote stap de boel omgezet naar de laatste Delphi versie (dus geschikt gemaakt voor unicode, etc...) daarna wordt deel voor deel aangepakt. Ook omdat er ook nieuwe functionaliteit toegevoegd moet worden, kun je niet alleen focussen op refactoring. En wat denk je van eventuele problemen waarbij je tegenaan loopt, dat kun maar beter in kleine stukjes aanpakken. Dit is onze aanpak en bevalt me nu eigenlijk wel prima.
    Ieder zijn eigen ding, benieuwd hoe andere het opgepakt hebben :-)
    Nederlandse Firebird Nieuwsgroep
    Hoe meer je weet, hoe meer je beseft hoe weinig je weet.

  15. #30
    Dag Arno,

    Fijn je eens te 'lezen', ik heb uw naam al vaak zien opduiken rond Firebird. We gaan inderdaad bij FB blijven en ons focussen op de versie 4. De 3 hadden we overgeslagen omdat we net bij de uitgave volop bezig waren met updates van de 1.5 -> 2.5.

    Ik denk inderdaad ook van dezelfde aanpak te doen zoals je omschrijft. Een ganse rewrite is inderdaad niet haalbaar. Ik denk dat we nu rond de 300.000 regels code hebben in totaal. Een rewrite zou snel zorgen voor hopen onvoorziene bugs ook. Al die code herprogrammeren zonder fouten te maken, lijkt me niet echt realistisch. Ik zal het dus ook in kleine stukken aanpakken om het risico naar klanten toe ook te beperken.

    Bedankt en groeten!

Page 2 of 2 FirstFirst 1 2

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
  •