Tema: Buenas prácticas de programación

tener un buen manual corporativo con todas las reglas bien claras, desde nombres de variables a procedimientos estándar que hay que seguir. Mientras eso no exista, va a ser siempre algo desordenado y siempre va a generar quejas.

Por otro lado, decirte que algo es buena o mala práctica sin saber ni siquiera de qué lenguaje estamos hablando sería algo tirado de las mechas, y aunque supiéramos qué lenguaje es de todas formas siempre habrán críticas dentro de la empresa pq seguramente el procedimiento a seguir o el protocolo que tienen internamente es otro.

Saludos.

Lo primero (por trauma personal) es tener un control de versiones absolutamente estricto.

Ya me ha pasado en dos pegas diferentes

Pega 1: No había ningún control de versiones y después se agregó a la fuerza. Ante cualquier bug el encargado se metía por FTP al servidor y arreglaba código en tiempo real. Como inicialmente no había versionamiento no habían entornos de desarrollo, y nunca quise ni preguntar comom habían hecho la primera versión de la aplicación

Pega 2: Un híbrido Rails / PHP con otras tecnologías. La parte Rails estaba bien versionada por lo menos. Cuando pregunté donde estaba el repositorio de laparte PHP para tratar de levantar algo localmente me miraron como si estuviera loco.

-UML.
-Documentación, tanto en código como manuales.
-Estandarización de variables.

Al menos con esas es bueno partir según mi punto de vista.

sres. todo está escrito, bueno, al menos en java.

existen las java coding conventions de oracle, documentos de especificaciones para aplicaciones empresariales, patrones de diseño y uml.

mi recomendacion es crear un buen documento de arquitectura (que incluya todo lo anterior, desde los diagramas de arquitectura de sw hasta la nominación de los metodos/procedimientos)
y obligar a los egipcios a ceñirse a esa biblia.

todo fluye más tranquilo con orden y un "lenguaje" común.


en todo caso, nada que un arquitecto de sw no sepa, quizá debas empezar contratando uno

Yo creo que lo principal es hacer entender a las jefaturas que el análisis, diseño y modelamiento son etapas fundamentales en los proyectos de software, que toman tiempo y que se deben hacer y documentar. Sino, por muchas normas que hayan igual termina quedando la cagá y el desorden al desarrollar. Todo ello aplicado no solo a proyectos nueos, sino que tambien a moificaciones o mantenciones.

buenas practicas, todo lo que se enseña en la ing de software.

harta documentacion, reglas den comun para la programacion (llamese usar control de versiones, variables nemotecnicas etc etc)

realizar proyectos basados en un ciclo de vida (y no siguiendo un proceso caotico), en lo posible aplicar cmm.

y ponerle gran enfasis a la ingenieria de requerimientos (si es que el ciclo de vida lo amerita)

he intenta evitar el cascada

Iniciado por Manuel_CHW

-UML.

Hay veces que te reclaman porque en el diagrama de casos de uso no pusiste el peo que se debe tirar el usuario al apretar enter

---------- Post added at 12:38 ---------- Previous post was at 12:35 ----------

pd:

Iniciado por Cosme

Hay veces que te reclaman porque en el diagrama de casos de uso no pusiste el peo que se debe tirar el usuario al apretar enter

---------- Post added at 12:38 ---------- Previous post was at 12:35 ----------

pd:
[qimg]https://dl.dropbox.com/u/5911749/job-fails-something-definitely-gets-lost-in-transit.jpg[/qimg]

para eso esta el IEEE 830

Iniciado por Xzwatz

Yo creo que lo principal es hacer entender a las jefaturas que el análisis, diseño y modelamiento son etapas fundamentales en los proyectos de software, que toman tiempo y que se deben hacer y documentar. Sino, por muchas normas que hayan igual termina quedando la cagá y el desorden al desarrollar. Todo ello aplicado no solo a proyectos nueos, sino que tambien a moificaciones o mantenciones.

No necesariamente, de hecho esas metodologías rigidas no sirven mucho para el software. Es mejor tener un enfoque liviano y ágil para el desarrollo.

Hay que documentar lo menos posible, lo suficiente para dejar claro el tema; pero sin caer en la construcción de biblias.

Iniciado por Miguelost

buenas practicas, todo lo que se enseña en la ing de software.

harta documentacion, reglas den comun para la programacion (llamese usar control de versiones, variables nemotecnicas etc etc)

realizar proyectos basados en un ciclo de vida (y no siguiendo un proceso caotico), en lo posible aplicar cmm.

y ponerle gran enfasis a la ingenieria de requerimientos (si es que el ciclo de vida lo amerita)

he intenta evitar el cascada

No realmente, mucha documentación puede ser incluso más dañino que la nula documentación.




Hay bastante libros sobre el tema, tanto a nivel de código como a nivel de proyectos.

