Cómo definir una obra maestra en el desarrollo de software

Nunca escuché a nadie usar el término “Master Piece” en el desarrollo de software. Es divertido ya que tenemos aprendices, artesanos y jornaleros. Se podría pensar que tendríamos una obra maestra. Tampoco he oído hablar de un maestro artesano en el campo.

Sin embargo, si uno pudiera producir una obra maestra, tendría que ser una pieza significativa. No tenemos gremios de programadores, al menos ninguno conocido.

Sin embargo, existe un círculo de desarrolladores de software bien conocidos y respetados en la comunidad de desarrollo de software. De facto, cada desarrollador conocido es mejor conocido por alguna creación significativa y, aunque todavía no se considera una obra maestra, por definición de pieza maestra (ver Masterpiece – Wikipedia).

Aquí hay algunos ejemplos de figuras respetadas en la comunidad de desarrollo de software y sus obras maestras.

• Padre de Java – James Gosling – Wikipedia
• Filosofía de código limpio – Robert Martin
• Código libro completo – Steve McConnel
• Patrones de diseño – Banda de cuatro
• Método Booch – Grady Booch
• Lenguaje C – Dennis Ritchie
• Lenguaje C ++ – Bjarne Stroustrup
• COBOL – Grace Hopper
• Linux – Linus Torvald
• El arte de la programación – Knuth
• Algoritmo de ruta más corta: algoritmo de Dijkstra – Wikipedia
• Pac-man – Toru Iwatani
• Facebook – Mark Zuckerberg
• Google – Larry Page
• Creador de jQuery John Resign

Hay muchos más … demasiados, de hecho, para que yo los mencione. Estos son algunos nombres realmente grandes en las siguientes capas, hay otros que son bien conocidos en el mundo contemporáneo.

Para resumir, la obra maestra puede venir en forma de libro, algoritmo, producto de software, metodología, filosofía, o programa de movimiento / movimiento, etc. Hay muchos otros desarrolladores bien conocidos dentro de su nicho que han creado marcos de nicho bien conocidos y tal.

Independientemente, cualquiera puede crear una obra maestra y ser reconocido dentro de su pequeño círculo por ello.

Tendría que decir que una pieza maestra tendría que ser definida por los siguientes atributos:

• El trabajo debe hacerse de forma independiente; por ejemplo, puede ser una pequeña parte de un sistema más grande. Sin embargo, tiene ese componente debe haberse hecho de forma independiente. Tiene que estar completo.
• Tiene que llevar una cantidad significativa de belleza y artesanía. No puede ser algo que pueda ser eliminado por cualquier novato y algo que incluso un desarrollador experimentado tendría que esforzarse mucho para reproducirse.
• Tiene que resolver un problema no trivial. Ese algo obtendría el reconocimiento de sus compañeros.

No requiere que tenga un impacto prolífico como los ejemplos que di anteriormente, pero el trabajo debe ser respetado. Sin embargo, si es bien conocido, sería indiscutible que sea una obra maestra, como en los ejemplos anteriores.

No daré un ejemplo específico, sino un resumen general. El primer lugar para comenzar es disculparnos del criterio de que una obra maestra en software está definida por su interfaz de usuario. En cambio, se puede decir que el software tiene alta calidad cuando cumple con algunos de los estándares definidos por el Dr. Donald Knuth en Vol. 1 de El arte de la programación de computadoras.

En el capítulo 1 del vol. 1, el Dr. Knuth finalmente describe las cualidades de un buen algoritmo. Presenta 5 cualidades de un buen algoritmo. Mientras habla de algoritmos, creo que su criterio es una perspectiva general que puede aplicarse a los propios programas. Los 5 elementos de un buen algoritmo según el Dr. Donald Knuth, resumidos como 5 criterios para un programa de alta calidad son:

