Hábitos que se consideran importantes para un desarrollador (y cualquiera)

Posted on 23 abril 2008. Filed under: Trabajo en Equipo |

Anoche leyendo un foro de los que acostumbro, tuve la oportunidad de rescatar las siguientes líneas. Quiero comentarles que estos axiomas corresponden a apreciaciones que hacen Ingenieros, Programadores, Gerentes y Testers de varios países como España, Chile, Colombia, Perú, Argentina, y otros de habla hispana.

  • "Intenta siempre buscar la simplicidad". Busca siempre y por defecto la solución más simple, más natural, más clara frente a la optimizada, compleja y eficiente. Hoy en día, el rendimiento es algo que se ha superado con creces gracias a los potentes procesadores. Intentarlo inicialmente de la manera "fácil" y, si no da buen resultado, dar un paso hacia la optimización. Pero sólo uno. Si sigue dando problemas, da otro paso.
  • "Capacidad de organizar tu trabajo". Cada programador debe ser consciente de cuales son las horas más productivas del día para el y utilizarlas al máximo y dejar los momentos más flojos para tareas mecánicas. Es decir, evitar errores por cansancio que desembocan en un montón de correcciones a posteriori. (p. Ej.: para mi las primeras horas de la mañana son las más productivas y dejo para última hora de la tarde las tareas monótonas, reuniones, etc.)
  • "Analizar y organizar tu trabajo antes de hacerlo". El papel suele ser un buen medio. Es importante para tener claro en tu cabeza que vas a hacer.
  • "Intentar ser exigente en tu trabajo no sólo en las grandes tareas sino en todos los aspectos mínimos de un proyecto". A veces son los que marcan la diferencia. (Desde borrar variables en un fichero a optimizar los plazos de un proyecto. Todo es importante).
  • "Intentar ser pausado". Es una mala costumbre dar por buena al que más teclea. El programador debe acostumbrarse a ser reflexivo. A medio plazo compensa.
  • "Piensa en el test, tanto unitario como funcional". Una posibilidad es usar metodologías de desarrollo orientadas al test (Test Driven Development), pero no es la única. Lo cierto es que pensar en como vamos a verificar en el momento del desarrollo significa un ahorro importante durante fases de test y mantenimiento futuro.
  • "Deberías revisar las buenas prácticas de programación que se utilizan en extreme programming"
  • “Programación en pares – Reutilización -Uso de estándares”, entre otros
  • "La información debe fluir". Es decir, debe pasar de unas manos a otras, de una rutina a otra. De esta forma, evitaríamos (o al menos minimizaríamos) el uso de las tan peligrosas variables globales. Como caso práctico, nosotros solemos aplicar esta regla cuando pasamos de un formulario de la aplicación a otro. En lugar de que el formulario destino "tome" la información que necesita, se la pasamos a través de un método "Execute".
  • "Borrar la declaración de las variables que ya no se usan". Es práctica común ir copiando un programa de otro y comentar lo que no sirve para el nuevo pero no borrarlo, por ejemplo en lenguajes como C ó C siempre  se  tiende  a  dejar  las  variables que no se usan. Para ello las últimas versiones de los entornos de desarrollo ya incluyen ciertas herramientas de refactoring y una de ellas suele ser la de eliminar las variables no utilizadas.
  • "Usar una herramienta control de versiones".
  • Como dice el bueno de Steve (McConnell) en su "Code Complete 2", la clave del éxito de un producto software es la gestión contínua y correcta de la simplicidad.
  • "Haz que tu código se parezca lo más posible al lenguaje normal". El mismo que utilizarías si le quieres explicar a alguien ajeno qué hace ese programa. Identifica las palabras más importantes que utilizas en la explicación y haz que salgan en el código. Volviendo al ejemplo de antes, si dices "si el fichero está abierto, lo cierro", no escribas "if CurrentFile.fOpen<>NULL" !!!
  • Cuando implementes una solución, sigue el orden que cualquier ser humano esperaría. Prepara primero el trabajo y luego hazlo. Una buena idea (sugerida también por McConnell) consiste en escribir la solución en "cristiano" antes de comenzar a teclear código. Luego convierte esas frases en comentarios y, bajo él, introduce el código correspondiente.
  • Explica por qué no has podido hacerlo más simple. Cuando empezamos a trabajar en un código heredado, todos los programadores deseamos encontrarnos los comentarios adecuados en el sitio adecuado. Pues acuérdate de eso cuando seas tú el que has escrito el código.
  • La frase de "divide y vencerás" está tan manida que la llegamos a olvidar injustamente. ¿A que te joroba encontrar una rutina de 3 pantallas en el código ajeno? Muchas veces merece la pena hacer una rutina de una línea (del estilo "bool File.IsOpen( )") en aras de la legibilidad.
  • "Fortalecer la comunicación con sus compañeros"
  • "planificar su día antes de empezar a trabajar"

Liked it here?
Why not try sites on the blogroll...

A %d blogueros les gusta esto: