Como din, se non te avergoñas do teu código antigo, entón non estás crecendo como programador, e estou de acordo con esta opinión. Comecei a programar por diversión hai máis de 40 anos, e profesionalmente hai 30, así que teño moitos erros. moito. Como profesor de informática, ensino aos meus alumnos a aprender dos erros: os seus, os meus e os dos demais. Creo que é hora de falar dos meus erros para non perder a modestia. Espero que lle sexan útiles a alguén.

Terceiro lugar: compilador Microsoft C

O meu profesor da escola cría que Romeo e Xulieta non podían ser considerados unha traxedia porque os personaxes non tiñan ningunha culpa tráxica: simplemente se comportaban estúpidamente, como deberían os adolescentes. Daquela non estaba de acordo con el, pero agora vexo un gran de racionalidade na súa opinión, sobre todo en relación coa programación.

Cando rematei o meu segundo ano no MIT, era novo e sen experiencia, tanto na vida como na programación. No verán, realice unha internada en Microsoft, no equipo do compilador C. Ao principio fixen cousas rutineiras como soporte de perfiles, e despois encargáronme traballar na parte máis divertida do compilador (como pensaba): a optimización do backend. En particular, tiven que mellorar o código x86 para as declaracións de rama.

Decidido a escribir o código de máquina óptimo para cada caso posible, tireime á piscina de cabeza. Se a densidade de distribución dos valores era alta, entreinos táboa de transición. Se tiñan un divisor común, useino para facer a táboa máis axustada (pero só se a división se podía facer usando cambio de bits). Cando todos os valores eran potencias de dous, fixen outra optimización. Se un conxunto de valores non cumpriu as miñas condicións, dividíno en varios casos optimizables e usei o código xa optimizado.

Foi un pesadelo. Moitos anos despois dixéronme que o programador que herdou o meu código odiaba.

Lección aprendida

Como escriben David Patterson e John Hennessy en Computer Architecture and Computer Systems Design, un dos principais principios da arquitectura e do deseño é facer que as cousas funcionen o máis rápido posible.

Acelerar os casos comúns mellorará o rendemento de forma máis eficaz que optimizar os casos raros. Irónicamente, os casos comúns adoitan ser máis sinxelos que os raros. Este consello lóxico supón que sabes que caso se considera común, e isto só é posible mediante un proceso de probas e medicións coidadosas.

Na miña defensa, tentei descubrir como eran as declaracións de rama na práctica (como cantas ramas había e como se distribuían as constantes), pero en 1988 esta información non estaba dispoñible. Non obstante, non debería ter engadido casos especiais cando o compilador actual non puidese xerar o código óptimo para o exemplo artificial que se me ocorreu.

Necesitaba chamar a un programador experimentado e, xunto con el, pensar cales eran os casos comúns e tratalos de forma específica. Escribiría menos código, pero iso é bo. Como escribiu o fundador de Stack Overflow, Jeff Atwood, o peor inimigo dun programador é o propio programador:

Sei que tes as mellores intencións, como todos nós. Creamos programas e gústanos escribir código. Así estamos feitos. Pensamos que calquera problema se pode solucionar con cinta adhesiva, unha muleta caseira e un chisco de código. Por máis que os codificadores lles doa admitilo, o mellor código é o código que non existe. Cada nova liña necesita depuración e soporte, hai que entendela. Cando engades un novo código, deberías facelo con desgana e desgusto porque todas as outras opcións esgotáronse. Moitos programadores escriben demasiado código, converténdoo no noso inimigo.

Se tivese escrito un código máis sinxelo que cubra casos comúns, sería moito máis fácil actualizar se fose necesario. Deixei atrás unha lea coa que ninguén quería tratar.

Segundo lugar: publicidade en redes sociais

Cando traballaba en Google en publicidade en redes sociais (lembras de Myspace?), escribín algo así 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)) {
  }
}

Os programadores poden ver inmediatamente o erro: o último argumento debería ser j, non i. As probas unitarias non revelaron o erro, nin o meu revisor. O lanzamento levouse a cabo e unha noite o meu código foi ao servidor e fallou todos os ordenadores do centro de datos.

