Respuestas de foro creadas

Mostrando 1 respuesta al debate
  • Autor
    Entradas
    • #19772

      A simple vista lo primero que se detecta es que no se respeto en lo mas minimo SoC, SRP  ademas que estoy completamente seguro que no se podria reutilizar casi nada de la solucion provista(DIP)

      «In a clean system we organize our classes so as to reduce the risk of change» Robert. C. Martin – Clean Code

      Muchas veces debemos realizar cambios, esperados o no en nuestras implementaciones. Necesitamos en todos los casos tener entornos de testing, staging y finalmente produccion. Si lo se a veces «no hay tiempo» para probar las cambios pero en que caemos entonces? Por temas de tiempo no realizaremos testing a nuestro codigo ? dejaremos de respetar los Design Patterns que hacen que nuestra solucion sea robusta, escalable y facil de mantener?.

      Otro punto que me llama la atencion en la situacion presentada, la cual no justifica para nada el resultado, es que al parecer no se tenia documentacion del uso del producto en lo mas minimo o quizas se busco la mano de obra mas economica lo que muchos de los clientes suelen preferir. Se que documentar nuestras aplicaciones es tedioso, a veces aburrido, pero a pesar de todo trae beneficios a largo plazo. Si el «mecanico» a cargo del trabajo tenia la documentacion pudo encontrar alli el tema del cable que iba conectado al motor, quien pudo diseñar un producto de esta manera, y asi evitar el quedar tan mal realizando una tarea supuestamente sencilla que termino en que el automovil no encienda mas.
      Un cambio en la aplicacion no deberia bajo ninguna razon «crashear» la aplicacion, quiza desde mi punto de vista afectar al modulo mas cercano a donde se realize el cambio directamente, esto nos quita la reputación que cuesta mucho crear la cual debemos cuidar y valorar a veces inclusive mas que la cantidad de dinero que podamos ganar por realizar un trabajo.

    • #19386

      Raul Aillon para servirles.

Mostrando 1 respuesta al debate