¡Oye, desarrolladores! Las ‘mejores prácticas’ pueden convertirte en un imbécil complaciente



¿Alguna vez has horneado galletas y te has preguntado por qué la receta es exactamente así y no otra? Si cambias este ingrediente o esa temperatura, ¿las galletas serían aún mejores?

Ciertamente he tenido estos pensamientos. Es la razón por la que la mayoría de las cosas que horneo no son muy comestibles…

Cuando se trata de programación, estos pensamientos surgen también. ¿Y si escribiera esta parte como una función separada? Si codificara este bit de allí, ¿facilitaría el código? ¿Puedo reescribir esas diez feas líneas en dos elegantes?

No hay recetas en la programación, pero hay mejores prácticas. No son tan precisos como una receta, pero lo suficientemente claros como para que sean evidentes si no los ha implementado. Al igual que con las recetas, algunas mejores prácticas se repiten durante generaciones de programadores. A veces tiene sentido hacerlo; a veces eso no es más que una tradición. Programación de culto de cargasi quieres llamarlo así.

Pero eventualmente, incluso la tradición más genial se extingue o se convierte en algo más útil. Lo mismo ocurrirá con algunas, pero no todas, las mejores prácticas en programación.

El “no te repitas” y la separación de preocupaciones simultáneos no funcionan

Recientemente revisé parte de mi antiguo código y noté que las mismas cuatro líneas de código aparecían tres veces en el mismo archivo.

Ahora, cualquier persona que haya estudiado informática formal (no yo, hice física) le dirá que esto es una tontería porque necesita mantener su código SECO. Don’t Repeat Yourself se ha convertido en una especie de mantra.

No soy un estudiante de ciencias de la computación, pero leo un poco, e internalicé ese mantra. Así que tomé esas cuatro líneas y las puse en una función.

Luego me di cuenta de que no podía hacerlo tan fácilmente porque esas cuatro líneas no eran completamente idénticas. Un pequeño cambio en la tercera línea significaba que tendría que agregar al menos una opción a mi nueva función. También necesitaría una cláusula if y quizás un nuevo parámetro booleano para invocar esa opción.

Eso habría hecho que el código fuera tan complicado como lo era antes.

Pero luego noté que esas cuatro líneas siempre se invocan después de llamar a otras funciones, dos funciones diferentes en tres lugares diferentes, así que pensé que también podría agregar las cuatro líneas a esas funciones. Esto funcionó bien porque el pequeño cambio en la tercera línea sería manejado por cada una de las funciones anteriores, y una de las dos ya contenía un parámetro coincidente.

Esto simplificó un poco mi código. Terminé repitiéndome, pero solo dos veces en lugar de tres veces. Y violé la Principio de responsabilidad única porque mis dos funciones estaban haciendo más de lo que se anunciaba.

Podría argumentar que probablemente solo escribí un código incorrecto y que podría haber soluciones alternativas mucho más elegantes para lo que estaba tratando de lograr. Y estas soluciones podrían incluso haber satisfecho ambos principios.

Lo suficientemente justo. Es difícil refutar una afirmación como esa.

Pero a los programadores no se les paga para escribir el código más elegante y hermoso de la década. Se les paga para hacer que algo funcione.

Mi proyecto funciona. Y más código-cosméticos me costaría un tiempo valioso que preferiría gastar en otros proyectos que aún no funcionan.

Tal vez soy tan tonto que ni siquiera puedo hacer que dos principios de programación funcionen. Pero te garantizo que hay franjas enteras de programadores que están en un nivel similar al mío.

Grupos de personas que tampoco pueden hacer que DRY y SRP trabajen juntos.

Es poco probable que esto provoque que DRY se seque (lo siento, el juego de palabras tenía que ser así). Es un principio extremadamente útil, por ejemplo, en la programación funcional, que está cobrando fuerza estos días.

El principio de responsabilidad única, por otro lado, podría volverse más raro. Piense en las redes neuronales, por ejemplo. No se dan cuenta de una sola cosa. Los más sofisticados entienden y reaccionan ante millones de imágenes diferentes, mensajes de texto o proteínas complicadas. Eso es lo contrario de SRP.

En otras palabras… SRP se está SECANDO.

Por favor, reinvente la rueda de vez en cuando.

Al igual que DRY y SRP, esta práctica fue popularizada por personas con buenas intenciones. Pero eso no cambia el hecho de que no siempre es sensato implementarlo.

