Hoe code te lezen: Een project/applicatie begrijpen

[Gamebuster]

Op mijn werk werk ik met meerdere applicaties door elkaar. Alhoewel dit vaak dezelfde applicaties zijn, worden deze applicaties vaak en snel geupdate en voorzien van nieuwe functionaliteit.

Vanzelfsprekend ben ik niet op de hoogte van alle updates binnen de applicaties, laat staan over alle applicaties. Het komt daarom regelmatig voor dat ik moet werken aan/met code die ik niet ken.

Alhoewel alle code geschreven wordt door mij en mijn collega's en hoofdzakelijk vergelijkbare structuur hebben, heb ik vaak moeite om de werking van code in me op te nemen en echt te begrijpen. Dit heeft soms als gevolg dat het lastig voor me is om me te concentreren op datgene wat ik moet aanpassen, wat daarop weer ervoor zorgt dat ik soms (veel) langer bezig ben met bepaalde aanpassingen dan nodig zou moeten zijn: Niet alleen omdat ik (nog) niet weet hoe bepaalde onderdelen in elkaar zitten, maar ook omdat het soms lastig is om in me op te nemen hoe het werkt en wat ik precies moet doen om te bereiken wat ik wil bereiken.

Het is geen gebrek aan kennis: Als ik concentratie heb, kan ik prima bereiken en uitzoeken hoe het werkt. Ik mis echter vaak de concentratie daarvoor en heb daarom al gauw een "failed to allocate memory" effect in mijn brein, terwijl ik in eigen geschreven applicaties veel meer en sneller kan werken.

Heeft iemand tips op dit gebied? Wat is een efficiente manier om te werken aan code die je niet zelf geschreven hebt?

[ Voor 4% gewijzigd door Gamebuster op 18-02-2013 11:12 ]

[WhizzCat]

Documenteren en standaardiseren. Een andere oplossing is er niet

[Gamebuster]

De code is grotendeels al "gestandaardiseerd" en documentatie is in beperkte mate (waar echt nodig) aanwezig of (mondeling) te vinden bij aanwezige collega's. Maar zelfs als het me staat uitgeschreven of wordt uitgelegd, kan ik de informatie moeilijk of zelfs niet in me opnemen. Mocht dat wel gelukt zijn, dan lukt het me nog steeds amper om wat met de informatie te doen.

Ik heb soms echt het idee alsof ik aan eigen projecten binnen 1-2 uur hetzelfde bereik als op m'n werk over een hele (werk)dag.

[ Voor 33% gewijzigd door Gamebuster op 18-02-2013 11:17 ]

[Afvalzak]

WhizzCat schreef op maandag 18 februari 2013 @ 11:12:
Documenteren en standaardiseren. Een andere oplossing is er niet

Dít, bij mij helpen diagrammen altijd fijn om de structuur in te zien (klassendiagrammen met opmerkingen)
maar uiteindelijk is andermans code altijd lastiger te begrijpen omdat je er niet midden in zat en je niet altijd precies weet wat de persoon dacht tijdens het schrijven (tenzij hij dat gedocumenteerd heeft:P)

[Aphelion]

Een tip voor als er geen documentatie en architectuur diagrammen aanwezig zijn waarbij je code moet aanpassen waarvan je de architectuur niet kent.

Pak een uml tool (Sparx bijv.) en plaats daarin de classes die je raakt. Breng de dependencies voor jou scope in kaart, niet de gehele arcitectuur. Als je zo 20 classes raakt behoud je, in jou scope, het overzicht en kan je sneller de keuze maken waar je de fix dient te plaatsen.

[Gamebuster]

Een UML tool lijkt me wel het proberen waard. Nou nog een werkende vinden voor Mac...

[Verwijderd]

Ik gebruik OmniGraffle voor UML op de Mac en voor kleinere diagrammer de Chrome App LucidChart. Ik kan ze allebei best wel aanraden!

[Hydra]

Ik vind gewoon naar de commits en de comments daarbij (die verplicht horen te zijn) een goeie bron om door te krijgen wat er uberhaupt veranderd is. Documentatie loopt eigenlijk altijd achter.

[Grijze Vos]

Code van anderen is nou eenmaal inherent moeilijker te lezen dan je eigen code.
Zelfs als je aan code standards e.d. doet.
Doe je niet veel aan.

[Janoz]

Door het toevoegen van fatsoenlijke unit en integratie test kun je ook met code uitleggen wat de daadwerkelijke functionaliteit is van een stuk code. Commentaar bij de test kan aangeven wat er gebeurt (eventueel met verwijzing naar het functioneel ontwerp of naar een issue in wat voor tracking tool jullie ook maar gebruiken) en je kunt zelfs met een debugger door de bende heenstappen om exact te zien wat er gebeurt.

[Waster]

Mijn standaard is om code net zo lang te refactoren totdat het simpel, zelf-gedocumenteerde code is die iedereen kan lezen. Wijzigingen kosten dan weinig tijd, omdat je precies weet waar je een break point moet zetten en de wijzigingen hebben slechts effect op één module. Helaas heeft niet iedereen die standaard. Het is de business die deze prioriteit stelt. Dus ik zou je baas/team overtuigen om te refactoren of gewoon incalculeren dat het minstens 5 keer zo lang duurt om een wijziging uit te voeren in spaghetti code.

[R4gnax]

Waster schreef op maandag 18 februari 2013 @ 20:50:
Mijn standaard is om code net zo lang te refactoren totdat het simpel, zelf-gedocumenteerde code is die iedereen kan lezen. Wijzigingen kosten dan weinig tijd, omdat je precies weet waar je een break point moet zetten en de wijzigingen hebben slechts effect op één module. Helaas heeft niet iedereen die standaard. Het is de business die deze prioriteit stelt. Dus ik zou je baas/team overtuigen om te refactoren of gewoon incalculeren dat het minstens 5 keer zo lang duurt om een wijziging uit te voeren in spaghetti code.

QFE.

Met de toevoeging dat slechts weinigen echt het inzicht, de knobbel en het doorzettingsvermogen hebben om goede self-documenting code te schrijven. Dat moet je voor een groot deel gewoon kunnen: het valt maar tot op zekere hoogte aan te leren.

Omgekeerd heb je echter ook altijd wel een paar man aan verloren gevallen die het systematisch wel zo bot maken of gemaakt hebben, dat je je af en toe af gaat vragen of ze gepoogd hebben job security te kweken door code te produceren die enkel door hun eigen kromgeslagen gedachtekronkels nog te volgen zijn.

[Janoz]

Nou, ik zou daar heel voorzichtig mee zijn. Wat 'self documenting code' is, is soms wel sterk afhankelijk van de persoon. Je moet voorkomen dat de afdeling alleen maar bezig is met het refactoren van elkaars code naar wat diegene toevallig als 'self documenting' beschouwd. Dergelijke refactor acties zul je eigenlijk altijd middels pair programming/in overleg moeten doen, maar als het goed is zou dat al bij de code review gebeurt zijn .

[farlane]

Gamebuster schreef op maandag 18 februari 2013 @ 11:10:
Heeft iemand tips op dit gebied? Wat is een efficiente manier om te werken aan code die je niet zelf geschreven hebt?

Klein beginnen, en van daaruit verder werken. Als je het vaak doet wordt het makkelijker omdat je sneller patronen herkent. Imho is dit echt een van die 10k uren skills ...

[denyos]

Voor mij werkt het vaak prima om ergens al relatief snel een breakpoint te zetten en dan gewoon eens door de flow van het programma heen lopen. Daarnaast werkt een diagram vaak ook fijn, al zijn die zelden up2date.