Hace poco se publicó esta foto en FEDA DEV
y me pareció bastante interesante, y me gustaría que la comunidad de developers de MV diera su opinión respecto a esto
¿Qué hábitos creéis que son buenos para formar un buen desarrollador? ¿Se entrena para ello? ¿Os parece cierta/ciertas algunas de las afirmaciones de la imagen? ¿Por qué?
La 3 cómo se hace? xd
Hago todo menos la 3 (no sé qué es) y la 10 (cuando me empecino en terminar algo no me saca del ordenador nadie!)
#2 stackoverflowear a piñón :si:
#3 La tres significa arreglar un bug antes de seguir con el proyecto en vez de dejarlo ahí para cuando acabes.
Leer el código de otras personas.
Esto es casi más difícil que encontrar vida en el Sol.
Yo añadiría: usar Doxygen o derivados. Ayudarás a la gente que lee tu código.
#4 ah vale, había leído mal. Lo había entendido como "arreglar un bug antes de escribir el código" (su propio código para fixearlo xD)
#5 Es jodidamente dificil leer codigo de otros sin comentarios (bueno no siempre), hay cada bodrio por ahí...
No me malinterpreteis si leeis lo mismo direis PERO TIO QUE PUTA MIERDA ES ESTA.
Si tienes que currarte una aplicacion con mas gente, lo MINIMO que se puede hacer es comentar y programar de forma ordenada, que a veces te encuentras parrafos o ficheros que no hay dios quien los lea.
Tengo la costumbre de comentar un monton de cosas y eso ayuda que no veas.
Hay que saber bien qué comentar y que no. A veces la documentación es más dificil de entender que el propio código (si el código está bien hecho, claro).
Yo añadiría importancia a que el código se entienda por si mismo. Que sepas que contiene una variable al leer su nombre, lo mismo con las funciones, y que estas se encarguen de un solo pequeño objetivo.
Además es importante establecer un convenio dentro del equipo.
Evitar el sindrome de diógenes y llevar a cabo la regla del boyscout (deja el código mejor de lo que te lo encontraste).
Yo intento seguir las 10 reglas de la imagen (y más, excepto la 6 y la 7, que tengo pendiente retomarlas) aún cuando voy justo de tiempo. Prefiero entregar algo más tarde pero que no reviente a los pocos meses, que entregarlo en su momento o antes y tenerlo que arreglar poco después.
Organización. Soy de esos que tiene siempre su habitación patas arriba (limpia, pero con muchos trastos por medio), pero a la hora de trabajar necesito que todo esté bien organizado y sea fácil de leer.
Tener ficheros de texto bien organizados con lineas de código que usas cada dos por tres pero no eres capaz de recordar. Si lo tienes bien organizado tardas menos que buscando en Google o en el código de otro script.
No debugear mañana lo que puedes debugear hoy.
"A veces vale la pena quedarse en la cama el lunes, en lugar de pasar el resto de la semana depurando el código del lunes."
#7 La culpa no es de que tenga comentarios o no, es de que el código está mal escrito.
Los comentarios en la mayoría de los casos son una bazofia. Debería explicar como mucho por qué se usa un método de una forma y no otra o por qué, por poner un ejemplo tonto, se ha usado un mergesort en vez de un quicksort. Por lo demás, la propia signatura de la función debería explicar qué hace, ser obvia y que sólo se pueda usar de una manera.
A mi algo como esto me parece absurdo:
/**
* returns the device
*/
public Device getDevice() {
return device;
}
Oh no me digas, no me había dado cuenta de que getDevice devuelve un Device. La mayoría de comentarios son como ese ejemplo: inútiles. Vamos que es mejor hace un buen código que un mal código lleno de comentarios que al final estarán obsoletos, mal escritos y no te dirán nada útil.
Todo esto suponiendo que no estés desarrollando librerías. Ahí ya la cosa cambia algo más porque se supone que el que va a utilizarlo no tiene ni papa ni de por donde le sopla el aire
Un tip: TDD ya. Si no lo haces, empieza a hacerlo desde hoy, no esrcibir nada de código sin haber escrito el test primer. Yo era un poco reticente a hacer TDD y es un camino de ida, después de obligarme durante un par de meses (algo duros), ya no hay marcha atrás.
#7 Self Documented Code
publc int sum(int number1, int number2){
return number1 + number2;
}
vs
/**
* Suma los caracteres b y c
*/
public int aMethod(int b, int c){
return b+c;
}
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
#13 Me olvide del self documented code...
En realidad una de las cosas que mas me gustan de objective-c es que es jodidamente facil leer codigo ya escrito en el.
#12 Si que es verdad que muchos comentarios son absurdos, pero otros son totalmente necesarios y mas cuando, igual ese codigo no lo tocas hasta dentro de 6 meses que entonces ya me diran quien se acuerda porque usabas esa funcion y no otra :/
#12 la única excepción ahí la tienes si quieres generar un javadoc y que otros puedan leerlo sin meterse al código. Pero sí, completamente de acuerdo, y un coñazo de mantener.
#12 Ese es un comentario javadoc autogenerado. Para que después el desarollador lo complete con mas información pero manteniendo la sintaxis de comentarios necesaria para genera el javadoc. El problema es que mucha gente por pereza ponen el comentario autogenerado y no lo completan.
En eclipse por ejemplo este bloque de comentarios se genera situandote en la cabecera del metodo con el atajo Alt+Shift+J
El javadoc enguarra tanto el código que a veces es mejor no generarlo y documentar aparte que meter siete mil líneas de comentario en el proyecto.
#16 Por eso indico que si estás creando librerías o frameworks que vas a publicar la cosa cambia xD. Por ejemplo, la documentación de java me parece perfecta precisamente por eso, explica cómo se usan las clases y cuándo deberían usarse. Vamos lo que uno espera de una documentación cuando va a usar una librería.
#17 Ese javadoc lo he escrito yo para poner el ejemplo. Como eso miles que te encuentras en códigos.
El otro ejemplo de lo que me refiero es lo que ha escrito #13
A mi la documentación de librerias open source como Spring / Hibernate, me parecen muy perfectas.
Vas a un metodo, y te explica perfectamente lo que hace, para que sirve cada parametro y que excepciones lanza y porqué.
Hacer pair programming ayuda.
Y luego, las interrupciones, cada hora, no cada 5 minutos.
en #2 se ha dicho algo muy importante... no creerte que lo sabes todo... siempre hay alguien que sabe mas que tu (en este foro se llama blzkz pero en otros adquieren otros nombres, les llaman semidioses)
· TDD
· 0 spaghetti
· Usar pull request o similares en caso de trabajar con más personas
. Pensar que no vale solo con que funcione, tu o cualquier otro puede tener que entrar ahí en un tiempo y verse en una jungla.
· Comentar siempre y cuando el código no hable por si solo
· No tener miedo a aprender cosas nuevas, quedarse en la zona de comodidad hace que te oxides y te envicies.
· TDD
· y TDD
tengo k aprender k es TDD, spaghetti, pull request y todas las demas palabras hipsters que has soltado #22 xDDD
TDD es Test Driven Development: http://en.wikipedia.org/wiki/Test-driven_development
Las pull request lo utilizas para mergear en la rama principal del repositorio git tu rama o tu fork con los cambios: https://help.github.com/articles/using-pull-requests
Y el spaghetti es basicamente esto:
#24 Ya que estamos, ¿algún buen libro técnico sobre TDD? Los que he encontrado son más de intentar venderme la metodología a base de contarme las ventajas y de explicar poco como se hace.
#25 lo mejor es que encuentres uno especifico para la tecnología con la que trabajas porque si no te vas a morir del asco.
Este video es muy bueno, aunque sea con Ruby es bastante general:"
http://www.confreaks.com/videos/2741-wickedgoodruby-killing-fibonacci
A mi para rails por ejemplo me encanta este:
