#4 Claro, tenemos a los trabajadores cuyo trabajo ven peligrar, pero del mismo modo muchas empresas ven peligrar ese trabajo que ofrecen y no les queda más que despedir o cerrar. Las medidas tienen que tener en cuenta todo la cadena que une trabajador con trabajo.

#3 por no decir leyes mal hechas, con precipitación y por gente incompetente.

#3 Por muy buena intención que tengan, a veces no es tan fácil: El Gobierno prohibirá temporalmente a las empresas despedir por motivos relacionados con el coronavirus/c10#c-10

#18 Conociendo al bicho humano, cuenta con ello.

#18 ¿volveremos a destrozarlo? que pasa que en 15 días lo hemos arreglado, entonces no era para tanto.

#107 Ni de lejos se arregla con un parón de semanas o meses, me refería a que volveremos al proceso habitual de destrozarlo, y más duramente si cabe...

Pero para empezar, tenemos un aire más limpio y animales que no suelen adentrarse en entornos urbanos campando por sus anchas, delfines acercándose a las costas normalmente plagadas de ruidos de barcos.

#107 Ni de lejos se arregla con un parón de semanas o meses, me refiero a que volveremos al proceso de seguir destrozándolo.

De momento tenemos estampas curiosas de animales salvajes que se acercan a entornos urbanos aprovechando la ínfima afluencia de gente y vehículos. Tenemos delfines que se acercan curiosos a las costas que han dejado de estar plagadas de ruidos de motores de barcos. Y desde mi ventana observo un mayor número de pájaros alrededor.

#107 Ni de lejos se arregla con un parón de semanas o meses, me refiero a que volveremos al proceso de seguir destrozándolo.

De momento tenemos estampas curiosas de animales salvajes que se acercan a entornos urbanos aprovechando la ínfima afluencia de gente y vehículos. Tenemos delfines que se acercan curiosos a las costas que han dejado de estar plagadas de ruidos de motores de barcos. Y desde mi ventana observo un mayor número de pájaros alrededor.

#122 Totalmente de acuerdo, ¨Y lo de los pájaros es flipante, yo vivo en un adosado, y a ver, sí, ves 2 ó 3 pájaros, pero ahora igual tengo a 20 en el patio...

#15 Todas las libertades con una vigilancia férrea... Millones de personas han muerto por esa libertad que tan fácil relativizas tú ahora. Una vida libre vale más que mil vidas esclavas del miedo. No sé si ves tu propia contradicción, pero gracias por participar.

#9 No sé tú, pero mi libertad no la vendo tan barato. Si se nos llena la boca diciendo que daríamos la vida por la libertad de expresión ajena, deberíamos hacer incluso un poquito más por la libertad individual.

#13 No tiene que ser toda libertad, pero si por no sacrificarla a tiempo terminamos con la vida de muchas personas. Y aún así, alternativamente, se podrían mantener todas las libertades pero con una vigilancia férrea.

#15 Todas las libertades con una vigilancia férrea... Millones de personas han muerto por esa libertad que tan fácil relativizas tú ahora. Una vida libre vale más que mil vidas esclavas del miedo. No sé si ves tu propia contradicción, pero gracias por participar.

#1 todo eso significa mucho menos crecimiento y menos beneficios para los poderes económicos, yo espero que esas élites impulsen soluciones médicas que nos permitan volver a producir, consumir y contaminar como antes.
Es broma, me gustaría no volver a contaminar, pero me temo que todo va unido.

#6 Creo que al coche eléctrico le han fastidiado el negocio por una década al menos. Vuelta al diésel. La gente va a malvender ese híbrido tan molón y desempolvar la vieja Mobilette que tiene olvidada en el pueblo para seguir yendo al curro (al que le quede).

#7 Entre la potencial recesión económica y el bajísimo precio del petróleo la verdad es que sí, pero más rápido o más despacio llegará. Mientras tanto el problema lo veo en que se limite el aforo de personas en coches y transporte público, y no se implante el teletrabajo allá donde se pueda.

#4 por lo que he leido, parece que es una mutación del virus la que produce la falta de sabor y olfato, porque pasa sobre todo en los EEUU... pero creo que es una teoría, y podría ser condiciones de tu alimentación, etc.

#7 #11 #34 Pese a que Uncle Bob es un crack, ese libro es todo obviedades, simplificaciones absurdas y 'truquitos'.

Que la gente presuma de haber leído ese libro, lo recomiende, o considere que 'desearía haberlo leído antes' es una prueba mas de lo en pañales que está aún esta ciencia.

