¿La decisión de diseño o programación más lamentable que tomaste? [cerrado]

Me gustaría saber qué tipo de decisiones de diseño tomaste y cómo fueron contraproducentes. Debido a una mala decisión de diseño, terminé teniendo que apoyar esa mala decisión para siempre (también participé en ella). Esto me hizo darme cuenta de que un solo error de diseño puede perseguirlo para siempre. Quiero aprender de las personas más experimentadas qué tipo de errores han experimentado y qué aprendieron de ellos.

Estoy seguro de que esto será de gran ayuda para otros programadores al ayudarlos a no repetir esas decisiones.

Gracias por compartir tu experiencia.

Ignorando a YAGNI , una y otra vez ...

"Lo haré más tarde"
"Más tarde" nunca llega.

C ++, herencia virtual múltiple en forma de diamante . Tienes la idea.

La configurabilidad en una aplicación es agradable. Demasiada configurabilidad es una pesadilla para usar y mantener.

De uno de mis errores, he aprendido que la normalización de DB no debe seguirse a ciegas. Puede, y en algunas situaciones DEBE aplanar sus mesas.

Terminé administrando un montón de tablas (a través de modelos) y el rendimiento no fue tan bueno como podría ser con un pequeño aplanamiento para las tablas.

Usar un único carácter en bases de datos para estados, etc. No tiene sentido en absoluto, la sobrecarga de usar un carácter más largo () o nvarchar2 () es minúsculo en comparación con la red y el análisis incurrido por cualquier llamada SQL, pero los caracteres siempre terminan más bien ofuscado o agotado (no por estados, sino por otras cosas). Mucho mejor simplemente poner la versión legible para humanos y también tener en su modelo Java (en mi caso) una enumeración con valores coincidentes.

Supongo que esta es una forma de optimización prematura innecesaria y ciega. Como si usar un solo personaje salvara al mundo en estos días. Aparte de booleanos Y / N en bases de datos que no admiten booleanos / bits.

No desarrollar una capa de acceso a datos adecuada y tener SQL en todas partes en mi código, solo para obtener algo "rápido" en funcionamiento. Más tarde, cuando el proyecto comenzó a expandirse y los requisitos cambiaron, se convirtió en una pesadilla. No sabía qué era un DAL en ese momento.

... me alegro de haber pasado eso, aunque todavía veo programadores con más de 20 años de "experiencia" haciendo esto.

Pensando que podría ser Arquitecto, Desarrollador y PM, todos en el mismo proyecto.

2 meses de sueño 3 horas por noche me enseñaron que simplemente no puedes hacerlo.

Elegir Microsoft Foundation Classes (MFC) para escribir un IDE de Java.

No fue mi decisión (me uní a la compañía un poco más tarde), pero un lugar en el que trabajé fue demasiado lejos, incluyendo la traducción de todos sus mensajes de registro.

Resultados:

• Más doloroso agregar nuevos registros
• Más costo por traducción
• Los registros son más difíciles de leer después

Ups

Reinventando la rueda

Haciendo demasiado diseño . Crear muchos diagramas UML, particularmente diagramas de secuencia para cada operación, muchos de los cuales al final resultaron inútiles. Al final resultó que una cantidad significativa de tiempo podría haberse ahorrado al saltarse diseños / diagramas innecesariamente detallados e iniciar la codificación directamente.

Los clientes creyentes saben lo que quieren y luego hacen demasiado antes de consultar con ellos.

¿Mi peor decisión de diseño? En la década de 1980 estaba trabajando en un proyecto donde se nos ocurrió la brillante idea de crear una especie de plantilla para nuestras pantallas de entrada de datos que se interpretaría en tiempo de ejecución. No es una mala decisión: hizo que las pantallas de entrada fueran fáciles de diseñar. Básicamente, simplemente cree un archivo que se parezca a la pantalla de entrada de datos, con algunos códigos especiales para identificar qué era una etiqueta frente a qué era un campo de entrada, e identificar si los campos de entrada eran alfa o numéricos. Luego decidí agregar algunos códigos especiales más a estos archivos para identificar qué validaciones deberían realizarse. Luego agregué más códigos para permitir la construcción condicional de la pantalla, el campo X solo se incluyó cuando alguna condición era verdadera, etc. Luego agregué más códigos para hacer un procesamiento simple de las entradas. Etcétera etcétera. Finalmente, convertimos nuestra plantilla de pantalla en un nuevo lenguaje de programación, completo con expresiones, estructuras de control y una biblioteca de E / S. ¿Y para qué? Hicimos un montón de trabajo para reinventar FORTRAN. Teníamos un estante lleno de compiladores para idiomas que estaban mejor diseñados y mejor probados. Si hubiéramos dedicado tanto esfuerzo a construir productos en los que realmente teníamos algo de experiencia, esa compañía aún podría estar en el negocio hoy.

Aplicación demasiado entusiasta de YAGNI (que se denomina Diseño por enumeración en trampas del desarrollo orientado a objetos ) en un entorno donde cualquier persona sensata podría decir que los requisitos definitivamente iban a cambiar. Y cambia repetidamente.

Si ha codificado todo exactamente con los requisitos actuales, mientras golpea a cualquiera que diga "¿no podría ser esto más genérico?" con su mazo YAGNI, y luego los requisitos cambian drásticamente (pero de una manera que podría haberse anticipado razonablemente), entonces esa puede ser la diferencia entre tomar 2 semanas para adaptarse, o tomar 20 minutos.

ACTUALIZACIÓN: Para aclarar, aquí hay un ejemplo ficticio que no está muy lejos de lo que sucedió. Stack Overflow fue diseñado para admitir insignias, pero supongamos que al principio solo puedan pensar en cuatro insignias. Solo cuatro, un número tan pequeño, por lo que codificaron el soporte para exactamente cuatro insignias en toda la lógica del sitio. En la base de datos, en la información del usuario, en todo el código de visualización. Porque "Ya no necesitarás" ninguna insignia en la que no puedas pensar, ¿verdad? Supongamos que el sitio se activa y la gente comienza a sugerir nuevas insignias. Cada insigniatoma hasta dos semanas para agregar, porque hay mucho hardcoding para ajustar por todas partes. Pero aún así, "Ya no necesitarás" más insignias que la lista de hoy, por lo que nunca hay una refactorización para admitir una colección genérica de insignias. ¿Una colección tan genérica hubiera tomado más tiempo por adelantado? No mucho, si alguno.

YAGNI es un principio valioso, pero no debe (ab) usarse para excusar un diseño deficiente y una codificación inadecuada. Hay un equilibrio, y con experiencia, creo que me estoy acercando.

Recursos humanos incompetentes

¡Intentando hacer algo correcto y grandioso con las personas equivocadas!
Incluso si están en el papel de un ego superfluo PM (que es bastante común, especialmente en grandes empresas donde su incompetencia puede durar más tiempo).

Cada vez que creo una deuda técnica, escribo un código de procedimiento, me salteo las pruebas de escritura, etc. porque me estoy apurando. Casi inevitablemente encuentro que esto me causa dolor en el camino.

Uso de los servicios de integración de SQL Server (SSIS).

No se lo deseo a mi peor enemigo.

Después de construir varios paquetes de SSIS en los últimos dos meses, solo para descubrir que los paquetes que desarrollé no son distribuibles y no se pueden implementar. Específicamente en un entorno no web, sin licencia de SQL Server.

Es una situación muy mala, cuando tiene menos de 48 horas para volver a escribir sus paquetes SSIS en código puro .NET POCO o perder su fecha límite específica.

Me sorprende que pude reescribir tres paquetes SSIS (que me tomó dos meses probar y desarrollar), en 12 horas en código puro .NET, con adaptadores OLEDB y adaptadores SQL.

SSIS no es distribuible y no ejecutará paquetes desde una máquina cliente si no tiene instalada una licencia de SQL Server (específicamente DTSPipeline.dll). Sería genial saberlo por adelantado. Veo el descargo de responsabilidad ahora (en letra pequeña) en MSDN. Eso no sirve de nada cuando tiene un código de ejemplo en Internet utilizando un código de máquina con licencia SQL solamente. Básicamente, debe crear un servicio web que hable con su servidor SQL para ejecutar sus paquetes SSIS mediante programación. No puede ejecutarlos desde código .NET puro, a menos que tenga una licencia SQL instalada en la máquina ejecutora. ¿Qué tan poco realista es eso? ¿Microsoft realmente espera que se use SSIS desde máquinas que requieren la instalación del servidor SQL? Qué desperdicio completo de dos meses.

Mi empresa nunca volverá a utilizar SSIS debido a esta pequeña "gotcha".

No definir el mecanismo / modelo de implementación lo antes posible.

Agregue algunos huevos de pascua 'divertidos' en un código que escribí antes de irme de vacaciones por 2 semanas. Pensé que sería la única persona que lo leería cuando volviera, me haría reír y estar listo para volver a codificarlo.

Huelga decir que mi jefe no estaba impresionado cuando lo revisó mientras yo estaba fuera, y estaba aún menos impresionado cuando uno de los 'huevos de pascua' estaba involucrando su cara graciosamente dibujada en ASCII.

Mmmmmm ...

Usar ASP.Net Themes cuando solo una carpeta CSS normal hubiera funcionado bien.

Tomar el camino rápido para que funcione el código, en lugar del camino correcto (poco general, pero lo llamaremos una abstracción y, por lo tanto, una respuesta "correcta").

Mi empresa tiene un modelo de desarrollo similar a una cascada, donde nuestros usuarios comerciales y analistas comerciales definirán los requisitos para los proyectos. En uno de nuestros proyectos "grandes", obtuvimos una gran cantidad de requisitos, y noté que varios requisitos contenían detalles de implementación , específicamente información relacionada con nuestro esquema de base de datos utilizado por nuestro sistema de contabilidad.

