Yo dibujaba el algoritmo (Diagramas de flujo/cosas similares)
#32 Cuidado que muchos programadores se ofenden por ello. Herejia copiar de otro. Cuando es una cosa natural para ahorrar tiempo siempre y cuando sepas lo que está haciendo y comprobando que opción se adapta a tu caso y lo que está mejor optimizado.
Copiar por copiar no sirve de nada.
#33 En mi empresa hay un junior que le quitas Stackoverflow y no sabe hacer nada.
De todas formas, SO esta bien, pero pensar tampoco hace daño.
#34 Eso es falta de conocimiento y como bien comentas vagueria y comodidad. Por eso digo que copiar por copiar no te lleva a nada ya que acostumbras a tirar a lo fácil y cuando no existe la solución, acabas fracasando.
Yo me puedo tirar sin miedo a decir una hora probando cosas yo mismo y leyendo los manuales para algo que no entiendo. Si tras ese tiempo en el que he estado trabajando, no sale. Ya busco soluciones más especificas, pero cuando llegas a esa solución o viendo los consejos de la gente, te salta la "bombilla" y te das cuenta de que haciendo algo más simple o o menos rebuscado es lo mismo.
Al final programar no es meter código sino saber porque estás metiendo ese código.
#36 Yo puedo hablar por mí. Yo llevo varios meses sin tocar nada de html y php y si me pidieran hacer algo con esto tendría que mira alguna solución.
También el margen que uno tiene de trabajar desde casa no es el mismo que desde una oficina. Quitas a mucha gente de tener acceso a internet y solo a redes internas y tienes que despedir a la mitad de la plantilla.
El otro día tuve que mirar, literalmente, un "hello world" de JSON porque mi cerebro había querido hacerme cree que poner comas al final de cada objeto ( aunque sea el último, tipo JS ) era una práctica normal y, claro, todo saltaba por los aires y no veía el error...
Llevaré como un año a full maquetando, manteniendo librerías SASS, manteniendo gulpfiles/gruntfiles y programando behaviours con JS y sin tocar nada de intercambio de datos.
Es increíble como el cerebro puede hacer tal meltdown en algo menos de un año y desconectar algo tan simple como el ejemplo de las comas.
Desde ese día ya no linteo solo JS xDDDD
Autodescriptivo + Comentarios generales.
Nada de comentar cada línea ni nada de no ver un solo comentario por favor.
Para empezar en la programación es bueno a enseñarse a comentar pues de un vistazo puedes ver algo que hiciste días atrás que no has vuelto a practicar y luego lo visualizas mejor.
Claro está que nombrar las clases y metodos de una manera que puedan ser entendidas es un factor favorable.
Otro punto a destacar que yo uso, es usar el inglés para nombrar metodos y clases, a la hora de que no hispano hablantes puedan entender tu código te abre muchas puertas.
#44 Por? Soy bastante nazi con los comentarios. El código tiene que ser descriptivo y no te cuento ya si tiene test.
Evidentemente que existen pero muy especificos o doc.
#45 el código no es descriptivo, lo serán los nombres de variables/métodos/clases. El código si acaso estará bien estructurado, lo suficiente como para poder no necesitar echar un ojo a documentación, pero hay veces que es inevitable, y muchos casos en los que viene bien escribirse comentarios para uno mismo, ya no para los demás (que desde luego, también). No te ha pasado alguna vez que has hecho algo, ha pasado un tiempo y has vuelto, y no sabías por qué has hecho X? Y ya no hablo a nivel de lenguaje, si no a nivel de lógica de negocio.
Y está claro que no hablo de escribir libros a modo de comentario xD.
#46 
Es lo único que se me ocurre si no eres capaz de entender tu propio código. Los nombres y organización del código aportan la misma información que los comentarios. De ahí que se diga que es autodescriptivo.
Yo creo que lo fundamental es la documentación. Describir que hace cada clase, cuales son sus parámetros de entrada y cuales son los de salida. Y las excepciones. Vamos lo básico de documentación.
Con eso debería sobrar, es más, el otro día en Ing del Software 2 nos soltaron que los métodos no deben tener más de 20 líneas. Con lo que no sería necesario añadir comentarios al código, simplemente hacer la documentación.
#47 No siempre trabajas sólo, y no, dentro de dos años no me acordaré de por qué hice ciertas cosas. Suelo usar docblocks o similar en el trabajo siempre, la gente no tiene por qué gastar tiempo innecesariamente en entender que quise hacer.
Cada vez que veo un código sin comentar me dan ganas de ir y pegar a quien lo hizo.
#49 Me cuesta encontrar una explicación al porqué un comentario es capaz de explicarme que hace UN método y no es capaz su propia definición de decirme lo mismo.
Lo mismo es porque estáis haciendo 300 cosas dentro de ese método. Otra explicación no le encuentro.
Y vuelvo a repetir que con test aún son menos necesarios.
#50 no es qué hace, es cómo lo hace. Si usas algún algoritmo rarete por ejemplo ponte tu a entenderlo en 5 minutos sin una explicación. Vamos no se cual será tu experiencia en trabajo en equipo ni en qué has trabajado, pero con cosas complejas suerte sin documentación.
Papel y lapiz. Siempre papel y lapiz.
Y por cierto, si estas empezando, yo no recomendaria usar IDEs ni nada parecido. Un editor de texto y una terminal y a volar. Vamos, a mi de primeras me meten a aprenderme a manejarme un IDE + programacion en C++ y hubiera sido mucho mas penoso el esfuerzo.
Yo recomiendo poner comentarios en cada linea de codigo, asi cuando lo veas sen un par de anyos o lo vea otro puede entender que has hecho ahi, asi acabaras con un stackoverflow local
Iba a hackathons en los que la gente decian que eran expertos en copy&paste y que en base a eso habian solucionado muchos problemas. Ademas no se atribuyen a ellos mismos el codigo, escriben tambien el link al hilo por si hay alguna mejora o algo en el futuro
#45Fastestwat:El código tiene que ser descriptivo y no te cuento ya si tiene test.
te iba a apoyar hasta que has dicho esto... como que "y no te cuento ya si tiene test" ?? desde que aprendí lo que es un test y en que me ayudan, no se trabajar sin test, y un buen test es mejor que cualquier documentación que te puedas encontrar.
Seguro que cuando programas en algún lenguaje o con cualquier framework mirais los test en vez de la docu.
Cuando son cosas como bucles y operaciones, es más prueba y error. Hacer pruebas, imprimir por pantalla cosas como "por aquí pasa" o usar el debugger.
Si son cosas más complicadas y de teoría, vas a necesitar alguien que te lo explique bien y de otra forma, es decir, un compañero de clase que pilote del asunto o un profesor particular.
#58 por supuesto pero aquí la gente se lee clean Code y se hace pajillas con lo que dice y solo se queda con las cosas que les interesa, como por ejemplo lo de los comentarios en el código, primero equiparándolo a documentación cuando es solo una parte de esta y después obviando la parte que dice como escribir buena docu y comentarios. Además pone como ejemplo la docu de Java como una docu excelente pero eso a la pena se le olvida básicamente porque no gusta escribir documentación y la peña es muy vaga.
Pero bueno eso, cuando pilles un legacy por ahí vosotros decís que ya miráis el código, que nos hace falta documentacion
