Development Donderdagen #9

Interessante artikels

JUnit5: conditions (20 min)

Met JUnit 5 kan je tests conditioneel laten runnen/disablen. Dit kan je doen door een annotatie te schrijven die een class bevat die een bepaalde interface van JUnit implementeert.  Je kan bijvoorbeeld tests maken die alleen op een bepaald besturingssysteem draaien of tests niet meer laten draaien als daarvoor een andere bepaalde test is gefaald.

http://blog.codefx.org/libraries/junit-5-conditions/

Git mindmap (5 min)

Deze Git mindmap bevat zo’n beetje elk soort commando dat je aan het versioneringssysteem kan geven, gegroepeerd per topic.

http://www.alexkras.com/git-mind-map/

 

Talk of the week: Adam Tornhill – Treat your code as a crime scene (46 min)

  • Ontwikkelaars spenderen het grootste deel van hun tijd aan het aanpassen van bestaande code, niet aan het schrijven van volledig nieuwe stukken
    • Om bestaande code te kunnen aanpassen, moet je ze eerst begrijpen
    • Hedendaagse systemen zijn vaak te groot/ontwikkeld door meerdere teams zodat niemand een volledig overzicht heeft van hoe het systeem werkt
  • Als we code bekijken weten we vaak ‘intuïtief’ of iets complex is of niet.
    • Deze intuïtie is eigenlijk een herinnering of eerdere, soortgelijke ervaring die we al eens hadden met een stuk code
    • Problemen met deze aanpak
      • Intuïtie is biased (aangezien het uit onze herinnering komt)
      • Intuïtie is niet schaalbaar
  • Om de problematiek van het begrijpen van complexe code op te lossen, moeten we te werk gaan zoals de mensen die in de forensische psychologie werken. (denk bv aan CSI, Silence of the Lambs)
  • Bv: Geographical offender profiling
    • Om een misdaad te begaan moet er een overlapping zijn tussen waar en wanneer een misdadiger en een slachtoffer elkaar ontmoeten
    • Daardoor bevat een crime scene steeds info over de dader
    • Op die manier kan je ‘hotspots’ op een landkaart aanduiden.
      • 70% van de tijd zal de misdadiger ergens binnen die hotspot leven
    • Kijk vanaf 9:25 voor een voorbeeld over hoe men deze techniek heeft gebruikt bij Jack the Ripper
  • Hoe kunnen we deze techniek gebruiken in de codebase?
    • Bv: visualisatie dmv http://wettel.github.io/codecity.html
      • Vormt klassen/packages om in gebouwen/straatblokken met een bepaalde grootte gebaseerd op de grootte/complexiteit van de component
    • Als we dit combineren met Version Control Systems, weten we welke code op welk moment en door wie werd gemaakt/verplaatst/aangepast
    • Wanneer we die VCS data aggregeren en projecteren op CodeCity, zien we “code hotspots” ontstaan. Plekken in de codebase waarin we vaak zaken aanpassen én die complexe code bevatten
  • In een groot systeem zijn enkele modules vaak de oorzaak van een groot deel van de bugs
    • Dit zijn vaak de ‘hotspots’
  • Vaak is de oorspronkelijke structuur van klassen/methodes/modules goed, maar naarmate de tijd verstrijkt, gaat de kwaliteit naar omlaag
    • Dikwijls zijn het een beperkt aantal klassen die heel vaak veranderen en waarvan de kwaliteit naar omlaag gaat naarmate het aantal changes toeneemt
    • We moeten deze stukken code waarvan de kwaliteit over tijd daalt, proberen te vinden
      • Dit kan door middel van een ‘complexity trend’: Hoe erg stijgt de complexiteit van een klasse over een bepaalde tijdspanne?
  • Code doesn’t lie
    • Als we willen weten hoe iets werkt, moeten we gewoon naar de code kijken
    • Maar code heeft ook een historiek van changes.
      • Die kan je niet vinden door gewoon naar de meest recente code te kijken
      • Temporal coupling: als bepaalde files steeds samen veranderen tijdens commits, is er waarschijnlijk een code coupling
        • Mogelijk is er spraak van code duplication die je steeds op meerdere plaatsen moet aanpassen wanneer een nieuwe feature moet worden geïmplementeerd
        • Zo kan je ook dependencies tussen teams/api’s ontdekken
  • Hoe meer verschillende ontwikkelaars aan een bepaalde module werken, hoe groter de kans is op kwaliteitsproblemen in die module
    • Via VCS is het mogelijk om te weten te komen welke modules getouched zijn door een hoog aantal verschillende ontwikkelaars en hoeveel code ze in zo’n module hebben aangeraakt
    • Modules die een hoog aantal ontwikkelaars ‘aantrekken’ hebben mogelijk te veel verantwoordelijkheden
    • Je kan ook de “Main developer” identificeren. De persoon die het meest aantal lijnen heeft veranderd in een module, kent er waarschijnlijk ook het meeste vanaf
      • Als bepaalde modules slechts door één ontwikkelaar zijn gemaakt/aangepast, moet je tijd maken voor kennisdeling!
  • Al deze grafieken kunnen ook gebruikt worden door testers, bv voor exploratory testing van de complexe stukken

https://www.youtube.com/watch?v=TfZmuS01CNs

Slides: http://gotocon.com/cph-2015/presentation/Treat%20Your%20Code%20as%20a%20Crime%20Scene

Dictionary.put()

Linus’s Law stelt het volgende:

“Given enough eyeballs, all bugs are shallow.”

Deze wet werd bedacht door Linus Torvalds (Linux, Git) en open-source-voorstander Eric S. Raymond en was dé mantra tijdens de ontwikkeling van Linux en open-source projecten in het algemeen. Samengevat betekent deze wet dat wanneer genoeg verschillende programmeurs naar een stuk code kijken, uiteindelijk elke bug gevonden zal worden.

https://nl.wikipedia.org/wiki/Wet_van_Linus

Technologie in de kijker: Electron.js

Met Electron kan je desktop toepassingen schrijven door middel van HTML, CSS en JavaScript die op elk populair besturingssysteem werken.  Onder andere de desktop client van Slack, de code editor Atom en de browser Brave (zie Development Donderdagen #4) werden of worden gebouwd met Electron. De library bevat standaard Chromium, de open-source versie van Chrome.

http://www.wired.com/2016/05/javascript-conquered-web-now-taking-desktop/

https://github.com/electron/electron

finally {

Is dit de beste 404-pagina ooit? https://meh.com/404

}

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s