Tekniker Och Deras Tidsplanering

Jag har en bok hemma som jag fick av utvecklingschefen på mitt förra jobb, jag har visserligen glömt titeln men det var något i stil med "time management for sysadmins". Det var en väldigt bra bok, och en av poängerna han gjorde var att förklara problemet i att vi säger "det är två dagars arbete - jag kan ha det gjort om två veckor". Det gäller för utecklare med.

Så här ser verkligheten ut: Man har ett planeringsmöte, det är ett riktigt bra planeringsmöte med tidsskattning och prioritering och det mynnar ut i en fin lista med planerade leveranser på planerade tidspunkter. Utvecklaren är nöjd och känner att "vecka X blir tuff men det här kommer vi fixa". Sedan kliver vekligheten in: sälj måste ha just det företagest annons skapad och publicerad precis nu för det har de lovat. Den ambitiösa nya medarbetaren har hitta ett antal irriterande, men ganska snabbfixade buggar, chefen har ett bra förslag att diskutera och servern äter upp alla inodes i en av cachemapparna. I teorin skall svaret på alla dessa frågor vara "återkom om två månader", men hur ska den som frågar, och har ett i deras yrkesroll akut problem, förstå varför det inte går att skjuta in en "så snabb fix" i planeringen? Och hur skall man förklara att en snabb fix betyder 5 minuter för att lokalisera var i kodträdet fixen skall in, 10 minuter för att fundera över oönskade konsekvenser av fixen, 10 minuter för att kolla så att ingen av de där läskiga sakerna hände, 5 minuter för att driftsätta och peta in i svn och 5 minuter för att faktiskt göra fixen. Dvs att det åtgår 35 minuter för den där feminutersfixen?

Så vad väljer du? Backlogg i planeringen eller besvikna och oförstående medarbetare, som känner att du inte bryr dig om deras problem? Lägg sedan till att det är trevligt att ibland vara social med sina kolleger....

PHP skalar inte

... hör jag här och där från sura gamla javakodare. Nähä? Devote.se har ungefär 400k unika besökare och i runda slängar 4500k sidvisningar per vecka. Med den lasten idlar våra, inte alls särskilt brutala, webbserverresurser mest hela tiden. Sedan finns det andra saker i systemet som har svårt att hänga med vid peaklast och det får vi ordna - men det har inte med php att göra.

Sedan gnäller folk på överlagring och spagettikod - och visst, jag har sett javakodare försöka trycka javas hårt typade, metodkjedande modell på php och det blir ju bajs. Det är lite svårt att överlagra en metod med lika många argument i ett icke typat språk. Så då använder man defaultvärden på metodparametrarna istället - och om man verkligen måste kunna skicka in en integer och ett komplext objekt på samma position i ett anrop får man kolla det inne i anropet. Funkar precis likadant....

Annat det gnälls på är MVC-separation. Och det är sant att mycket php-kod blandar presentation och logik, men det beror mer på programmeraren än på språket...

Hela den här harangen beror på att jag precis fick en phpklass som en javakodare hade skrivit och den var full med syrliga kommentarer om språket. Min reaktion på det är ungefär att "ja, om man kodar som du så suger php". Dvs om han hade kunnat språket hade han inte stött på de problemen han gjorde. Poängen är alltså i korthet att om man vet hur språket fungerar så blir det bra, jag kan skriva skrotkod i java eller c++ med, men jag bör hålla mig ifrån att skylla på språket.

Sedan är det klart att ett tolkat språk aldrig blir lika snabbt som ett kompilerat, men med vettig opcode-caching och lite andra hemliga trix kan man komma ganska nära. Iaf tillräckligt nära för att den snabbare utvecklingen skall göra de ökade hårdvarukraven till en i kronor och flexibilitet bra affär.