febrero 12, 2007

Memorandum de un programador

Sé que no soy un erudito en la materia, y que probablemente lo aquí escrito ya lo haya dicho, pensado o escrito alguien más, hasta el momento lo desconozco, si uds. lo saben favor de mencionármelo; pero en lo personal, los años que estudié del 2001 al 2005, además de todo el 2006 a la fecha en la experiencia de prácticas y trabajo en mi área, me hicieron llegar en distintos momentos a pensar en alguno de estos puntos. Por supuesto, los puntos personales, como ambición, ganas, esfuerzo, disciplina, moralidad, ética, tenacidad, proactividad, gentileza, humildad son siempre puntos a favor, y aplican para toda la vida no importando el tipo de trabajo. No sé si uds coincidan, o quieran tomarlos como "mandamientos" o técnicas de programación, análisis, o tomarlo como una analogía al juramento Hipocrático, no creo que llegue a tanto, pero al menos para mí, creo que me servirá bastante como referencia.

Como programador, analista, ingeniero o licenciado en sistemas:

  1. Debo dedicarle el mejor tiempo al buen análisis del problema. Sin que esto lleve a dejar muy poco tiempo a las demás tareas de diseño, programación, pruebas y depuración.
  2. Debo explicar en lenguaje común, entendible y lo más simple posible qué hacen los programas, funciones, o para qué se necesitan ciertas variables en el código, de modo que cualquier otro pueda tener idea de lo que se necesita y lo que se propuso para solucionarlo.
  3. Debo documentar lo que hago.
  4. Debo respaldar siempre.
  5. Debo llevar un control de versiones.
  6. Debo tratar de usar ambientes de desarrollo, pruebas (test) y final (productivo, estable o como se le llame).
  7. Debo probar en distintos sistemas operativos, hardware, diversos escenarios de prueba, para evaluar el rendimiento o impacto.
  8. Debo establecer estándares de programación.
  9. Debo seguir los estándares de programación: nombrado de variables, funciones.
  10. Debo inicializar variables.
  11. Tratar de reutilizar código.
  12. Trataré de que mis códigos sean modulares, orientados a objetos o sencillos, ya que el avance en puntos clímax o clave conlleva a códigos cada vez más complejos que en la medida de lo posible deben ser entendibles.
  13. El código debe ser eficiente. Tomando en cuenta longitudes de variables, uso de memoria, requerimientos de usuario.
  14. Trataré de que las características sean personalizables, con roles, con categorias o catalogos, y evitar lo mas posible el código duro.
  15. Las bajas de ser posible deberán ser lógicas y no físicas, en caso de que se desee borrar, puede ser conveniente llevar bitácoras o respaldos de tablas a determinada fecha.
  16. De ser posible llevar logs o bitácoras de acciones en los procesos críticos.
  17. Debo otorgar y denegar privilegios a archivos, carpetas, tablas, usuarios, módulos, acciones.
  18. Debo tener scripts de mis bases de datos.
  19. Debo tomar en cuenta las sugerencias de los demás, el proyecto y código es un producto humano y por tanto sujeto a errores, involuntarios o no previstos; cualquier otra persona, sea más joven o más experimentada puede encontrar errores en mi código, no deberé enojarme sino más bien agradecer la observación y aprender de estas situaciones.
  20. Debo someter a testeo y stress a mis proyectos.
  21. En la medida de lo posible debo delegar y asignar tareas de autorización, validación o evaluación a TERCERAS personas. Ya sea antes de agregar nuevos campos a las tablas, modificar funciones, borrar código, deberé consultarlo y tener el visto bueno de la mayoría, hasta llegar a un concenso.
  22. Debo capturar, cachar o dar tratamiento a errores o excepciones lo más particular posible sin que moleste al usuario con demasiados mensajes de error, validación o notificación, sino sólo lo necesario.
  23. Debo tener eventual comunicación (no tanto que sea diaria ni tan esporádica que sean sólo una o dos veces) y revisión de avances con los usuarios, para que no se llegue a avanzar o trabajar en módulos o puntos que no serán utilizados en vez de otros necesarios, o revisar antes de tener malinterpretaciones por ambos lados.
  24. Debo recordar mis errores para que mis agendas de trabajo se apeguen lo mas cercanos a lo establecido y el próximo proyecto sea de mejor calidad.
  25. Debo leer y mantenerme actualizado, lenguajes, tecnologías, metodologías, diagramas, hardware, software, sistemas operativos, bases de datos, redes, i.a... El mundo cambia, los sistemas cambian, yo cambio. No debo cambiar porque los demás lo digan o yo lo piense una sola vez. Más que cambio, debe ser evolución. Tomar lo mejor de cada experiencia, asimilarla, entenderla, aplicarla, y decidir si el cambio ha sido el mejor para vivir en adelante con él, entonces, habrá evolución.
  26. Algunos dicen: especialízate, otros, aprende de todo un poco. Yo no digo qué cosa hacer, que cada quien decida su vida. Simplemente me escribo, para recordarme algunas cosas, porque yo no tengo memoria para toda la vida...

Enlaces de mi agrado (no porque necesariamente deba creerlo, pero da qué pensar):

¿Viejos Lenguajes?

Keep it Simple

De todo un poco:

¿Por qué es tan difícil desarrollar software de calidad en plazo?

http://news-service.stanford.edu/news/2005/june15/jobs-061505.html

http://www.microsiervos.com/archivo/ordenadores/sistema-orion.html

Tareas (tentativas) a hacer (To Do):

  • Dejar el post tal como está.
  • Agrupar los puntos por tipo de proyecto (para todos los proyectos, proyectos chicos, medianos, grandes) .
  • Agrupar por rol (programador, analista, tester, responsable de aplicación, líder de proyecto).

Imágenes del flujo de un sistema


Se aceptan sugerencias, quejas, comentarios, nuevos títulos, más puntos, actualizaciones, traducciones, aportaciones, seguimientos o siguientes versiones (creo que ésta ya puede catalogarse como una 1.0).

:)



Actualización 2007-11-26 (Otros puntos de vista):

20 tips para ser un mejor programador
Los principios del programador