Comenté a los usuarios comerciales que la implementación es mi dominio, no debería estar incluida en los requisitos. No estaban dispuestos a cambiar sus requisitos porque, después de todo, son EL NEGOCIO, y solo tiene sentido que los contadores diseñen software de contabilidad. Como desarrollador humilde que está demasiado lejos en la encuesta de tótems, me pagan por hacer en lugar de pensar . Por mucho que luché contra él, no pude persuadirlos para que volvieran a escribir los requisitos: hay demasiado papeleo y burocracia en torno a los cambios que es demasiado complicado.

Entonces, les di lo que pidieron. Por lo menos, funciona , pero la base de datos está extrañamente diseñada:

• Mucha normalización innecesaria. Un único registro que contiene 5 o 10 campos se divide en 3 o 4 tablas. Puedo lidiar con eso, pero personalmente me gustaría tener todos los campos 1: 1 en una sola tabla.

• Mucha desnormalización inapropiada. Tenemos una tabla que almacena los datos de la factura que almacena más que los datos de la factura. Almacenamos una serie de indicadores varios en la tabla InvoiceData, incluso si el indicador no está relacionado lógicamente con la tabla InvoiceData, de modo que cada indicador tiene un valor de clave primaria mágico y codificado y todos los demás campos anulados en la tabla InvoiceData. Dado que la bandera está representada como un registro en la tabla, sugerí colocar la bandera en su propia tabla.

• Mucha más desnormalización inapropiada. Ciertos indicadores de toda la aplicación se almacenan como columnas en tablas inapropiadas, de modo que cambiar el indicador de una aplicación requiere actualizar todos los registros de la tabla.

• Las claves primarias contienen metadatos, de modo que si una clave primaria varchar termina con "D", calculamos las facturas utilizando un conjunto de valores, de lo contrario lo calculamos con otro conjunto. Tendría más sentido extraer estos metadatos en una columna separada, o extraer el conjunto de valores para calcularlos en otra tabla.

• Las claves externas a menudo van a más de una tabla, de modo que una clave externa que termina con "M" podría vincularse a nuestra tabla de cuentas hipotecarias, mientras que una clave externa que termina con "A" podría vincularse a nuestra tabla de cuentas automáticas. Sería más fácil dividir los datos en dos tablas, MortageData y AutoInsuranceData.

Todas mis sugerencias fueron derribadas con muchos gemidos y crujir de dientes. La aplicación funciona tal como está diseñada, y aunque es una gran bola de barro, todos los trucos desagradables, casos especiales y reglas comerciales extrañas están documentados sarcástica y humorísticamente en el código fuente.

Se adhieren a la tecnología anterior porque parece demasiado complicado permitir que sus clientes actualicen a una nueva versión de .NET Framework, pero en realidad tomará más tiempo de desarrollo crear el software porque no puede utilizar algunos componentes (que ahorran tiempo) Versión marco más nueva.

De vuelta en la universidad, estaba trabajando en mi proyecto de diseño senior. Otro tipo y yo estábamos escribiendo un sistema de seguimiento de errores basado en la web. (Nada innovador, pero los dos queríamos tener algo de experiencia web). Hicimos lo mismo con los servlets de Java, y funcionó razonablemente bien, pero por alguna razón tonta, en lugar de optar por usar Excepciones como nuestro mecanismo de manejo de errores, elegimos para usar códigos de error.

Cuando presentamos nuestro proyecto para una calificación y uno de los profesores preguntó lo inevitable: "Si tuvieras que hacerlo de nuevo, ¿qué harías de manera diferente?" Al instante supe la respuesta: "Usaría excepciones, para eso están ahí".

No es mi elección de método, pero creé un XSLT para convertir un archivo XML basado en filas en un informe HTML basado en columnas.

Solo funcionaba en IE, era completamente imposible decodificar cómo funcionaba. Cada vez que necesitábamos expandirlo, era increíblemente difícil y tomó años.

Al final, lo reemplacé por un pequeño script de C # que hizo lo mismo.

tratando de usar todas las nuevas tecnologías (para aprender nuevas tecnologías) a pesar de que ni siquiera se requiere ...

No tomé suficiente tiempo para evaluar el modelo de negocio. Hice lo que me pidió el cliente, pero entre 6 y 12 meses después, ambos llegamos a la conclusión de que debería haber sido diferente.

Diseño sin especificación.

Implementé una subsección de una aplicación de acuerdo con los requisitos.

Resulta que los requisitos estaban hinchados y chapados en oro, y mi código estaba sobrediseñado. Debería haber diseñado mi subsección para que solo funcione con lo que estaba agregando en ese momento, pero planifique agregar todas las demás cosas sin incluir soporte genérico para ello desde el principio.