De eerste echte dag van RailsConf stond in het teken van tutorials. Van de acht tutorials van ieder 4 uur kon je er dus maar 2 volgen. Daarnaast was de unconference “Bohconf” begonnen. Een unconference is een gratis alternatief voor de conferentie, met wat lichtere onderwerpen in een informele setting. Er wordt gezellig gehackt en gekletst, de ene keer wat gestructureerder dan de andere keer.

Ik ben naar twee tutorials geweest en heb een aantal onderwerpen bijgewoond op de BohConf. Ik zal dus hier een samenvatting geven van een van deze tutorials.

Avoiding and fixing Rails antipatterns

Tijdens deze tutorials gingen Chad Pytel (thoughtbot, inc.) en Tammer Saleh (Tammer Saleh Consulting, Inc.) in op een aantal eenvoudige antipatterns en hoe je heel simpel deze kan verhelpen. Dit deden ze door te vertellen over het proces waarin ze bepalen of ze een slecht project overnemen, een soort van “Rescue Mission”.

15 minuten code review

Tammer Saleh introduceerde zijn 15 minuten code review en noemde de punten op waarmee hij snel bepaalt of de code een beetje fatsoenlijk is. 15 minuten is te kort om de applicatie daadwerkelijk goed aan de praat te krijgen en goed rond te kijken. Maar door naar de code zelf te kijken is er genoeg om te vinden wat er mis is. Bijvoorbeeld:

• Zijn er te veel modellen? Er wordt te vaak teveel genormaliseerd en dat zorgt voor onnodig complexe code
• Grep op “assert true”, de standaard test die Rails genereert. Als deze er nog staan, dan is dat een slecht teken
• SQL code is zelden echt nodig en dus een teken van prutserij.
• Controllers dienen RESTful te zijn.
• Probeert de originele programmeur het wiel opnieuw uit te vinden, door bijvoorbeeld zijn eigen authenticatie te schrijven?
• Zien de views eruit als PHP, oftewel zit er teveel logica in de views?
• Kijk in de lib/ directory, want daar vind je dingen die weggestopt zijn, zoals duck punching
• Zijn er grote files (meer dan pak-em-beet 400 regels)?
• Is de code Rubyesque?
• Wordt er teveel gemetaprogrammeerd?

De reden van slechte code is vaak het gevolg van een slecht proces. Het kan zijn dat het een moeilijk probleem is, of slechte ontwikkelaars, maar dat is vaak moeilijk te achterhalen. Vaak wordt “technical debt” niet afgelost en begrijpen developers en managers niet goed dat refactoren continu nodig is. Het kan ook zijn dat er geen focus is op de kwaliteit. Het belang van goed ontwikkelen wordt te vaak onderschat. Technical debt kan er toe leiden dat nieuwe features inbouwen in de toekomst tot 8x zo lang duren.

Dus je hebt gezien dat het project wat je kan overnemen een ramp is. Moet je een rescue mission aangaan? Het antwoord is nee. Het fixen van deze projecten zorgt er niet voor dat je als held uit de bus komt, maar eerder als iemand die gewoon langer doet over het toevoegen van nieuwe features. Het refactoren van grote delen van de code is voor de klant niet zichtbaar. Deze klant heeft vaak ook niet genoeg geld meer over om nog fatsoenlijk te investeren in het repareren van de code. Het zijn alleen ontwikkelaars die de schoonheid van code kunnen begrijpen. Je kan makkelijk de helft meer vragen voor dit soort projecten.

Maar goed, stel dat je toch besluit het project aan te pakken. Hoe ga je dan te werk? Er zijn drie stappen die in deze volgorde ook uitgevoerd moeten worden:

Stap 1: Train de klant

Het probleem begint bij de klant. Deze moeten leren begrijpen hoe ze om moeten gaan met software ontwikkeling. Geef ze daarom Getting Real of Rework van 37signals.

