Com diuen, si no us fa vergonya el vostre codi antic, no creixeu com a programador, i estic d'acord amb aquesta opinió. Vaig començar a programar per diversió fa més de 40 anys, i professionalment fa 30 anys, així que tinc molts errors. molt. Com a professor d'informàtica, ensenyo als meus alumnes a aprendre dels errors: els seus, els meus i els dels altres. Crec que és hora de parlar dels meus errors per no perdre la meva modèstia. Espero que siguin útils a algú.
Tercer lloc: compilador Microsoft C
La meva professora de l'escola creia que Romeu i Julieta no es podia considerar una tragèdia perquè els personatges no tenien cap culpa tràgica: simplement es comportaven estúpidment, com haurien de fer els adolescents. Aleshores no estava d'acord amb ell, però ara hi veig un gra de racionalitat, sobretot pel que fa a la programació.
Quan vaig acabar el meu segon any al MIT, era jove i sense experiència, tant en la vida com en la programació. A l'estiu, vaig fer pràctiques a Microsoft, a l'equip del compilador C. Al principi vaig fer coses rutinàries com el suport de perfils, i després em van encarregar de treballar en la part més divertida del compilador (com pensava): l'optimització del backend. En particular, vaig haver de millorar el codi x86 per a les declaracions de branca.
Decidit a escriure el codi de màquina òptim per a cada cas possible, em vaig llançar a la piscina de cap. Si la densitat de distribució dels valors era alta, els vaig introduir . Si tenien un divisor comú, el vaig fer servir per fer la taula més ajustada (però només si la divisió es podia fer utilitzant ). Quan tots els valors eren potències de dos, vaig fer una altra optimització. Si un conjunt de valors no satisfà les meves condicions, el vaig dividir en diversos casos optimitzables i vaig utilitzar el codi ja optimitzat.
Va ser un malson. Molts anys després em van dir que el programador que va heretar el meu codi m'odiava.
Lliçó apresa
Tal com escriuen David Patterson i John Hennessy a Computer Architecture and Computer Systems Design, un dels principis principals de l'arquitectura i el disseny és generalment fer que les coses funcionin el més ràpidament possible.
Accelerar els casos habituals millorarà el rendiment de manera més eficaç que optimitzar els casos rars. Irònicament, els casos habituals solen ser més simples que els rars. Aquest consell lògic suposa que sabeu quin cas es considera comú, i això només és possible mitjançant un procés de proves i mesuraments acurats.
En la meva defensa, vaig intentar esbrinar com eren les declaracions de branca a la pràctica (com ara quantes branques hi havia i com es distribuïen les constants), però el 1988 aquesta informació no estava disponible. No obstant això, no hauria d'haver afegit casos especials sempre que el compilador actual no pogués generar un codi òptim per a l'exemple artificial que vaig plantejar.
Necessitava trucar a un desenvolupador experimentat i, juntament amb ell, pensar quins eren els casos habituals i tractar-los específicament. Escriuria menys codi, però això és bo. Tal com va escriure el fundador de Stack Overflow, Jeff Atwood, el pitjor enemic d'un programador és el mateix programador:
Sé que tens les millors intencions, com tots nosaltres. Creem programes i ens encanta escriure codi. Així estem fets. Pensem que qualsevol problema es pot resoldre amb cinta adhesiva, una crossa casolana i un pessic de codi. Per molt que els codificadors facin mal admetre-ho, el millor codi és el codi que no existeix. Cada línia nova necessita depuració i suport, s'ha d'entendre. Quan afegiu codi nou, hauríeu de fer-ho amb reticència i fàstic perquè totes les altres opcions s'han esgotat. Molts programadors escriuen massa codi, convertint-lo en el nostre enemic.
Si hagués escrit un codi més senzill que cobria casos habituals, hauria estat molt més fàcil actualitzar-lo si fos necessari. Vaig deixar enrere un embolic amb el qual ningú volia fer front.
Segon lloc: publicitat a les xarxes socials
Quan treballava a Google en publicitat a les xarxes socials (recordes Myspace?), vaig escriure una cosa com això en C++:
for (int i = 0; i < user->interests->length(); i++) {
for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
keywords->add(user->interests(i)->keywords(i)) {
}
}Els programadors poden veure immediatament l'error: l'últim argument hauria de ser j, no i. Les proves unitàries no van revelar l'error, i el meu revisor tampoc. El llançament es va dur a terme i una nit el meu codi va anar al servidor i va bloquejar tots els ordinadors del centre de dades.
No va passar res dolent. No es va trencar res per a ningú, perquè abans del llançament global el codi es va provar en un centre de dades. A menys que els enginyers de l'SRE deixin de jugar al billar durant un temps i fessin una mica de retrocés. L'endemà al matí vaig rebre un correu electrònic amb un bolcat, vaig corregir el codi i vaig afegir proves unitàries que detectarien l'error. Com que vaig seguir el protocol, en cas contrari, el meu codi simplement no s'executaria, no hi havia cap altre problema.
Lliçó apresa
Molts estan segurs que un error tan important costarà definitivament l'acomiadament del culpable, però no és així: en primer lloc, tots els programadors s'equivoquen i, en segon lloc, rarament cometen el mateix error dues vegades.
De fet, tinc un amic programador que era un enginyer brillant i va ser acomiadat per haver comès un sol error. Després d'això, el van contractar a Google (i aviat el van promocionar): va parlar honestament de l'error que va cometre en una entrevista i no es va considerar fatal.
Això és sobre Thomas Watson, el llegendari cap d'IBM:
Es va anunciar una ordre governamental per valor d'un milió de dòlars. IBM Corporation, o millor dit, Thomas Watson Sr. personalment, volia aconseguir-ho. Malauradament, el representant de vendes no va poder fer-ho i IBM va perdre l'oferta. L'endemà, aquest empleat va entrar a l'oficina del Sr. Watson i va col·locar un sobre al seu escriptori. El senyor Watson ni tan sols es va molestar a mirar-ho: estava esperant un empleat i sabia que era una carta de renúncia.
Watson va preguntar què va fallar.
El representant comercial va parlar detalladament de l'evolució de la licitació. Va anomenar els errors comesos que es podrien haver evitat. Finalment, va dir: "Senyor Watson, gràcies per deixar-me explicar. Sé quant necessitàvem aquesta comanda. Sé lo important que era”, i es va disposar a marxar.
Watson se li va acostar a la porta, el va mirar als ulls i li va tornar el sobre amb les paraules: “Com puc deixar-te anar? Acabo d'invertir un milió de dòlars en la teva educació.
Tinc una samarreta que diu: "Si realment aprens dels errors, llavors ja sóc un mestre". De fet, quan es tracta d'errors, sóc doctor en ciències.
Primer lloc: API d'App Inventor
Els errors veritablement terribles afecten un gran nombre d'usuaris, esdevenen de coneixement públic, triguen molt de temps a corregir-los i els cometen aquells que no els han pogut fer. El meu error més gran s'ajusta a tots aquests criteris.
Com pitjor millor
Jo llegeixo sobre aquest plantejament als anys noranta com a estudiant de grau, i m'agrada tant que ho pregunto als meus alumnes. Si no ho recordes bé, refresca la memòria, és petit. Aquest assaig contrasta el desig de "fer-ho bé" i l'enfocament "pitjor és millor" de moltes maneres, inclosa la senzillesa.
Com hauria de ser: el disseny ha de ser senzill en la implementació i la interfície. La senzillesa de la interfície és més important que la senzillesa d'implementació.
Com pitjor, millor: el disseny ha de ser senzill en la implementació i la interfície. La senzillesa d'implementació és més important que la senzillesa de la interfície.
Oblidem-ho per un minut. Malauradament, me'n vaig oblidar durant molts anys.
Inventor d'aplicacions
Mentre treballava a Google, vaig formar part de l'equip , un entorn de desenvolupament en línia d'arrossegar i deixar anar per a aspirants a desenvolupadors d'Android. Era l'any 2009, i teníem pressa per llançar la versió alfa a temps perquè a l'estiu poguéssim fer classes magistrals per a professors que poguessin utilitzar l'entorn a l'hora d'ensenyar a la tardor. Em vaig oferir voluntari per implementar sprites, nostàlgic de com solia escriure jocs a la TI-99/4. Per a aquells que no ho sàpiguen, un sprite és un objecte gràfic bidimensional que es pot moure i interactuar amb altres elements de programari. Alguns exemples de sprites inclouen naus espacials, asteroides, marbres i raquetes.
Hem implementat App Inventor orientat a objectes a Java, de manera que només hi ha un munt d'objectes. Com que les boles i els sprites es comporten de manera molt semblant, vaig crear una classe de sprites abstractes amb propietats (camps) X, Y, Speed (velocitat) i Heading (direcció). Tenien els mateixos mètodes per detectar col·lisions, rebotar a la vora de la pantalla, etc.
La principal diferència entre una bola i un sprite és el que es dibuixa exactament: un cercle ple o un ràster. Com que vaig implementar els sprites primer, era lògic especificar les coordenades x i y de la cantonada superior esquerra d'on es trobava la imatge.
Un cop els sprites funcionaven, vaig decidir que podia implementar objectes de bola amb molt poc codi. L'únic problema va ser que vaig fer la ruta més senzilla (des del punt de vista de l'implementador), indicant les coordenades x i y de la cantonada superior esquerra del contorn que emmarcava la pilota.
De fet, calia indicar les coordenades x i y del centre del cercle, tal com s'ensenya a qualsevol llibre de text de matemàtiques i qualsevol altra font que mencioni cercles.
A diferència dels meus errors passats, aquest no només va afectar els meus companys, sinó també milions d'usuaris d'App Inventor. Molts d'ells eren nens o completament nous a la programació. Van haver de realitzar molts passos innecessaris a l'hora de treballar en cada aplicació en què hi havia la pilota. Si recordo els meus altres errors amb el riure, aquest em fa suar encara avui.
Finalment, vaig arreglar aquest error fa poc, deu anys després. "Pedaçat", no "fixat", perquè com diu Joshua Bloch, les API són eternes. No hem pogut fer canvis que afectessin els programes existents, hem afegit la propietat OriginAtCenter amb el valor false als programes antics i true en tots els futurs. Els usuaris poden fer una pregunta lògica: qui fins i tot va pensar a situar el punt de partida en un lloc diferent del centre. A qui? A un programador que era massa mandrós per crear una API normal fa deu anys.
Lliçons apreses
Quan treballeu amb API (cosa que gairebé tots els programadors han de fer de vegades), hauríeu de seguir els millors consells descrits al vídeo de Joshua Bloch ""o :
- Una API us pot aportar un gran benefici i un gran dany.. Una bona API crea clients recurrents. El dolent es converteix en el teu etern malson.
- Les API públiques, com ara els diamants, duren per sempre. Dóna-ho tot: mai hi haurà una altra oportunitat de fer-ho tot bé.
- Els esquemes de l'API han de ser breus — una pàgina amb signatures i descripcions de classes i mètodes, que no ocupa més d'una línia. Això us permetrà reestructurar fàcilment l'API si no resulta perfecta la primera vegada.
- Descriure casos d'úsabans d'implementar l'API o fins i tot de treballar en la seva especificació. D'aquesta manera evitareu implementar i especificar una API completament no funcional.
Si hagués escrit fins i tot una breu sinopsi amb un guió artificial, molt probablement hauria identificat l'error i l'hauria corregit. Si no, un dels meus companys ho faria sens dubte. Qualsevol decisió que tingui conseqüències de gran abast s'ha de pensar durant almenys un dia (això no només s'aplica a la programació).
El títol de l'assaig de Richard Gabriel, "Worse Is Better", fa referència a l'avantatge que suposa ser el primer a comercialitzar —fins i tot amb un producte imperfecte— mentre algú altre passa una eternitat perseguint el perfecte. Reflexionant sobre el codi sprite, m'adono que ni tan sols havia d'escriure més codi per fer-ho bé. Digui el que sigui, m'he equivocat molt.
Conclusió
Els programadors cometen errors cada dia, tant si es tracta d'escriure codi amb errors com si no volen provar alguna cosa que millori la seva habilitat i productivitat. Per descomptat, pots ser programador sense cometre errors tan greus com jo. Però és impossible convertir-se en un bon programador sense reconèixer els teus errors i aprendre d'ells.
Contínuament em trobo amb estudiants que senten que cometen massa errors i, per tant, no estan preparats per a la programació. Sé com de comú és la síndrome de l'impostor a les TI. Espero que aprenguis les lliçons que he enumerat, però recorda la principal: cadascú de nosaltres comet errors: vergonyós, divertit, terrible. Em sorprèn i em molestarà si en el futur no tinc prou material per continuar l'article.
Font: www.habr.com