#61 la pena es que lo normal es encontrarse funciones de 300 líneas con 5 parametros de entrada dentro de clases monstruosas. Son obviedades que hace la vida de los demás mucho más fácil.

#64 La pena es que en 2019 la gente describa las propiedades del software en base a líneas de código o "cantidad" de parámetros de entrada de clases, que además describe con términos tan específicos como "monstruosas". En estos términos, es normal que ese libro sea tan popular.

Hay muchos otros libros, como object oriented design heuristics, que creo mucho mas relevantes, pero claro, no te explican 'truquitos' o conceptos tan imprecisos, enfocados a que produzcas código sin entender absolutamente nada. Dicho esto, insisto: Uncle Bob es un crack, no estoy diciendo que el autor de ese libro no entienda nada, estoy diciendo que ese libro es adorado por gente que generalmente, no entiende nada, y que eso es consecuencia del público al que está dirigido y la forma en la que está redactado y explicado todo.

Aun así, te he votado positivo por que no querer hacer "clases monstruosas", pese a lo impreciso de todo, al menos muestra interés por producir software mantenible y extensible, que ya es mucho hoy en día

#69 en el comentario #89 ya he comentado razones por que escribir código límpio y para mi la pena es que en 2019 la gente no sea un autentico talibán del código límpio. No sólo son líneas de código y parámetros de entrada, es también no indentar 3 if y dos fors, poner nombres de variables y nombres de funciones claros...

#69 ¿Podrías iluminarnos con algo de tu código? ¿Algún repositorio o algo? ¿O eres el clásico tertuliano?

#64 poco codigo has visto, por mi lado he llegado a ver funciones de 2000 y pico lineas en ficheros de mas de 15000 lineas... todavia me entra el tembleque cuando lo recuerdo.

#71 Como se revisa eso? Incluso el mismo que lo ha escrito, como puede identificar lo que hace.

A mi me pasan eso o paso el marrron a otra persona en pla hijo puta o miro que función tenia eso y lo reescribo de 0. Seguramente seria mejor que intentar saber que es eso.

#71 he tenido entonces mucha suerte en mi vida laboral,uuuf, 2000 líneas en una función, jajajajaja. Cómo mantienes eso! Y ya flipa si lo tiene que hacer otra persona.
No digo nada de revisión por que evidentemente eso no ha podido ser revisado.

#91 #71 creo que el primer programa que me tocó mantener en mi vida laboral fue un programa en C++, con punteros por todos lados (vamos, C con objetos...) y en el que me encontré una clase de 21k líneas que tenía una función de 6k líneas y hasta 16 niveles de condiciones.
No había ningún test y se sabía que esa función fallaba a veces, pero nadie se atrevía a tocarla.

Cabe decir que todos o casi todos los que desarrollaron esa monstruosidad eran tan Juniors que muchos no habían acabado la carrera.

#91 No es agradable, y el perpetrador es con toda probabilidad un desarrollador junior o alguien con muy poco respeto por sus compañeros... pero es también parte de nuestro trabajo aprender a lidiar con estos monstruos.

Y con eso no me refiero a aprender a resignarse, sino a aprender algunas técnicas y heurísticas que ayudan a entender mejor el código, debugarlo, refactorizarlo... algunas son más o menos universales, algunas dependen del lenguaje de programación que se esté usando... y algunas del proyecto en sí.

Lo que sí puedo decir es que tiro mucho de herramientas de análisis estático de código e IDEs potentes, rollo IntelliJ, que aligeran un poco la carga de trabajo, aunque te ponen la CPU a punto de freír huevos.

En cuanto a qué hacer a la hora de tratar con lenguajes "dinámicos" (no voy a entrar aquí en definiciones precisas, sé que hay mil sutilezas aquí), trato de anotar tipos siempre que sea posible (por ejemplo en Python y PHP se puede), aunque el código parezca más "denso", ayuda muchísimo.

Otro "truco" es tener los cojones de decirle a tu jefe que tardarás más de lo que él quiere y que da igual lo que insista, que es lo que hay. Y dedicar ese tiempo, con calma, a entender y mejorar el código. Y si te echan por eso, felicidades, ahora tienes tiempo para ir a un sitio mejor.

#71 He visto un programa cuyo listado no lo levantaba una persona sin ayuda. En producción.
Su mantenimiento (pues era insustituible ya que nadie sabía lo que hacía) era todo un arte.

#64 y con comentarios que son obviamente de cuando esa función tenía solo dos parámetros.

#61 Los comentarios de esta web están llenos de gente que está de vuelta de todo, macho, qué asquito.

