Código Calligraph VS Code Chicken Scratch

Durante los últimos 17 años he trabajado en más de 90 proyectos con muchos equipos. Pero no fue hasta que encontré la blamefunción de Git que aprendí sobre la "escritura a mano" de cada programador. Esta simple curiosidad pronto se convirtió en un hábito. Siempre que veía un código nuevo, intentaba adivinar quién lo escribió. Entonces verificaría mi suposición con un git blame.

(Por cierto, si aún no está familiarizado con git, es una forma popular para que los desarrolladores colaboren en el código, y su función de "culpa" le muestra quién es el autor de un código fuente de línea determinado).

Después de un par de años, comencé a ver patrones, al igual que un experto en escritura a mano podría detectar a un sociópata por la forma en que dibuja sus W. La escritura en código revela mucho sobre el programador que la escribió.

Puede aprender casi cualquier cosa de la escritura del código de un programador: cuánta experiencia tienen, cuánto les importa la legibilidad de su código (y, por extensión, cuánto se preocupan por sus compañeros de equipo).

El código habla. ¡El código incorrecto grita! Entonces, ¿el código que está leyendo es un código de caligrafía o es un código de cero?

Un breve descargo de responsabilidad: lo que estás a punto de leer se basa puramente en mi intuición subjetiva. Hasta donde yo sé, no ha habido estudios académicos revisados ​​por pares. Mis habilidades de análisis de escritura de código me han servido bien en el pasado y también pueden ayudarlo, pero, como con todo lo que lee en Internet, su kilometraje puede variar.

Insight # 1: código hinchado = lucha

Por lo general, cuando descubro un código que se ha hinchado y mucho más grande de lo necesario, muestra a un programador que estaba luchando por terminar una tarea que estaba más allá de sus habilidades. O no tenían el conocimiento o el tiempo para terminar el trabajo correctamente.

En la vida real, las personas que hacen menos tienden a hablar más. Es lo mismo en la tierra de los códigos: aquellos que no pueden hacer el trabajo con elegancia tienden a escribir mucho código.

Desafortunadamente, los errores se alimentan del código, y cuantas más disposiciones de código, mayor es el hábitat de los errores.

"Odio el código y quiero la menor cantidad posible de este en nuestro producto" - Jack Diederich

Insight # 2: Código muerto = descuido

¿Alguna vez ha visto grandes bloques de código comentado comprometidos con el repositorio? O peor aún: ¿código que no hace nada especial pero que existe por razones históricas?

Curiosamente, esto tiene una correlación directa con el desorden del escritorio del programador que lo escribió. ¿Alguna vez ha visto comentarios o pruebas desactualizados? Sí, encontraste a un programador descuidado.

3. Código complejo = estupidez o codicia

Me encanta esta cita de Schumacher:

“Cualquier tonto inteligente puede hacer las cosas más grandes, más complejas y más violentas. Se necesita un toque de genialidad y mucho coraje para moverse en la dirección opuesta ". - Fritz Schumacher

Si encuentra un código que es difícil de seguir o comprender, tenga la seguridad de que fue escrito por alguien que no tiene ni idea de lo que está haciendo o por alguien que busca seguridad laboral al tomar la "propiedad" de esa parte del código.

Insight # 4: Comentarios = un jugador de equipo (a menos que…)

Todos los lenguajes de alto nivel permiten escribir código lo suficientemente legible como para que no necesite comentarios. Pero a veces la complejidad es inevitable debido a la falta de conocimiento, tiempo o marco elegante.

Realmente me encanta cuando los programadores ponen un enlace a la referencia de API o una pregunta relevante de Stack Overflow cuando se dan cuenta de que sus compañeros (o su yo futuro) cuestionarán una línea de código en particular.

Dicho esto, el uso excesivo de comentarios muestra una falta de autoestima (o, como mencioné anteriormente, tratar de explicar el “código inflado”).

Insight # 5: Nombres = habilidad de comunicación

Nombres de variables, nombres de funciones, nombres de parámetros, nombres de clases. Estos son el nivel básico de comunicación para los encargados del mantenimiento del código.

Si encuentra nombres de una sola letra (excepto i, que es el predeterminado en los forbucles), ha encontrado un programador con falta de habilidades de comunicación o empatía por los demás.

A menos que sea un proyecto temporal que no se mostrará a nadie más ni se mantendrá, cada segundo que se dedique a elegir un nombre adecuado da como resultado un buen karma.

