Los 39 secretos del programador.

Lo que viene a continuación es una recopilación de consejos que provienen de grandes veteranos de la programación y que nos harán pulir ciertos aspectos a la hora de plantear y desarrollar Software.

1. La mayoría de las veces, emplear la herencia perjudica el diseño de aplicaciones orientadas a objetos a largo plazo. Reduce la usabilidad y dificulta el testeo del código. Es recomendable, siempre que sea posible, utilizar interfaces en su lugar.

2. Evitar introducir interfaces hasta que nos sintamos cómodos en el dominio de nuestra aplicación. Introducir interfaces prematuramenente puede conducir a futuros problemas de diseño.

3. Códigos con un alto nivel de anidado (tanto entre funciones, como dentro de las mismas) son más propensos a producir errores y más difíciles de mantener.

4. Estimar el tiempo de desarrollo es muy difícil, prueba de ello es el amplio uso de metodologías ágiles como Scrum.

5. La encriptación propia es muy difícil, por lo que no debemos inventar nuestro propio sistema de encriptado a menos que tengamos una razón de peso para hacerlo.

6. Es bueno utilizar lógica que no produzca efectos paralelos, ya que facilitará la comprensión del código y la determinación de sus estados en cada momento, además de facilitar las pruebas automatizadas.

7. Es muy útil aprender a razonar en torno al estado del ciclo de vida de nuestro programa.

8. La concurrencia puede ser un punto muy conflictivo si no empleamos las primitivas adecuadas. Elementos como Threadpools, Queues, Observables y Actors pueden ser de gran ayuda.

9. La optimización prematura es la raíz de todos los males. El orden a seguir para un buen desarrollo es:
1) Haz que funcione,
2) Haz el código bonito y
3) Optimiza.

10. Comprende tus estructuras de datos básicas y la complejidad temporal, ya que ésta es la manera de hacer que tu código sea mucho más rápido sin añadir complejidad.

11. Utilizar la estimación back-of-the-envelop, o lo que es lo mismo, estimaciones aproximadas de mayor precisión que una conjetura, pero menor que un cálculo exacto o prueba matemática, por ejemplo, ¿Cuántos elementos serán parte del código general que debemos mantener en memoria?

12. Escribe el código como si fueses a leerlo, es decir, lo suficientemente descriptivo para que se pueda entender a simple vista. Los comentarios deben añadirse sólo en partes complejas o difíciles de entender, como algoritmos recursivos u operaciones más específicas.

13. Configura tus herramientas de construcción (build) de la manera que te sea más fácil para empezar el proyecto. Documenta los (pocos) comandos que necesites para construir, ejecutar, probar y empaquetar el código en un fichero README.

14. Asegurarse de que tus proyectos pueden ser construidos desde la línea de comandos, hace que las cosas sean mucho más fáciles en el futuro.

15. Manejar librerías de terceros en la mayoría de lenguajes puede ser un verdadero desastre, específicamente cuando dos librerías distintas dependen de diferentes versiones. Algunas claves importantes a tener en cuenta sobre este tema son:
1) Cuestionarse constantemente las dependencias,
2) Las pruebas automatizadas pueden ayudarte a esto y
3) Fijar siempre qué versión de las dependencias de terceros deben ser usadas.

16. Los proyectos populares de código abierto son una buena forma de aprender sobre el proceso de desarrollo de código y la mantenibilidad del mismo.

17. Cada línea que añadimos al código lo hace más complejo y propenso a tener errores. Eliminar código es una de las mejores formas de eliminar posibles fallos.

18. Las rutas de código que manejan fallos son raramente probadas/ejecutadas (por una buena razón). Esto les hace un candidato perfecto para ocasionar bugs.

19. La validación de la entrada no es muy útil por razones de seguridad, aunque ayuda a encontrar errores tempranos.

20. Relacionado con el punto anterior, la validación del estado del programa y de la salida ayuda a la detección de errores tempranos pero no son aconsejables por motivos de seguridad.

21. Las revisiones de código son una buena manera de mejorar como programador. Recibiremos críticas de nuestro código que nos ayudarán a aprender de nuestros errores y aprenderemos a detectar errores en el código de otros, además de los fallos más comunes.