#75 eso que escribes no es precisamente lo que escribiría alguien que "está de vuelta de todo"?

Has creado un comentario recursivo

#61 "es una prueba mas de lo en pañales que está aún esta ciencia. "

O de lo sobrado que te crees tú.

#81 eso depende de la definición de sobrado.

Eso depende enteramente de lo que consideres que significa que alguien se "cree sobrado". Como no puedo adivinar a que te refieres con algo tan indefinido como 'ir de sobrado', te explico mi postura y tu decides si el caso es que la programación está en pañales, o es que yo soy me creo un sobrado, o quizás las dos cosas.

En primer lugar, el propio autor define su obra como:

The mission of this series is to improve the state of the art of software craftsmanship

sacado de la primera página después de la portada. Es decir, el mismo reconoce que esto va de "artesanía". No es un libro de software engineering, ni de principios de la informática. Es un libro de "artesania". Dentro del libro se habla de cosas como que las funciones sean "cortas" o que hagan una sola cosa (aunque no definen claramente que significa eso, de una manera objetiva y medible).

Todo el libro es una oda a la "intuición" y los "truquitos". Si bien no tengo nada en contra de ello, no es mas que un recopilatorio de "aprendizajes" de un señor que ha programado mucho, y desde luego es un experto. Fíjate que Robert C. Martin si entiende muy bien los fundamentos conceptuales que existen detrás de sus consejos simplificados y sus "truquitos", pero ese tipo de explicaciones no las vas a encontrar en clean code. Las vas a encontrar en otras obras mas conceptuales.

Yo no tengo nada en contra de Robert C. Martin, al cual considero un gran programador y un gran ingeniero, y tampoco tengo nada en contra de hacer un libro recolectando todo tipo de truquitos básicos de la industria que simplifican y proporcionan estrategias y mecanismos para poder realizar ciertas tareas sin entender lo que se está haciendo.

Sin embargo, el primer ordenador del mundo se creó en el 36. Las ciencias de la computación se apoyan en matemáticas que tienen siglos y los fundamentos en los que se basa la programación tienen también siglos. Pues bien, tras tantos años los programas informáticos se siguen programando de forma desastrosa y la gente necesita que Robert C. Martin le explique que tiene que crear códigos cortos conectados entre si que crean codigos mas complejos, que conectandos entre si crean otros mas complejos, que conectados entre si crean programas completos. Y que al hacerlo así, todo es mucho mas fácil.

Es triste. Si entender cosas tan básicas como esa me hace un sobrado, debo ser un sobrado. ¿Lo que yo pienso? Que no tengo ni puta idea. Que las estructuras conceptuales que construyen un programa moderno son de tal complejidad que razonar sobre ellas escapa a mis posiblidades y a las de casi nadie, y que tardaremos aun años en crear las abstracciones y herramientas necesarias para que todo esto mejore lo suficiente como para poder cubrir las necesidades de digitalización de la humanidad.

Pero aunque soy consciente de la complejidad, entiende que me asombre cuando abro meneame y veo que el libro revelador es precisamente un libro lleno de dibujos que te trata como a un niño pequeño y te explica de manera simplificada hasta el absurdo la forma en la que principalmente no tienes que hacer tus programas, basandose en ejemplos inespecificos y con comparaciones culturales.

Pero bueno, en el resto de ciencias lo normal es exigir un mínimo de rigor, en esta ciencia lo normal es comprar libros de instrucciones para intentar atajar, y poder crear sin entender nada. Y es normal, como digo las necesidades de digitalización son tan fuertes que empujan a esto. Es el mercado amigo.

#82 estoy de acuerdo que casi es un libro que no debería hacer falta, pero sin embargo mis experiencias personales me dicen todo lo contrario y es un libro que recomendaría a la mayoria de programadores que he tenido alrededor. Son conceptos (y truquitos, sí) básicos que todo programador deberia conocer para no escribir auténticos tronchos infumables.

#82 Igual es que no has entendido que no es una ciencia sino una INGENIERIA.

Se trata de ingeniar soluciones para resolver problemas de la gente, no de pajearse con matematicas.

#95

Creo que estás muy perdido.

Decir que la informática no es una ciencia sino una ingeniería es absurdo e ignorante. La informática es todo el campo de estudio relacionado con el uso, aplicación y construcción de computadoras. Dentro de ese campo tan grande, hay varias ciencias, principalmente la física y las matemáticas, creando un campo llamado "ciencias de la computación" que es muchas cosas, pero principalmente es el estudio científico de las computadoras.