La idea es que si ya existe una solución a su problema, debe usarla. Probablemente tenga menos errores y sea más eficiente que su solución casera.

Hay algunos problemas con este pensamiento.

En primer lugar, las soluciones existentes rara vez coinciden con su problema específico al 100 por ciento. Por lo tanto, es bastante probable que resuelva, digamos, el 75 por ciento importando una solución o un paquete que aborde su problema. Pero aún tendrá que hacer una parte sustancial del trabajo de campo usted mismo, además de las pruebas, la depuración y el mantenimiento.

En segundo lugar, las soluciones existentes suelen tener más de una función. Y probablemente no usará todas las funciones. Por lo tanto, introducirá una cierta cantidad de código superfluo en su proyecto, lo que lo hace más difícil de entender y de mantener. Podrías haberlo evitado creando el tuyo propio.

Tercero, cuidado con incorporar soluciones de código abierto en proyectos propios. Esto es una violación de los derechos de autor y, en el peor de los casos, puede causarle problemas legales. Si usa código de código abierto en su proyecto, su proyecto también debe ser de código abierto.

Finalmente, reinventar la rueda no garantizará la ausencia de errores de todos modos. Incluso si se ha probado, probado y actualizado (lo cual es bastante raro), aún debe incorporarlo correctamente y escribir el código repetitivo a su alrededor.

Entonces, ¿por qué no escribir su propia solución personalizada, cometer algunos errores en el proceso y aprender de ellos? Este tipo de lecciones pueden ser extremadamente valiosas y te convertirán en un programador mucho más valioso a largo plazo.

Cantidad sobre calidad

El escritor Sean Kernan (es genial, échale un vistazo) tiene una gran pieza sobre cómo debe presionar por la cantidad, no por la calidad cuando está haciendo un trabajo creativo.

Para la escritura, esto significa que si escribe un artículo al mes y lo pule hasta que esté genial, estará bien. No muy bien, porque no has usado mucho tus músculos de escritura con un solo artículo. Pero no está mal, está mal porque lo has pulido bastante.

Pero si escribiste 30 artículos en un mes, es muy poco probable que todos ellos sean malos, malos o correctos. Algunos de ellos serán geniales, y uno o dos de ellos incluso podrían ser excelentes.

Por supuesto, no ha tenido tiempo para pulir tanto su trabajo, pero sus músculos para escribir serán del tamaño de Arnold-Schwarzenegger una vez que termine el mes. Y habrá tenido tiempo para cometer todos los errores posibles, desde errores tipográficos hasta pisar los pies de otras personas, y con suerte interiorizó las lecciones.

Ahora, podría objetar que la programación es bastante diferente a la escritura libre.

Sí, la programación es más técnica que la escritura y es posible que necesite muchos más conocimientos previos incluso para comenzar. Pero la programación es, en esencia, una disciplina bastante creativa.

La programación se trata básicamente de encontrar formas interesantes, elegantes y eficientes de resolver problemas con una computadora. ¡Eso es creativo!

Detractores podría decir que 100 piezas de código mediocre siguen siendo mediocres y, por lo tanto, una pieza de código excelente es mejor.

Pero en serio, si tienes 100 disparos, seguramente dispararás uno en la dirección correcta. Según las leyes de la estadística, si en promedio hay 100 piezas de código mediocre, diez serán excelentes y dos serán excelentes, y eso es mejor que una sola pieza de código excelente.

Así que codifica más, comete más errores y aprende más.

Las mejores prácticas te convierten en un idiota complaciente

Todo se reduce a esto: eres libre de seguir todas las mejores prácticas.

Pero pueden limitar su pensamiento y cegarlo a soluciones más innovadoras.

Si realmente quiere sobresalir de manera positiva, use las mejores prácticas como guía. Rompe esas pautas cuando te parezca apropiado.

Las personas que siempre siguen las reglas se vuelven complacientes. Y la complacencia, con el tiempo, mata el éxito.

Comienza a romper las reglas y tendrás la oportunidad de unirte a los grandes jefes.

Repítete si eso es mejor para ti.

Deje sus responsabilidades enredadas si eso es más fácil de mantener.

Codifique sus propias soluciones en lugar de importar las existentes que no encajan a la perfección.

Y código más. Mucho más. Incluso si es malo o tiene errores. Habrá algunas piedras preciosas en el desorden que crees.

Este artículo fue publicado originalmente en Medium. Puedes leerlo aquí.



Fuente: TNW

Compartir:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para fines de afiliación y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Ver Política de cookies
Privacidad