#51 "Comentar código es algo que siempre es necesario, y más con métodologías ágiles en las que se hace menos énfasis en la documentación pura y dura"

No en metodologias agiles como XP (eXtreme Programming), lo de que siempre es necesario es una afirmacion dada en los metodos tradicionales generalmente (pero otras metodologias como XP como digo afirma lo contrario) asi que esa afirmacion es mas bien una opinion. Es mas en metodologias agiles como XP la documentacion es el propio codigo, que refactorizacion tras refactorizacion y empleando ciertos patrones de diseno para evitar estos comentarios al final permite crear algo parecido a un pseudocodigo en cuanto a la esencia del codigo se refiere. Cuando estude en la universidad mi codigo era el mas claro y no precisaba de comentarios porque empleaba estas tecnicas (en comparacion con el resto de clase) pero ademas es que no solo sirve para programas pequenos como en la universidad (y por eso hacia referencia a C3) de hecho yo mismo he empleado en varias de las empresas en las que he estado metodologias agiles sin comentarios en el codigo, pero he de reconocer que he usado comentarios cuando trabaje en codigo de bajo y medio nivel al desarrollar partes de un sistema operativo grande como es IOS (para otra empresa la que trabaje, Cisco systems). A lo que me refiero es que no se puede generalizar cuando empleas ciertos lenguajes para desarrollar alto o bajo nivel, ni por motivos como optimizacion (ya que yo estaba en el equipo de optimizacion de paquetes) el codigo es critico y predomina esa optimizacion sobre la legibilidad de codigo, es ahi donde si entiendo ciertos comentarios... pero no en programas donde la claridad es por culpa de malas practicas empleadas por el programador como el mal uso de la semantica por ejemplo.

#64 como bien expuse en #63 explico las razones de por que a veces es necesario comentar, pero comentar como lo hace la gente habitualmente es un error, simplemente recomiendo que leas el libro de "The Pragmatic programmer" (el que haya trabajado en alguna empresa con XP vera que no todo es utopia) simplemente la gente tiene ciertas costumbres y cree que porque es una costumbre no puede ser un mal habito, cuando en casi todos los casos lo es, excepto en contados... en mi caso cuando trabaje en esa empresa me tocaba revisar el codigo de IOS en busca de bugs, asi que no creo que sea yo al primero al que le interese perder legibilidad en el codigo me estaria echando piedras en mi propio tejado; simplemente digo que para programas o porciones de codigo 'no criticas' pruebes y apliques la teoria de dicho libro y me digas si funciona, es solo una sugerencia, si no te funciona podras comprobarlo luego.

Obviamente para escribir codigo claro se necesitan ciertas nociones y no todo el mundo es competente a la hora de desarrollar, asi que se necesita un tiempo y ver codigo de otros profesionales para darse cuenta que funciona (de ahi que recomendase otros libros en mis comentarios anteriores).

#67 "Mirando el historial del source safe vi que empezó recibiendo pero que a lo largo de unos 8 años, y tras pasar por 10 programadores, se le fueron añadiendo más datos a insertar en base de datos y nadie cayó en crear una clase que encapsulara todo."

Por eso mismo ciertas metodologias agiles recomiendan refactorizar siempre que puedas, no se puede mantener un codigo simplemente desarrollando sin refactorizar, es una practica de buenos habitos.

#68 Por eso día lo de talibán. Si programas elegantemente (métodos de pocas líneas y poco anidados, objetos que sólo hacen una cosa pero la hacen eficientemente, etc) apenas necesitas comentarios. Pero aun así siempre pongo el Javadoc (o equivalente) en todo lo que creo.

#70 Justamente de eso tambien habla XP, sobre los plazos que casi nunca se suelen cumplir empleando el metodo tradicional (a no ser que los programadores hagan muchas mas horas los ultimos dias para llegar a dicho plazo). Pero es mas, te contestare que eso en metodologias no agiles es mucho mas costoso por los ciclos del proyecto:

http://www.agile-process.org/

