Jespers weblog om løst og fast, nok mest det førstnævnte.

Tags - Kategorier : Alle | Bøger | Eclipse | Fodbold | F.C.København | Java | Mad | Musik
Permalink
Fordele og ulemper ved Word-programmering
(altså ikke i betydningen Basic makroer)
For tiden arbejder jeg primært som word programmør hvor jeg producerer Word dokumenter og tegninger, fylder tavler og bladrer i aldrende, sommetider ufuldstændig dokumentation, går til møder og taler i en uendelig strøm, heldigvis med rigtig begavede mennesker. Resultatet går videre til en kommité af ikke-udviklere og først om et par måneder (tidligst) vil de abstrakte højniveautanker blive til konkrete designs og først måske om et halvt år bliver det til Java kode, XML skemaer, databasetabeller, etc.

Jeg tror der er mange it-udviklere (nogle af mine kolleger, ved jeg) der helst er fri for denne type opgave. Men prøv at se det på denne måde:

  • Man kan komme langt omkring: I Word behøver du ikke starte fra bunden eller noget. Du kan være vævende, bare kald det helikoptersyn. Du behøver ingen import-sætninger, ingen cheked exceptions.
  • Det går hurtigt. Tegn en kasse - vupti, det er en server, en cylinder: Straks det er en database. Og en enkelt linje kan være alt hvad du vil ha' den til at være (undlad pilespidser, så kan du overføre alle slags trafik blot med at gestikulere lidt med fingeren)
  • Det er nemt: Hvis du f.eks. forbinder to kasser med en streg, der passerer igennem en sky betyder det at nogen skal fedte i timevis med underlige VPN-fænomener og grimme NAT-tabeller. Men ikke dig - ihvertfald ikke lige nu.
  • Alt kan lade sig gøre: Du behøver ikke tænke på om data følger samme formater. Bare man tegner kasserne i pæne lag kommer der nogen og fylder dem ud som hhv. applikationsserver, databaser og magisk middleware.
  • Brugerhåndtering uden brugere: Tændstikmænd brokker sig aldrig. Tænk på perspektiverne!
  • Fejlhåndtering: Bare sig kompenserende aktioner. Det lyder jo meget mere struktureret end fejlhåndtering.
  • Det er nemt at tegne en stabil arkitektur. Man skal bruge masser af akronymer, f.eks. SOA, BPEL, WS-xxx og OIO. Gentaget tilstrækkeligt kan arkitekturen beskyttes fra kloge spørgsmål.
Nu er der jo som bekendt ingen træer, der vokser ind i himlen, og derfor er det nok også nødvendigt at nævne nogle af ulemperne:
  • Man kan ikke unit-teste et Word dokument.
  • Nogen vil spørge om løsningen er forberedt for X, hvis man har glemt et akronym. Seneste skud på stammen er BPMN og Semantic Web. Nå ja, det er ikke mine penge.
  • Den redaktionelle proces i Word kan være lidt af en prøvelse. Nåja, Word betyder jo blot tekstbehandling, men diagrammer, pæne mapper, notater og et virvar af flip-over kladder bliver ret uhåndtérligt i længden.
  • Tændstikmanden forstår dig ikke.
  • Møder, møder, møder
  • Efter nogle uger begynder en lille nagende fornemmelse af rastløshed at melde sig. En rastløshed som kun kureres ved kode og kørende systemer.
Så selvom Word programmering er spændende så anbefaler jeg at have lidt praktisk arbejde i baghånden…

Jeg mener man med stort held kan teste Word-dokumenter må jeg sige. Det er det man gør på whiteboards. Med mindre de er beskyttet af noget andet, monopoler eller sådan noget, så burde dine kunder frygte M-ordet (Måneder) som Malaria.
Ikke kun har de monopol, de er også omfattet af såkaldt konkurrencefremmende foranstaltninger (udbudsregler), så alle de kloge tanker i Word-dokumenterne skal først tolkes af (evt.) andre leverandører, der også gerne lige vil sætte et fingeraftryk. Den ultimative "Design by Committee" proces.

Tag ikke fejl, M-ordet frustrerer også mig, men de er en del af spillereglerne.



Skriv en kommentar

Overskrift
Indhold
HTML : b, i, blockquote, br, p, pre, a href="", ul, ol, li
Navn
E-mail addresse
Hjemmeside
Husk mig Ja  Nej 

E-mail addresser bliver ikke vist på bloggen, så du skal kun skrive din e-mail adresse hvis du vil modtage en e-mail, når der bliver skrevet nye kommentarer til dette blog indlæg (du kan afmelde når du har lyst).