Kodegenerering: Udvikling på EPO

Af 6

Jeg har lige haft fornøjelsen af at opdatere med nogle lexer/parser specifikationer til JFlex og JavaCup - det er ellers snart lang tid siden, jeg har rodet med dem. Som udgangspunkt er det en dejligt effektiv følelse at kunne slippe for at skrive skabelon-kode og kunne nøjes med at koncentrere sig om det væsentlige, nemlig hvordan man vil have, at slutproduktet skal opføre sig. At det også er lidt sjovt at måtte finde Dragebogen frem og håndskrive en parser en gang imellem må jeg gemme til en anden gang...
 
Men der er altså et par ting, der har været temmeligt irriterende. Det er ret mange år siden, jeg sidst seriøst kodede Java i Notepad, men da mit udviklingsmiljø ikke liiige har understøttelse for den type parser-specifikationer, føler man sig pludselig hensat til sin ungdom, når man skal skrive de kodestumper. Ingen sytax highlighting. Ingen auto-completion. Ingen jeg-checker-lige-Javadoc'en-Ctrl-Q. Og resultatet er, at jeg ender med at måtte re-generere parseren adskillige gange, når jeg får lavet en tastefejl eller har glemt et argument til en metode. Øv.
 
Også i fremtiden kan jeg forudse, at jeg kommer til at være på Herrens (m/k) mark: Når der en dag kommer en forbi (det kunne f.eks. være mig) og laver en smart refaktorering på nogle af de klasser, der refereres i parseren, vil det være den genererede kode, der bliver refaktoreret, men desværre ikke specifikationen. Det opdager man først næste gang, parseren skal regenereres - og hvis man er rigtig uheldig, giver det ikke engang en kompileringsfejl, men begynder bare at opføre sig utilsigtet.
 
Hvis kodegenerering er udvikling på EPO, så er det vist nu, jeg har bemærket bivirkningerne sætte ind. Er der en læge blandt læserne?

Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Torben Mogensen Blogger

Hvis man går ind og modificerer genereret kode, så er man selv ude om det, hvis man mister ændringerne, når man regenererer koden. Det svarer til at modificere den assemblerkode, som en oversætter laver. Det er de fleste vel efterhånden enige om er noget rod.

Hvis man vil refaktorere genereret kode, så bør man (hvis det er muligt) ændre sin specifikation, så den giver den ønskede kode, eller hvis ikke dette er muligt, ændre kodegeneratoren, så den genererer den refaktoriserede kode. Man skal i givet fald sikre sig, at den refaktoriserede kodegenerator virker for alle specifikationer, og ikke kun ens egen.

Hvis ingen af ovenstående giver det ønskede, så lav et script, der går ind i den genererede kode og erstatter den oprindelige kode med den refaktoriserede, og giver en fejlmeddelelse, hvis koden ikke ser ud som forventet. Så kan du genkøre scriptet, når du regenererer koden. Dette er dog ikke helt uden risiko, da du kan risikere, at selv om den oprindelige kode stadig findes, så er forudsætningerne for refaktoriseringen bortfaldet.

  • 0
  • 0
#3 Klaus Elmquist Nielsen

I min studietid grinede vi meget over denne efterhånden klassiske artikel: Real Programmers Don't Use Pascal. Ingen hentydninger, men de skitserer da den klassiske løsning på problemet. :-)

Mere seriøst: For mig lyder det dit refaktoreringsproblem som om at din udviklingsomgivelse ikke støtter værktøjer der genererer kildetekst. Eller at der ikke anvendes de mekanismer som udviklingsomgivelsen støtter.

Den slags problemer har man ikke i samme grad når man bruger "vi" og "make". Eller vesta (vestasys.org) for den sags skyld.

  • 0
  • 0
#4 Anne-Sofie Nielsen

Problemet er jo netop, at IntelliJ som jeg og resten af udviklingsafdelingen på min arbejdsplads udvikler i, ikke understøtter JFlex og JavaCup-værktøjerne, og jeg er ikke bekendt med, at der eksisterer nogle andre tilsvarende værktøjer, som IntelliJ faktisk understøtter. Man kunne muligvis selv strikke en plugin sammen, men det orker jeg alligevel ikke at bruge min tid på, i betragtning af, at min anvendelse af de omtalte lexer/parsergeneratorer alligevel er begrænset.

Men det kunne da godt være, at jeg skulle finde en Emacs frem næste gang for i det mindste at få syntax highlighting, tak for linket Morten :-)

Nej, man bør ikke rette i genereret kode. Men hvis ens udviklingsmiljø ikke understøtter, at man opdager, at det er det, man gør, så kan man godt komme til det vha. automatiske refaktoreringer. Og dem vil jeg alligevel heller ikke undvære!

  • 0
  • 0
#5 Jonas Kongslund

En lavpraktisk løsning på problemet med utilsigtet at komme til at rette i genereret kode, f.eks. med en automatisk refactoring, er at skrivebeskyttede de genererede filer. Den proces er let at automatisere med f.eks. Ant og jeg gætter på at IntelliJ vil komme med en advarsel, hvis den skal i gang med at modificere skrivebeskyttede filer.

Derudover kan problemet også gøres mindre ved aldrig at committe den genererede kode (jeg ved ikke, hvad jeres praksis er på det område), men det indebærer selvfølgelig at de resterende udviklere skal have installeret JFlex og JavaCup for at kunne lave et build.

  • 0
  • 0
#6 Jonas Kongslund

Lige en tilføjelse: hvis muligt, så sørger jeg altid for at den genererede kode ligger i et namespace i stil med com.foo.bar.generated så andre udviklere (og én selv et stykke tid efter man sidst har haft fingre i projektet) bliver mindet om at koden er genereret.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen