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. #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
  2. #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
  3. kmon #8 kmon
    Más de una vez he publicado partes grandes de código que al final era una mala solución y sabía que lo iba a desechar, para a continuación publicar el bueno
    0 K 7
  4. #39 jaramero
    ¿Sólo dos días?, ¿cuantos test cases tenía? Lo mismo hasta fue demasiado rápido.
    0 K 7
  5. baronrampante #41 baronrampante
    Un problema con esto es que un compañero chapucero puede presentar una solución en la mitad de tiempo y modificando cien líneas, aunque no haya entendido bien lo que estaba tocando y deje un pufo a futuro. Pues este tío, para muchos jefes, es lo más.
    0 K 7
  6. pedrobz #59 pedrobz
    #44 Y lo peor es que nadie medio importante valora/comprende todo ese esfuerzo...
    0 K 7
  7. #63 AGlC
    #1Pues nada. Se revisa otra vez un poco el código, se cambian dos lineas bien elegidas sin documentar ni comentar los cambios y se le devuelve al listo de turno diciendole que haber cuanto tarda el en arreglarlo.
    0 K 7
  8. #64 AGlC
    #17 :troll:
    0 K 7
  9. pedrobz #66 pedrobz
    #62 Era obvio en cuanto soltaste "incapaz de entender"
    0 K 7
  10. #88 ximiu
    #46 La respuesta está contenida en los decimales de Pi.

    También todas las respuestas incorrectas y otras cosas diversas. El problema es saberlo distinguir.
    0 K 7
  11. #89 --569461--
    Porque para que un avión funcione todo tiene que estar perfectamente calibrado, pedazo de subnormal.
    0 K 7
  13. #105 --527011-- *
    La informatica y sus cosas.
    0 K 7
  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. #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
  16. Efnauj72 #42 Efnauj72
    Hello
    World!!!
    0 K 6
  17. #43 AptGetInstallFortune
    #30 Muchas veces yo le llamo arqueología de código.
    0 K 6
  18. #71 --10016--
    Joder, esto está lleno de programadores !!!. A mi siempre me ha parecido una tontería equiparar el número de líneas con el trabajo realizado, hay gente que programa una línea sí y otra no para verlo más claro, ¿qué trabaja el doble ?. Además no hace falta que sean dos líneas, que falte una coma ya vale para joder un proyecto entero....
    0 K 6
  19. #76 telcnp
    Total factura = 1000 euros
    Tornillo = 0.1 euros
    Saber que tornillo tocar = 999.9 euros
    0 K 6
  20. maloconocido #108 maloconocido
    #14 es un campo de remolachas?
    0 K 6
  21. 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
  22. 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
  23. 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
  24. Puño_mentón #120 Puño_mentón
    #34 eso sustituirá a la ballena en mis pesadillas.........dios santo......:shit:
    0 K 6
  25. #121 galleto *
    #104 Son comentarios de línea, no de bloque.

    // pon lo que quieras
    /* lo que
    tu quieras
    */
    0 K 6
  26. #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
12»
comentarios cerrados

menéame