edición general
226 meneos
4624 clics

Sólo has añadido dos líneas. ¿Por qué tardaste dos días? (ENG)

Puede parecer una pregunta razonable, pero hace algunas suposiciones terribles: líneas de código = esfuerzo, líneas de código = valor, todas las líneas de código son iguales. Nada de eso es cierto. ¿Por qué un arreglo que parece tan simple cuando se observan los cambios realizados tomó dos días para completarse?

| etiquetas: programación , bugs
111 115 1 K 325 tecnología
126 comentarios
111 115 1 K 325 tecnología
12»
  1. #101 pcmaster
    #12 Go to #3
    0 K 11
  2. #102 WifredoIII_ElGayu *
    #7 Pero ese código hace 1 mes era El brand new code que refactorizaba el legacy code anterior
    1 K 12
  3. #103 WifredoIII_ElGayu
    Creo que eso se debe a que la informática no es una ingeniería... o si :troll:
    0 K 8
  5. #105 --527011-- *
    La informatica y sus cosas.
    0 K 7
  6. #106 --527011--
    #90 Yo la escuché con un tornillo.
    Apretar tornillo, un dolar, saber qué tornillo apretar, 9.999.
    1 K 11
  7. #107 --527011--
    #51 O estar una semana intentando replicar un bug y que no salga, y al final es que el cliente tiene las mayúsculas puestas y el soft distingue entre mayúsculas y minúsculas, y te dice.. ahh, es que el password lo tengo todo en mayúsculas y por eso las dejo puestas. El bug es una tontería pero cuando no puedes ni replicarlo es un infierno.
    1 K 16
  8. maloconocido #108 maloconocido
    #14 es un campo de remolachas?
    0 K 6
  10. #110 Chicho_
    #104 Puedes hacer comentarios con /* comentario */ que serviría para múltiples líneas (hasta que se cierra el tag) o con // que entonces ya ignora el resto de código pero sólo de ese línea.
    0 K 9
  11. Jaski #111 Jaski *
    El problema es que muchos empleados, cuando el jefe ordena "resolver un cubo de rubik", se ponen a mover y a combinar como locos hasta conseguir un cubo perfecto con cada cara de un color. Cuando al jefe, le valdría con que cogieras una brocha gorda y lo pintaras.
    ¿Que el primer método es técnicamente perfecto? Sí. ¿Que el segundo método es una chapuza horrible y no has resuelto nada? También, pero se tarda menos y hasta puede llegar a dar el pego.
    Por desgracia, en España no hay cultura laboral. Los jefes quieren todo YA de cualquier manera, y si luego pasa algo, que lo resuelva el siguiente becario.
    0 K 9
  12. #112 derp
    Me ha pasado hoy mismo. Después de mucho investigar, mucho StackOverflow, patearme la especificación de SVG y la de la API DOM, por fin pude primero comprender, después aprender, y por último implementar una solución al extraño problema que tenía por delante

    La solución no era especialmente voluminosa en cuanto a cantidad de código y recibí la susodicha frasecita del tiempo vs el número de líneas...

    Maldito Shadow DOM :shit:
    0 K 8
  13. Juan_Antonio_Martínez_2 #113 Juan_Antonio_Martínez_2
    Un mes de trabajo
    Un maldito punto y coma tras la condición en un bucle while....
    Encima el código era mío

    Hoy día cualquier compilador o el propio IDE me hubieran insultado con cientos de warnings avisando del error ... pero esto fue hace treinta años...
    Todavía tengo pesadillas
    0 K 6
  14. #114 malditopendejo
    #36 otra pregunta sería: "¿Cuál era el problema?" y te contesten, "No se, pero con esas líneas funciona".
    0 K 7
  15. dav #115 dav
    #2 A parte de la broma, también te puedes llevar dos días para quitar una línea (caso real), pero claro hasta que llegas a la conclusión de que eso es lo que hay que hacer y no poner 100 líneas nuevas y que además al solucionar tu problema no creas 20 nuevos pues...
    1 K 15
  16. dav #116 dav
    #107 Efectivamente, replicar un bug puede ser la peor parte del problema. Hay bugs que ocurren siempre, otros que ocurren "a veces" o como tu caso "no ocurren", y eso sí que es un problemón
    1 K 13
  17. hasta_los_cojones #117 hasta_los_cojones
    #115 cierto. Pero si por el camino has hecho un montón de testing y de investigación, a parte de las dos lineas en el código del producto tienes un montón documentación y de tests.

    Yo voy llenando la issue de información, sobre: dependencias, modelos, sugerencias...

    No para justificar mi tiempo, sino porque sé que me va a ser útil en el futuro.
    0 K 9
  18. dav #118 dav
    #74 Trabajar con máquinas con menos recursos (memoria, micro...) es algo desesperante y que además le cuestan una pasta a la empresa; es algo que no puedo llegar a entender.
    0 K 6
  19. dav #119 dav
    #117 el problema es que a veces no quieren que "pierdas el tiempo con toda esa documentación", porque lo más habitual es corregir los errores relativamente rápido porque son relativamente estándar, y cuando un error es más largo de lo habitual te encuentras con que no tienes documentación previa. De todos modos, tengo la fortuna de que a mi esto no me ha pasado y no se ha puesto en duda si algo "con poco código" lleva más o menos tiempo
    0 K 6
  20. Puño_mentón #120 Puño_mentón
    #34 eso sustituirá a la ballena en mis pesadillas.........dios santo......:shit:
    0 K 6
  21. #121 galleto *
    #104 Son comentarios de línea, no de bloque.

    // pon lo que quieras
    /* lo que
    tu quieras
    */
    0 K 6
  23. #123 --527011--
    #116 Ya te digo...
    En videojuegos, los QA, graban continuamente la partida, así por lo menos hay constancia del bug y como se produjo..
    0 K 7
  24. #124 failure
    #44 ¿Qué lenguaje es ese que no te da una excepción de formato al parsear 0.9 como entero y, especialmente, ninguna excepción al dividir por cero?
    0 K 8
  25. #125 MANOLO_HARD
    #124 Es Java, pero piensa que lo que comentas no es algo que esté restringido por lenguaje, mucho menos si este es orientado a objetos. Al final, un .valueOf(), .intValue(), A.divide(B), / o una función dividir que yo programe se comporta de forma diferente si se trata de los métodos de un Float, float, Double, double, BigDecimal o de una clase "importe" que yo haya programado. Alguna de ellas dará error al dividir por 0 y otras no.
    0 K 6
  26. #126 failure
    #125 Por los nombres de los métodos ya me imaginaba que hablabas de Java.

    Pero es que en Java un Integer.parseInt() de un número con decimales te da una java.lang.NumberFormatException (que por otro lado, no entiendo por qué hacían un parseInt() de unos cálculos intermedios. Me suena a alguna chapuza estilo parseInt() de un BigDecimal.toString() o algo por el estilo).

    Y un BigDecimal una java.lang.ArithmeticException: Division by zero si intentas dividir por 0. Sí es cierto que con Double o Float lo que obtendrías es un POSITIVE_INFINITY, pero no son simplemente números muy grandes y en cuanto intentaras usarlos como valores numéricos obtendrás una excepción igualmente: por ejemplo, un new BigDecimal(Double.POSITIVE_INFINITY) te va a dar java.lang.NumberFormatException: Infinite or NaN.

    Otra cosa es que, como comentas, escriban sus propias implementaciones de división...

    Pero vamos, la cosa es que difícilmente en Java vas a obtener silenciosamente un número muy grande al dividir por cero, salvo que así lo implementes expresamente capturando las excepciones. No quiero ni pensar con qué tipo de enrevesado código te encontraste y todo por lo que dices, no usar lo que el lenguaje ya te da hecho por ejemplo con Calendar.
    0 K 8
12»
comentarios cerrados

menéame