Principios de programación que nadie te enseñó

TThe Coding Koala
Computing/SoftwareManagement

Transcript

00:00:00¿Sabes por qué algunas personas parecen nunca progresar como desarrolladores a pesar de pasar años en
00:00:04este campo? Hay varios factores involucrados. Y una de esas razones es no entender
00:00:09los principios fundamentales de la programación. Estos no son solo conceptos teóricos que aprendes una vez
00:00:14y olvidas. Son cosas reales que realmente te harán crecer más rápido como desarrollador.
00:00:19Comencemos con el primer principio: la regla del boy scout. Este principio proviene de los boy scouts en Estados Unidos.
00:00:25Básicamente, tienen esta regla simple: deja el campamento más limpio de como lo encontraste.
00:00:31No sé cuántos de ustedes conocen a Uncle Bob, pero él es quien popularizó este concepto
00:00:36en la comunidad de programación, que es la práctica de dejar el código un poco más limpio de como lo encontraste.
00:00:41Al hacer cambios en una base de código existente, la calidad del código a menudo se degrada, lo que puede
00:00:47aumentar la deuda técnica. Y la deuda técnica se puede reducir mediante la mejora continua,
00:00:52sin importar qué tan pequeña sea. Supongamos, por ejemplo, que te asignaron una tarea para hacer un cambio en
00:00:57el valor de esta función. Lo hiciste, pero puedes ver que el nombre de la variable no es lo suficientemente
00:01:03comprensible. Así que, como la mayoría de los desarrolladores, podrías simplemente ignorarlo y enviar lo que se te asignó.
00:01:08Pero si sigues este principio, también cambiarías el nombre de la variable a algo más
00:01:12comprensible. Este es solo un ejemplo simple, no solo con nombres de variables, sino que si ves algo que
00:01:18puede ser mejorado, simplemente hazlo. Y este simple gesto será realmente valioso para la base de código.
00:01:24Segundo principio: evita la optimización prematura. Lo que esto significa es: no intentes hacer que tu
00:01:30código sea más rápido antes de que realmente necesite serlo. Primero, haz que funcione. Solo entonces, optimiza si es necesario.
00:01:36Había una famosa cita de Donald Knuth: "la optimización prematura es la raíz de todos los males",
00:01:42lo cual es cierto porque los programadores a menudo pierden la mayor parte de su tiempo preocupándose por la velocidad de
00:01:47partes no críticas de sus programas. Eso es porque ha existido esta moda del concepto de
00:01:51optimizar todo. Este principio no está en contra de optimizar tu base de código. Se trata de
00:01:57entender qué necesita ser optimizado y, lo más importante, cuándo optimizar. Y creo que esta
00:02:03es la debilidad de la mayoría de los desarrolladores porque he visto gente usando microservicios aunque tienen
00:02:08100 usuarios o añadiendo caché para algo que ni siquiera es necesario. Tercer principio:
00:02:14escribe código para el encargado del mantenimiento, lo que simplemente significa que cuando escribes código, debes hacerlo de tal
00:02:19manera que los futuros desarrolladores que mantendrán tu código no tengan dificultades para gestionarlo y
00:02:23entenderlo. Eso es porque el código que escribes hoy será mantenido por otros desarrolladores o por
00:02:29ti mismo. Si solo te concentras en hacerlo funcionar y no te enfocas en la claridad, en el futuro, si
00:02:35necesitas volver al código, tendrás dificultades para entender qué está pasando. Solo mira
00:02:39este ejemplo. Ambos funcionan y hacen exactamente la misma funcionalidad. Pero, ¿cuál preferirías
00:02:45ver en tu base de código? Entonces, la lección es que, siempre que escribas o generes código con IA,
00:02:50asegúrate siempre de que sea fácil de entender y mantenible antes de confirmar tu trabajo.
00:02:55Nuestro cuarto principio se llama YAGNI, que es solo la abreviatura de "you aren't going to need it" (no lo vas a necesitar).
00:03:01Este principio simplemente significa que no deberías construir algo que no necesitas realmente o simplemente porque
00:03:06tal vez lo necesites en el futuro. Porque la mayoría de los desarrolladores tienen el hábito de predecir lo que
00:03:10podrían necesitar en el futuro. Pero la mayoría de las veces, nunca se usarán y solo añaden una complejidad extra
00:03:16al proyecto. Siempre recuerda esto: si estás trabajando en algo que podrías requerir en el
00:03:21futuro, no estás dedicando tu tiempo a lo que realmente necesitas ahora. Quinto principio: haz lo más
00:03:27simple que posiblemente pueda funcionar. Esto significa que siempre que enfrentes un problema, elige siempre la
00:03:32solución más simple que realmente funcione. No lo pienses demasiado. No sobrecargues la ingeniería. Solo pregúntate:
00:03:38¿qué es lo más simple que podría resolver esto ahora mismo? Esta idea proviene de la programación extrema,
00:03:43que nos dice que construyamos algo simple primero, y luego refactoricémoslo en algo
00:03:48mejor. La mayoría de los desarrolladores no se dan cuenta de esto, pero a menudo intentan construir la solución perfecta desde
00:03:53el inicio, lo cual eventualmente complica excesivamente su solución. Con este principio, obtienes un código que funciona
00:03:59más pronto e incluso si tienes que cambiarlo después, suele ser más fácil que arreglar un diseño complejo
00:04:04que estaba mal. Y créeme, como desarrollador, darte cuenta de cuándo estás sobrecargando algo
00:04:10es muy importante. Así que estos fueron los cinco principios de programación que deberías empezar a
00:04:14implementar de inmediato. Aparte de estos, también hay otros principios que no he cubierto
00:04:19en este video. Si esto fue útil, házmelo saber en los comentarios y crearé una segunda parte.
00:04:24Por ahora, dejémoslo hasta aquí. Asegúrense de mostrar algo de apoyo y nos vemos en la próxima.