Non pasou nada malo. Nada rompeu para ninguén, porque antes do lanzamento global o código foi probado nun centro de datos. A non ser que os enxeñeiros da SRE deixaran de xogar ao billardo por un tempo e fixesen un pequeno retroceso. Á mañá seguinte recibín un correo electrónico cun vertedoiro, corrixín o código e engadín probas unitarias que detectarían o erro. Xa que seguín o protocolo -se non, o meu código simplemente fallaría ao executarse- non houbo outros problemas.

Lección aprendida

Moitos están seguros de que un erro tan importante custará definitivamente o despedimento do culpable, pero non é así: en primeiro lugar, todos os programadores cometen erros e, en segundo lugar, raramente cometen o mesmo erro dúas veces.

De feito, teño un amigo programador que era un enxeñeiro brillante e foi despedido por cometer un só erro. Despois diso, foi contratado en Google (e pronto ascendeu): falou sinceramente sobre o erro que cometeu nunha entrevista e non se considerou fatal.

Iso é o que contar sobre Thomas Watson, o lendario xefe de IBM:

Anunciuse unha orde gobernamental por valor dun millón de dólares. IBM Corporation -ou mellor dito, Thomas Watson Sr. persoalmente- realmente quería conseguilo. Desafortunadamente, o representante de vendas non puido facelo e IBM perdeu a oferta. Ao día seguinte, este empregado entrou na oficina do señor Watson e puxo un sobre na súa mesa. O señor Watson nin sequera se molestou en miralo: estaba esperando un empregado e sabía que era unha carta de renuncia.

Watson preguntou que pasou mal.

O representante comercial falou polo miúdo sobre o avance da licitación. Nomeou os erros cometidos que poderían evitarse. Finalmente, dixo: "Señor Watson, grazas por deixarme explicar. Sei canto necesitamos esta orde. Sei o importante que era”, e preparouse para marchar.

Watson achegouse a el na porta, mirouno aos ollos e devolveulle o sobre coas palabras: “Como podo deixarte ir? Acabo de investir un millón de dólares na túa educación.

Teño unha camiseta que di: "Se realmente aprendes dos erros, entón xa son un mestre". De feito, cando se trata de erros, son doutor en ciencias.

Primeiro lugar: API de App Inventor

Os erros verdadeiramente terribles afectan a un gran número de usuarios, fanse de coñecemento público, tardan moito en corrixilos e son cometidos por aqueles que non puideron facelos. O meu maior erro encaixa con todos estes criterios.

Canto peor mellor

Eu leo ensaio de Richard Gabriel sobre este enfoque nos anos noventa como estudante de posgrao, e gústame tanto que llo pregunto aos meus alumnos. Se non o lembras ben, refresca a memoria, é pequeno. Este ensaio contrasta o desexo de "facelo ben" e o enfoque de "peor é mellor" de moitas maneiras, incluída a sinxeleza.

Como debe ser: o deseño debe ser sinxelo en implementación e interface. A sinxeleza da interface é máis importante que a sinxeleza de implementación.

Canto peor, mellor: o deseño debe ser sinxelo en implementación e interface. A simplicidade de implementación é máis importante que a sinxeleza da interface.

Esquecémonos diso por un minuto. Por desgraza, esquecinme durante moitos anos.

Inventor de aplicacións

Mentres traballaba en Google, formei parte do equipo Inventor de aplicacións, un ambiente de desenvolvemento en liña de arrastrar e soltar para aspirantes a desenvolvedores de Android. Corría o 2009, e tiñamos présa por lanzar a versión alfa a tempo para que no verán puidésemos facer clases maxistrais para profesores que puidesen utilizar o medio ambiente á hora de ensinar no outono. Ofrecínme voluntario para implementar sprites, nostálxico de como adoitaba escribir xogos na TI-99/4. Para aqueles que non o saiban, un sprite é un obxecto gráfico bidimensional que pode moverse e interactuar con outros elementos de software. Exemplos de sprites inclúen naves espaciais, asteroides, canicas e raquetas.

