Convertirse en programador es inscribirse en un entrenamiento de por vida. El flujo de novedades (nuevas funciones, nuevos idiomas, nuevas herramientas, nuevos marcos) nunca se agota. Pero al mismo tiempo, la programación es una esfera, sorprendentemente fiel a las tradiciones, donde todo se basa en principios probados por el tiempo. Introdujimos programación orientada a objetos, soluciones de hardware modernas, inteligencia artificial, sin embargo, a pesar de todos estos cambios, muchos de los axiomas que se formularon en la generación anterior resultan ser ciertos hoy en día.Dediqué este artículo a algunas de mis declaraciones favoritas sobre programación. El único criterio por el cual hice la selección fue el requisito de que la cotización sea igual a por lo menos veinte años. Porque solo las tecnologías obsoletas se vuelven rápidamente inutilizables, mientras que los antiguos mandamientos de nuestros programadores ancestrales han permanecido relevantes durante mucho tiempo.1. Indirecta
"Todos los problemas de programación se resuelven creando un nivel adicional de indirección" - David Willer
Aquí hay una cita del libro Computer Science Theory and Application, que a todos les gusta repetir y a pocas personas les gusta explicar. Sin embargo, esta es una de mis verdades de programación favoritas: revela acertadamente la esencia misma de la programación.La forma más fácil de dar sentido a la indirección es imaginar capas. Bueno, por ejemplo, imagine que tiene un pequeño proyecto en el que necesita colocar el componente A dentro del componente B:Ambos componentes están estandarizados, por lo que desarmarlos en componentes y cambiar el principio de funcionamiento no funcionará. Podría crear un componente adicional separado ( PlugTwoProngVariant), pero esto es tanto trabajo como duplicación innecesaria. Hay una mejor solución: agregue una capa de adaptador entre estos dos componentes que interactúe con éxito con ambos y sirva como intermediario entre ellos.Con todo esto, si la indirección se agota mediante la adición de capas adicionales entre componentes que de otro modo no se acoplarían, sería, por supuesto, útil, pero muy limitada en su aplicación. Pero la idea misma de resolver problemas cambiando el entorno de las áreas problemáticas impregna toda la programación de arriba a abajo. Lo encuentra cuando intenta ajustar un nuevo modelo de datos a la interfaz anterior. Lo encuentra cuando intenta adjuntar una aplicación con código heredado al backend de un nuevo servicio web. Lo encuentra cuando necesita agregar varias funciones nuevas de alto nivel como iniciar sesión y almacenar en caché o coordinar el trabajo de varios servicios de alto nivel como enviar mensajes y realizar transacciones.En la parte superior de esta pirámide, llega a direcciones refinadas como el aprendizaje automático (si no puede escribir su propio comportamiento, agregue otra capa de código que resolverá este problema por usted).Muchos le dirán que el objetivo de la programación es escribir instrucciones claras en un lenguaje que incluso la computadora más tonta pueda entender . Pero la cita de David Wheeler ofrece una mirada más profunda a la pregunta. Ser un buen programador significa subir la escalera de la indirección, luchando por las soluciones más comunes.Una cotización adicional sobreindirecta es una herramienta poderosa, pero hay que pagar por la complejidad. La gente rara vez cita la declaración que sigue inmediatamente a la famosa cita:"Esto generalmente crea un nuevo problema". - David Wheeler.
Gracias a esta verdad, los programadores han permanecido durante mucho tiempo en el negocio.2. Sobre la simplicidad
"La simplicidad es un requisito previo para la confiabilidad" - Edsger Dijkstra
No faltan los programadores sabios que nos advierten contra la complicación del código sin una necesidad urgente. Pero pocos lograron mostrar tan claramente cuál es la complejidad para nosotros como pioneros en informática, Edsger Dijkstra .Este es el punto: usted elige a favor de la simplicidad no solo por el deseo de hacer que el futuro sea agradable para las personas. Y no porque asumas la capacidad de reutilizar este código en el futuro. Y no porque desee que observe con mayor precisión las inspecciones, y no porque desee facilitar el proceso de realizar cambios en el futuro (aunque todo esto, por supuesto, es una ventaja valiosa). Haces esto porque la simplicidad es un requisito previo. Sin él, nunca tendrá un código confiable que pueda confiar para administrar un negocio o trabajar con datos.Para tomar la posición de Dijkstra, necesitamos cambiar nuestra comprensión de lo que es "buen código". Este no es necesariamente el código más conciso, o el más rápido, y ciertamente no es el más abstruso. Un buen código es un código en el que puede confiar.Una cita adicional sobre un temaUna de las mejores maneras de mantener el código simple es recordar que menos es más. Dijkstra ofrece una nueva unidad de medida que siempre nos recordará esto:"Si queremos contar el número de líneas de código, no debemos percibirlas como escritas, sino como gastadas" - Edsger Dijkstra
3. Sobre legibilidad y reescritura
"El código es más difícil de leer que de escribir" - Joel Spolsky
A primera vista, esta cita de Joel Spolsky , leyenda de la programación y cofundador de Stack Overflow, parece razonable, pero aparentemente superficial. Sí, los fragmentos de código son ricos en información, demasiado comprimidos o muy largos. Y esto se aplica no solo a lo que otras personas escribieron. Si miras tu propio trabajo del año pasado, necesitarás algo de tiempo para recrear la lógica que una vez conociste.Pero la observación de Spolsky se desarrolla en algo interesante. El peligro de un código que es difícil de leer no es solo las consecuencias más obvias (es difícil corregirlo y mejorarlo). Existe otro gran peligro: el código que es difícil de leer parece peor de lo que realmente es. De hecho, entender el código de otra persona puede parecer una tarea tan abrumadora que te sentirás tentado a hacer lo que Spolsky llama el más grave de todos los errores : reescribir todo nuevamente.No digo que la arquitectura del sistema nunca se beneficie de tales reescrituras. Por supuesto, sucede que gana. Pero una mejora de este tipo es costosa. En todo lo que concierne a probar y corregir errores, y estos son dos componentes del desarrollo que toman más tiempo que escribir el código en sí, usted regresa a la posición inicial. La reescritura parece tentadora porque encaja en uno de los conceptos erróneos más comunes de los desarrolladores: la tendencia a subestimar los costos laborales de las cosas conceptualmente simples. Es por eso que el 50% del tiempo se gasta en el 5% final del proyecto. ¡Las tareas elementales pueden llevar mucho tiempo! Y la solución a un problema que ya se ha resuelto en el pasado siempre parece simple.Bueno, si reescribe todo desde cero para llevar el código a la perfección, no debería, ¿cuáles son las alternativas más exitosas? Respuesta: involucre a cada desarrollador en el proceso de refactorización fragmentada continua . Por lo tanto, su código se mejora constantemente, debido a una cadena de pequeños cambios, un beneficio real con riesgos mínimos. La legibilidad se puede mejorar en el camino.Cita adicional al temaSi aún duda de la importancia de la legibilidad, Martin Fowler lo ayudará a analizar el problema de manera más amplia:“Cualquier tonto puede escribir código que las computadoras puedan entender. Los buenos programadores escriben código que la gente puede entender. ”- Martin Fowler
En otras palabras, la tarea del programador es emitir no solo código de trabajo, sino también código con lógica interna.4. Sobre repeticiones
"No repitas. Cada conocimiento debe tener una representación única, inequívoca y confiable en el sistema "- Andy Hunt y David Thomas
Todo programador que se precie sabe que muchos problemas radican en la repetición. Si escribe lo mismo en varios lugares, debe dedicar más esfuerzo a probar y corregir errores. Peor aún, crea las condiciones para las discrepancias; por ejemplo, una parte del código puede actualizarse posteriormente y otros procedimientos relacionados pueden no cumplirse. Un programa divergente es un programa en el que no se puede confiar, y un programa en el que no se puede confiar no se puede considerar una solución viable.Este error podría evitarse con el métodoGetTeamUniform(), sin embargo, las repeticiones causan estragos no solo en el código. Esta versión del conocido principio DRY (No te repitas) interpreta el principio de eliminar los duplicados ampliamente, cubriendo otros lugares donde las repeticiones pueden abrirse camino. Ahora la conversación ya no se trata de duplicados en el código; también estamos hablando de repeticiones en todo el sistema. Y los sistemas codifican el conocimiento en varios formatos. En particular, estos son:- Operadores
- Comentarios de código
- Documentación para desarrolladores o clientes.
- Esquemas de datos (por ejemplo, tablas de bases de datos)
- Otras especificaciones: planes de prueba, documentos de organización de procesos, reglas de ensamblaje
Todos estos grupos pueden superponerse en el contenido. Y cuando esto sucede, existe el riesgo de que comiencen a transmitir diferentes versiones de una realidad. Digamos qué hacer si la documentación describe un modelo de trabajo y la aplicación en sí sigue uno diferente. ¿Qué en este caso se considera el poseedor de la verdad? Pero, ¿qué pasa si las tablas en la base de datos no coinciden con el modelo de datos del código? ¿O si los comentarios del código describen una operación o algoritmo que es fundamentalmente diferente de la implementación real? Cada sistema necesita una representación única y confiable sobre la cual descansa todo lo demás.Por cierto, uno no debería pensar que los conflictos entre los solicitantes de la verdad ocurren solo en proyectos pequeños o son el resultado de un código de baja calidad. Uno de los mejores ejemplos que ha aparecido a simple vista es la batalla entre XHTML y HTML5. Un lado afirmó que las especificaciones: esta es la versión oficial correcta, y los navegadores deben adaptarse a ella. Otro grupo objetó que era el comportamiento de los navegadores lo que debería considerarse el estándar de facto; después de todo, así es como los diseñadores imaginaron todo cuando escribieron páginas web. Finalmente, ganó la versión de la verdad que promovieron los navegadores . Desde entonces, HTML5 es lo que realmente hacen los navegadores, incluidos los accesos directos y errores válidos.Cita de bonificación en el tema.La posibilidad de que el código y sus comentarios entren en conflicto entre sí ha generado discusiones animadas: ¿qué más hay de los comentarios, buenos o malos? Los partidarios de la programación extrema los tratan con absoluta desconfianza."El código nunca miente, pero esto sucede con los comentarios" - Ron Jeffries
5. Sobre problemas complejos
"En informática, solo hay dos problemas complejos: invalidar el caché y encontrar nombres" - Phil Carleton
En apariencia, esta cita parece ser solo una broma de programador, divertida, pero no se destaca de las demás. Todos pueden sentir el contraste entre algo que suena como una tarea desalentadora (invalidar el caché) y algo que suena como una tontería real (inventar nombres). Cualquier programador al menos una vez mató un reloj entero por algún problema ridículamente pequeño: dos parámetros, ordenados incorrectamente, una variable que está en algún lugar con una letra mayúscula, pero en otro lugar no (¡gracias, JavaScript!). Si bien las personas tienen que trabajar con computadoras para lograr sus objetivos, la programación siempre será una mezcla de planificación de sistemas de alto nivel y errores tipográficos estúpidos.Pero si miramos más de cerca las palabras de Phil Cardboard, encontraremos aquí más espacio para pensar. Es difícil encontrar nombres, no solo por los pequeños dolores de cabeza que tiene un programador, toda su vida va perdiendo la cabeza. El punto aquí es que los nombres son una de las facetas de la tarea principal del programador, el diseño del programa. En otras palabras, ¿cómo se escribe generalmente un código claro, ordenado y consistente?Hay muchas variedades de malos nombres. Todos nos reunimos con variables que fueron nombradas por tipos de datos ( myString, obj), abreviaturas ( pces decir, catálogo de productos), algunos detalles de implementación insignificantes ( swappable_name, formUserInput), o incluso sin nombre ( ret_value,tempArray) Es fácil caer en una trampa y nombrar una variable en función de lo que está haciendo ahora, y no de su contenido. Y con los valores de los tipos de datos lógicos, el problema es: ¿qué significa progressque el progreso ya ha comenzado, que necesita mostrar información sobre el progreso en la interfaz o algo más en general?Fuente: CommitStrip.comTransferir«results_tmp_2? ?.. , ? !» — «, … , results_tmp_2. »
Pero los nombres de las variables son solo el comienzo. Cuando comienzas a encontrar nombres para las clases, surge la pregunta de cómo dividir el código en partes independientes. Los nombres de los miembros públicos determinan cuál será la presentación de la interfaz a través de la cual las diferentes partes de la aplicación interactuarán entre sí. Al asignar un nombre a un fragmento de código, no solo está describiendo lo que puede hacer, sino que está estableciendo lo que hará.Cita de bonificación en el tema.« – , » —