M$ tiene un set de reglas y convenciones para sus lenguajes (aunque se pueden extrapolar a otros).



Yo compré hace un tiempo un libro interesante sobre el tema, se llama Code Complete de Steve McConnell; con buenas prácticas a todo nivel.


Una buena "práctica" es dejar de soñar con la cartas gantt o pensar que usar el PMBOK va a ayudar con un proyecto de informática. La regla número 1 en esto de la informática es "cambio"; simplemente NO se puede pensar que el cliente/usuario/weon no va a pedir cambios, siempre los va a pedir, y eso es una realidad (y lo de definir requerimientos firmados simplemente es una fantasía, porque al final atenta contra la necesidad).

Muy de acuerdo con el comentario del usuario de arriba, recomiendo revisar el manifiesto de desarrollo agil, y su mas reciente evolucion, el manifiesto sobre artesania de software.

Hace tiempo, lei sobre un excelente libro, pero lástima que por ahora no tenga el tiempo de revisarlo, para el que le interesa le dejo el link.
[ame="http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_2?ie=UTF8&qid=1346981225&sr=8-2&keywords=the+clean+coder"]Amazon.com: Clean Code: A Handbook of Agile Software Craftsmanship (9780132350884): Robert C. Martin: Books[/ame]

Iniciado por zxy

Muy de acuerdo con el comentario del usuario de arriba, recomiendo revisar el manifiesto de desarrollo agil, y su mas reciente evolucion, el manifiesto sobre artesania de software.

Hace tiempo, lei sobre un excelente libro, pero lástima que por ahora no tenga el tiempo de revisarlo, para el que le interesa le dejo el link.
Amazon.com: Clean Code: A Handbook of Agile Software Craftsmanship (9780132350884): Robert C. Martin: Books

Buen dato, lo acabo de comprar, mañana lo reviso (kindle FTW)

Iniciado por Ribosoma

Una buena "práctica" es dejar de soñar con la cartas gantt o pensar que usar el PMBOK va a ayudar con un proyecto de informática. La regla número 1 en esto de la informática es "cambio"; simplemente NO se puede pensar que el cliente/usuario/weon no va a pedir cambios, siempre los va a pedir, y eso es una realidad (y lo de definir requerimientos firmados simplemente es una fantasía, porque al final atenta contra la necesidad).

Me encantó esa frase. El desarrollo, en mi opinión, necesita ser lo más flexible posible, sin por eso, ser desordenado.

Lo que muchos pierden de vista con la planificación y documentación, es que el propósito de ambas es facilitar los procesos de desarrollo, implementación y mantención. En el momento que por documentar y hacer planes se empieza a estorbar a esos procesos, se pierde el objetivo y se entra en la burocracia. Del mismo modo, nunca sale nada bueno lanzándole líneas al compilador 10 segundos después de recibir el encargo.

Esta bueno el dato del libro, lo buscaré.

Muchos de los tips arriba son clave, el más importante por mucho es el que está en negrita. Los clientes/usuarios/weones (quoteo de como dice arriba) derechamente no saben lo que quieren. Antes que te llegue un listado de requisitos de lo que el programa debe tener, debe pasar por un filtro de mercadotecnia o de metodologías de programación.

En cuanto al desarrollo yo en general no concuerdo con lo de Desarrollo Ágil pero tiene un punto importante que es no exagerar con la documentación... hay cosas que tienen que ir sí o sí: la licencia obvio, el detalle de casos de uso pendientes; una FAQ porque derechamente sin importar qué tan listo o torpe sea tu cliente hay dudas básicas fuera del entorno técnico del programa que va a tener.

Tener un sistema de control de versiones más que decente, tener un beta tester independiente, no reinventar la rueda a menos que haya motivos técnicos importantes para hacerlo pero al mismo tiempo no comprar ruedas extranjeras cuando tienes un requerimiento funcional interno de *hacer* que una rueda funcione.

Otra cosa, no ponerse filosófico e irse por las ramas con el programa agregándole características de bonus y preparación para casos exceptionales hasta después que cumpla, de manera certera, con los requerimientos básicos como están estipulados. El juego de Doom dentro de Excel no es de mucha utilidad si la funcionalidad de sumar una columna no sirve.

Iniciado por zxy

Muy de acuerdo con el comentario del usuario de arriba, recomiendo revisar el manifiesto de desarrollo agil, y su mas reciente evolucion, el manifiesto sobre artesania de software.

Hace tiempo, lei sobre un excelente libro, pero lástima que por ahora no tenga el tiempo de revisarlo, para el que le interesa le dejo el link.
Amazon.com: Clean Code: A Handbook of Agile Software Craftsmanship (9780132350884): Robert C. Martin: Books

Bueno, acabo de leer los primeros 3 capitulos, y no me gusto.... Prefiero el code complete 2.

