[Copy&Paste] Cada vez que me encuentro con un programador a quien le gusta programar me echo a temblar. La razón es que programar es como escribir, escribir es como hablar y hablar es más fácil que escuchar. [...]
Compendio de burradas para burros empleados en cárnicas con contratos temporales precarios cuya función es regurgitar lo ya masticado por el que estaba antes en su puesto y cagarlo para que el siguiente que ocupe su sitio pueda comerlo.
así es el software de las carnicas, una mierda regurgitada de un vomito comido de programador.
cuando lees código lo primero que necesitas es adivinar qué tenía en la cabeza la persona que lo escribió y el esfuerzo que requiere empatía no mola.
Lo mismo pasa cuando lees blogs. ¿Por qué lo ha escrito? ¿Porque se ha encontrado con un código que no sabe/quiere/puede leer? ¿Por qué cree que es capaz de hacer cosas fáciles de leer? ¿Quién le ha dicho que sabe escribir?
"10º) No es suficiente con tener un patrón Modelo-Vista-Controlador, además hay que tener una capa de microservicios agrupados en servicios que el controlador pueda llamar."
Realmente, o yo soy muy ignorante y no llego a entender de que esta hablando o...¡bueh! me parece que seria mejor pedirle al autor del articulo que se explaye un poco mas sobre el tema.
Pues a mí me gusta escribir código, pero también me gusta leer código escrito por otra persona, así captas y descubres nuevas formas de ver el mismo problema, y a veces ves que ha dado más vueltas que tú para llegar al mismo resultado, pero otras veces ves que lo hace de forma más interesante
El código debe explicar no sólo lo que hace, sino también por qué lo hace de esa manera. Para eso se inventaron los comentarios insertados dentro del código. Escribe la puta documentación. Es ilegal vender gadgets sin un manual de uso e instrucciones de seguridad. Entonces ¿por qué das por acabado software simplemente con una licencia que dice que se entrega “tal cual”?
Los comentarios son rendiciones: cuando te das cuenta que lo que has hecho es tal mierda que nadie lo va a entender es cuando pones comentarios.
Que me parece muy bien y todos en algun momento los ponemos, pero me parece mal considerarlos algo bueno....
7º) Si funciona no hay que tocarlo. Cada vez que se añade una línea de código aumenta el número de defectos software y el coste de mantenimiento. Agregar nuevo código para mejorar uno anterior (sin retirarlo de servicio) sólo es más bugs y más coste de mantenimiento. Por otra parte, todo ese horrible código espagueti del programador anterior está ahí por una razón la cual conviene saber antes de re-escribirlo para retirarlo.
Carne pura.... Si no quieren que haga mi trabajo que no me contraten.
El primer mandamiento del buen Boy Scout es dejar todo SIEMPRE mejor de lo que estaba cuando lo encontrastes.
8º) Salvo casos excepcionales, las funciones tendrán entre 10 y 100 líneas de extensión. No tan cortas como para no hacer nada significativo ni tan largas como para que no quepan enteras en la pantalla.
Las funciones tendran la longitud necesaria para realizar todo lo que tenga que hacer para cumplir lo que dice su nombre que hace y solo lo que dice su nombre que hace subdividiendose en ordenes de una complejidad inmediatamente inferior a la funcion que le permitiran cumplir su cometido.
Si tienen que ser 3 lineas 3 lineas, si tienen que ser 200... es que tu funcion hace mas de una cosa.
#6 Eso te lo compraria en los años 80s, cuendo la informática era "ciencia/matemática de la computación". Desde que se transformó en ingenieria ya no debe ser así. La ingenieria debe ser bella, práctica, austera, y que busque la mayor simpleza siempre que pueda.
El codigo no se lee, se debuggea, para que quieres leer lo que hace una funcion, libreria u api si la documentacion del codigo te dice la entrada y la salida esperada, y si el problema esta dentro de la funcion, pues lo que he dicho, se debuggea para ver que hace y con suerte lo puedes arreglar mientras tanto sin tener que hacer más de una pasada por el.
Comentarios
El mejor código es ilegible,increiblemente corto, indescifrable y cuando lo logras entender dices OHHHHH CLAAARO ES LA HOSTIA!
#c-2" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2426061/order/2">#2 ##Hostias!
#2 ¿Perl?
#4 hablo de programar, no de lenguajes de programación. programar no es conocer uno o 5 lenguajes de moda, es.. yo que se, es otra cosa.
#5 Papel y lápiz.
Compendio de burradas para burros empleados en cárnicas con contratos temporales precarios cuya función es regurgitar lo ya masticado por el que estaba antes en su puesto y cagarlo para que el siguiente que ocupe su sitio pueda comerlo.
así es el software de las carnicas, una mierda regurgitada de un vomito comido de programador.
Niños, de lo que dice este, todo lo contrario.
cuando lees código lo primero que necesitas es adivinar qué tenía en la cabeza la persona que lo escribió y el esfuerzo que requiere empatía no mola.
Lo mismo pasa cuando lees blogs. ¿Por qué lo ha escrito? ¿Porque se ha encontrado con un código que no sabe/quiere/puede leer? ¿Por qué cree que es capaz de hacer cosas fáciles de leer? ¿Quién le ha dicho que sabe escribir?
"10º) No es suficiente con tener un patrón Modelo-Vista-Controlador, además hay que tener una capa de microservicios agrupados en servicios que el controlador pueda llamar."
Realmente, o yo soy muy ignorante y no llego a entender de que esta hablando o...¡bueh! me parece que seria mejor pedirle al autor del articulo que se explaye un poco mas sobre el tema.
#9 supongo que hablará de esto:
http://stevelorek.com/service-objects.html
Yo, en el momento que veo que alguien hace una lista ordenada de manera manual en vez de usar , que además repite un punto, el 3...
es equiparable al que mete espacios en un documento de word en vez de un tabulador...
es equiparable a ese programador que le gusta programar...
irrelevante.
Pues a mí me gusta escribir código, pero también me gusta leer código escrito por otra persona, así captas y descubres nuevas formas de ver el mismo problema, y a veces ves que ha dado más vueltas que tú para llegar al mismo resultado, pero otras veces ves que lo hace de forma más interesante
El código debe explicar no sólo lo que hace, sino también por qué lo hace de esa manera. Para eso se inventaron los comentarios insertados dentro del código. Escribe la puta documentación. Es ilegal vender gadgets sin un manual de uso e instrucciones de seguridad. Entonces ¿por qué das por acabado software simplemente con una licencia que dice que se entrega “tal cual”?
Los comentarios son rendiciones: cuando te das cuenta que lo que has hecho es tal mierda que nadie lo va a entender es cuando pones comentarios.
Que me parece muy bien y todos en algun momento los ponemos, pero me parece mal considerarlos algo bueno....
7º) Si funciona no hay que tocarlo. Cada vez que se añade una línea de código aumenta el número de defectos software y el coste de mantenimiento. Agregar nuevo código para mejorar uno anterior (sin retirarlo de servicio) sólo es más bugs y más coste de mantenimiento. Por otra parte, todo ese horrible código espagueti del programador anterior está ahí por una razón la cual conviene saber antes de re-escribirlo para retirarlo.
Carne pura.... Si no quieren que haga mi trabajo que no me contraten.
El primer mandamiento del buen Boy Scout es dejar todo SIEMPRE mejor de lo que estaba cuando lo encontrastes.
8º) Salvo casos excepcionales, las funciones tendrán entre 10 y 100 líneas de extensión. No tan cortas como para no hacer nada significativo ni tan largas como para que no quepan enteras en la pantalla.
Las funciones tendran la longitud necesaria para realizar todo lo que tenga que hacer para cumplir lo que dice su nombre que hace y solo lo que dice su nombre que hace subdividiendose en ordenes de una complejidad inmediatamente inferior a la funcion que le permitiran cumplir su cometido.
Si tienen que ser 3 lineas 3 lineas, si tienen que ser 200... es que tu funcion hace mas de una cosa.
Si fue difícil de programar, debe ser difícil de leer.
#6 Eso te lo compraria en los años 80s, cuendo la informática era "ciencia/matemática de la computación". Desde que se transformó en ingenieria ya no debe ser así. La ingenieria debe ser bella, práctica, austera, y que busque la mayor simpleza siempre que pueda.
#6 lo difícil no es hacerlo, lo difícil es hacerlo bien.
El codigo no se lee, se debuggea, para que quieres leer lo que hace una funcion, libreria u api si la documentacion del codigo te dice la entrada y la salida esperada, y si el problema esta dentro de la funcion, pues lo que he dicho, se debuggea para ver que hace y con suerte lo puedes arreglar mientras tanto sin tener que hacer más de una pasada por el.