Hola a todos, abro este tema para saber sus opiniones. En la noche de ayer estuve hablando con un colega; sobre los estándares de programación.
Hay de todos tipos:
Estándares del propio  lenguaje (Java, Python, C, C#, etc...)
Estándares empresariales
Estándares propios
los globales que todos deberíamos utilizar.
Y llegamos a la conclusión, que el mejor es el propio. Uno como programador debe escribir código entendible para cualquier persona con algo de conocimiento sobre programación. aparte que en cada empresa debe haber un estándar de codificación.
el diseño orientado a objetos es lo que debe imperar.
hace poco leí que al empezar un proyecto se debería ir redactando dos documentos; uno para el usuario que utilizara el proyecto y otro para los desarrolladores que posiblemente lleguen a seguir desarrollando la aplicación.
pocas veces se sigue en algunas empresas; un antiguo jefe me contó que en microsoft eso es obligatorio, jejeje


Igual sucede con las metodologías de gestión de proyectos; llame se: Scrum y Xp, agile development, testing, blablabla seria bonito si todo se siguiera en base a eso pero siempre el business side cambia las cosas.

la pregunta del knock out! fue: que cosas tu harías para resolver eso: el business side cambia las cosas.

No sacamos una respuesta...simplemente pensamos que de eso se encarga el boss. Pero seria bueno averiguar... conocer y profundizar en ese tema. Quien sabe el destino nos tiene escrito ser algún día un Boss y nos borriguero. no hay que caer en lo mismo...no creen¿?

Mira, un principio Kantiano que sigo es: No hagas lo que no te gustaría que te hiciesen.

A mi me gusta que me expliquen las cosas un millón de veces si hace falta, ¡y por eso suspendo programación!tiendo a explicarlo absolutamente todo, me ocupe el código que me ocupe.

Lo óptimo sería que todo el codigo estuviese totalmente estructurado, pecando bastante de ello, y los procesos sólo hicesen cosas simples (no tanto como coger un numero, pero sí lo suficiente como para no perdernos con la sintaxis), cosa que muy pocas veces ocurre (leer el codigo del juego Ragnarok Online es una puta locura, en serio)

Normalmente eso toma mucho tiempo, y las empresas siempre te aprietan las tuercas: si se hace bien en 2 semanas (15 días, pongamos), ellos te lo piden para 10 y así saben que estarás programando sí o sí.

Yo le veo muchos inconvenientes a esa forma de trabajar. Para mí lo óptimo en un equipo de trabajo (que eso creo que tendría que darse cuenta alguien, digo yo) seria que si los programadores son unos gañanes que no ponen ni comentarios, alguien que fuese muy muy pesado o que supiese leer código hiciese ese mismo trabajo... pero claro, no van a pagar a alguien para hacer eso.

Metro de Madrid, por ejemplo, tiene un grupo de programadores que se dedica a proporcionarles software. Conozco a ciertas personas que están trabajando dentro de la empresa (no de esa sección), y cuando un soft tiene que reformarse, simplemente lo tiran y vuelven a empezar de cero (otro currazo),pero su jefe prefiere hacerlo así a tener un montón de libros sobre cómo se han hecho las cosas (para que la gente no se lo lleve a casa y no revelen secretos de la compañía).

Depende de muchas cosas, aunque yo prefiero que pequen de dejar un webo de comentarios a que no dejen ninguno...

Hola Niniel, gracias por darme a conocer tu opinión... Si es totalmente cierto lo que dices. La mayoría de las compañías de desarrollo de software, te pagan para programar; y no para cumplir los estándares. Sencillamente programas o programas; lo único que desean es ver terminado y funcionando lo más rápido posible; la aplicación.
He pensado en una posible solución... Donde trabajaba, laborábamos de lunes a sábado. siendo de 8am - 5pm de lunes a viernes y los sábados de 8am - 12md.
Con un horario así, sinceramente yo solo programaba de lunes a viernes; y los sábados; hacia tareas de documentación.
Y nunca tuve quejas por parte de mis jefes...
la chingada, es que labores de lunes a viernes... dudo! que alguien sacrifique 4 horas del sábado que nadie le va a pagar...para documentar todo.

Y llego la hora de las opiniones controvertidas!

La frontera que salva el software libre del privativo es simplemente el infinito y el -infinito:

Son la misma recta, pero estan tan lejos...

Tanto es asi, que muchos han sido los softwares privativos, que ante el fracaso han sido liberados, y pocos de ellos han salido adelante, y de esos pocos, la mayoria costo mucho tiempo darles arrancada.

La empresa tiene completo derecho a elegir si sus programas deben estar documentados o no (development siempre).

Y para elegir si debe o ne debe documentar debe valorar varias cosas:

El tamaño e importancia de la pieza de software:
Puede ocurrir que la mayor parte del software que produce una empresa sea de tipo auxiliar, o que trabaje sobre prototipos (en el mundo de la simulacion ingenieril es muy tipico). Entonces, esos fragmentos de codigo, o solo se van a usar una vez, o son un simple parche momentaneo que cuando deje de funcionar se podra tirar a la basura sin complejos.

Se dispone de personal mas cualificado:
Se que suena mal, pero resulta que para los pogramadores mas novatos en la empresa (o en general) algunos comentarios les resultan cruciales, y algunas ideas que tienen creen que son simples genialidades, pero entonces llega el respetable de turno, y lee tu codigo sin pararse a mirar un puto comentario, como si lo llevara dentro.
Las empresas grandes es tipico que tengan gente muy cualificada capaz de recuperar tu codigo si es necesario.

Se dispone de tiempo:
Si la empresa no dispone de tiempo, no dispone de tiempo y punto.

La empresa es grande:
Las empresas grandes tienen sus ventajas, pero tambien sus desventajas. Una de las mas grandes es que sus empleados trabajan y producen software con una cierta despreocupacion, luego, otras personas lo integran en paquetes mas grandes, modificandolo como necesiten, y mas tarde los beta test devuelven errores que corrigen otras personas distintas. Todo eso pasa a construir los nucleos del software, que son llamados asi simplemente porque ya nadie podra volver a entrar alli.

Mi opinion sobre si hay que documentar las cosas es que por supuesto si, siempre que planees recuperar ese trabajo mas tarde (tu u otra persona).

Tambien hay que tener en cuenta un ultimo factor fundamental, ¿tienes algo que documentar?
Muchas veces es dificil encontrar el compromiso exacto entre desarrollo y documentacion. Si vas documentando cada paso que tomas, pierdes el hilo, avanzas demasiado lento, y puede incluso que montes aun mas follon (luego resulta que no funciona, y te toca corregir el codigo y la documentacion). Si documentas cada demasiado tiempo, el asunto esta demasiado frio, y entonces cuesta retomarlo, lo quer acaba resultando en documentaciones pobres.

Como dice Torvalds, hay que escribir el código de tal manera que los otros lo entiendan y hay que documentar que hace, NO cómo lo hace, y al ser posible, SÍ porque lo hace. Documentar una función no ocupa más de 5 minutos de tecleo y siguiendo el modelo inteligente, que es hacer código legible, el desarrollo tardío es más cómodo y te ahorras más errores.

El software libre simplemente sabe que cualquier persona puede ver tu código y modificarlo, por eso se ocupan de documentarlo mejor. Los señores empresarios simplemente, con que funcione... así les va, que cada día se usa menos el software privativo y más el libre.

Tienes razón con:
Que en el software libre se ve mucho más documentado el código de las aplicaciones; obviamente debido a que se sabe que ese código puede ser visto por cualquiera.
Pero hay que decir que no todas las aplicaciones creadas bajo la ideología del software libre; son bien documentadas.