Over Atos Origin
Contact
Diensten
Nieuws
Home
Feedback  |  Atos Origin.com  |  Syndicatie
Syndicatie
 
Links
Archief
Meer over de bloggers
Onderwerpen
Alle onderwerpen
Agile
Algemeen
Architectuur
Besturingssystemen
Bpm
Business intelligence
Business proces design
Cloud computing
Eai
Governance
Ibm
Integratie
It consultancy
Java
Microsoft
Nljug
Open source
Oracle
Process standaarden
Project management
Requirements engineering
Rich internet applications
Saas
Security
Sharepoint
Soa
Testing
Virtualisatie
Xml

Voornemens 2010...
Geplaatst op 8 January 2010, 12:28 door Mylène Reiners in java, open source

Het valt me de laatste tijd steeds meer op, dat wij, ontwikkelaars, een enorm lui zootje zijn. Uiteraard zullen er uitzonderingen zijn, maar overdrijving wil wel eens helpen om een punt te maken.

 
RTFMHet komt best vaak voor dat mensen emails sturen met vragen die zonder enig probleem op het Internet te vinden zijn - soms duurt (volgens mij in elk geval) het schrijven van de email langer dan het zelf zoeken geduurd zou hebben...

Het is geen ramp, maar de kans bestaat natuurlijk wel dat als er een keer een echt belangrijke vraag komt, daar maar half naar gekeken wordt - de afzender vraagt immers altijd naar de bekende weg. Jammer.

Misschien een goed voornemen voor 2010 om eerst even zelf na te denken voor je hulp inroept?
En uiteraard (voor de ontvanger) om eraan te denken dat iemand kan veranderen, en niet altijd met onzinvragen hoeft te komen...

Een tweede punt waar ontwikkelaars regelmatig de fout in gaan, is in het gebruik van de (door mij zo gewaardeerde) Code Inspection Tools (Checkstyle, PMD, Findbugs etc.).

Goede voornemens

Stel, je hebt een stuk code geschreven, en ineens komt je architect (of lead developer, of klant of....) met het onzinnige idee om Code Inspection Tools in te zetten. Je doet een controle met Checkstyle, en je hebt een paar duizend warnings.

Kun je twee dingen doen: de warnings die het vaakst voorkomen uitzetten in je configuratie file (dat is in elk geval een heel snelle manier om minder warnings te krijgen....). Je zou ook je IDE (Eclipse is daar in elk geval erg goed in) zo kunnen instellen dat de meeste zaken automatisch goed gezet worden (met format source bijv.), en de overige warnings oplossen...

Goed voornemen in dit kader is dus niet meer meteen de eerste optie te kiezen....

Om toch even mijn stokpaardje van stal te halen (zie een hoop andere blogposts): Goed voornemen 3: Nadenken voordat je iets doet (denk aan code schrijven, code kopiëren etc. - maar het gaat natuurlijk veel verder dan alleen code)...

Drie voornemens zijn meer dan genoeg... Als je er een of twee kunt volhouden, petje af!





Share this | 373 keer bekeken | 0 reacties
Reacties Syndicatie en RSS
Reageer
 
 
Top artikelen
  • J-Spring 2009:Hop on board the Java Troubleshooting Platform
  • Softwaredocumentatie met Sandcastle
  • Agile Springboard
  • Blik op kwaliteit door middel van Six Sigma
  • Developers zijn kikkers
Recente reacties
  • IDC voorspelt dat SaaS mainstream wordt binnen paar ...
  • PrimeFaces is nauwelijks nog bekend terwijl het veel ...
  • Dank!
  • Het bijwerken is met behulp van if(contains()) remove() ...
  • Alleen keuren de bovengenoemde alternatieven duplicate entries af ...
  • Terms of use
  • Legal