Aja, más Cosas que me hubiese gustado saber cuando empecé, 5ta edición.
Puedes encontrar el primer artículo de la serie aquí.
Y el artículo anterior aquí
Lees código más a menudo de lo que lo escribes. Optimiza para leer
En lugar de imaginar que nuestra tarea principal es instruir a una computadora qué hacer, concentrémonos más bien en explicar a los seres humanos lo que queremos que una computadora haga. _Donald Knuth
¿Esta funcionalidad es extremadamente importante y tu manager te está presionando para que la entregues ASAP?
¿Estás trabajando en un ambiente extremadamente lean y no tienes tiempo para escribir buen código?
Lo entiendo, estás demasiado ocupado para escribir buen código. Me inclinaría a decir que escribir mal código nunca se justifica, pero también estoy consciente de que hay algunas situaciones difíciles en el trabajo. Aun así, escribir mal código con la excusa de ahorrar tiempo no solo es poco profesional, sino que tampoco funciona.
La realidad de nuestra profesión es que leemos código mucho más a menudo de lo que lo escribimos. Algunos dicen que por un factor de 10:1, en mi experiencia, puede ser un poco más que eso. Al escribir código que es difícil de leer, estás haciendo más difícil la tarea más común.
En arquitectura de computadoras, hay un concepto llamado ley de Amdahl. Te da una estimación teórica de la aceleración resultante de mejorar solo una pequeña parte del código. Una de las principales perspicacias de la ley es que tiene poco sentido paralelizar una parte de tu programa que se ejecuta solo un par de veces. Si quieres ver una mayor aceleración podrías tener más suerte con una mejora más pequeña en las partes de tu código que se ejecutan más a menudo.
Podemos aplicar la misma lógica al escribir código. Si leemos código más a menudo de lo que lo escribimos, deberíamos pasar nuestro tiempo haciéndolo lo más fácil de leer posible. Incluso si escribir código fácil de leer toma el doble de tiempo (incluso si toma 10 veces más), sigue siendo una inversión sabia.
Pasa tiempo escribiendo buen código, no se ahorra tiempo a largo plazo escribiendo código descuidado.
No optimices prematuramente
El problema real es que los programadores han pasado demasiado tiempo preocupándose por la eficiencia en los lugares equivocados y en los momentos equivocados; la optimización prematura es la raíz de todo mal (o al menos la mayor parte) en la programación. _Donald Knuth
Recuerdo cuando empecé a programar, estaba OBSESIONADO con la velocidad de mis programas.
Pensaba que era lo único que importaba, o al menos cerca de la parte superior de la lista de prioridades. Así que pasé mucho tiempo haciendo pequeños ajustes para que mi código corriera más rápido. Había dos grandes problemas que, en retrospectiva son obvios, pero era demasiado ingenuo como para darme cuenta:
- No tenía idea de lo que estaba haciendo. Esas ‘optimizaciones de rendimiento’ estaban horriblemente implementadas y usualmente hacían más daño que bien.
- A nadie le importaba la velocidad a la que mis programas de juguete corrían, y la mayoría del software que he escrito desde entonces corrió a velocidades suficientemente buenas por defecto.
La realidad es que en la mayoría del desarrollo de software comercial, esas optimizaciones no se necesitan. Nuestro hardware e infraestructura actual proporcionan velocidad satisfactoria desde el inicio. En su lugar deberías pasar tiempo creando código que sea fácil de leer y soluciones bien arquitecturadas. Si hay un problema de rendimiento, puedes usar herramientas de profiling para averiguar cuál es la parte problemática de tu código y aplicar optimizaciones a esa parte, lo cual es más fácil si:
- Sabes que realmente necesitas la optimización.
- La cobertura de pruebas es buena y CI está en su lugar.
- El proyecto está escrito y estructurado usando buenas prácticas.
El punto principal es, la optimización prematura daña tu código y usualmente ni siquiera se requiere. En la mayoría de las situaciones, simplemente meter hardware más poderoso es más fácil (y más barato, si cuentas el costo de horas-ingeniero) que ajustar cosas a mano.
Para algunos casos como sistemas embebidos u otras formas de programación de bajo nivel, exprimir tanto rendimiento como puedas de tu hardware tiene sentido. Para aplicaciones web o alguna otra forma de software de consumidor, la optimización debería ocurrir solo si hay una necesidad real. Una mejor arquitectura, hardware más poderoso y redundancia son otras opciones con usualmente un mayor impacto en el rendimiento.
Así que no optimices tu código hasta que averigües si realmente lo necesitas, ve por una solución limpia y obvia primero.
Aprende a aprender
La tecnología se mueve rápido, y mantenerse al día con los cambios requiere que seas capaz de aprender cosas nuevas rápidamente.
Cultivar tu habilidad para aprender es una buena manera de invertir tu tiempo, a pesar de los desafíos de nuestra era. Por un lado, el hecho de que nunca hemos tenido tanto material disponible debería hacer las cosas más fáciles. Al mismo tiempo, la disrupción de las redes sociales y otros distractores hacen más difícil concentrarse en aprender en profundidad.
Tener la disciplina para trabajar a través de libros y tutoriales, y para practicar tus habilidades te diferenciará de todos tus pares. Aprender, como otras actividades, es algo en lo que te vuelves mejor si lo haces frecuentemente. Si sientes que leer libros para aprender cosas es demasiado difícil, puedo garantizarte que se volverá más fácil después de un par de libros.
Recuerda que tus programas están hechos de pensamientos e ideas, los contenidos de tu cabeza son las materias primas para el oficio. Pasa tiempo expandiendo tu conocimiento, es la única manera de controlar la dirección que toma tu carrera.
Oh, pero yo también sabía todas estas cosas.
Está bien, tal vez en el próximo artículo encuentres algo que aún no sabías.
Gracias por leer, espero que hayas aprendido una o dos cosas nuevas o al menos hayas obtenido algo nuevo en qué pensar.
Qué hacer a continuación:
- Comparte este artículo con amigos y colegas. Gracias por ayudarme a llegar a gente que podría encontrar útil esta información.
- Lee el siguiente artículo de la serie.
- Envíame un email con preguntas, comentarios o sugerencias (está en la página Autor)