#24 Je, casualmente en mi trabajo actual esa era la situación aunque en parte eso me ha venido bien ya que al final la opción más simple era la de "dime que quieres que haga esta pantalla/módulo y lo hago de cero".
En ese sentido tardé unos meses meterme de lleno puesto que me encargué de renovar todo el código, estructurarlo y crear clases para funciones que se repetían por todo el código. Porque aquí documentación nula, pero sí tengo al responsable que lo hizo para preguntar al menos.
Así que sí, es una cuestión de la propia predisposición y conocimiento del que entre y también de la facilidad que se le de para encarar el proyecto. Yo he tenido a gente que en 3 meses no daba pie con bola y otros espabilados que en un mes están integrando código sin problema.
#27 No comparto que el buen código no necesita comentarse, eso sería lo idóneo en un desarrollo de una persona en cosas muy simples. Pero en código compartido es imposible. Y sí, da igual que una función se llame "ComparaFechas" y la descripción sea "Función que compara fechas, devuelve X valores". Eso ya te quita tiempo de tener que entrar a saber que hace y que devuelve esa función.
Lo digo porque con todo el código legacy que me he encontrado tener que entrar a leer que carajo hace algo y entenderlo (sólo para saber que hace y no para tocar nada) es bastante puñetero por muy bien que esté programado.
Un buen código no quita que se pueda comentar.
