Werken aan Ansi support voor Windows is verspilde tijd, behalve voor historici.
Oud onderwerp, maar:
RE- factoring betekent toch dat iemand eerder iets VAUT heeft gedaan? In dat geval kun je inderdaad je code versimpelen. Voor de rest is refactoring de waan van de dag, Onzin.
Werken aan Ansi support voor Windows is verspilde tijd, behalve voor historici.
Nee, refactoring betekent zeker niet per definitie dat iemand iets fout heeft gedaan. Refactoring is een normaal onderdeel van een ontwikkel proces, tenminste wel bij mijn ontwikkel proces.
Marcel
Moet je altijd uitgaan van wat de refactoring geeft. Ik heb het wel eens getest en kwam tot mijn conclusie dat het eindresultaat omslachtiger was dan dat ik had ingetyped. Of zie ik dat verkeert.
Delphi is great. Lazarus is more powerfull
Hoe bedoel je "wat de refactoring geeft"?
Marcel
Nou nee. Het betekent dat iemand iets geleerd heeft. Als je het in een keer perfect kunt heb je niks geleerd. Het is een essentieel gereedschap bij het maken van modellen. Als ik een complex probleem moet oplossen begin ik met een simpel model. Bij het uitbreiden tot het hele probleem opgelost wordt moet ik soms het model direct uitbreiden, en soms abstracties toevoegen. Met name als ik abstracties toevoeg moet ik code refactoren om die abstracties te gebruiken.
Beginvoorwaardes kunnen veranderen, aannames van de initiele implementatie kunnen veranderd zijn. Het programma kan te lang organisch gegroeid zijn voorbij de originele design parameters
Maar voor mij is refactoren voornamelijk iets op macro niveau. De samenhang van het programma en de kern datastructuren en gerelateerde code.
Lange procedures herstructureren en identifiers renamen horen er ook nog bij, maar zijn meer de details.
Last edited by marcov; 27-Jul-11 at 13:08.
Precies. Refactoring is het aanpassen van code die (waarschijnlijk) goed was op het moment dat het geschreven werd, maar die niet meer voldoet aan de huidige eisen. Je kunt besluiten om te refactoren als je een nieuwe aanpassing moet doen die niet goed aansluit op de code die je al had. Door wat bestaande code om te bouwen met de nieuwe inzichten die je hebt, en de nieuwe eisen die je hebt gekregen, kun je er weer een poosje mee vooruit.
Code schrijven die dan perfect is en blijft, zonder dat je er ooit wat aan hoeft aan te passen, dat is de waan. Onzin.
1+1=b
Refactoren jullie niet tijdens het ontwikkelen dan? Ik merk dat ik meestal begin met het tikken van "wat het moet doen", daarna refactor en daarna eens ga kijken wat de compiler ervan vind.
Marcel
Ja, maar refactoren van code die ik nog bezig ben te ontwikkelen noem ik geen refactoren. Dat noem ik gewoon factoren. Lijkt me een logisch onderdeel van het ontwikkelproces, niet alleen iets werkend maken, maar ook die code nog een beetje kritisch bekijken, en eventueel verbouwen tot iets waar je je later niet voor hoeft te schamen.
1+1=b
Terminologie is een tikje lastig. Het klein grut natuurlijk ja, bij elke modificatie. Maar niet iedere modificatie/herschikking is IMHO een refactoring, dat is voor mij toch iets meer met beleid erachter.
Het grotere werk is typisch voor rustige weken of zelfs complete nieuwe major versies die makkelijk over een jaar to market kunnen zijn. Al zou je dat rearchitecten kunnen noemen. (wat de grote broer van refactoren is)
Ik ben op dit moment met zo wat bezig. De hoofd controller classes van het framework opnieuw aan het opzetten.
De nieuwe inzichten zijn vooral op meer plaatsen "m x n" relaties introduceren in de datastructuren, en ondanks al deze vrijheidsgraden de initializatie van een gemiddeld programma toch simpel houden. En, belangrijker, snel en stabiel.
De redenen hiervoor liggen in het toenemend camera's (zowel reeel als verwacht) in onze applicaties, en het feit dat steeds meer apps camera's gebruiken met asymmetrische instellingen (en camera's dus minder uitwisselbaar zijn). Applicaties moet daarom beter in staat zijn door te draaien als een camera uitvalt, en het risico (en dan vooral de noodzaak tot handmatig ingrijpen) op het bedrijven van een camera met de verkeerde instellingen minimalizeren.
De rest van het framework is de afgelopen twee jaar herschreven, maar de centrale classes raken teveel, en de basis aannames stammen van het begin. Dan maar een major versie, en proberen zoveel mogelijk andere noodzakelijke dingen die compatibiliteit met oude versies breken in een keer mee te nemen.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks