Cita de Torvalds sobre buen programador [cerrado]

Accidentalmente me topé con la siguiente cita de Linus Torvalds:

"Los malos programadores se preocupan por el código. Los buenos programadores se preocupan por las estructuras de datos y sus relaciones".

Lo he pensado durante los últimos días y todavía estoy confundido (lo que probablemente no sea una buena señal), por lo tanto, quería discutir lo siguiente:

• ¿Qué interpretación de esto es posible / tiene sentido?
• ¿Qué se puede aplicar / aprender de él?

Podría ser útil considerar lo que dijo Torvalds justo antes de eso:

git en realidad tiene un diseño simple, con estructuras de datos estables y razonablemente bien documentadas. De hecho, soy un gran defensor del diseño de su código en torno a los datos, en lugar de al revés, y creo que es una de las razones por las que git ha tenido bastante éxito [...]. De hecho, afirmaré que la diferencia entre un mal programador y uno bueno es si considera que su código o sus estructuras de datos son más importantes.

Lo que está diciendo es que las buenas estructuras de datos hacen que el código sea muy fácil de diseñar y mantener, mientras que el mejor código no puede compensar las estructuras de datos deficientes.

Si se está preguntando sobre el ejemplo de git, muchos sistemas de control de versiones cambian su formato de datos con relativa regularidad para admitir nuevas funciones. Cuando actualiza para obtener la nueva función, a menudo también tiene que ejecutar algún tipo de herramienta para convertir la base de datos.

Por ejemplo, cuando DVCS se hizo popular por primera vez, mucha gente no podía entender qué pasaba con el modelo distribuido, las fusiones eran mucho más limpias que el control de versiones centralizado. La respuesta es absolutamente nada, excepto que las estructuras de datos distribuidos tenían que ser mucho mejores para tener la esperanza de funcionar. Creo que los algoritmos de fusión centralizados se han puesto al día desde entonces, pero tomó bastante tiempo porque sus viejas estructuras de datos limitaban los tipos de algoritmos que podían usar, y las nuevas estructuras de datos rompieron una gran cantidad de código existente.

Por el contrario, a pesar de una explosión de características en git, sus estructuras de datos subyacentes apenas han cambiado. Preocúpese primero por las estructuras de datos, y su código será naturalmente más limpio.

Algoritmos + Estructuras de datos = Programas

El código es solo la forma de expresar los algoritmos y las estructuras de datos.

Esta cita es muy familiar para una de las reglas en "The Art of Unix Programming", que es el fuerte de Torvalds para ser el creador de Linux. El libro se encuentra en línea aquí.

Del libro está la siguiente cita que expone lo que dice Torvalds.

Regla de representación: Doble el conocimiento en datos para que la lógica del programa pueda ser estúpida y sólida.

Incluso la lógica de procedimiento más simple es difícil de verificar para los humanos, pero las estructuras de datos bastante complejas son bastante fáciles de modelar y razonar. Para ver esto, compare la expresividad y el poder explicativo de un diagrama de (digamos) un árbol de puntero de cincuenta nodos con un diagrama de flujo de un programa de cincuenta líneas. O compare un inicializador de matriz que exprese una tabla de conversión con una instrucción de cambio equivalente. La diferencia en transparencia y claridad es dramática. Ver la Regla 5 de Rob Pike.

Los datos son más manejables que la lógica del programa. De esto se deduce que cuando vea una opción entre la complejidad en las estructuras de datos y la complejidad en el código, elija el primero. Más: al desarrollar un diseño, debe buscar activamente formas de cambiar la complejidad del código a los datos.

La comunidad de Unix no originó esta idea, pero una gran cantidad de código de Unix muestra su influencia. La facilidad del lenguaje C para manipular punteros, en particular, ha alentado el uso de estructuras de referencia modificadas dinámicamente en todos los niveles de codificación desde el núcleo hacia arriba. Las persecuciones de puntero simples en tales estructuras con frecuencia cumplen funciones que las implementaciones en otros idiomas tendrían que incorporar en procedimientos más elaborados.

El código es fácil, la lógica detrás del código es compleja.

Si está preocupado por el código, eso significa que aún no comprende los conceptos básicos y es probable que se pierda en el complejo (es decir, las estructuras de datos y sus relaciones).