yo soy de los que hay que documentar, mas que nada para el tema de la mantencion del software y como respaldo por si algun dia hay que hacer un software medianamente parecido a alguno que se desarrollo años atras, no tener que reinventar la rueda ni los requerimientos.

sobre el tema de que los requerimientos estan en constante cambio, es verdad, por eso siempre hay que basarse en algun ciclo de vida que permita realizar permanente cambios sobre eso (llamese incremental, prototipado, xp bla bla bla)

Iniciado por Ribosoma

No necesariamente, de hecho esas metodologías rigidas no sirven mucho para el software. Es mejor tener un enfoque liviano y ágil para el desarrollo.

Hay que documentar lo menos posible, lo suficiente para dejar claro el tema; pero sin caer en la construcción de biblias.

No realmente, mucha documentación puede ser incluso más dañino que la nula documentación.

Hay bastante libros sobre el tema, tanto a nivel de código como a nivel de proyectos.

M$ tiene un set de reglas y convenciones para sus lenguajes (aunque se pueden extrapolar a otros).

Yo compré hace un tiempo un libro interesante sobre el tema, se llama Code Complete de Steve McConnell; con buenas prácticas a todo nivel.


Una buena "práctica" es dejar de soñar con la cartas gantt o pensar que usar el PMBOK va a ayudar con un proyecto de informática. La regla número 1 en esto de la informática es "cambio"; simplemente NO se puede pensar que el cliente/usuario/weon no va a pedir cambios, siempre los va a pedir, y eso es una realidad (y lo de definir requerimientos firmados simplemente es una fantasía, porque al final atenta contra la necesidad).

100% de acuerdo.

Muchas veces una simple hoja de papel con un par de rayas dice mucho más que un manual de 100 hojas.

Para control de cambio es suficiente basta ponerse de acuerdo y enviar un email dando a entender claramente el cambio. Una reunión para quedar de acuerdo sobre el cambio y luego ponerse a trabajar, ya se perdió tiempo y la esencia del cambio. En las reuniones todo se entrampa y adquiere una complejidad mayor a lo pedido y se comienza a involucrar a otras áreas que no les compete y piden para igualar la cancha.

No estoy diciendo que no a las reuniones pero reunión por cada cosa es una locura. Basta una reunión para formalizar varios cambios.

Anécdota:
En un seminario llevado a cabo en Santiago - Chile, los japoneses expusieron que Chile es el país donde más reuniones/seminarios/conferencias se dictan en el mundo y la pregunta que ellos se hacen es: ¿Cuándo se trabaja para llevar a la práctica tales nuevos conocimientos y como repercute en la productividad?

Saludos

Iniciado por Miguelost

yo soy de los que hay que documentar, mas que nada para el tema de la mantencion del software y como respaldo por si algun dia hay que hacer un software medianamente parecido a alguno que se desarrollo años atras, no tener que reinventar la rueda ni los requerimientos.

sobre el tema de que los requerimientos estan en constante cambio, es verdad, por eso siempre hay que basarse en algun ciclo de vida que permita realizar permanente cambios sobre eso (llamese incremental, prototipado, xp bla bla bla)

esos sistemas ya están algo obsoletos, es más, dudo que alguna vez funcionaran :S

Iniciado por jacosito

100% de acuerdo.

Muchas veces una simple hoja de papel con un par de rayas dice mucho más que un manual de 100 hojas.

Para control de cambio es suficiente basta ponerse de acuerdo y enviar un email dando a entender claramente el cambio. Una reunión para quedar de acuerdo sobre el cambio y luego ponerse a trabajar, ya se perdió tiempo y la esencia del cambio. En las reuniones todo se entrampa y adquiere una complejidad mayor a lo pedido y se comienza a involucrar a otras áreas que no les compete y piden para igualar la cancha.

No estoy diciendo que no a las reuniones pero reunión por cada cosa es una locura. Basta una reunión para formalizar varios cambios.

Anécdota:
En un seminario llevado a cabo en Santiago - Chile, los japoneses expusieron que Chile es el país donde más reuniones/seminarios/conferencias se dictan en el mundo y la pregunta que ellos se hacen es: ¿Cuándo se trabaja para llevar a la práctica tales nuevos conocimientos y como repercute en la productividad?

Saludos

sobre las reuniones, no es nada... onda, si estas metido con ITIL los putos cambios tienen que pasar por un comité para ser aprobados :S

(ITIL está bien cuando el cambio es una actualización de los equipos, pero es una mierda para el desarrollo)

a mi me enseñaron que las reuniones de equipo deben ser en oficinas sin sillas ni mesas, solo con una pizarra (al estilo gringo)

el por que? simple, con sillas y mesas y cafe se desvirtua la reunion y se termina hablando de la luli en 1 hora de reunion.

sin sillas ni mesas, todos quieren puro irse asi que haran una reunion corta y consisa de 15 minutos y que sera mas productiva