Los trucos que vemos: 1. Nivel de identación 2. Evita else 3. Encapsula los primitivos 4. Encapsula las colecciones 5. Sigue la ley de Demeter 6. No abrevies 7. Mantén tus entidades pequeñas 8. No clases con más de 2 dependencias en los constructores 9. No hagas getters/setters. Tell don't ask 10. Utiliza Object Calisthenics 11. Utiliza un Linter 12. Utiliza las GitHub actions para CI y CD 13. Usa un analizador estático del código 14. Sigue la regla de 3 repeticiones para evitar abstracciones prematuras 15. Ten un fichero "EditorConfig" ...
#4:
#2 Mejor escribe código tan claro que no necesite comentarios, aunque en caso de utilizar algún algoritmo particularmente complejo, es mejor comentarlo desde luego. Ahora, la calidad de los comentarios también importa... pero eso es otra historia.
#5:
#4 El error está en creer que los comentarios son sólo para explicar COMO funciona algo. También se utilizan para explicar POR QUÉ se ha escogido un algoritmo, por qué se hace determinada cosa en lugar de algo más común, etc.
#2 Mejor escribe código tan claro que no necesite comentarios, aunque en caso de utilizar algún algoritmo particularmente complejo, es mejor comentarlo desde luego. Ahora, la calidad de los comentarios también importa... pero eso es otra historia.
#4 El error está en creer que los comentarios son sólo para explicar COMO funciona algo. También se utilizan para explicar POR QUÉ se ha escogido un algoritmo, por qué se hace determinada cosa en lugar de algo más común, etc.
"Mejor escribe código tan claro que no necesite comentarios, aunque en caso de utilizar algún algoritmo particularmente complejo o tener que explicar porque se ha escogido ese en particular, es mejor comentarlo desde luego."
Yo mismo pongo comentarios hasta con enlaces a StackOverflow para cosas así...
#8 Pero es que hay muchos mas casos: por ejemplo, en un driver, explicar que algo se hace así porque existe un bug en el hardware, o cosas así. Existen miles de casos en los que los comentarios son necesarios, aparte de "para explicar cómo funciona el código".
#4 Si la documentación estuviera bien recogida, pues te daría la razón, pero como los funcionales actualizados son unicornios (arriba scrum master, fuera analistas funcionales, sigamos la moda), luego ocurre un error o algo que no funciona como se espera, y el error es siempre del programa, no del correo a última hora donde a un iluminado del cliente decidió que se hiciera de tal manera.
Y a lo mejor tienes suerte y hay gente del equipo original, pero como no es así, tienes una caja negra que no sabes bien si funciona bien y que deberás de poner una capa por encima para que funciona como se quiere ahora.
#4 Estoy de acuerdo, hay que reducir los comentarios al minimo, muchos comentarios es signo de una mala programacion, con un codigo claro basta. Yo
cuando reviso mi codigo, normalmente los bloques de codigo comentados los refactorizo a una nueva funcion cuyo nombre es una adaptacion de ese comentario.
#2 Eso, salvo excepciones, se considera mala práctica. La idea es usar nombres de variables y metodos suficientemente claros para entender que se hace. Tambiar encapsular bloques de código en funciones con un nombre apropiado.
#9 Espero que tengas buenas memoria para recordar todas las reuniones y todos los cambios de parecer que se han ido teniendo a larga en el proyecto, por que los errores funcionales solo con el código te los comes.
El código es como funciona realmente. Si no funciona bien, arreglas el código.
Y no es que no hay comentarios. Es que el propio codigo es el comentario. De eso se trata. Que el codigo pueda ser leido por humanos fácilmente. Como si fuera pseudocódigo.
#17El código es como funciona realmente. Si no funciona bien, arreglas el código.
Eso es poner parches, que es todavía mejor.
¿Qué la ballena no vuela como dice el código? pues le añado unas alas, ya que se espera que deba volar, no se analiza si realmente una ballena deba volar.
Podemos aducir que es culpa del usuario, pero también está la parte de aconsejar al usuario. El arquitecto asume los deseos del usuario, pero al final te hace unos planos, y detalla minuciosamente lo que se va a hacer, no le ves haciendo apaños a posteriori (salvo si eres Calatrava ) después de ver como se tambalea el edificio.
#21 Tú puedes hacer una cambio simple, que implique cambiar una condición, que un valor pase de X a Y o cualquier chorrada, derivado de una petición del cliente.
Luego el cliente puede venir y decirte que el cambio no es como esperaba, al final corriges y punto.
El problema es cuando un tiempo después, un error en otra parte, que pasa por ese parte de código que tocaste (o que lo llama al ser en otro módulo), implica algo que no funciona como se espera, y entonces habrá que recordar que es derivado de una petición del cliente, y que ahora es como se tiene que funcionar, no por un error de programación.
Si hay suerte, a lo mejor dejaste comentado en el jira que se pueda buscar, o un comentario extendido en el git, o a saber donde, y poder relacionarlo con la nueva funcionalidad definida.
Si no hay suerte, habrá que ver que está mal, si tu cambio o la parte afectada, y el código te dirá que está bien todo, ya que ambas partes están bien.
#22 Estoy intentando recordar si me he encontrado algo así alguna vez. Creo que no, o al menos, no lo recuerdo.
Hay algo que no se ajusta a los requerimientos del cliente -> se crea un ticket jira -> abres una rama -> actualizas codigo y tests.
Se detecta un bug consecuencia del nuevo cambio -> lo 1o que tengo que hacer es determinar donde tengo el error. Puede ver en los test cual es el supuesto correcto. Puedo ver en el historial de cambios en git que cambios se han hecho en el código.
Las veces que un comentario me ha ayudado es justamente cuando el código no puede expresar el porque. Tipo //there is a bug in xxx so we do yyy here.
#14 Buf, todo tiene mil problemas. Por ejemplo, los microservicios en cuanto propagas un poco de información entre una y otra algunos cambios triviales acaban siendo una locura. Mejor, sí, la panacea, no.
Pero, por otro lado, ¿cuál es la solución? ¿invertir todo el tiempo necesario en infraestructura? Estuve en una empresa con tres "supercracks" que definían estructuras, daban consejos, machacaban a los demás en las PR... no eran mala gente, ni siquiera eran chulos o prepotentes. Para nada. Tenían la cabeza llena de pájaros, eso sin duda.
Sin embargo, tras un año, resulta que no hicieron casi nada, no aportaron valor. Comenzaron una API para machacar la "API Legacy" y casi diez meses después anunciaron que iban a hacer otra API nueva para machacar la otra. Con nombres rimbombantes. Sin embrgo a duras penas habían subido funcionalidad a producción, un producto se canceló porque no tenía backend porque se estaban liando ellos solos.
Y no les va mal, dieron charlas sobre la "superestructura" que habían montado en la empresa. Hoy en día dan charlas, cursos y es fácil verlos en los grupos de programación superchupiguays de su ciudad.
#29 Ahora ando aterrizando en el mundo de microservicios, no llevo mucho, entre arquitecturas mixtas y ahora, pues serán unos 2 años ya largos.
La idea no está mal, puedes centrar funcionalidad en un módulo, con lo que se concentra el buscar errores.
La realidad es que al final es como el efecto mariposa
Y para buscar errores de amplio alcance, A que llama B, que luego llama a C, que ..... pues miras los logs, te montas un sistema complejo, verificas que se recoge y que se manda, y si no te vuelves loco, pues puedes ir razonando que pasa a lo Sherlock
Yo es que luego soy un poco bestia, me meto en el código de la otra aplicación y a buscar por que si les mando x, me devuelven z y no y. Pero es un show, y añades lo de la agilidad, que al final es "te controlo el tiempo que me has dicho que ibas a tardar", fiuuuuuu ... así voy, rebotando cada ciertos proyectos
#30 Es que... es así. Más te vale tenerlo todo muy bien protegido por logs para que efectivamente sean cajas negras que hacen lo que se dice que hacen.
Pero no se puede tener todo protegido, generalmente lo que falla es justo lo que no había protección
15 NO ESCRIBAS COMENTARIOS La mayoría de los comentarios son considerados "bad smells". Añaden complejidad y te permiten trabajar haciendo código de mierda "porque ya leerán el comentario". Además, ¡Hay que mantenerlos!
La única ocasión en la que hay que usar los comentarios es cuando hay que explicar por qué se hace una cosa de una forma.
Si el comentario explica qué hace el código, muy mal. Si explica el por qué, se acepta.
Por supuesto, si hay que asumir la deuda tecnológica por narices, entonces es mejor escribir comentarios para cualquier cosa. El código es una mierda y tú única forma de sobrevivir es escribiendo comentarios, bueno, habrá que aceptar barco.
#7 Lo que habría que mantener es el funcional, pero como se hace tiene n-mil historias que van cambiando y que configuran la funcionalidad que no hay por donde cogerla y que se mantiene por ciertas personas que en cuanto desaparezcan crean cajas negras.
Luego eso pasa a llamarse código legacy y ya se planificará la definición de una nueva aplicación por imposibilidad de meter código a la caja negra, o mejor aún, generar una capa por encima para readaptar las respuestas.
Ahora con los microservicios, se dice que esto no será así, .... está por ver.
- no debes exponer partes que realmente son de implementación y que no deberían de ser públicas.
- ni debes proporcionar acceso directo a elementos que deberían ser privados ( se admite devolver interfaces ya que así en caso de editar el return no estamos jodiendo el elemento interno, y setters si tienen lógica añadida como validación etc.)
Con esas dos reglas, la gran mayoría de accessors que puedas encontrar en todo proyecto sobra.
Si en lugar de java estas en otra cosa como pueda ser angular entonces ya directamente el compilador de Ivy se encargará de recordarte que no debes usarlos prácticamente el 99% de las veces destrozando la ram del navegador a base de rerenderizados
#16 Es que dicho así es un poco muy duro. Parece que nunca debas usarlos, pero no es del todo así. Lo que no tienes que hacer es ponerlos parar todo campo de tus clases así tal cual, permitiendo que hagas cambios no deseados o controlados.
Por ejemplo, si tienes una clase persona, puedes usar un get para obtener el nombre de la persona, cuidado de hacer el setter o no. Lo que no debes hacer es un get de la lista de Amigos que permita luego añadir o quitar amigos desde fuera sin ningún control por parte de la clase Persona, mejor devolver un iterable que el propio array de la clase. Tampoco deberías tener un set que permita crear una lista de amigos desde fuera. Si pondrás métodos para añadir o quitar amigos.
Que manía con no usar la I en c# para las interfaces. Lo siento pero es lo que recomienda Microsoft, y además así es como está tanto en las interfaces de la propia Microsoft como en cualquier biblioteca que uses. A quien no le guste que no mire o que convenza a Microsoft de no hacerlo así. A mi personalmente es que hasta me gusta, será costumbre ya.
Comentarios
0 -> COMENTA EL PUTO CODIGO
#2 Mejor escribe código tan claro que no necesite comentarios, aunque en caso de utilizar algún algoritmo particularmente complejo, es mejor comentarlo desde luego. Ahora, la calidad de los comentarios también importa... pero eso es otra historia.
#4 El error está en creer que los comentarios son sólo para explicar COMO funciona algo. También se utilizan para explicar POR QUÉ se ha escogido un algoritmo, por qué se hace determinada cosa en lugar de algo más común, etc.
#5 Me vale también. Amplio mi comentario:
"Mejor escribe código tan claro que no necesite comentarios, aunque en caso de utilizar algún algoritmo particularmente complejo o tener que explicar porque se ha escogido ese en particular, es mejor comentarlo desde luego."
Yo mismo pongo comentarios hasta con enlaces a StackOverflow para cosas así...
#8 Yo incluso he llegado a poner referencias a reuniones, correos o jiras donde se indica que cierta funcionalidad ha de ser así.
Por tanto, los comentarios han de ser aclaratorios, ya que no todo está en el código, si no quieres crear una caja negra.
#8 Pero es que hay muchos mas casos: por ejemplo, en un driver, explicar que algo se hace así porque existe un bug en el hardware, o cosas así. Existen miles de casos en los que los comentarios son necesarios, aparte de "para explicar cómo funciona el código".
#23 Ya veo que eres cuadriculado...
#25 Eso, y que tengo más de 25 años de experiencia como programador a mis espaldas.
#26 Todavía te gano por casi una década, jovencito, así que no te las tires tanto.
#23 Regla número 1 de los comentarios: Los comentarios mienten.
#4 Si la documentación estuviera bien recogida, pues te daría la razón, pero como los funcionales actualizados son unicornios (arriba scrum master, fuera analistas funcionales, sigamos la moda), luego ocurre un error o algo que no funciona como se espera, y el error es siempre del programa, no del correo a última hora donde a un iluminado del cliente decidió que se hiciera de tal manera.
Y a lo mejor tienes suerte y hay gente del equipo original, pero como no es así, tienes una caja negra que no sabes bien si funciona bien y que deberás de poner una capa por encima para que funciona como se quiere ahora.
#4 Estoy de acuerdo, hay que reducir los comentarios al minimo, muchos comentarios es signo de una mala programacion, con un codigo claro basta. Yo
cuando reviso mi codigo, normalmente los bloques de codigo comentados los refactorizo a una nueva funcion cuyo nombre es una adaptacion de ese comentario.
#2 Eso, salvo excepciones, se considera mala práctica. La idea es usar nombres de variables y metodos suficientemente claros para entender que se hace. Tambiar encapsular bloques de código en funciones con un nombre apropiado.
#9 Espero que tengas buenas memoria para recordar todas las reuniones y todos los cambios de parecer que se han ido teniendo a larga en el proyecto, por que los errores funcionales solo con el código te los comes.
#11 Alguien ha explicado en otro coentario un buen uso de los comentarios.
No expliques el como, el porque está bien.
#13 Al final pasa lo que pasa, como no hay costumbre de poner comentarios o está mal visto, pues nadie comenta nada.
Y los funcionales nadie los quiere, y cuando hay un error, te dicen que mires el código, como si fuera la Biblia
#15 es que el codigo es la biblia.
El código es como funciona realmente. Si no funciona bien, arreglas el código.
Y no es que no hay comentarios. Es que el propio codigo es el comentario. De eso se trata. Que el codigo pueda ser leido por humanos fácilmente. Como si fuera pseudocódigo.
#17 El código es como funciona realmente. Si no funciona bien, arreglas el código.
Eso es poner parches, que es todavía mejor.
¿Qué la ballena no vuela como dice el código? pues le añado unas alas, ya que se espera que deba volar, no se analiza si realmente una ballena deba volar.
Podemos aducir que es culpa del usuario, pero también está la parte de aconsejar al usuario. El arquitecto asume los deseos del usuario, pero al final te hace unos planos, y detalla minuciosamente lo que se va a hacer, no le ves haciendo apaños a posteriori (salvo si eres Calatrava ) después de ver como se tambalea el edificio.
#20 Creo que no has entendido el comentario.
#21 Tú puedes hacer una cambio simple, que implique cambiar una condición, que un valor pase de X a Y o cualquier chorrada, derivado de una petición del cliente.
Luego el cliente puede venir y decirte que el cambio no es como esperaba, al final corriges y punto.
El problema es cuando un tiempo después, un error en otra parte, que pasa por ese parte de código que tocaste (o que lo llama al ser en otro módulo), implica algo que no funciona como se espera, y entonces habrá que recordar que es derivado de una petición del cliente, y que ahora es como se tiene que funcionar, no por un error de programación.
Si hay suerte, a lo mejor dejaste comentado en el jira que se pueda buscar, o un comentario extendido en el git, o a saber donde, y poder relacionarlo con la nueva funcionalidad definida.
Si no hay suerte, habrá que ver que está mal, si tu cambio o la parte afectada, y el código te dirá que está bien todo, ya que ambas partes están bien.
#22 Estoy intentando recordar si me he encontrado algo así alguna vez. Creo que no, o al menos, no lo recuerdo.
Hay algo que no se ajusta a los requerimientos del cliente -> se crea un ticket jira -> abres una rama -> actualizas codigo y tests.
Se detecta un bug consecuencia del nuevo cambio -> lo 1o que tengo que hacer es determinar donde tengo el error. Puede ver en los test cual es el supuesto correcto. Puedo ver en el historial de cambios en git que cambios se han hecho en el código.
Las veces que un comentario me ha ayudado es justamente cuando el código no puede expresar el porque. Tipo //there is a bug in xxx so we do yyy here.
#24 A mi me ha pasado cuando:
* el usuario ha definido mal un requerimiento funcional.
* afecta a otra parte del código que no estaba contemplada a la hora de hacer el cambio.
Si el bug afecta a lo que estoy tocando, es como dices, o bien se ve en los test, en la pruebas o incluso tras subir a producción (pasando a hotfix)
Pero ahora con tanto módulo definido, y con la definición de microservicios, a veces afecta a otras partes del código.
#2 Un código bien hecho apena necesita comentarios
#14 Buf, todo tiene mil problemas. Por ejemplo, los microservicios en cuanto propagas un poco de información entre una y otra algunos cambios triviales acaban siendo una locura. Mejor, sí, la panacea, no.
Pero, por otro lado, ¿cuál es la solución? ¿invertir todo el tiempo necesario en infraestructura? Estuve en una empresa con tres "supercracks" que definían estructuras, daban consejos, machacaban a los demás en las PR... no eran mala gente, ni siquiera eran chulos o prepotentes. Para nada. Tenían la cabeza llena de pájaros, eso sin duda.
Sin embargo, tras un año, resulta que no hicieron casi nada, no aportaron valor. Comenzaron una API para machacar la "API Legacy" y casi diez meses después anunciaron que iban a hacer otra API nueva para machacar la otra. Con nombres rimbombantes. Sin embrgo a duras penas habían subido funcionalidad a producción, un producto se canceló porque no tenía backend porque se estaban liando ellos solos.
Y no les va mal, dieron charlas sobre la "superestructura" que habían montado en la empresa. Hoy en día dan charlas, cursos y es fácil verlos en los grupos de programación superchupiguays de su ciudad.
#29 Ahora ando aterrizando en el mundo de microservicios, no llevo mucho, entre arquitecturas mixtas y ahora, pues serán unos 2 años ya largos.
La idea no está mal, puedes centrar funcionalidad en un módulo, con lo que se concentra el buscar errores.
La realidad es que al final es como el efecto mariposa
Y para buscar errores de amplio alcance, A que llama B, que luego llama a C, que ..... pues miras los logs, te montas un sistema complejo, verificas que se recoge y que se manda, y si no te vuelves loco, pues puedes ir razonando que pasa a lo Sherlock
Yo es que luego soy un poco bestia, me meto en el código de la otra aplicación y a buscar por que si les mando x, me devuelven z y no y. Pero es un show, y añades lo de la agilidad, que al final es "te controlo el tiempo que me has dicho que ibas a tardar", fiuuuuuu ... así voy, rebotando cada ciertos proyectos
#30 Es que... es así. Más te vale tenerlo todo muy bien protegido por logs para que efectivamente sean cajas negras que hacen lo que se dice que hacen.
Pero no se puede tener todo protegido, generalmente lo que falla es justo lo que no había protección
Será un progama pequeñito, porque en tan poco tiempo...
15 NO ESCRIBAS COMENTARIOS La mayoría de los comentarios son considerados "bad smells". Añaden complejidad y te permiten trabajar haciendo código de mierda "porque ya leerán el comentario". Además, ¡Hay que mantenerlos!
La única ocasión en la que hay que usar los comentarios es cuando hay que explicar por qué se hace una cosa de una forma.
Si el comentario explica qué hace el código, muy mal. Si explica el por qué, se acepta.
Por supuesto, si hay que asumir la deuda tecnológica por narices, entonces es mejor escribir comentarios para cualquier cosa. El código es una mierda y tú única forma de sobrevivir es escribiendo comentarios, bueno, habrá que aceptar barco.
Fuente. Martin Fowler (y la experiencia)
#7 Lo que habría que mantener es el funcional, pero como se hace tiene n-mil historias que van cambiando y que configuran la funcionalidad que no hay por donde cogerla y que se mantiene por ciertas personas que en cuanto desaparezcan crean cajas negras.
Luego eso pasa a llamarse código legacy y ya se planificará la definición de una nueva aplicación por imposibilidad de meter código a la caja negra, o mejor aún, generar una capa por encima para readaptar las respuestas.
Ahora con los microservicios, se dice que esto no será así, .... está por ver.
Mejor para un script kiddie.
#define if(x) if ((x) && (rand() < RAND_MAX * 0.99))
Esa linea es mano de santo. Metiendola en tu codigo programas que alucinas!.
¿Por qué no recomienda el get y set?
#16 si estás en java o otro OO:
- no debes exponer partes que realmente son de implementación y que no deberían de ser públicas.
- ni debes proporcionar acceso directo a elementos que deberían ser privados ( se admite devolver interfaces ya que así en caso de editar el return no estamos jodiendo el elemento interno, y setters si tienen lógica añadida como validación etc.)
Con esas dos reglas, la gran mayoría de accessors que puedas encontrar en todo proyecto sobra.
https://www.infoworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html
Si en lugar de java estas en otra cosa como pueda ser angular entonces ya directamente el compilador de Ivy se encargará de recordarte que no debes usarlos prácticamente el 99% de las veces destrozando la ram del navegador a base de rerenderizados
#33 Gracias por la explicación y el artículo
#16 Es que dicho así es un poco muy duro. Parece que nunca debas usarlos, pero no es del todo así. Lo que no tienes que hacer es ponerlos parar todo campo de tus clases así tal cual, permitiendo que hagas cambios no deseados o controlados.
Por ejemplo, si tienes una clase persona, puedes usar un get para obtener el nombre de la persona, cuidado de hacer el setter o no. Lo que no debes hacer es un get de la lista de Amigos que permita luego añadir o quitar amigos desde fuera sin ningún control por parte de la clase Persona, mejor devolver un iterable que el propio array de la clase. Tampoco deberías tener un set que permita crear una lista de amigos desde fuera. Si pondrás métodos para añadir o quitar amigos.
Con eso ya tienes una buena razón para no usarlos, más en el enlace que te da #33 y aquí: https://softwareengineering.stackexchange.com/questions/284215/how-do-you-avoid-getters-and-setters
No te metas ni a músico ni a dibujante ni a programador si no te resulta fácil.
No todos valemos para todo. De los ejemplos que he puesto, podría emplear la vida en los dos primeros y no pasar de mediocre.
Que manía con no usar la I en c# para las interfaces. Lo siento pero es lo que recomienda Microsoft, y además así es como está tanto en las interfaces de la propia Microsoft como en cualquier biblioteca que uses. A quien no le guste que no mire o que convenza a Microsoft de no hacerlo así. A mi personalmente es que hasta me gusta, será costumbre ya.