¿Existen "deudas técnicas" específicas que no valen la pena?

Question

Hay (al menos) dos formas en que las deudas técnicas se abren paso en los proyectos. El primero es por decisión consciente. Algunos problemas simplemente no valen abordarse por adelantado, por lo que conscientemente se les permite acumularlos como deuda técnica. El segundo es por ignorancia. Las personas que trabajan en el proyecto no saben o no se dan cuenta de que están incurriendo en una deuda técnica. Esta pregunta trata del segundo. ¿Hay deudas técnicas que dejaste entrar en tu proyecto que hubieran sido triviales evitar ("Si lo hubiera sabido ...") pero una vez que se integraron en el proyecto, se volvieron dramáticamente más costosas?

Answer 1

No iniciar un proyecto web sin utilizar un marco de JavaScript y aplicar cosas que ya estaban disponibles. El mantenimiento de la javascript escrita a mano se convirtió en un dolor tan grande que terminé arrancando todo y rehaciéndolo con el marco.

Answer 2

Un ejemplo de esto es ejecutar una base de datos en un modo que no admite Unicode. Funciona justo hasta el momento en que se ve obligado a admitir cadenas Unicode en su base de datos. La ruta de migración no es trivial, dependiendo de su base de datos.

Por ejemplo, SQL Server tiene una longitud de fila máxima fija en bytes, por lo que cuando convierte sus columnas a cadenas Unicode (NCHAR, NVARCHAR, etc.) puede que no haya suficiente espacio en la tabla para contener los datos que usted ya tengo. Ahora, su código de migración debe tomar una decisión sobre el truncamiento o debe cambiar el diseño de la tabla por completo. De cualquier manera, es mucho más trabajo que simplemente comenzar con todas las cadenas Unicode.

Answer 3

No tener un diseño cohesivo en la parte delantera tiende a conducir a ella. Puede superarlo hasta cierto punto si se toma el tiempo de refactorizar con frecuencia, pero la mayoría de la gente sigue criticando un diseño general que no coincide con sus requisitos cambiantes. Esta puede ser una respuesta más general que lo que está buscando, pero tiende a ser una de las causas más populares de la deuda técnica.

Answer 4

En una empresa anterior usaron y forzaron COM para cosas para las que no era necesario.

Otra compañía con una base de código C++ no permitió STL. (¿WTF ?!)

Otro proyecto en el que estaba conectado utilizaba MFC solo para las colecciones: no había UI involucradas. Eso fue malo.

Las ramificaciones, por supuesto, para esas decisiones no fueron grandes. En dos casos, tuvimos dependencias de lamentables tecnologías de MS sin ninguna razón y el otro obligó a las personas a utilizar peores implementaciones de genéricos y colecciones.

Los califico como "deuda" ya que tuvimos que tomar decisiones y hacer concesiones más adelante en los proyectos debido a las decisiones idiotas de la delantera. La mayoría de las veces tuvimos que solucionar las deficiencias.

Answer 5

Aunque no todos pueden estar de acuerdo, creo que el mayor contribuyente a la deuda técnica está comenzando desde la interfaz de cualquier tipo de aplicación y trabajando en la pila. He aprendido que hay menos posibilidades de desviarse de los objetivos del proyecto mediante la implementación de una combinación de TDD y DDD, porque aún puede desarrollar y probar la funcionalidad principal con la interfaz convirtiéndose en la guinda.

De acuerdo, no es una deuda técnica en sí misma, pero he descubierto que el desarrollo descendente es más bien una puerta abierta que invita a decisiones que no están bien pensadas, todo por el bien de hacer algo el "se ve genial". Además, entiendo que no todos estarán de acuerdo o sienten lo mismo al respecto, por lo que su millaje puede variar en este caso. La dinámica y las habilidades del equipo también forman parte de esta ecuación.

Answer 6

Ignorando por completo los problemas de seguridad.

Los scripts de sitios cruzados son un ejemplo. Se considera inofensivo hasta que aparezca alert('hello there!') en la interfaz de administración (si tiene suerte, el script también puede copiar silenciosamente todos los administradores de datos que tienen acceso o servir malware a sus clientes).

Y luego necesita 500 plantillas fijadas ayer. La corrección apresurada hará que los datos se escapen por partida doble y no cubrirá todas las vulnerabilidades.

Answer 7

realmente lucha con éste, tratando de equilibrar YAGNI frente a "Me he quemado en esta vez con demasiada frecuencia"

Mi lista de cosas que comentario para cada aplicación:

1. Localización:
   2. ¿Es la zona horaria alguna vez va a ser importante? En caso afirmativo, mantenga la fecha/hora en UTC.
   3. ¿Los mensajes/texto van a ser traducidos? Si es así, externaliza los mensajes.
2. Platform Independence? Elija una implementación fácilmente portada.

Otras áreas en las que la deuda técnica se puede incurrir, incluyen:

• La recolección de datos Negro-Agujero: Todo lo que entra, nada nunca se apaga. (No hay un plan a largo plazo para archivar/eliminar datos antiguos)
• Falla en mantener MVC o niveles limpiamente separados a lo largo de la vida de la aplicación, por ejemplo, permitiendo que demasiada lógica se filtre en la Vista, haciendo que agregar una interfaz para dispositivos móviles o servicios web mucho más costosos.

Estoy seguro de que habrá otros ...

Answer 8

Almacenamiento de fechas en una base de datos en la zona horaria local. En algún momento, su aplicación se migrará a otra zona horaria y usted tendrá problemas. Si alguna vez termina con fechas mixtas, nunca podrá desenredarlas. Solo guárdelos en UTC.

Answer 9

Escalabilidad: en aplicaciones empresariales controladas por datos. He visto más de una vez donde todo parece funcionar bien, pero cuando el entorno UAT finalmente se pone de pie con tamaños de tabla de base de datos que se acercan a las producciones, entonces las cosas comienzan a caer a la derecha y a la izquierda. Es fácil que se ejecute una pantalla en línea o un programa por lotes cuando el db mantiene básicamente todas las filas en la memoria.

Answer 10

Pruebas unitarias: creo que si no se escriben las pruebas sobre la marcha, se incurre en una ENORME deuda que es difícil de compensar. Aunque soy fanático de TDD, realmente no me importa si escribes tus pruebas antes o después de implementar el código ... siempre y cuando mantengas tus pruebas sincronizadas con tu código.

Answer 11

El cliché es que la optimización prematura es la raíz de todo mal, y esto sin duda es cierto para micro -Optimización. Sin embargo, ignorar por completo el rendimiento a un nivel de diseño en un área donde claramente importará puede ser una mala idea.