Zeg tegen de klant dat het jouw taak als ontwikkelaar is om zo min mogelijk features te gaan bouwen. Je moet je concentreren op features die waarde toevoegen en klanten hebben de neiging om veel te veel te willen, dus daar moeten de verwachtingen goed gemanaged worden.

Leg ook uit dat je een deel van de tijd (maar niet alles) gaat besteden aan het verbeteren van oude functionaliteit. Dit is voor hun eigen bestwil, zodat de features daarna sneller klaar zijn. Dit gaat er niet altijd in en kan er toe leiden dat je de klant kwijt raakt. Dat is beter dan het project toch gaan doen en vervolgens hard te falen.

Stap 2: Repareer het proces

Neem alles op, stuur van overleg een samenvatting om ervoor te zorgen dat je op dezelfde pagina zit met de klant. Laat je voortgang zien in dagelijkse of wekelijkse standup meetings. Het is van groot belang dat de klant kan zien dat je serieus met het probleem bezig bent en niet stil zit.

Gebruik bijvoorbeeld Github en zorg ervoor dat de klant de activity feed leest. Gebruik ook Pivotal Tracker, een planningstool die real time berekent wat nieuwe features voor invloed hebben op de planning en kan meten wat de snelheid (velocity) van het project is. Zo kan je aantonen dat zolang je niet de technical debt terugbetaalt, de velocity daar onder zal lijden. Daarnaast zijn applicaties als Basecamp en Campfire ideaal om gecentraliseerd de communicatie bij te houden.

Stap 3: Schrijf code

Eindelijk, na de wereld van de klant meerdere keren op z’n kop te hebben gezet kan je dan eindelijk beginnen met het daadwerkelijk schrijven van code. Maar hoe pak je dat dan aan?

De belangrijkste manier is door pair programming. Door met z’n tweeën achter 1 computer te zitten werk je sneller, draag je sneller kennis over, blijf je beter gefocust en geef je een enorme boost aan de kwaliteit.
Programmeren is een tweemanstaak.

Verder schrijf je voor het huidige gedrag integratietests, met bijvoorbeeld Cucumber, om het huidige gedrag vast te leggen. Dit zorgt ervoor dat je zonder problemen kan gaan hakken in de code, maar duidelijk kan zien of de applicatie, functioneel gezien, nog werkt zoals vroeger.

Neem niet teveel hooi op je vork. Laat je niet teveel afleiden door problemen die je tegen komt. Pak maar 1 onderdeel tegelijkertijd aan en laat daarbij de boel de boel. Doe dit werk op een aparte branch in git. Dit zorgt ervoor dat je makkelijk kan switchen om snel tussendoor nog bugfixes te doen. Ook kan je makkelijk je branch weggooien mocht het op niets uitlopen.

Maar blijf ook nieuwe features toevoegen. Alleen refactoren heeft voor de klant niet direct meerwaarde en er is vaak geen geld voor.

Oefenen

We kregen na deze uitleg een Rails applicatie waar we mee gingen toepassen wat we net geleerd hadden. Zo gingen we data denormaliseren en views opschonen. Al met al een nuttige exercitie. Het is van belang om zo veel mogelijk van de Rails API te kennen, om zo niet af te wijken van de conventies. Ga ook niet doelbewust afwijken van deze conventies. Enig voordeel wat je daar uit haalt ben je weer kwijt als andere ontwikkelaars moeten uitzoeken wat je gedaan hebt.

Morgen

Morgenochtend vroeg (in Nederland is dat in de middag), is de keynote van David Heinemeier Hanson. Iedereen is benieuwd of hij een bijzondere aankondiging gaat doen met betrekking tot de release van Rails 3. Veel spannender dan de iPhone 4, als je het mij vraagt
In ieder geval is morgen gevuld met traditionele presentaties. Houdt de RailsConf hashtag in de gaten en op de website kan je (na inloggen heb ik begrepen) de presentaties live volgen.