Y si la funcionalidad de una entidad cambia, es importante refactorizar su nombre en consecuencia.

Algunos programadores afirman que los nombres no son importantes, ya que a las máquinas no les importa. Bueno, a menos que esté escribiendo código literalmente en ceros y unos, ¡también está escribiendo código para humanos!

Insight n. ° 6: legibilidad deficiente = falta de fluidez

A veces, los programadores dominan un idioma, pero intentan torcer y doblar otro idioma para comportarse como su idioma favorito.

JavaScript es uno de esos lenguajes de destino deficientes.

La mayoría de los programadores de back-end tienen el lujo de elegir su "lengua materna". Y muchos son lo suficientemente valientes como para hackear algunas líneas de código front-end. Pero dado que la tierra del navegador es principalmente JavaScript (que es un lenguaje flexible), intentan imitar cualquier patrón que les sea familiar de su "lengua materna".

¡Todo esto está bien hasta que un programador de JavaScript real ve el código y se tira de los pelos!

Insight # 7: Hacks = personalidad superficial o falta de disciplina

¿Alguna vez pasó mucho tiempo ordenando una base de código solo para presenciar a su compañero vertiendo gasolina en su hermoso código usándolo como una plataforma para arreglos rápidos y sucios?

Felicitaciones: ¡conociste a un hacker!

Los piratas informáticos son excelentes para hacer arreglos rápidos sin molestarse en comprender la arquitectura de manera integral (generalmente al preocuparse por un depurador o mediante prueba y error).

Entonces, ¿cuál es el truco? Solucionan un problema y crean otros 10.

Los consultores tienden a mostrar este comportamiento (ya que su tiempo es caro y no van a vivir con las consecuencias de sus cambios). Además, se les puede pagar para solucionar esos otros 10 problemas y sembrar seguridad laboral creando 100 nuevos.

Sin embargo, he sido testigo de programadores internos que hacen que hasta los consultores más descuidados parezcan estrellas de rock. ¿Alguna vez estimó que un problema demoraría 8 horas, pero algún gerente de producto recorta su estimación a solo 1 hora? Generalmente es entonces cuando nacen los trucos.

Dicho esto, a veces necesita una entrega rápida (como durante la fase de creación de prototipos en una puesta en marcha para validar la idea) y se acepta para recortar gastos debido a los recursos limitados. A nadie le importa un código bonito que no resuelva ningún problema. ¡Pero todavía hay una diferencia entre cortar con tijeras o cortar con un machete!

Insight # 8: Inconsistencia = orgullo y fanatismo

En Roma has lo que hacen los romanos. - un proverbio

Hay tantas convenciones de codificación. Realmente no importa cuál se elija. Pero una vez que su equipo elige algunas convenciones, es fundamental que las respeten.

Si los colaboradores ignoran algunas o todas las convenciones, están pirateando o están demasiado orgullosos para cambiar su estilo para que coincida con su base de código.

Lo peor de todo es cuando, en cambio, presionan por sus propias convenciones. Eso es puro fanatismo. Y puede estar seguro de que el programador también es de mente estrecha en otros asuntos.

Insight # 9 código WET = mala memoria

Lo contrario de Dry ("No te repitas") es WET ("Disfrutamos escribiendo" o "Escribe todo dos veces").

Bueno, los errores se reproducen a través de un proceso complicado llamado "copiar" y "pegar".

Sorprendentemente, existen muchos tipos de código WET. Por ejemplo:

  1. Una función o clase que se escribe dos veces, solo con pequeñas diferencias
  2. Una variable que tiene el valor de otra variable.
  3. Un conjunto de instrucciones repetitivas que pueden residir en una función.

Esto es diferente del código inflado, en que en lugar de ser simplemente complejo o retorcido, el código WET se repite literalmente.

Por lo general, el código repetitivo es una señal de que un programador no puede recordar (o peor aún, no ha visto) el otro código similar. Una de las principales tareas del cerebro humano es detectar patrones. Cuando un programador no puede detectar un código similar, es una señal de inexperiencia o falta de atención a los detalles.

Perspicacia n. ° 10. Soluciones temporales = falta de disciplina

A veces, los desarrolladores inyectarán una solución rápida y sucia como una solución temporal, con la esperanza de que algún día puedan refactorizarla. Esto suele ocurrir debido a una fecha límite cercana o por falta de conocimiento. Pero como todos sabemos, las soluciones temporales están ahí para quedarse.

