Página 1 de 3 123 ÚltimoÚltimo
Resultados 1 al 20 de 54

Tema: Buenas prácticas de programación

  1. #1
    Pajarito Nuevo Avatar de InvisoChile
    Fecha de ingreso
    19 Nov, 11
    Mensajes
    49

    Buenas prácticas de programación

    Estimados amigos :

    A menudo trabajando como externo, me ha pasado que el código llega al area de tecnología de la empresa y empiezan las críticas. Que falta documentación, que hay malas prácticas, y un sinnúmero de etcs.

    Lo curioso, es que es siempre el mismo tipo de desarrollo pero las críticas varían.

    Según ustedes, ¿Qué prácticas son las correctas, o se deben tener en cuenta, para hacer un programa bajo buenas prácticas de programación?

    Eso.

    Saludos!

  2. #2
    Zend Certified Engineer

    Overlord
    Avatar de unreal4u
    Fecha de ingreso
    02 Oct, 05
    Ubicación
    Eindhoven, The Netherlands
    Mensajes
    12,129

    Re: 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.
    Lee Nuestra FAQ, los famosos 14 mandamientos de CHW.
    El Reglamento de Compra-Venta, Nuestra Visión y por último, Nuestra Historia


    Futurama & The IT Crowd fanboy
    Frase célebre: "Debido a la gran cantidad de guiños y referencias relacionadas con el mundo informático, esta sección permanecerá siempre incompleta, al menos hasta que se complete"
    Para el bronce: Oh, i'm very confortable with my sexuality, i just don't want to be slapped in the face with THEIR sexuality

    Mi blog | Mi Twitter | Zend Certified Engineer

  3. #3
    Enajenado
    Avatar de [VJ]
    Fecha de ingreso
    10 Jan, 06
    Ubicación
    Santiago, Chile
    Mensajes
    10,291

    Re: Buenas prácticas de programación

    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.


    Cotiza tu notebook en SoloNotebooks

    Arma tu tarro en SoloHardware

    Encuentra tu nuevo LCD/LED en SoloElectro


  4. #4
    Wn amargo Avatar de Manuel_CHW
    Fecha de ingreso
    25 May, 09
    Ubicación
    Santiago
    Mensajes
    3,065

    Re: Buenas prácticas de programación

    -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.

  5. #5
    Buscando el norte
    Avatar de Kensho
    Fecha de ingreso
    16 Aug, 06
    Ubicación
    En este cuerpo que me contiene.
    Mensajes
    2,349

    Re: Buenas prácticas de programación

    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
    A los que contemplan la luna las nubes a veces ofrecen una pausa.

    Portable: Shure se-215 / HifiMan RE-0 / Sennheiser PX-200 II | Studio: Samson Resolv 40a / Fiio A1 | HT: Onkyo TX-SR 308 / Paradigm Titan Monitor v. 6

  6. #6
    Pajarito Nuevo
    Fecha de ingreso
    02 Mar, 12
    Mensajes
    50

    Re: Buenas prácticas de programación

    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.

  7. #7
    Programador - Arch User
    Avatar de Miguelost
    Fecha de ingreso
    20 Nov, 07
    Ubicación
    Mi Cama - La Serena
    Mensajes
    3,153

    Re: Buenas prácticas de programación

    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

  8. #8
    Guru
    Avatar de Cosme
    Fecha de ingreso
    27 Feb, 05
    Ubicación
    Santiago
    Mensajes
    9,257

    Re: Buenas prácticas de programación

    Cita Iniciado por Manuel_CHW Ver mensaje
    -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:



  9. #9
    Programador - Arch User
    Avatar de Miguelost
    Fecha de ingreso
    20 Nov, 07
    Ubicación
    Mi Cama - La Serena
    Mensajes
    3,153

    Re: Buenas prácticas de programación

    Cita Iniciado por Cosme Ver mensaje
    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

  10. #10
    Guru
    Avatar de Ribosoma
    Fecha de ingreso
    04 Jan, 06
    Ubicación
    Santiago, Chile
    Mensajes
    5,133

    Re: Buenas prácticas de programación

    Cita Iniciado por Xzwatz Ver mensaje
    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.



    Cita Iniciado por Miguelost Ver mensaje
    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).

  11. #11
    zxy
    zxy está desconectado
    Pajarito Nuevo Avatar de zxy
    Fecha de ingreso
    07 Apr, 11
    Mensajes
    125

    Re: Buenas prácticas de programación

    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]
    Última edición por zxy; 06/09/2012 a las 22:35
    Nadie sabe de lo que es capaz hasta que lo intenta

  12. #12
    Guru
    Avatar de Ribosoma
    Fecha de ingreso
    04 Jan, 06
    Ubicación
    Santiago, Chile
    Mensajes
    5,133

    Re: Buenas prácticas de programación

    Cita Iniciado por zxy Ver mensaje
    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)

  13. #13
    Usuario
    Fecha de ingreso
    27 Mar, 09
    Mensajes
    150

    Re: Buenas prácticas de programación

    Cita Iniciado por Ribosoma Ver mensaje
    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é.

  14. #14
    Orgullosament Retro Avatar de ryan.chappelle
    Fecha de ingreso
    15 Nov, 05
    Ubicación
    Temuco, CHILE
    Mensajes
    211

    Re: Buenas prácticas de programación

    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.

  15. #15
    Guru
    Avatar de Ribosoma
    Fecha de ingreso
    04 Jan, 06
    Ubicación
    Santiago, Chile
    Mensajes
    5,133

    Re: Buenas prácticas de programación

    Cita Iniciado por zxy Ver mensaje
    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.

  16. #16
    Programador - Arch User
    Avatar de Miguelost
    Fecha de ingreso
    20 Nov, 07
    Ubicación
    Mi Cama - La Serena
    Mensajes
    3,153

    Re: Buenas prácticas de programación

    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)

  17. #17
    Experimentado
    Fecha de ingreso
    03 Sep, 07
    Mensajes
    631

    Re: Buenas prácticas de programación

    Cita Iniciado por Ribosoma Ver mensaje
    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
    Última edición por jacosito; 08/09/2012 a las 22:37

  18. #18
    Guru
    Avatar de Ribosoma
    Fecha de ingreso
    04 Jan, 06
    Ubicación
    Santiago, Chile
    Mensajes
    5,133

    Re: Buenas prácticas de programación

    Cita Iniciado por Miguelost Ver mensaje
    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


    Cita Iniciado por jacosito Ver mensaje
    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)

  19. #19
    Programador - Arch User
    Avatar de Miguelost
    Fecha de ingreso
    20 Nov, 07
    Ubicación
    Mi Cama - La Serena
    Mensajes
    3,153

    Re: Buenas prácticas de programación

    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

  20. #20
    ltr
    ltr está desconectado
    Pajarito Nuevo Avatar de ltr
    Fecha de ingreso
    21 Nov, 11
    Mensajes
    31

    Re: Buenas prácticas de programación

    Opinión personal :
    1.- Test Driven Development y Test First , al menos en JAVA es increíblemente útil si lo llevas a la practica, requiere de que sueltes la mano por un tiempo, pero una vez que absorbes la filosofía de hacer el test primero te das cuenta de que te ahorras una cantidad de tiempo increíble y también costos post entrega y fix en producción. No es facil y la frustración en un principio puede acabar con la idea.
    2.- Control de versiones (SVN o en el mejor de los casos GIT) y cultura para llevar branches,tags y trunks.
    3.- Entorno de desarrollo configurable y perfilable por desarollador, unas de las cosas que me a ayudado un montón en desarrollos grandes, a sido que el ambiente de desarrollo puede estar montado en menos de 1 hora en cualquier SO.
    4.- Mock objects (para los tests)
    5.- Tests unitarios, aparte de los tests de integración los unitarios te pueden ahorrar cientos de horas si las sumas todo en un mes, típico que en algunos ambientes tienes que levantar todos los componentes o deployarlos en un AP solo para hacer F5 y ver si te resulto un if!
    6.- Base de datos embebidas (ej. hsdb, derby), no necesariamente por que la DB en producción es oracle tienes que tener una DB para probar.
    7.- un Wiki
    8.- Scrum (solo para algunos casos, es una pesadilla contable $$$)
    9.- entrando más en lo técnico : ocupar "Tell , dont ask" en el desarrollo OOP.
    10.- JAVA Doc
    11.- un solo programador "rockstar" por equipo
    12.- ciclos de QA acelerados 15 días max. siempre mantener un servidor con los "nightly builds" del sistema a disposición del cliente.
    13.- documentación Just in time, antes de hacer un requerimiento hacer los diagramas pertinente en una servilleta o algo mas "persistible" ,


    esas son las prácticas que mas tengo presente en este momento que me han ayudado un montón a acelerar las cosas en cuanto a desarrollo con teams grandes.
    uno de los problemas mas grandes es traspasar las buenas practicas y evangelizar a los resistentes al cambio.
    Última edición por ltr; 11/09/2012 a las 18:54 Razón: documentación JIT

Página 1 de 3 123 ÚltimoÚltimo

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •  
*