Para ampliar un poco la respuesta de Morons , la idea es que comprender los detalles del código (sintaxis y, en menor medida, estructura / diseño) es lo suficientemente fácil como para construir herramientas que puedan hacerlo. Los compiladores pueden comprender todo lo que se necesita saber sobre el código para convertirlo en un programa / biblioteca en funcionamiento. Pero un compilador en realidad no puede resolver los problemas que hacen los programadores.

Podría llevar el argumento un paso más allá y decir "pero tenemos programas que generan código", pero el código que genera se basa en algún tipo de entrada que casi siempre se construye a mano.

Entonces, sea cual sea la ruta que tome para llegar al código: ya sea a través de algún tipo de configuración u otra entrada que luego produce código a través de una herramienta o si lo está escribiendo desde cero, no es el código lo que importa. Lo que importa es el pensamiento crítico de todas las piezas que se requieren para llegar a ese código. En el mundo de Linus, eso es en gran medida estructuras y relaciones de datos, aunque en otros dominios puede ser otras piezas. Pero en este contexto, Linus solo dice "No me importa si puedes escribir código, me importa que puedas entender las cosas que resolverán los problemas con los que estoy lidiando".

Linus significa esto:

Muéstrame tus diagramas de flujo [código], y oculta tus tablas [esquema], y seguiré desconcertado; muéstrame tus tablas [esquema] y generalmente no necesitaré tus diagramas de flujo [código]: serán obvios.

- Fred Brooks, "El mes del hombre mítico", cap. 9.

Creo que está diciendo que el diseño general de alto nivel (estructuras de datos y sus relaciones) es mucho más importante que los detalles de implementación (código). Creo que valora a los programadores que pueden diseñar un sistema sobre aquellos que solo pueden centrarse en los detalles de un sistema.

Ambos son importantes, pero estaría de acuerdo en que, en general, es mucho mejor obtener una visión general y tener problemas con los detalles que al revés. Esto está estrechamente relacionado con lo que estaba tratando de expresar acerca de dividir las funciones grandes en pequeñas .

Bueno, no puedo estar completamente de acuerdo, porque tienes que preocuparte por todo. Y para el caso, una de las cosas que me encantan de la programación son los cambios a través de diferentes niveles de abstracción y tamaño que saltan rápidamente de pensar en nanosegundos a pensar en meses, y viceversa.

Sin embargo, las cosas superiores son más importantes.

Si tengo una falla en un par de líneas de problemas que causa un comportamiento incorrecto, probablemente no sea demasiado difícil de solucionar. Si está causando un bajo rendimiento, probablemente ni siquiera importe.

Si tengo una falla en la elección de la estructura de datos en un subsistema, que causa un comportamiento incorrecto, es un problema mucho más grande y más difícil de solucionar. Si está causando un bajo rendimiento, podría ser bastante grave o soportable, aún apreciablemente menos bueno que un enfoque rival.

Si tengo una falla en la relación entre las estructuras de datos más importantes en una aplicación, que causa un comportamiento incorrecto, tengo un rediseño masivo frente a mí. Si está causando un bajo rendimiento, podría ser tan malo que casi sería mejor si se comportara mal.

Y será lo que dificulte la búsqueda de esos problemas de nivel inferior (solucionar errores de bajo nivel normalmente es fácil, encontrarlos puede ser difícil).

Las cosas de bajo nivel son importantes, y su importancia restante a menudo se subestima seriamente, pero palidece en comparación con las cosas grandes.

Alguien que conoce el código ve los "árboles". Pero alguien que entiende las estructuras de datos ve el "bosque". Por lo tanto, un buen programador se centrará más en las estructuras de datos que en el código.

Saber cómo fluirán los datos es muy importante. Conocer el flujo requiere que diseñe buenas estructuras de datos.

Si retrocede veinte años, este fue uno de los grandes puntos de venta para el enfoque orientado a objetos utilizando SmallTalk, C ++ o Java. El gran argumento, al menos con C ++ porque eso fue lo que aprendí primero, fue diseñar la clase y los métodos, y luego todo lo demás caería en su lugar.