22. El aprendizaje de nuevos lenguajes es una buena manera de aprender nuevos paradigmas y un buen método con el cual nos cuestionaremos nuestros antiguos hábitos.

23. A la hora de la conversión entre texto y bytes, no olvides nunca especificar la codificación del texto, tanto en la lectura/escritura en red, en ficheros o con fines de encriptación. Si confiamos en la configuración local del conjunto de caracteres, tarde o temprano tendremos problemas de corrupción de datos. A ser posible, debemos utilizar un conjunto de caracteres UTF.

24. Debemos conocer bien nuestras herramientas, incluyendo el editor, el terminal, el sistema de control de versiones y las herramientas de construcción.

25. Aprender a utilizar las herramientas sin usar el ratón (atajos de teclado) nos proporciona velocidad, ergonomía y eficiencia.

26. Reutilizar código no es un objetivo final, y no hará que tu código sea más mantenible por si mismo, es más, si lo hacemos sin control, mezclaremos dominios diferentes y haremos que dependan entre si más de lo necesario. Reutilizaremos código complejo teniendo cuidado con lo dicho.

27. Estar sentado demasiado tiempo frente a nuestro equipo puede acarrear lesiones importantes en nuestro cuerpo:
1) Haz caso a tu espalda, cuello y muñecas te transmitan, en el momento que empiecen a doler, tómate un descanso, ya que ayuda más de lo que creemos tanto al cuerpo como a la mente. La hora del café (o té) puede ayudar más de lo que creemos.
2) Hay que descansar la vista de vez en cuando, retirando la mirada de la pantalla.
3) Utilizar un buen teclado para evitar movimientos bruscos de muñeca.

28. Las pruebas automatizadas, y en particular las unitarias, no solo están comprobando que tu código hace lo que debería, también:
1) Documenta cómo se supone que se utiliza el código.
2) Ayuda a comprender cómo se siente otra persona a la hora de utilizar el mismo. Ésto último junto con un enfoque de testing temprano ayuda a producir APIs mucho más limpias.

29. Testear lo que necesita ser testeado. Si hacemos pruebas de menos nos retrasará en la labor de encontrar bugs. Hacer pruebas de más nos retrasará porque en cada cambio que sufra el programa, debemos cambiar también todas sus pruebas.

30. Los lenguajes dinámicos, por lo general, requieren de un número mayor de pruebas que los lenguajes compilados para afirmar que funcionan correctamente (las herramientas de análisis de código offline pueden ser de gran ayuda).

31. Las condiciones de carrera son mucho más comunes de lo que creemos. Ésto se debe a que las computadoras utilizan más TPS (sistemas de procesamiento de transacciones) de los que creemos.

32. Comprender bien los conceptos de rendimiento y latencia es muy útil cuando estamos optimizando nuestros sistemas.

33. En muchas ocasiones, podemos conseguir un alto rendimiento mediante la introducción de smart batching (procesamiento inteligente desatendido por el usuario).

34. Haz commits con fragmentos de código pequeños y funcionales.

35. Mantener la duración de las ramas (branches) de nuestro control de versiones lo más cortas posibles, intentando que su duración no sobrepase las 2 semanas. Para características más largas y elaboradas, subdividir en ramas más pequeñas que puedan ser implementadas con pocos commit.

36. Hemos de conocer el entorno de producción y pensar estrategias de despliegue para que los cambios sean efectivos en el menor tiempo posible.

37. El envío de código frecuente tiende a reducir el riesgo en vez de aumentarlo.

38. Aprender los aspectos básicos de un lenguaje orientado a objetos es fácil, sin embargo dominar el paradigma es bastante difícil. Conocer los principios SOLID y los Patrones de Diseño te ayudarán a entender y dominar el diseño orientado a objetos.

39. Aunque tengamos un buena arquitectura, puede que encontremos código pésimo incrustado en la misma, pero, al disponer de una base bien diseñada, éste es fácilmente reemplazable. Por esto, es esencial tomar una base sólida y desacoplada antes que hacer un código impecable, ya que si cumplimos esta premisa el código podrá ser reemplazado sin problemas.