Key Takeaway

Adoptar principios de diseño como la regla del Boy Scout, YAGNI y la simplificación de soluciones maximiza la mantenibilidad del código y acelera el desarrollo real frente a la optimización especulativa.

Highlights

  • La regla del Boy Scout dicta que el código debe dejarse siempre más limpio de lo que se encontró para reducir la deuda técnica acumulada.

  • La optimización prematura desperdicia tiempo de desarrollo en partes no críticas de una aplicación, siendo esta la raíz de ineficiencias innecesarias.

  • El código debe escribirse pensando siempre en el futuro desarrollador encargado de su mantenimiento para asegurar su legibilidad.

  • El principio YAGNI (You Aren't Going to Need It) evita la complejidad innecesaria al prohibir la construcción de funcionalidades no requeridas actualmente.

  • La ingeniería sobrecargada suele surgir al intentar alcanzar una solución perfecta desde el inicio, en lugar de implementar la opción más simple que funcione.

Timeline

Principios básicos de limpieza y optimización

  • La regla del Boy Scout exige mejorar la calidad del código en cada interacción, por pequeña que sea.
  • La optimización prematura precede a menudo a la necesidad real, consumiendo tiempo valioso en componentes no críticos.
  • La deuda técnica se reduce mediante la mejora continua de la base de código existente.

La calidad del software se degrada naturalmente durante el desarrollo. La aplicación constante de pequeñas mejoras, como renombrar variables poco claras, contrarresta este fenómeno. Paralelamente, se advierte contra la optimización excesiva, citando a Donald Knuth: la optimización prematura es la raíz de todos los males. Es fundamental priorizar el funcionamiento del software antes de aplicar técnicas de rendimiento, evitando implementaciones complejas como caché o microservicios que no son necesarios para los requerimientos actuales.

Mantenibilidad y simplicidad en el desarrollo

  • Escribir código para el encargado del mantenimiento garantiza su legibilidad a largo plazo.
  • El principio YAGNI evita añadir funcionalidades basadas en predicciones futuras que rara vez se materializan.
  • La solución más simple que funciona es preferible a un diseño perfecto pero sobrecargado.

El código actual será mantenido por terceros o por el propio autor en el futuro, por lo que la claridad es fundamental. Construir funcionalidades solo por una posible necesidad futura añade una complejidad innecesaria al proyecto. La programación extrema sugiere construir la solución más simple que funcione y realizar refactorizaciones posteriores. Intentar alcanzar una solución perfecta desde el inicio suele resultar en una ingeniería sobrecargada que complica innecesariamente el mantenimiento y altera los tiempos de entrega.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video