5 Citas de Programación Famosas, Explicadas

Ser programador es inscribirse para una vida de aprendizaje constante. La fuente de lo nuevo—nuevas funciones, nuevos lenguajes, nuevas herramientas, nuevos marcos-nunca deja de brotar. Pero la informática también es un campo sorprendentemente tradicional que se basa en principios probados en el tiempo. Hemos añadido programación orientada a objetos, hardware moderno e inteligencia artificial. Pero a pesar de estos cambios, muchas de las ideas que se articularon por primera vez hace una generación siguen siendo válidas hoy en día.

En este artículo, he analizado algunas de mis citas favoritas sobre informática. La única condición que pongo es que cada cita tenga al menos veinte años de antigüedad. Porque mientras la tecnología antigua se vuelve inútil rápidamente, los antiguos mandamientos de nuestros antepasados de la programación tienen mucho más poder de permanencia.

“Todos los problemas en informática se pueden resolver por otro nivel de indirección.”- David Wheeler

Aquí hay una cita de compsci a menudo repetida que pocos desarrolladores quieren explicar. Pero es una de mis verdades de programación favoritas, porque golpea el corazón de lo que es la codificación.

La forma más fácil de empezar a pensar en la indirección es imaginar capas. Por ejemplo, supongamos que tiene un proyecto pequeño que necesita encajar el componente A en el componente B:

Ambos componentes están estandarizados, por lo que no puede romperlos y cambiar la forma en que funcionan. Podrías construir un componente completamente nuevo (PlugTwoProngVariant), pero eso es mucho trabajo y duplicación innecesaria. Un mejor enfoque es agregar una capa entre las dos piezas, un adaptador que se ajuste a ambos componentes y se traslade entre ellos.

Ahora, si la indirección se limitara a agregar una nueva capa para unir piezas incompatibles, sería agradable pero muy útil. Pero la idea de resolver problemas construyendo en torno a ellos es un concepto que se extiende desde la parte inferior hasta la parte superior de la computación. Lo ves cuando intentas adaptar un nuevo modelo de datos a una interfaz de usuario antigua. Lo ves cuando intentas adaptar una aplicación heredada a un nuevo backend de servicio web. Lo ve cuando necesita utilizar funciones de nivel superior, como el registro y el almacenamiento en caché, o coordinar servicios de nivel superior, como mensajería y transacciones. Y en la parte superior de la pirámide, llegarás a temas enrarecidos como el aprendizaje automático (cuando no puedas codificar el comportamiento que necesitas, escribe otra capa de código que lo resuelva por ti).

Mucha gente te dirá que la codificación se trata de escribir instrucciones explícitas en un lenguaje que incluso las computadoras idiotas pueden entender. Pero la cita de David Wheeler revela una mejor visión. Una buena programación consiste en subir la escalera de la abstracción para llegar a las soluciones más generales.

Cotización relacionada con el bono:

La indirección es poderosa, pero hay un costo para la complejidad. La gente muy rara vez cita el comentario de seguimiento inmediato de Wheeler sobre la indirección:

“Pero eso generalmente creará otro problema.”- David Wheeler

Esa verdad ha mantenido a los programadores en el negocio desde entonces.

Sobre la simplicidad

“La simplicidad es un requisito previo para la fiabilidad.”- Edsger Dijkstra

No faltan programadores sabios que nos adviertan de no complicar en exceso nuestro código. Pero pocos ponen el costo de la complejidad más claro que el pionero holandés en informática Edsger Dijkstra.