Indudablemente, Linus estaba hablando en términos más amplios, pero las estructuras de datos mal diseñadas a menudo requieren una revisión adicional del código, lo que también puede generar otros problemas.

¿Qué se puede aplicar / aprender de él?

Si puedo, mi experiencia en las últimas semanas. Las discusiones anteriores aclararon la respuesta a mi pregunta: "¿qué aprendí?"

Reescribí un código y reflexioné sobre los resultados que seguía viendo y diciendo "estructura, estructura ..." es la razón por la cual hubo una diferencia tan dramática. Ahora veo que fue la estructura de datos la que marcó la diferencia. Y me refiero a todo .

• Al probar mi entrega original, el analista de negocios me dijo que no estaba funcionando. Dijimos "agregar 30 días" pero lo que queríamos decir era "agregar un mes" (el día en la fecha resultante no cambia). Agregue años, meses y días discretos; No 540 días durante 18 meses, por ejemplo.

• La solución: en la estructura de datos, reemplace un entero entero con una clase que contenga múltiples enteros, el cambio a su construcción se limitó a un método. Cambie las declaraciones aritméticas de la fecha real, las 2 de ellas.

La recompensa

• La nueva implementación tenía más funcionalidad, pero el código del algoritmo era más corto y claramente más simple.

En la fijación del comportamiento del código / resultados:

• Cambié la estructura de datos, no el algoritmo.
• NO se tocó la lógica de control en ningún lugar del código.
• No se cambió la API.
• La clase de fábrica de estructura de datos no cambió en absoluto.

Me gusta imaginar un equipo muy inteligente de bibliotecarios en una biblioteca bellamente hecha con un millón de libros al azar y brillantes, sería una locura.

No puedo estar más de acuerdo con Linus. Centrarse en los datos ayuda a destilar en gran medida una solución simple y flexible para un problema dado. Git en sí mismo es un ejemplo de prueba: dado que hay tantas funciones compatibles en los años de desarrollo, la estructura de datos central permanece en gran medida sin cambios. Eso es magia! --2c

He visto que esto es numerosas áreas.

Piense en el análisis comercial ... Supongamos que está analizando la mejor manera de apoyar el marketing en una empresa de productos de consumo como Colgate. Si comienza con ventanas sofisticadas o la última tecnología, no ayudará a la empresa casi tanto como si piensa primero en las necesidades de datos de la empresa y luego se preocupa por la presentación posterior. El modelo de datos dura más que el software de presentación.

Considera hacer una página web. Es mucho mejor pensar primero en lo que quiere mostrar (el HTML) y preocuparse por el estilo (CSS) y las secuencias de comandos (elija su herramienta) después.

Esto no quiere decir que la codificación no sea importante también. Necesita habilidades de programación para obtener lo que necesita al final. Es que los datos son la base. Un modelo de datos deficiente refleja un modelo de negocio demasiado complejo o poco pensado.

Me encuentro escribiendo nuevas funciones y actualizando las existentes con mucha más frecuencia que tener que agregar nuevas columnas o tablas a mi esquema de base de datos. Esto probablemente sea cierto para todos los sistemas bien diseñados. Si necesita cambiar su esquema cada vez que necesita cambiar su código, es una clara señal de que es un desarrollador muy malo.

Indicador de calidad del código = [cambios en el código] / [cambios en el esquema de la base de datos]

"Muéstrame tus diagramas de flujo y oculta tus tablas, y seguiré desconcertado. Muéstrame tus tablas, y generalmente no necesitaré tus diagramas de flujo; serán obvios". (Fred Brooks)

Parece que esta idea tiene varias interpretaciones en los distintos tipos de programación. Es cierto para el desarrollo de sistemas y también es cierto para el desarrollo empresarial. Por ejemplo, uno podría argumentar que el cambio brusco en el enfoque hacia el dominio en el diseño impulsado por el dominio es muy similar al enfoque en las estructuras y relaciones de datos.

Aquí está mi interpretación: usa código para crear estructuras de datos, por lo que el enfoque debe estar en lo último. Es como construir un puente: debe diseñar una estructura sólida en lugar de una que parezca atractiva. Sucede que las estructuras de datos bien escritas y los puentes se ven bien como resultado de sus diseños eficientes.