Además de las ciencias, la informática incluye también la ingeniería, que emerge como resultado de aplicar la informática. La ingeniería informática estudia la computación aplicada. Dentro de la ingeniería hay muchas disciplinas.

Como te veo muy perdido, te recomiendo mirar este video, aquí lo explica todo muy bien.

#97 yo creo que el perdido eres tu:

Vivimos de solucionar problemas y eso es lo que hacemos como ingenieros.

Y la ingenieria depende del INGENIO y la ciencia solo marca los limites.

Porque recomiendo ese libro a gente? porque se que les va a ayudar y esta escrito de manera muy amena.

Porque quiero que mejoren

Porque me encanta lo que hago, soy buen compañero y en lo que pueda les ayudare.

Porque no soy un sobrado.

#97 Aunque soy de los que piensa como tu (que es necesario abstraerse hasta conceptos cuando lees definiciones o conclusiones para poder aplicar esos conceptos de forma multidisciplinar y correcta) creo que te has colado un poco.

La ciencia solo busca herramientas y la ingenieria las aplica. Un ingeniero no tiene que saber como se descubre la herramienta, si no que existe, funciona, y por que funciona.

Saber como se descubren las herramientas es util. Pero la mayoria de gente no son capaces de poder profundizar tan alla sobre el por que existe nuestra ciencia. En su trabajo, lo que deben dedicarse es a poder montar los puzzles requeridos para resolver un problema, y montarlos de una manera eficiente y mantenible.

Cualquiera que lea el libro de Clean Code sacara conocmiento. Aquellos que vemos y pensamos mas alla tambien sacaremos mas conocimientos. Y aquellos que simplemente piensen "esto funciona" sacaran lo justo para mejorar su codigo, asi que aprenderan. Por eso es un libro tan bueno.

¿Que alguien que sepa clean code no lo hace mejor programador? Temo que tengo que discrepar. Nosotros valoramos los resultados. No los caminos. Si una persona llega a buenos resultados y sabe que tiene que aplicar y tiene un autor de referencia me parece suficientemente bueno. Que una persona con mas capacidad pueda explicarte eso a un nivel mayor esta genial. Pero ambos son igual de buenos programadores.

#95 mmm, tienes "computer's science" y "computers engineering", así que diría, que sí, que sí es una ciencia además de una parte de ingeniería.

Además, en una ingeniería también debes seguir una serie de formas concretas para resolver los problemas, no lo haces como quieras.

#118

La ciencia solo busca herramientas y la ingenieria las aplica. Un ingeniero no tiene que saber como se descubre la herramienta, si no que existe, funciona, y por que funciona.

La ciencia no busca herramientas, busca conocimiento en forma de predicciones y explicaciones comprobables. La ingeniería construye herramientas en base a esas explicaciones y predicciones y en base a las herramientas que otros ya han creado en base también a esas mismas predicciones y explicaciones. Para dudas, ver:

https://en.wikipedia.org/wiki/Science

Primer párrafo:

Science (from the Latin word scientia, meaning "knowledge")[1] is a systematic enterprise that builds and organizes knowledge in the form of testable explanations and predictions about the universe.[2][a]

Entonces, un ingeniero es básicamente una persona que tiene que construir una solución. En la medida en la que el ingeniero entienda la ciencia, mas herramientas tendrá para construir sus soluciones. Cuanto mas ignore la ciencia, menos herramientas tendrá. Nadie conoce toda la ciencia o ninguna parte de la ciencia. Todos los ingenieros están en un espectro entre un hipotético desconocimiento total de la ciencia, y un hipotético e imposible entendimiento completo y absoluto de la naturaleza.

En este hilo sin ir mas lejos en #95 puedes leer como un supuesto ingeniero, típico lector de clean code, llama a las ciencias de la computación sobre las que se sostiene el libro, "pajas mentales matemáticas". Ya te puedes imaginar el tipo de soluciones que se pueden alcanzar desde esa perspectiva. Creo que ejemplifica perfectamente mis sentimientos sobre ese libro.


Saber como se descubren las herramientas es util. Pero la mayoria de gente no son capaces de poder profundizar tan alla sobre el por que existe nuestra ciencia. En su trabajo, lo que deben dedicarse es a poder montar los puzzles requeridos para resolver un problema, y montarlos de una manera eficiente y mantenible.

