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

Thread: Delphi sourcecode parser

  1. #16
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    9,904
    Het schijnt dat fcl-passrc overigens wel anonymous methods ondersteund. pas2js gebruikt het :-)

  2. #17
    Misschien zie ik het verkeerd, maar wat je beschrijft lijkt me grotendeels overbodig als je een versiebeheersysteem en unit tests hebt.

    Versiebeheer -> Elke wijziging gedocumenteerd. In de commit message kan je verwijzen naar issue/ticket nummers e.d.
    Unit tests -> Tests gerelateerd aan code, met hun eigen versiebeheer erop waarin je kan verwijzen naar tickets of documentie van business logic.

    Vereist gedisciplineerd gebruik, maar dat geldt voor elke oplossing.
    Last edited by GolezTrol; 02-May-19 at 14:32.
    1+1=b

  3. #18
    De werkwijze die jij beschrijft is hoe ik het nu min of meer doe maar ik vind het omslachtig, foutgevoelig en weinig flexibel. Volgens mij komt dit doordat de koppeling tussen je versiebeheer log en je issue/ticket systeem redelijk losjes is. Moet je eerst je logs versiebeheer doorspitten om dit te koppelen aan een ticket/issue. Het zou mooi zijn als die koppeling wat strakker lag voor bepaalde zaken.

  4. #19
    Tja, losjes... hoe gaat jouw tool er straks mee om als iemand een procedure hernoemt? Hoe gaat alle gekoppelde documentatie dan mee?

    Unit tests zitten wat dat betreft dichter op je code. Je kan heel veel commentaar en uitleg kwijt bij zo'n test. Elke test zou in principe voor een stukje business logic kunnen staan. Die omschrijving kan je kwijt in de naam van je test, en in het commentaar erbij. Je hebt dan een stuk implementatie dat controleert of je code doet wat hij moet doen, en tegelijk documenteert wat het moet doen, en waarom het dat moet doen. Als je een functie aanpast of verwijdert, die je direct het resultaat. Weet je zeker dat die functie weg moet? Dan verwijder je de tests ook, en daarmee is je documentatie ook opgeschoond.

    En commit messages, dat is ook een kwestie van conventies afspreken en die handhaven. Met veel tools kan je daar zelfs automatische controles op doen. Github heeft daarbij een handige integratie, dat je iets als fixes #123 in je commit message te zetten om de commit niet alleen aan het issue te linken, maar het ook direct af te sluiten.
    Bij ons hebben commit messages en pull requests een titel die begint met [TicketNr] gevolgd door een korte beschrijving. Als een collega daarvan afwijkt kan je 'm simpelweg vragen het aan te passen. Met de juiste toepassing van die structuur zullen pull requests (en hun status) automatisch gekoppeld worden aan Jira, en kan je ook makkelijk pull requests terugzoeken op basis van een ticketnummer (of andersom). En als er een nieuwe versie van de software live wordt gezet, wordt er automatisch een mailtje verstuurd met de links naar alle tickets, op basis van de ticketnummers in de titel van de pull requests die in die build verwerkt zitten.

    Ik geef toe dat het losjes is. Met name een typfoutjes in een ticketnummer is zo gemaakt en niet zo snel ontdekt. Toch is dat maar heel zelden, en plukken we er verder allemaal de vruchten van, terwijl het vrijwel geen tijd kost om bij te houden, in tegenstelling tot externe documentatie die ook makkelijk uit de pas gaat lopen met de werkelijkheid.

    Maar goed, ik zit wellicht in een wat andere situatie, dus misschien kijk ik er daarom wat anders tegenaan.
    1+1=b

  5. #20
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    9,904
    Veel commerciële VCS diensten hebben die koppeling wel. Gitlab is ook weer wat vrijer geworden.

    Ikzelf heb ooit iets simpels geregeld voor SVN revisies, om deze te sorteren, er commentaar aan toe te voegen en mantis links in commit messages klikbaar te maken. Dit met name voor massmerges. (zie http://www.stack.nl/~marcov/mergelogs32/)

    Binnenkort gaat het echter naar de vuilnishoop. Blijkbaar moeten we naar GIT, ook al moet mergetracking daar met messages in commits geemuleerd worden.

  6. #21
    @GolezTrol

    Wat moet ik me in jouw context voorstellen bij een ticket? Is dat een bug, een requirement, een methode of iets anders?

    Hoe/door wie worden deze tickets ingevoerd?

    Wat doe je bijvoorbeeld als er om een of andere reden testen die voorheen succesvol waren opeens falen? Maak je dan voor iedere gefaalde test weer een ticket/issue aan?

  7. #22
    Die worden ingevoerd door de product owner, of soms door developers, stake holders of de applicatiebeheerder. Het kan een feature request, bug of algemene verbetering zijn.

    De tests worden uitgevoerd bij (na) het builden van de applicatie. Als tests dus ineens falen, dan heb ik het waarschijnlijk gesloopt met de aanpassing die ik zojuist heb gedaan. Meestal zit ik dan dus ook in de context van die wijziging, en is die simpelweg nog niet af zolang ik falende tests heb. Als er achteraf een bug of wijziging wordt aangedragen, dan kan dat tot een nieuw ticket leiden, en hopelijk bij de implementatie ook tot een nieuwe test die bewijst dat dat specifieke stukje inderdaad werkt.
    1+1=b

  8. #23
    Dank je wel alle feedback!

  9. #24
    @Benno

    Als ik het goed begrijp kun je met die delphiAST een soort van XML structuur genereren van je delphi code. Mogelijk is dat een goede basis voor je tool.
    Deze parser heeft dezelfde roots als de castalia variant. Zover als ik het begrijp maakt ie er alleen xml van.

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
  •