14 Reglas que un Desarrollador de Software debe seguir

Tener ciertas reglas para realizar nuestro trabajo ayuda a tomar mejores decisiones que si las realizáramos en el momento que surjan algún inconveniente. 

Las siguientes reglas (más que todo lineamientos) espero me ayuden y les ayuden a ser mejores desarrolladores:

1. Lo funcional mata lo elegante

Lo que funciona, funciona, lo que es elegante, no siempre funciona. Un patrón de diseño interesante no tiene que ser necesariamente funcional, y que sea el patrón de moda no es razón de implementarlo. 

2. Rediseñar una y otra vez no funciona

Como programadores tendemos a querer innovar siempre, y el código que escribimos ayer, hoy nos parece viejo y anticuado, y deseamos aplicar el novel patrón de diseño sobre el cual leímos hace minutos. Esto no es necesariamente malo, pero para trabajar, complica las cosas agregando código a lo que puede ser una solución simple, sin tanto moño.

O se viene el caso, en que pensamos que al implementar la funcionalidad X, también le agregamos la Y y la Z por si en el futuro....Y el futuro nunca llega, y tenemos código a implementar que no sirve prácticamente de nada más que para darnos más trabajo. No hay que anticiparnos tanto a lo que el usuario va a necesitar o utilizar.

En mi experiencia, he trabajado con gente que quiere la aplicación perfecta, implementar cambio tras cambio, aunque no sirva de nada, aunque una semana después se quite o que nunca se utilice. Hay gente que solo quiere trabajar por trabajar, para cumplir horas y no por objetivos reales.

3. Se abierto a la retroalimentación, es decir a que te critiquen

Cuando se trabaja en equipo es imposible no recibir una opinión contraria a lo que nosotros consideramos "correcto". Está bien tener confianza en nuestro trabajo y habilidades. Somos buenos, pero no perfectos. Aprovechemos el hecho de que alguien "nos de la contraria" o que nos critique, peor es que no te digan nada y pienses que estás haciéndolo todo bien. Es una oportunidad para crecer, para mejorar.

4. Se realista cuando estimes tiempos

Estimar cuanto tiempo nos va a tomar realizar una labor no es una ciencia exacta. Es lo más difícil, excepto cuando te imponen plazos, entonces ahí te evitas la tarea de estimar tiempos, en realidad si te dicen que tienes que terminar el viernes, tu estimación no vale nada, aunque la tarea vaya a demorar más tiempo.

Pero volvamos al caso en que nos pidan estimar el tiempo para una tarea. Se pueden conocer los requerimientos, pero los requerimientos cambian. Es bueno saber, que nadie acierta con los tiempos de desarrollo. Hay que ser realista, no poner semanas cuando puedes hacerlo en días o no estimes días cuando es posible que te tome un mes.

Lo bueno es que el estimado no es el plazo real. Estimas 3 días, pero el plazo lo pones en 5 porque sabes que pueden aparecer imprevistos o ya tienes tiempo comprometido. Mientras no te comprometas a un plazo imposible, no hay problema. Es un estimado. Y es importante la comunicación, si ves que a pesar de dar tu mejor esfuerzo, no vas a cumplir con el plazo, comunícalo a tu cliente o jefe inmediato.

5. Tener un plan

No hay que empezar a programar sin un plan. No se puede colocar una sola línea de código sin saber que es lo que se quiere hacer. Sin un plan, la programación se vuelve extremadamente complicada. Hay mucho que pensar antes de empezar a aporrear el teclado.

6. Prueba tu propio código

Nada frustra más a un tester o al usuario que una funcionalidad falle al primer clic. Por eso es importante realizar pruebas automáticas o manuales de nuestro propio código. A ningún programador le gusta realizar pruebas. "Hey, eso ya funciona", pensamos. Pero debemos entender que las pruebas son importantes, respetemos el tiempo de los testers o de los usuarios.

7. No sabemos todo

Si uno tiene algo de experiencia en el mundo de la tecnología, sabe lo amplio que es ese campo. Y en programación, tenemos varios lenguajes de programación, sobre esos lenguajes de programación tenemos varios frameworks, y sobre esos frameworks tenemos varias versiones, y sabemos que cada programador tiene su propio estilo. Vaya, hay varios "varios" en este texto. Entonces, ni siquiera sobre el framework sobre el que te consideras experto puedes saber todo de todo. Siempre hay que aprender. Hay una nueva técnica, o una forma de enfocar un problema y no lo podrías haber conocido.

Así, que si amigo desarrollador, recuerda que no sabes todo de todo.

8. Simple y que se mantenga así

Si alguien te dice que hay que mantener las cosas simples al programar, uno entiende que es lo correcto. Pero implementar esa simplicidad en el código no es tan simple.

Tu código solo debería hacer lo que debe hacer, y nada más. Si lo aplicas, vas a tener un software fácil de mantener.

9. Consistencia

La consistencia en el software es algo clave en el desarrollo de software. Se refiere a mantener la nomenclatura en el código, en la base de datos, sea en un proyecto propio o en uno existente. Hacerlo al comienzo es fácil, hacerlo después de un par de años, se vuelve confuso. Viene un nuevo programador y quiere imponer sus estándares, cuando en la empresa ya se tienen otros estándares. 

Hay que ser consistentes, y eso requiere disciplina. Personal y colaborativa.

10. Los atajos son necesarios

Con la experiencia te das cuenta que hay ocasiones en que es obligatorio o necesario tomar un atajo. No siempre se puede escribir el código limpio y simple que resuelva el problema que tenemos. Una pared sin acabados es tan funcional como una pared con azulejos. Y si tu plazo se acaba ¿para qué perder el tiempo aprendiendo a ponerlos? Levantamos la pared, y la casa está terminada. El otro mes podemos contratar a alguien que ponga los azulejos.

Igual en el software, si podemos solucionarlo de forma "fea pero funcional" hagámoslo, y no busquemos la "buena, bonita y barata" que a veces no existe o no siempre es barata.

11. Toma responsabilidad de tus errores

Te vas a equivocar y muchas veces, y hay que hacerse responsable de dichos errores. Y hacerse responsable no solo significa aceptarlo sino aprender de ellos. Es decir, en la siguiente experiencia, no volverás a cometer errores. Al menos los que cometiste la primera vez, ya tendrás otros.

No pierdas tiempo en dar excusas, sino en opciones de como resolverlo.

12. Aprender nuevas cosas

Lo nuevo es lo constante en el mundo de la tecnología. El día que dejes de aprender, dejas de crecer. Como dijo Bruce Lee: "el aprendizaje es un proceso de descubrimiento, un proceso sin fin".

13. Automatizar lo que se pueda

Si tienes tareas repetitivas, automatízalo. Esas tareas que se repiten son aburridas. Automatiza. Eso liberará una porción de tiempo que puedes usarla en cosas más útiles. Y al automatizar, se quita el factor humano: reducimos la propensión a equivocarnos.

14. Domina tus herramientas

Jeff Bezos dijo: "primero nosotros cambiamos a nuestras herramientas, luego nuestras herramientas nos cambiaron". Los programadores, sin herramientas, no somos nada. Conocer a nuestras herramientas que usamos, y usarlas de forma apropiada, nos ayudará a realizar nuestro trabajo de forma eficiente. Hablo de plugins, IDE, líneas de comando, editores de texto, etc. 

Una vez que hemos elegido nuestras herramientas, debemos tomarnos el tiempo para conocerlas, experimentar y dominarlas tan pronto como sea posible.





Comentarios