Cuanto menos entiendas ciencias de la computación, menos vas a poder realizar predicciones y conjeturas sobre las propiedades de un código para una computadora y para un humano. La ciencia estudia que hace que las cosas sean mantenibles, extensibles, escalables o fiables, y proporciona modelos mentales para que luego un ingeniero, con esos modelos, monte los puzzles. Si el ingeniero llama a esos modelos pajas mentales matemáticas y prefiere leerse un manual de instrucciones para, literalmente leído en este hilo "ser buen compañero", en lugar de "hacerse pajas mentales", ya te puedes imaginar el sistema que va a construir.

Eso no significa que necesites entender toda la ciencia para poder construir soluciones industrialmente válidas o viables, pero tampoco significa que puedas ignorar toda la ciencia y construirlas. Como digo, todo ingeniero está en un espectro intermedio, pero entender eso es vital, no engañarse y pensar que podemos crear un señor que resuelve puzzles de puta madre, en base a unos truquitos.

Cualquiera que lea el libro de Clean Code sacara conocmiento. Aquellos que vemos y pensamos mas alla tambien sacaremos mas conocimientos. Y aquellos que simplemente piensen "esto funciona" sacaran lo justo para mejorar su codigo, asi que aprenderan. Por eso es un libro tan bueno.

De cualquier conjunto de datos se puede extraer conocimiento dada suficiente capacidad cognitiva, siempre y cuando los datos no sean aleatorios (si es que eso es posible, que sean aleatorios, pero eso es otro debate). Yo no niego que ese libro pueda ser útil. Niego que su utilidad ses relevante como para ser mencionado como obra "que desearía haber leído antes". Eso lo entendería de otras obras, pero no de esta, pese a que reconozco que obviamente contiene conocimiento.

¿Que alguien que sepa clean code no lo hace mejor programador? Temo que tengo que discrepar. Nosotros valoramos los resultados. No los caminos. Si una persona llega a buenos resultados y sabe que tiene que aplicar y tiene un autor de referencia me parece suficientemente bueno. Que una persona con mas capacidad pueda explicarte eso a un nivel mayor esta genial. Pero ambos son igual de buenos programadores.

Me temo que discrepamos. Un programador es mejor o peor en la medida en la que es capaz de generar sistemas que cumplan con los requisitos a al menor coste posible. Y en mi experiencia, las personas no son capaces de mejorar en ese aspecto tras leer clean code, o al menos no de una forma substancial. Una persona que creaba código de mierda, lo sigue creando después de leer clean code, simplemente su código ahora está partido en trozos, que normalmente además estarán mal escogidos y será peor que si no lo hubiese partido. Una maraña conceptual es una maraña conceptual en uno o en 20 ficheros.

Si tu consideras que una persona es capaz de crear sistemas que cumplen los requisitos, a un coste menor después de leer clean code, estoy interesado en entender mejor el mecanismo.

#122 Dejalo, por que no entiendes el concepto de abstraccion y me vas a sacar definiciones del coño de la bernarda en las cuales no hay escuela ni conclusiones universales.

La tecnica abstrae la ingenieria. La ingenieria abstrae la ciencia. Y la ciencia abstrae la realidad. Esto si es literal y esta totalmente consensuado.

Y si la ingenieria abstrae la ciencia, significa que NO debes saber ciencia para hacer ingenieria (aunque ayuda, y mas a ciertos tipos de personas).

Para lo siguiente: vuelve a 1º de carrera, o a bachiller. Gracias. Y deja de hacernos perder el tiempo a los usuarios. Te puedes seguir poniendo medallitas en "googul consulting". Hasta luego.

#61 Son obviedades, simplificaciones absurdas y 'truquitos' cuando tienes una cierta experiencia. Y la experiencia la puedes adquirir con tiempo o leyendo libros. Y sabes que pasa? que hay gente que tiene unas aficiones diferentes y de programar solo vive.

Hay gente (lease #1) a la q no le puedes pedir que este todo el dia autoformandose y aun asi son tus compañeros de trabajo, sacan el producto adelante y son necesarios. Y si les puedes dar un libro que les pone todo blanco sobre negro y que dice grandes PRINCIPIOS que pueden hacer que SU codigo, con el que lidias TU sea mas comprensible sera bueno para ti y para ellos.

Si tus compañeros de trabajo no son tan buenos como tu entonces tu labor es hacerlos mejorar, por ellos, por ti y por tu empresa.

#90 Vale, entonces estamos de acuerdo.

Yo no niego la utilidad del libro, pero es un libro que sirve para que la gente que programa sin haber entendido las bases deje de romper o complicar el código de forma innecesaria. Entenderás mi sorpresa cuando la gente dice abiertamente que ese es el libro que desearía haber leído antes. Precisamente un libro que le das a la gente que no tiene bases pero cree saber y no para liarla...