Coses que mai hauries de fer, part 1

From The Joel on Software Translation Project

Revision as of 15:57, 28 February 2010 by Msonsona (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Article originalment publicat el dijous 6 d'abril de 2000 : Things You Should Never Do, Part I

Traducció : Miquel Sonsona


Netscape 6.0 està finalment en la seva primera beta pública. Mai ha sortit una versió 5.0. La última gran versió publicada, la 4.0, es va publicar fa quasi tres anys. Tres anys és un període terriblement llarg en el món d'Internet. Durant aquest temps, Netscape es va quedar de braços creuats, indefens mentre el seu nivell d'implantació al mercat queia en picat.

És una mica "pilota" per part meva criticar-los per esperar tant entre les publicacions d'aquestes versions. Ells no ho van fer a propòsit, oi?

Bé, sí. Ho van fer. Va ser fent la pitjor errada estratègica que qualsevol companyia de software pot fer:

Van decidir de reescriure el codi desde zero.

Netscape no va ser, però, la primera companyia en cometre tal errada. Borland va fer el mateix quan va comprar Arago i va tractar d'introduir-lo en el dBase per Windows, un projecte maleït que els va portar tant temps que Microsoft Access se'ls va menjar, aleshores ho van fer altre cop reescrivint Quattro Pro des de zero i impressionant a la gent amb la poca quanitat de característiques que tenia. Microsoft va fer una errada quasi tan grossa, tractant de reescriure el Word per Windows des de zero en un altre projecte maleït anomenat Pyramid que va ser tancat, llençat i amagat sota la catifa. Afortunadament per Microsoft, ells mai havien deixat de treballar en el codi antic, de manera que encara els quedava quelcom a vendre, obtenint així, solsament un desastre financer, però no pas un d'estratègic.

Nosaltres som programadors. Els programadors són, en el fons, arquitectes, i la primera cosa que volen fer quan arriben a algun lloc és deixar el lloc ben net i construir alguna cosa magnífica. No ens excita el concepte de renovació incremental: reparar, millorar, plantar floretes.

Hi ha una subtil raó per la qual els programadors sempre volen llençar el codi i començar de nou. La raó és que pensen que el codi antic és un embolic. I aquí rau una interessant observació: probablement s'equivoquen. La raó per la que pensen en el vell codi com un embolic és degut a una regla capital, fonamental de la programació:

És més dur llegir codi que escriure'l.

Aquest és el motiu pel qual reusar codi és tan dur. Aquest és el perquè tothom en el teu equip té funcions diferents per dividir strings en un array d'strings. Ells escriuen la seva pròpia funció perquè és més fàcil i divertit que tractar d'esbrinar com funciona l'antiga funció.

Com a corol·lari a aquest axioma, pots preguntar a qualsevol programador sobre el codi en el que estan treballant. "És un embolic ben pelut", us diran. "Res m'agradaria més que llençar-lo i començar de nou".

Per què és un embolic?

"Bé," diran, "mira aquesta funció. Ocupa dues pàgines! Res d'això va aquí! Ni tan sols sé per a què serveixen la meitat d'aquest crides a l'API."

Abans que els nous fulls de càlcul de Borland per Windows es venéssin, Philippe Kahn, el fundador de Borland, va ser àmpliament citat a la premsa enorgullint-se de quant millor seria Quattro Pro sobre Microsoft Excel, perquè estava escrit des de zero. Tot el codi font nou! Com si el codi font es rovellés.

La idea que el codi nou és millor que el vell és ben absurda. El codi antic ha estat utilitzat. Ha estat provat. Piles d'errors s'hi han trobat, i han estat corregits. No hi ha res de dolent en això. No adquireix més errades només per estar al teu disc dur. Au contraire, baby! És el software com un vell Dodge Dart, que es rovella només d'estar parat al garatge? És el software com un osset de pelutx que sembla revellit quan no és fet amb material nou?

Tornant a la funció que ocupava dues pàgines. Sí, ho sé, és només una simple funció per mostrar una finestra, però li han anat creixent cabells i coses i ningú sap perquè. Bé, jo t'explicaré perquè: són correccions a les errades. Un d'aquests arregla aquell error que la Nancy va fer quan va tractar d'instal·lar-lo en un ordinador que no tenia Internet Explorer. Un altre arregla l'errada que es presenta quan falta memòria. Un altre arregla l'errada de quan l'arxiu estava en un disquet i l'usuari el treia directament mentrestant. La crida a "LoadLibrary" és lletja però permet que el codi funcioni en versions antigues de Windows 95.

Cadascun d'aquests errors comportava setmanes d'ús en condicions reals per trobar-los. El programador pot haver passat un parell de dies reproduint l'error al laboratori i reparant-lo. Si és com molts errors, reparar-lo pot ser qüestió d'una línia de codi, o fins i tot d'un parell de caràcters, però molt temps i molta feina van a parar a aquests dos caràcters.

Quan llences el codi i comences des de zero, estàs llençant tot aquest coneixement. Totes aquestes reparacions als errors. Anys de programació.

Estàs llençant el teu lideratge en el mercat. Els estàs regalant dos o tres anys als teus competidors, i creu-me, això és molt de temps en quant a software.

T'estàs posant a tu mateix en una posició extremadament perillosa en la que estaràs venent una versió antiga del codi durant uns anys, completament incapaç de fer qualsevol canvi estratègic o reaccionar a noves característiques que el mercat demandi, perquè no tens codi vendible. Ben mirat, també podries tancar el negoci durant aquests anys.

Estàs malgastant una quantitat de diners desorbitada escrivint codi que ja existeix.

Hi ha alguna alternativa? El consens sembla ser que el codi vell de Netscape era realment dolent. Bé, podria haver estat dolent, però, saps què? Funcionava prou bé en una gran quantitat d'ordinadors reals.

Quan els programadors diuen que el seu codi és un embolic (tal com sempre fan), hi ha tres tipus de problemes.

Primer, hi ha els problemes d'arquitectura. El codi no està ben construit. El codi de xarxa està activant les seves pròpies finestres de diàleg des del no-res; això hauria d'haver estat manegat en el codi de la interfície d'usuari. Aquests problemes es poden resoldre, un per un, movent el codi amb cura, refactoritzant, canviant les interfícies. Es poden solventar per un programador treballant amb cura i comprobant els seus canvis tots de cop, de manera que ningú més es vegi afectat. Fins i tot grans canvis estructurals poden ser realitzats sense llençar el codi. Al projecte Juno nosaltres vam passar diversos mesos reestructurant en un punt: tan sols movent coses d'aquí cap allà, netejant-les, creant classes base amb sentit i creant interfícies entre els mòduls. Però ho vam fer amb cura, amb el nostre codi ja existent, i no vàrem introduir nous errors ni llençar codi que funcionés.

Una segon motiu pel qual els programadors pensen que el seu codi és un embolic és perquè és ineficient. El codi del renderitzat de Netscape era, segons els rumors, lent. Però això només afectava una petitat part del projecte, que pot ser optimitzada o fins i tot reescrita. No cal que ho reescriguis tot. Quan s'optimitza buscant més velocitat, l'1% de la feina et dóna el 99% de la millora.

Tercer, el codi pot ésser esfereïdorament lleig. Un dels projectes en els que vaig treballar fins i tot tenia un tipus de dades anomenat "FotutString". Un altre projecte havia començat a usar la convenció de començar el nom de les variables locals amb un guió baix, però més tard va canviar cap al més estàndard "m_". D'aquesta manera, la meitat de les funcions començaven amb "_" i l'altra meitat amb "m_", fins i tot feia mal als ulls. Francament, són aquest tipus de coses que es poden arreglar en cinc minuts amb una macro d'Emacs, no començant des de zero.

És important recordar que quan comences des de zero no hi ha cap raó per creure que en resulti un millor treball que el que ja hi havia. Primer de tot, probablement no tindràs el mateix equip de programadors que va treballar en la versió 1, de manera que no tens "més experiència". Tan sols faràs la majoria de les velles errades altre cop, i introduiràs nous problemes que no existien en la versió original.

El vell mantra construeix una vegada per llençar és perillós quan s'aplica a aplicacions comercials de gran escala. Si estàs escrivint codi experimentalment, potser voldràs desfer-te de la funció, que vas escriure la setmana passada, cercant un millor algoritme. Està bé. Pots voler refactoritzar una classe per fer-la més fàcil d'usar. També està bé. Però llençar el programa sencer és una follia, i si Netscape hagués disposat de supervisió adulta amb experiència en la indústria del software, no s'haurien fotut aquell tret al peu.

Personal tools