Las soluciones temporales indican un ingeniero pragmático que carece de gusto u orgullo por su trabajo. También pueden ser un signo de baja autoestima, porque no quieren decepcionar a nadie más (jefe, cliente, etc.).

La única vez que se acepta una solución temporal es para un proyecto de aprendizaje o creación de prototipos (prueba de concepto). E incluso en esos casos, es mejor refactorizarlo tan pronto como sepa cómo hacerlo de la manera correcta.

Perspectiva n. ° 11: muchas dependencias = descuido para el futuro del proyecto

Las dependencias deben mantenerse actualizadas. Cuando un proyecto tiene demasiadas dependencias, es un signo de descuido.

Es difícil decir qué es "demasiado", pero la regla general es: si el proyecto puede sobrevivir fácilmente sin una dependencia, es redundante.

Otra medida es que si no hay un requisito necesario para el problema subyacente que la dependencia está resolviendo, probablemente sea innecesario.

Hay tres motivaciones para las dependencias innecesarias:

Razón # 1: El desarrollador está demasiado ansioso por aprender cosas nuevas.

Al importar nuevas dependencias, tienen la oportunidad de hacer ese aprendizaje en un proyecto real.

La curiosidad es buena, pero debería haber otras plataformas de aprendizaje, como proyectos paralelos, tareas a corto plazo o hackatones.

No quiere perder a un buen desarrollador porque piensa que no puede crecer en su trabajo, pero tampoco quiere que traten su producto como su proyecto favorito.

Razón # 2: Lo hizo un desarrollador junior demasiado ambicioso.

Los recién llegados en cualquier campo tienden a sentirse abrumados por todas las nuevas palabras de moda, y por frustración o ignorancia (o la recomendación de un “profesional”) pueden decidir “saltar a la piscina” y aprender todo a la vez. No los dejes. Elija su tecnología.

Razón # 3: el desarrollador tiene equipaje de otro trabajo (o un proyecto paralelo)

Quieren tener una ventaja sobre sus compañeros aportando algo que solo ellos conocen muy bien.

Desafortunadamente, no hay una solución fácil para esto, excepto las habilidades blandas: el equipo tiene que cuestionar la elección de cada dependencia, y si existe un proceso adecuado de revisión y combinación de código, hace que sea difícil introducir código terrible sin que alguien lo note.

A veces, el codificador de vaqueros en cuestión puede hacer una refactorización masiva y luego poner al equipo en una posición para aceptar todo el cambio porque ya está hecho. Bueno, no lo hagas! Pídales que dividan su solicitud de extracción en partes más pequeñas y sean escépticos acerca de traer nuevas dependencias. Sí, es más trabajo, pero ahorrará mucho más tiempo y energía a largo plazo.

Los buenos desarrolladores se preocupan por el futuro de su proyecto porque gastaron su recurso más finito y preciado para crearlo: ¡su tiempo!

Por cierto, muchas dependencias y palabras de moda también pueden ser una señal de que el desarrollador está elaborando un currículum y ya se está preparando para su próximo trabajo.

Caligrafía de código

Ahora que hemos hablado del código scratch de pollo, hablemos de la otra cara: el código que es un placer absoluto de leer.

Algunos incluso dicen que "el código es poesía".

El código fuente de jQuery o lodash son excelentes ejemplos, pero casi todas las bibliotecas populares en Github en las que muchos contribuyentes eventualmente convergerán en la belleza. Esto, amigos míos, es una maravillosa caligrafía en código .

Esencialmente, un gran código es:

  1. Fácil de leer, seguir y depurar
  2. Flexible, configurable y extensible
  3. Inteligente con el uso de recursos
  4. Alto rendimiento

Tenga en cuenta que algunos proyectos exigen un orden diferente. Por ejemplo, es posible que el código fuente de Linux no sea muy fácil de leer porque el rendimiento es más importante para un sistema operativo. O una sencilla aplicación de IoT integrada puede sacrificar la configuración a favor de la optimización de recursos.

De todos modos, hay mucho más que puedes descubrir sobre tus compañeros con solo analizar su código. ¡El código habla más fuerte que las palabras! Entonces, la próxima vez que lea un código, pruebe el git blamecomando y comience a reconocer la escritura del código.

¿Te gustó lo que leíste? Sígueme para recibir notificaciones cuando escriba algo nuevo.

También es posible que desee comprobar por qué la programación es el mejor trabajo de todos.