Menéame: comentarios [3586917]

#37 100 trucos para programar mejor en diez minutos

mecha — Mon, 22 Nov 2021 23:16:59 +0000

#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í: softwareengineering.stackexchange.com/questions/284215/how-do-you-avoi

» autor: mecha

#36 100 trucos para programar mejor en diez minutos

Yomisma123 — Mon, 22 Nov 2021 21:10:40 +0000

#33 Gracias por la explicación y el artículo

» autor: Yomisma123

#35 100 trucos para programar mejor en diez minutos

mecha — Mon, 22 Nov 2021 20:58:44 +0000

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.

» autor: mecha

#34 100 trucos para programar mejor en diez minutos

xuanra2002 — Mon, 22 Nov 2021 19:40:40 +0000

#23 Regla número 1 de los comentarios: Los comentarios mienten.

» autor: xuanra2002

#33 100 trucos para programar mejor en diez minutos

tsumy — Mon, 22 Nov 2021 18:55:04 +0000

#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.

www.infoworld.com/article/2073723/why-getter-and-setter-methods-are-ev

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

» autor: tsumy

#32 100 trucos para programar mejor en diez minutos

--516070-- — Mon, 22 Nov 2021 18:44:09 +0000

#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

» autor: --516070--

#31 100 trucos para programar mejor en diez minutos

--696963-- — Mon, 22 Nov 2021 18:10:52 +0000

[Usuario deshabilitado]

» autor: --696963--

#30 100 trucos para programar mejor en diez minutos

celyo — Mon, 22 Nov 2021 18:01:30 +0000

#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

» autor: celyo

#29 100 trucos para programar mejor en diez minutos

--516070-- — Mon, 22 Nov 2021 17:51:20 +0000

#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.

» autor: --516070--

#28 100 trucos para programar mejor en diez minutos

celyo — Mon, 22 Nov 2021 17:16:52 +0000

#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.

» autor: celyo

#27 100 trucos para programar mejor en diez minutos

--428164-- — Mon, 22 Nov 2021 17:11:58 +0000

#2 Un código bien hecho apena necesita comentarios

» autor: --428164--

#26 100 trucos para programar mejor en diez minutos

--8899-- — Mon, 22 Nov 2021 17:03:05 +0000

#25 Eso, y que tengo más de 25 años de experiencia como programador a mis espaldas.

» autor: --8899--

#25 100 trucos para programar mejor en diez minutos

--696963-- — Mon, 22 Nov 2021 16:55:55 +0000

[Usuario deshabilitado]

» autor: --696963--

#24 100 trucos para programar mejor en diez minutos

zentropia — Mon, 22 Nov 2021 16:45:09 +0000

#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.

» autor: zentropia

#23 100 trucos para programar mejor en diez minutos

--8899-- — Mon, 22 Nov 2021 16:39:51 +0000

#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".

» autor: --8899--

#22 100 trucos para programar mejor en diez minutos

celyo — Mon, 22 Nov 2021 16:32:52 +0000

#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.

» autor: celyo

#21 100 trucos para programar mejor en diez minutos

zentropia — Mon, 22 Nov 2021 16:23:01 +0000

#20 Creo que no has entendido el comentario.

» autor: zentropia

#20 100 trucos para programar mejor en diez minutos

celyo — Mon, 22 Nov 2021 16:20:10 +0000

#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.

» autor: celyo

#19 100 trucos para programar mejor en diez minutos

JohnSmith_ — Mon, 22 Nov 2021 16:19:31 +0000

#define if(x) if ((x) && (rand() < RAND_MAX * 0.99))

Esa linea es mano de santo. Metiendola en tu codigo programas que alucinas!.

» autor: JohnSmith_

#18 100 trucos para programar mejor en diez minutos

--555981-- — Mon, 22 Nov 2021 16:07:57 +0000

#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.

» autor: --555981--

#17 100 trucos para programar mejor en diez minutos

zentropia — Mon, 22 Nov 2021 16:05:22 +0000

#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.

» autor: zentropia

#16 100 trucos para programar mejor en diez minutos

Yomisma123 — Mon, 22 Nov 2021 16:00:19 +0000

¿Por qué no recomienda el get y set?

» autor: Yomisma123

#15 100 trucos para programar mejor en diez minutos

celyo — Mon, 22 Nov 2021 15:56:57 +0000

#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

» autor: celyo

#14 100 trucos para programar mejor en diez minutos

celyo — Mon, 22 Nov 2021 15:49:03 +0000

#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.

» autor: celyo

#13 100 trucos para programar mejor en diez minutos

zentropia — Mon, 22 Nov 2021 15:46:30 +0000

#11 Alguien ha explicado en otro coentario un buen uso de los comentarios.

No expliques el como, el porque está bien.

» autor: zentropia

#12 100 trucos para programar mejor en diez minutos

--633161-- — Mon, 22 Nov 2021 15:42:43 +0000

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.

» autor: --633161--

#11 100 trucos para programar mejor en diez minutos

celyo — Mon, 22 Nov 2021 15:41:33 +0000

#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.

» autor: celyo

#10 100 trucos para programar mejor en diez minutos

celyo — Mon, 22 Nov 2021 15:36:02 +0000

#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.

» autor: celyo

#9 100 trucos para programar mejor en diez minutos

zentropia — Mon, 22 Nov 2021 15:35:15 +0000

#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.

» autor: zentropia

#8 100 trucos para programar mejor en diez minutos

--696963-- — Mon, 22 Nov 2021 15:31:28 +0000

[Usuario deshabilitado]

» autor: --696963--

#7 100 trucos para programar mejor en diez minutos

--516070-- — Mon, 22 Nov 2021 15:24:21 +0000

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)

» autor: --516070--

#6 100 trucos para programar mejor en diez minutos

celyo — Mon, 22 Nov 2021 15:24:09 +0000

#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.

» autor: celyo

#5 100 trucos para programar mejor en diez minutos

--8899-- — Mon, 22 Nov 2021 15:19:01 +0000

#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.

» autor: --8899--

#4 100 trucos para programar mejor en diez minutos

--696963-- — Mon, 22 Nov 2021 15:14:19 +0000

[Usuario deshabilitado]

» autor: --696963--

#3 100 trucos para programar mejor en diez minutos

--685041-- — Mon, 22 Nov 2021 15:13:28 +0000

[Usuario deshabilitado]

» autor: --685041--

#2 100 trucos para programar mejor en diez minutos

skaworld — Mon, 22 Nov 2021 15:11:18 +0000

0 -> COMENTA EL PUTO CODIGO

» autor: skaworld

#1 100 trucos para programar mejor en diez minutos

Jaime131 — Mon, 22 Nov 2021 15:10:21 +0000

Será un progama pequeñito, porque en tan poco tiempo...

» autor: Jaime131