1. Finito: el programa tiene puntos claros de inicio y salida. La finalización del programa está bien especificada en todas las circunstancias, incluido el aborto abrupto.
2. Definido: cada función, clase y elemento de código es preciso y no vago. Cada uno tiene una necesidad insustituible de existir y, cuando es posible, no duplica otro elemento funcional sin causa.
3. Entrada: los datos procesados ​​en el programa a través del programa están perfectamente definidos. La entrada se define y evalúa de manera precisa.
4. Salida: un programa siempre tiene salida. Buena entrada, mala entrada, siempre hay una salida correspondiente. No hay agujeros negros en los que haya misterio sobre lo que está haciendo el programa o en qué etapa del procesamiento se encuentra. Toda la salida debe ser rastreable, lógicamente o mediante artefactos de salida, como archivos de registro, hasta la entrada de origen.
5. Efectivo: Dr. Knuth significa que puede ejecutar un algoritmo en el mundo real sin una computadora. Extendido a los programas, esto significa que el programa está lo suficientemente optimizado en un nivel dado de abstracción, que podría explicarlo de manera directa. A partir de este y los puntos anteriores, puede probar en una conversación laica que el programa es correcto.

Cuando traduce estos 5 puntos en un programa, obtiene un resultado que puede considerarse una obra maestra de la siguiente manera. El programa parece relativamente simple, aunque trata con un proceso complejo. Es eficiente porque se escala bien a medida que aumenta la cantidad de datos. El programa evita consumir más memoria de la necesaria, en parte al evitar representaciones de datos por computadora extremadamente ineficientes. El programa generalmente llega al punto de procesar datos al evitar demasiadas capas de abstracción. En general, el programa es rápido y preciso con una cantidad mínima de código necesario para realizar el trabajo.

Esa es una pregunta simple para responder.

En mi opinión, una obra maestra de software es un cuerpo de software que cumple perfectamente sus especificaciones sin errores, donde el código fuente es fácil de entender y mantener por un desarrollador junior. Nada sofisticado, nada “complicado”, solo un cuerpo de código bueno, sólido, correcto y fácil de mantener.

Las obras maestras de software son raras, pero existen. He creado algunos en mi carrera, principalmente cuando tuve la oportunidad de escribir el código desde cero.

Un ejemplo. Personalmente desarrollé todo el firmware para un dispositivo médico y construí una capacidad de actualización remota, aunque nunca se necesitó una sola actualización remota, el sistema funcionó perfectamente desde el primer lanzamiento, sí, la versión 1.0. Miles de personas fueron puestas en el campo sin que se haya reportado un solo error. Para mí, esta fue una obra maestra, y creo que la razón por la que debería ser obvio, hizo exactamente lo que se suponía que debía hacer de manera eficiente y correcta, y sin una sola falla, nunca.

Mi mejor candidato sería TeX:

TeX – Wikipedia

Diseñado por nada menos que Donald Knuth, uno de los científicos informáticos más destacados de nuestro tiempo y autor del muy influyente The Art of Computer Programming, TeX resuelve el problema de formatear texto para publicaciones, como artículos y libros, y lo hace. bella y consistentemente.

Para citar Wikipedia:

‘Desde la versión 3, TeX ha utilizado un sistema de numeración de versión idiosincrásico, donde las actualizaciones se han indicado agregando un dígito adicional al final del decimal, de modo que el número de versión se acerque asintóticamente a π. Esto es un reflejo del hecho de que TeX ahora es muy estable y solo se anticipan actualizaciones menores. La versión actual de TeX es 3.14159265; se actualizó por última vez el 2014-01-12.

Entonces, tiene una herramienta utilizada por miles de científicos y creadores, que ha sido diseñada por uno de los mejores programadores de la historia, y que es tan estable que pasan años antes de que se encuentren errores.

Para mí, esto es programación en su máxima expresión.

En un extremo, el software de guía Apollo, haciendo tanto, con tan poco.

En el otro extremo, el sistema de tiempo de ejecución Erlang. Concurrencia masiva, distribuida, alta disponibilidad, intercambio de código activo, … No hay nada más que se acerque.

También se podría agregar Plan9, por pura elegancia.

Prefiere centrarse en las funciones y responsabilidades para mapear lo básico. A partir de ahí, defina por dónde comenzar y qué tecnología es adecuada teniendo en cuenta el plan de expansión. Por supuesto, la cascada o el método ágil realmente depende de la habilidad de tu equipo.