Lo digo porque a diferencia de otras metodologias, aqui si el proyecto fracasa o se queda a mitad por falta de presupuesto, etc. el cliente se queda con algo mas que un simple analisis o un analisis y un diseno, se queda con un programa funcional que cumple las funciones prioritarias y la falta de presupuesto hace que no cumpla las menos importantes (o no prioritarias). De todas formas yo no soy jefe de proyecto, pero mis jefes de proyecto no dan plazos imposibles, hablan con el cliente y de hecho el cliente envia a empleados suyos dentro de la empresa para ver el progreso del mismo (mas que nada para evitar sustos al final, eso tiene un nombre:

http://www.agile-process.org/byfeature.html
http://www.agile-process.org/change.html

Ya os digo, podeis ver el ejemplo historico de C3 y vereis donde esas especificaciones que comentais cambiaban, que el sistema estaba en produccion, que era un monstruo enorme complejisimo de reformar y que el resto de metodologias fallaron aqui, pero no XP (y en la historia se explica cada detalle y como se soluciono), si no recuerdo mal, esto esta explicado en el "extreme programming explained".

#69 Es que si uno no hace el trabajo bien hecho es imposible trabajar con el en un mismo equipo, o cambia o se le cambia, no he visto autenticas barbarides por suerte porque esa gente o no entraba o ha cambiado.

#68, ese proyecto ya no hay quien lo refactorice, sería más rápido quemarlo y empezar de 0. A parte, el presupuesto es tal que el cliente te dice "Oye, ahora quiero guardar también el dato X, eso se hace en 5 minutos,no me lo cobráis, ¿no?

#185 Por supuesto que tiene razón. Y tú tambien. Todos llevamos razón cuando explicamos nuestra experiencia personal. Otra cosa es cuando nos mojamos emitiendo una opinión sobre una tendencia, un colectivo...en fin, sobre algo no se ciña a nuestra estricta experiencia personal. Ahí es normal que te lluevan palos porque ante una opinión como la mía es normal que respondan los que no estan de acuerdo. Lo que pido es que se responda con respeto ( como has hecho tú )y a ser posible dando argumentos globales, que las experiencias personales tienen mala hechura para según qué debates. Poniendo un ejemplo extremo, yo no puedo argumentar contra el cancer de pulmón diciendo que tengo 90 años, me fumo dos paquetes diarios y aquí sigo tan feliz.

Saludos.

#163 pues entonces no vengamos con lo de la "consola agilipolladora", porque muchos de mis amigos son también jugadores habituales de toda la vida y el que más y el que menos tiene un cierto gusto por la lectura.

Te aseguro que los de la calaña del de "Pim, Pam, toma Lacasitos" no cogen ni libros ni consola alguna (en todo caso para jugar al "Pro"). Y esos si que son gilipollas profundos.

#185 Totalmente de acuerdo.

En general pienso que justamente el gran problema es que queremos meterles a los críos obras que superan con creces la capacidad que tienen a su edad. Obligar a leer hace que los chavales automáticamente lo rechacen, en ese infantil impulso de ir contra todo lo que te imponen (todos hemos pasado por eso).

Porque como ya dije, con todo mi respeto por Cervantes y los de su quinta, por mi cultura han hecho más Julio Verne y Emilio Salgari que ellos.

#24, bueno, ganamos sin Pau la final, el resto del Mundial sí lo jugó y fue una pieza importantísima. No digo que los demás no sean buenos, pero ese mantra de "el Mundial lo ganamos sin Pau" ya empieza a ser cansino, además de inexacto.

#20 pero eso es por que ella quiere, no te quepa duda de que nadie la obliga:ni su cultura ni su entorno cercano
Y por cierto, se me acaba de ocurrir, si yo me pongo un ropaje de esos de los que solo se me ven los ojos... ¿Puedo entrar en el vestuario femenino?????? nadie sabe si soy mujer u hombre ¿no? lo digo porque en las piscinas de mi pueblo el acceso a las piscinas se realiza por los vestuarios...