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

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
    9,840
    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,433
    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!

Page 2 of 2 FirstFirst 1 2

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (0 members and 2 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
  •