Cita:
|
Empezado por Al González
¡Hola a todos!
Gracias por el comentario, pero creo que te has perdido de la mejor parte (la Red Colaborativa).
Por cierto, si alguien quiere publicar mi artículo en su Web, siéntase con la libertad de solicitarme el texto original.
Anoche estuve pensando que sería conveniente revisar la organización de las especialidades ahí propuestas. Después de haber ganado algo de experiencia en este experimental modelo, creo que sería adecuado colocar PO (la programación escrita para las interfaces de usuario), PB y PL —Programación de Lógica de negocios (nueva)— como subespecialidades de una nueva especialidad abreviada como "PR" (Programación). Y considerar RE como parte de DO (diseño visual de las interfaces de usuario), o sea, no mutuamente exclusivas. En cuanto a MD aún tengo mis dudas de si debe aparecer o dónde debe ir, ya que todavía no he puesto en práctica esa especialidad de manera formal, aislada o explícita.
Algo que me faltó agregar en mi propuesta hecha en este hilo (sobre el esquema de trabajo), es que también es importante definir lanormativa de desarrollo , es decir, las reglas de estándares, estilos, nomenclaturas y demás que deberán seguirse durante el desarrollo del software, para no sólo trabajar bajo el mismo lenguaje sino también hablar el mismo idioma. Este asunto suele generar polémica cuando existe demasiado apego u obstinación a la manera de programar de cada uno, y para mí es uno de los parámetros clave que determina si una persona tiene o no facilidad para integrarse al trabajo en equipo; si antepone o no los objetivos del grupo a sus gustos personales.
En resumen, reiterando mi propuesta y, claro, si la mayoría de los interesados están de acuerdo, definamos el esquema general de trabajo y luego el proyecto de software.
Un abrazo esperando comentarios.
Al González.  |
Eso es algo
esencial, es lo primero que hago cuando inicio un nuevo proyecto: entregar a cada uno un documento con las normas a seguir para la nomenclatura de todos los datos. Y si cualquier parte no cumple esa norma, no pasa al proyecto final hasta que haya sido corregida.
De esta forma, el código se hace facilmente comprensible para cualquier persona que participa en el proyecto, casi como si fuese su propio código (siempre hay pequeñas diferencias sin importancia.