Aquí está la idea: No eliges la simplicidad como un regalo para el futuro. No lo haces porque estás anticipando la oportunidad de reutilizar tu código, o porque quieres que se vea más limpio en una revisión de código, o porque quieres que sea más fácil de modificar. (¡Aunque todos estos beneficios son valiosos! Lo haces porque la simplicidad es un requisito previo. Sin simplicidad, nunca podrá tener un código confiable en el que pueda confiar para administrar un negocio o manejar sus datos.

Para aceptar el punto de Dijkstra, necesitamos redefinir lo que significa “buen código”. No es el código más corto. No es necesariamente el código más rápido. Definitivamente no es el código más inteligente. Es un código en el que se puede confiar.

Cotización relacionada con el bono:

Una de las mejores formas de mantener el código simple es recordar que menos es más. Dijkstra ofrece una métrica para ayudarnos a tener eso en cuenta:

“Si queremos contar líneas de código, no debemos considerarlos como “líneas producido” sino como ” líneas pasado.””- Edsger Dijkstra

Sobre Legibilidad y Reescritura

“Es más difícil leer código que escribirlo.”- Joel Spolsky

A primera vista, esta cita de Joel Spolsky, leyenda del software y co-creador de StackOverflow, parece verdadera pero engañosamente superficial. Sí, el código puede ser denso, conciso y tediosamente largo. Y no es sólo el código de otras personas. Si nos fijamos en su propio trabajo de hace un año, probablemente necesitará algo de tiempo para analizar la lógica que una vez conoció íntimamente.

Pero la visión de Spolsky viene con un giro. El peligro del código que no puedes leer no es solo obvio (es difícil cambiarlo y mejorarlo). En cambio, el mayor peligro es que el código complejo parece ser peor de lo que realmente es. De hecho, la carga de tratar de entender el código ya escrito de otra persona es tan grande que podría sentirse tentado a cometer lo que Spolsky llama el peor error posible: decidir reescribir ese código desde cero.

No es que las reescrituras no puedan mejorar la arquitectura de un sistema. Definitivamente pueden. Pero estas mejoras tienen un gran costo. Restablecen el reloj en las pruebas y la corrección de errores, dos actividades que llevan mucho más tiempo que la mera codificación. Las reescrituras son tentadoras porque juegan con uno de los sesgos más comunes en el desarrollo de software: Subestimamos el esfuerzo por hacer cosas que son conceptualmente simples. Es por eso que el 5% final de un proyecto toma el 50% del tiempo. ¡Las cosas fáciles pueden ser sorprendentemente largas! Y nada parece más fácil que resolver un problema que ya has resuelto.

Entonces, si no debe reescribir todo para que sea perfecto, ¿cuál es la mejor solución? La respuesta es involucrar a todos los desarrolladores en la refactorización constante del tamaño de un bocado. Esto le brinda una pequeña mejora continua del código, recompensas reales con riesgos mínimos. Puede mejorar la legibilidad en el camino.

Cotización relacionada con el bono:

Si aún tiene dudas sobre la importancia de la legibilidad, Martin Fowler ayuda a ponerlo en perspectiva:

“Cualquier tonto puede escribir código que una computadora pueda entender. Los buenos programadores escriben código que los humanos pueden entender.”- Martin Fowler

En otras palabras, el trabajo de un programador no es solo hacer que las cosas funcionen, sino hacer que las cosas tengan sentido.

En Repetición

“No te repitas. Cada pieza de conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema.”- Andy Hunt y Dave Thomas

Todo programador que se precie sabe que la repetición es el corazón de mucho mal. Si estás escribiendo lo mismo en diferentes lugares, estás haciendo trabajo extra de escritura, pruebas y depuración. Peor aún, está introduciendo la posibilidad de inconsistencias, por ejemplo, si una parte del código se actualiza pero otras rutinas similares no están de acuerdo. Un programa inconsistente es un programa en el que no se puede confiar, y un programa en el que no se puede confiar ya no es una solución viable.

sin Embargo, el código no es el único lugar donde la repetición causa estragos. Esta versión de la famosa regla “no te repitas” (SECA) expande el principio de no duplicación para cubrir los otros lugares donde las inconsistencias pueden ocultarse. Ya no estamos hablando de duplicación de código. También estamos hablando de repetición en un sistema — y un sistema tiene muchas formas diferentes de codificar el conocimiento. Incluyen::

• Instrucciones de código
• Comentarios de código
• Documentación para desarrolladores o clientes
• Esquemas de datos (por ejemplo, tablas de base de datos)
• Otras especificaciones, como planes de prueba, documentos de flujo de trabajo y reglas de compilación

Todos estos niveles pueden superponerse entre sí. Y cuando lo hacen, se arriesgan a introducir diferentes versiones de la misma realidad. Por ejemplo, ¿qué sucede si la documentación describe una forma de trabajar pero la aplicación sigue otra? ¿Quién tiene la propiedad de la verdad? ¿Qué sucede si las tablas de la base de datos no coinciden con el modelo de datos del código? ¿O los comentarios describen el funcionamiento de un algoritmo que no coincide con su implementación real? Cada sistema necesita una representación única y autorizada de la que deriva todo lo demás.

Por cierto, las versiones competidoras de la verdad no son solo un problema en proyectos a pequeña escala o código mal diseñado. Uno de los mejores ejemplos surgió en el público con la batalla entre XHTML y HTML5. Un campamento argumentó que la especificación era la verdad oficial, y los navegadores necesitaban ser corregidos para seguirla. La otra facción afirmó que el comportamiento del navegador era el estándar de facto, porque eso es lo que los diseñadores tenían en mente cuando escribieron páginas web. Al final, la versión de navegador de la verdad ganó. A partir de ese momento, HTML5 fue lo que hicieron los navegadores, incluidos los accesos directos que permitieron y los errores que aceptaron.Cotización relacionada con el bono

:

La posibilidad de que el código y los comentarios se contradigan entre sí ha abierto un acalorado debate sobre si los comentarios hacen más daño que bien. Los defensores de la Programación Extrema los tratan con abierta sospecha:

“El código nunca miente; los comentarios a veces lo hacen.”- Ron Jeffries

En Problemas Difíciles

“Solo hay dos cosas difíciles en informática: invalidación de caché y nombres de cosas.”- Phil Karlton

A primera vista, esta cita parece una broma de programación divertida pero ordinaria. El contraste entre algo que suena difícil (invalidación de caché) y algo que suena indoloro (nombrar cosas) es instantáneamente identificable. Cada programador ha invertido horas de trabajo arreglando un problema ridículamente trivial, como un par de parámetros pasados en el orden incorrecto o una variable inconsistente en mayúsculas (gracias JavaScript). Mientras los humanos necesiten asociarse con máquinas para hacer las cosas, la programación será una mezcla de planificación de sistemas de alto nivel y errores tipográficos triviales.

Pero si echas un segundo vistazo a la cita de Phil Karlton, hay más que desempacar. Nombrar las cosas no es difícil solo porque la vida de un programador se arruina regularmente por pequeños dolores de cabeza. También se debe a que el tema de los nombres es en realidad la ventaja del trabajo más importante de cada programador: el diseño de software. En otras palabras, ¿cómo se escribe un código que sea claro, limpio y consistente?

Hay muchas maneras de equivocarse en el nombre. Todos hemos visto variables con nombres de tipos de datos (myString, obj), abreviaturas (pc para catálogo de productos), algunos detalles de implementación triviales(swappable_name, formUserInput), o incluso nada en absoluto (ret_value, tempArray). Es fácil caer en la trampa de nombrar una variable en función de lo que está haciendo con ella en ese momento en lugar de lo que contiene. Y los valores booleanos son particularmente complicados: progress establece cuándo comienza el progreso, indica que necesita mostrar información de progreso en la interfaz de usuario o marca algo completamente diferente?

Pero los nombres de las variables son sólo el comienzo. Las clases de nombres plantean la cuestión de cómo dividir el código en partes independientes. Los nombres de miembros públicos determinan cómo presentas la interfaz que permite que una parte de la aplicación interactúe con otra. Bloquear estos nombres no solo describe lo que puede hacer una pieza de código, sino que determina lo que hará.Cotización relacionada con el bono

:

“Hay dos cosas difíciles en la informática: invalidación de caché, nombres de cosas y errores desactivados por uno.”- Leon Bambrick