Implementamos App Inventor orientado a obxectos en Java, polo que só hai unha morea de obxectos. Dado que as bólas e os sprites se comportan de xeito moi semellante, creei unha clase de sprites abstractas con propiedades (campos) X, Y, Speed ​​​​(velocidade) e Heading (dirección). Tiñan os mesmos métodos para detectar colisións, rebotar no bordo da pantalla, etc.

A principal diferenza entre unha bola e un sprite é o que se debuxa exactamente: un círculo cheo ou unha trama. Xa que primeiro implementei os sprites, era lóxico especificar as coordenadas x e y da esquina superior esquerda de onde estaba a imaxe.

Unha vez que os sprites estaban funcionando, decidín que podía implementar obxectos bola con moi pouco código. O único problema foi que tomei a ruta máis sinxela (desde o punto de vista do implementador), indicando as coordenadas x e y da esquina superior esquerda do contorno que enmarca a pelota.

De feito, era necesario indicar as coordenadas x e y do centro do círculo, como se ensina en calquera libro de texto de matemáticas e calquera outra fonte que mencione círculos.

A diferenza dos meus erros pasados, este afectou non só aos meus compañeiros, senón tamén a millóns de usuarios de App Inventor. Moitos deles eran nenos ou completamente novos na programación. Tiveron que realizar moitos pasos innecesarios á hora de traballar en cada aplicación na que estaba presente o balón. Se lembro os meus outros erros coa risa, entón este faime suar aínda hoxe.

Finalmente reparei este erro hai pouco, dez anos despois. "Parcheado", non "fixado", porque como di Joshua Bloch, as API son eternas. Non se puideron facer cambios que afectasen aos programas existentes, engadimos a propiedade OriginAtCenter co valor false nos programas antigos e true en todos os futuros. Os usuarios poden facer unha pregunta lóxica: quen mesmo pensou en situar o punto de partida noutro lugar que non sexa o centro. A quen? A un programador que era demasiado preguiceiro para crear unha API normal hai dez anos.

Leccións aprendidas

Cando traballas en API (que case todos os programadores teñen que facer ás veces), debes seguir os mellores consellos descritos no vídeo de Joshua Bloch "Como crear unha boa API e por que é tan importante"ou nesta lista curta:

• Unha API pode traerche grandes beneficios e grandes danos.. Unha boa API crea clientes repetidos. O malo convértese no teu eterno pesadelo.
• As API públicas, como os diamantes, duran para sempre. Dádeo todo: nunca haberá outra oportunidade de facer todo ben.
• Os esquemas da API deben ser breves — unha páxina con sinaturas e descricións de clases e métodos, que non ocupa máis dunha liña. Isto permitirache reestruturar facilmente a API se non resulta perfecta a primeira vez.
• Describir casos de usoantes de implementar a API ou mesmo de traballar na súa especificación. Deste xeito evitarás implementar e especificar unha API completamente non funcional.

Se tivese escrito mesmo unha breve sinopsis cun guión artificial, moi probablemente tería identificado o erro e corrixido. Se non, entón un dos meus compañeiros definitivamente o faría. Calquera decisión que teña consecuencias de gran alcance debe ser pensada polo menos durante un día (isto non só se aplica á programación).

O título do ensaio de Richard Gabriel, "Worrse Is Better", fai referencia á vantaxe que supón ser o primeiro en comercializar -aínda cun produto imperfecto- mentres outra persoa pasa unha eternidade perseguindo o perfecto. Reflexionando sobre o código sprite, doume conta de que nin sequera tiven que escribir máis código para facelo ben. Diga o que se diga, estaba moi equivocado.

Conclusión

Os programadores cometen erros todos os días, xa se trate de escribir código con erros ou non querer probar algo que mellore a súa habilidade e produtividade. Por suposto, podes ser programador sen cometer erros tan graves como eu. Pero é imposible converterse nun bo programador sen recoñecer os teus erros e aprender deles.

Encontro constantemente estudantes que senten que cometen demasiados erros e, polo tanto, non están preparados para a programación. Sei o común que é a síndrome do impostor nas TI. Espero que aprendas as leccións que enumerei, pero lembra a principal: cada un de nós cometemos erros: vergoñento, divertido, terrible. Sorprenderei e molestareime se no futuro non teño material suficiente para continuar co artigo.

Fonte: www.habr.com