La decisione di progettazione o programmazione più spiacevole che hai preso? [chiuso]

Mi piacerebbe sapere che tipo di decisioni progettuali hai preso e in che modo si sono ritorti contro. A causa di una cattiva decisione di progettazione, ho finito per dover sostenere per sempre quella cattiva decisione (ne ho avuto anche una parte). Questo mi ha fatto capire che un singolo errore di design può perseguitarti per sempre. Voglio imparare dalle persone più esperte che tipo di errori hanno vissuto e cosa hanno imparato da loro.

Sono sicuro che questo sarà di grande aiuto per gli altri programmatori aiutandoli a non ripetere quelle decisioni.

Grazie per aver condiviso la tua esperienza.

Ignorando YAGNI , ancora e ancora ...

"Lo farò più tardi"
"Più tardi" non arriva mai.

C ++, eredità virtuale multipla a forma di diamante . Ti viene l'idea.

La configurabilità in un'applicazione è buona. Troppa configurabilità è un incubo da usare e da mantenere.

Da uno dei miei errori ho imparato che la normalizzazione del DB non dovrebbe essere seguita alla cieca. Puoi, e in alcune situazioni DEVI appiattire i tuoi tavoli.

Ho finito per gestire un sacco di tabelle (tramite modelli) e le prestazioni non erano buone come potrebbero essere con un piccolo appiattimento per le tabelle.

Utilizzo di un singolo carattere nei database per gli stati, ecc. Inutile in questo, l'overhead dell'uso di un carattere più lungo () o nvarchar2 () è minuscolo rispetto alla rete e all'analisi sostenuta da qualsiasi chiamata SQL, tuttavia i caratteri terminano sempre piuttosto offuscato, o esaurito (non per gli stati, ma altre cose). Molto meglio inserire semplicemente la versione leggibile dall'uomo e avere anche nel tuo modello Java (nel mio caso) un enum con valori corrispondenti.

Immagino che questa sia una forma di ottimizzazione prematura inutile e cieca. Come se l'uso di un solo carattere salverà il mondo in questi giorni. A parte Y / N booleani nei database che non supportano booleani / bit.

Non sviluppare un adeguato livello di accesso ai dati e avere sql ovunque nel mio codice, solo per avere qualcosa di "rapido" attivo e funzionante. Successivamente, quando il progetto ha iniziato ad espandersi e le esigenze sono cambiate, è diventato un incubo. Non sapevo cosa fosse un DAL in quel momento.

... felice di averlo superato, anche se vedo ancora programmatori con oltre 20 anni di "esperienza" nel fare questo.

Pensando che potrei essere architetto, sviluppatore e PM tutti sullo stesso progetto.

2 mesi di sonno 3 ore a notte mi hanno insegnato che non puoi farlo.

Scelta Microsoft Foundation Classes (MFC) per la scrittura di un IDE Java.

Non è stata una mia decisione (sono entrato in azienda un po 'più tardi), ma un posto in cui ho lavorato ha portato i18n un po' troppo lontano, inclusa la traduzione di tutti i loro messaggi di registro.

risultati:

• Più doloroso per aggiungere una nuova registrazione
• Più costi per la traduzione
• I registri sono più difficili da leggere in seguito

Ops.

Reinventare la ruota

Fare troppo design . Creare molti diagrammi UML, in particolare i diagrammi di sequenza per ogni singola operazione, molti dei quali alla fine si sono rivelati inutili. Alla fine si è scoperto che una notevole quantità di tempo avrebbe potuto risparmiare saltando progetti / diagrammi inutilmente dettagliati e avviando direttamente la codifica.

I clienti credenti sanno cosa vogliono e poi fanno troppo prima di verificare con loro.

La mia unica peggiore decisione di design? Negli anni '80 stavo lavorando a un progetto in cui avevamo avuto la brillante idea di creare una sorta di modello per le nostre schermate di immissione dei dati che sarebbe stato interpretato in fase di esecuzione. Non è una cattiva decisione: ha reso le schermate di input facili da progettare. Fondamentalmente basta creare un file simile alla schermata di immissione dei dati, con alcuni codici speciali per identificare ciò che era un'etichetta rispetto a quello che era un campo di input e per identificare se i campi di input erano alfa o numerici. Quindi ho deciso di aggiungere altri codici speciali a questi file per identificare quali validazioni dovrebbero essere eseguite. Quindi ho aggiunto più codici per consentire la costruzione condizionale dello schermo, il campo X incluso solo quando alcune condizioni erano vere, ecc. Poi ho aggiunto più codici per eseguire una semplice elaborazione degli input. Ecc. Ecc. Alla fine avevamo trasformato il nostro modello di schermo in un nuovo linguaggio di programmazione, completo di espressioni, strutture di controllo e una libreria di I / O. E per cosa? Abbiamo lavorato moltissimo per reinventare FORTRAN. Avevamo uno scaffale pieno di compilatori per linguaggi progettati e testati meglio. Se avessimo dedicato così tanti sforzi alla costruzione di prodotti in cui avevamo effettivamente una certa esperienza, quella società potrebbe essere ancora attiva oggi.

Applicazione troppo zelante di YAGNI (che è chiamato Design by Enumeration in Pitfalls of Object Oriented Development ) in un ambiente in cui qualsiasi persona sensibile potrebbe dire che i requisiti sarebbero sicuramente cambiati. E cambia ripetutamente.

Se hai (hard-) codificato tutto esattamente secondo i requisiti attuali, mentre picchia qualcuno che dice "non potrebbe essere più generico?" con la tua mazza YAGNI — e quindi i requisiti cambiano drasticamente (ma in un modo che avrebbe potuto essere ragionevolmente anticipato), allora quella può essere la differenza tra prendere 2 settimane per adattarsi, piuttosto che prendere 20 minuti.

AGGIORNAMENTO: per chiarire, ecco un esempio fittizio che non è troppo lontano da quello che è successo. Stack Overflow è stato progettato per supportare i badge, ma supponiamo che all'inizio possano pensare solo a quattro badge. Solo quattro, un numero così piccolo, quindi hanno codificato il supporto per esattamente quattro badge in tutta la logica del sito. Nel database, nelle informazioni utente, in tutto il codice visualizzato. Perché "Non avrai bisogno di" alcun badge a cui non riesci a pensare, giusto? Supponiamo quindi che il sito diventi attivo e che le persone inizino a suggerire nuovi badge. Ogni badgeci vogliono fino a due settimane per aggiungere, perché c'è così tanto hardcoding da modificare ovunque. Tuttavia, "Non avrai bisogno di" più badge rispetto all'elenco di oggi, quindi non c'è mai alcun refactoring per supportare una collezione generica di badge. Una collezione così generica avrebbe impiegato più tempo in anticipo? Non molto, se presente.

YAGNI è un principio prezioso, ma non dovrebbe essere (ab) usato per giustificare un design scadente e un hardcoding inappropriato. C'è un equilibrio e, con l'esperienza, credo di avvicinarmi.

Risorse umane incompetenti

Cercare di fare qualcosa di giusto e di bello con le persone sbagliate!
Anche se sono nel ruolo di un ego PM superfluo (che è piuttosto troppo comune soprattutto nelle grandi aziende in cui la loro incompetenza può durare più a lungo).

Ogni volta che creo debiti tecnici, scrivo codice procedurale, salto test di scrittura, ecc. Perché mi precipito. Quasi inevitabilmente trovo che questo crei dolore per me lungo la strada.

Utilizzo di SQL Server Intergration Services (SSIS).

Non lo desidero sul mio peggior nemico.

Dopo aver creato diversi pacchetti SSIS negli ultimi due mesi, ho scoperto solo che i pacchetti che ho sviluppato non sono distribuibili e non implementabili. In particolare in un ambiente con licenza non web, non SQL Server.

È una brutta situazione, quando hai meno di 48 ore per riscrivere i tuoi pacchetti SSIS in puro codice POCO .NET o perdere la scadenza prefissata.

Mi stupisce che sono stato in grado di riscrivere tre pacchetti SSIS (che mi hanno impiegato due mesi per testare e sviluppare), entro 12 ore in puro codice .NET, con adattatori OLEDB e adattatori SQL.

SSIS non è distribuibile e non eseguirà i pacchetti da un computer client se non è installata una licenza di SQL Server (in particolare DTSPipeline.dll). Sarebbe bello saperlo in anticipo. Ora vedo la dichiarazione di non responsabilità (in stampa fine) su MSDN. Ciò non è utile quando si dispone di un codice di esempio su Internet utilizzando solo codice macchina con licenza SQL. Fondamentalmente, devi creare un servizio web che parlerà con il tuo server SQL, per eseguire i tuoi pacchetti SSIS a livello di codice. Non è possibile eseguirli dal codice .NET puro, a meno che non si disponga di una licenza SQL installata sulla macchina in esecuzione. Quanto è irrealistico? Microsoft prevede davvero che SSIS verrà utilizzato da macchine che richiedono l'installazione del server SQL? Che spreco completo di due mesi.

La mia azienda non utilizzerà mai più SSIS a causa di questo piccolo "gotcha".

Non definire il meccanismo / modello di distribuzione il più presto possibile.

Aggiungendo alcune "divertenti" uova di Pasqua in un codice che ho scritto prima di andare in vacanza per 2 settimane. Pensavo di essere l'unica persona a leggerlo al mio ritorno, mi avrebbe fatto ridere e pronto a ricodificarlo.

Inutile dire che il mio capo non è stato impressionato quando lo ha recensito mentre ero via, e lo è stato ancora meno quando uno delle "uova di Pasqua" ha coinvolto la sua faccia stranamente animata in ASCII.

Mmmmmm ...

Usare i temi ASP.Net quando solo una normale cartella CSS precedente avrebbe funzionato bene.

Prendere la strada veloce per far funzionare un po 'di codice, piuttosto che la strada giusta (un po' generale, ma lo chiameremo un'astrazione e quindi una risposta "giusta").

La mia azienda ha un modello di sviluppo a cascata, in cui i nostri utenti e analisti aziendali definiranno i requisiti per i progetti. Su uno dei nostri "grandi" progetti, abbiamo ottenuto una serie di requisiti e ho notato che una serie di requisiti conteneva dettagli di implementazione , in particolare informazioni relative al nostro schema di database utilizzato dal nostro sistema di contabilità.

Ho commentato agli utenti aziendali che l'implementazione è il mio dominio, non dovrebbe essere contenuto nei requisiti. Non erano disposti a cambiare i loro requisiti perché, dopo tutto, sono IL BUSINESS, e ha senso solo per i contabili progettare software di contabilità. Come umile sviluppatore che è troppo in fondo al sondaggio totem, sono pagato per fare invece di pensare . Per quanto l'ho combattuto, non sono riuscito a convincerli a riscrivere i requisiti: ci sono troppe scartoffie e burocrazia per i cambiamenti che è solo una seccatura.

Quindi, ho dato loro quello che chiedevano. Per lo meno, funziona in qualche modo , ma il database è progettato in modo strano:

• Molta normalizzazione non necessaria. Un singolo record contenente 5 o 10 campi è suddiviso in 3 o 4 tabelle. Posso occuparmene, ma personalmente vorrei che tutti i campi 1: 1 fossero raccolti in un unico tavolo.

• Un sacco di denormalizzazione inappropriata. Abbiamo una tabella che memorizza i dati di fatturazione che memorizzano più dei dati di fatturazione. Archiviamo un numero di flag vari nella tabella InvoiceData, anche se il flag non è logicamente correlato alla tabella InvoiceData, in modo tale che ogni flag abbia un valore di chiave primaria codificata e tutti gli altri campi annullati nella tabella InvoiceData. Dato che la bandiera è rappresentata come un record nella tabella, ho suggerito di estrarre la bandiera nella sua tabella.

• Denormalizzazione molto più inappropriata. Alcuni flag a livello di app vengono archiviati come colonne in tabelle non appropriate, per cui la modifica del flag di un'app richiede l'aggiornamento di ogni record nella tabella.

• Le chiavi primarie contengono metadati, in modo tale che se una chiave primaria varchar termina con "D", calcoliamo le fatture utilizzando un set di valori, altrimenti lo calcoliamo con un altro set. Avrebbe più senso estrarre questi metadati in una colonna separata, oppure estrarre l'insieme di valori per calcolare in un'altra tabella.

• Le chiavi esterne vanno spesso a più di una tabella, in modo tale che una chiave esterna che termina con "M" potrebbe essere collegata alla nostra tabella dei conti dei mutui, mentre una chiave esterna che termina con "A" potrebbe essere collegata alla nostra tabella dei conti automatici. Sarebbe più semplice dividere i dati in due tabelle, MortageData e AutoInsuranceData.

Tutti i miei suggerimenti sono stati abbattuti con molto lamento e digrignamento dei denti. L'app funziona come progettato e, sebbene sia una grande palla di fango, tutti gli hack brutte, i casi speciali e le strane regole aziendali sono documentati sarcasticamente e umoristicamente nel codice sorgente.

Attenersi alla tecnologia precedente perché sembra troppo complicato consentire ai client di eseguire l'aggiornamento a una nuova versione di .NET framework, ma in realtà ci vorrà più tempo di sviluppo per creare il software perché non è possibile utilizzare alcuni componenti (che fanno risparmiare tempo) del nuova versione del framework.

All'università stavo lavorando al mio progetto di design senior. Un altro ragazzo e io stavamo scrivendo un sistema di tracciamento dei bug basato sul web. (Niente di rivoluzionario, ma entrambi volevamo avere qualche esperienza sul web.) Abbiamo fatto la cosa con i servlet Java, e ha funzionato abbastanza bene, ma per qualche ragione sciocca, invece di optare per usare Exceptions come nostro meccanismo di gestione degli errori, abbiamo scelto per usare i codici di errore.

Quando abbiamo presentato il nostro progetto per un voto e uno dei docenti ha chiesto l'inevitabile: "Se dovessi rifarlo, cosa faresti diversamente?" Ho subito capito la risposta: "Userei le eccezioni, ecco a cosa servono."

Non è la mia scelta del metodo, ma ho creato un XSLT per convertire un file XML basato su riga in un report HTML basato su colonna.

Funzionava solo in IE, era assolutamente impossibile decodificare come funzionava. Ogni volta che dovevamo espanderlo, era incredibilmente difficile e richiedeva anni.

Alla fine, ho sostituito con un piccolo script C # che ha fatto la stessa cosa.

cercando di usare tutte le nuove tecnologie (per apprendere nuove tecnologie) anche se ciò richiede anche ..

Non ho impiegato abbastanza tempo per valutare il modello di business. Ho fatto ciò che il cliente ha chiesto, ma 6-12 mesi dopo siamo arrivati ​​entrambi alla conclusione che avrebbe dovuto fare diversamente.

Progettare senza una specifica.

Ho implementato una sottosezione di un'applicazione in base ai requisiti.

Si scopre che i requisiti erano gonfiati e placcati in oro e il mio codice era stato riprogettato. Avrei dovuto progettare la mia sottosezione in modo che funzionasse solo con ciò che stavo aggiungendo in quel momento, ma avrei pianificato di aggiungere tutte le altre cose senza includere il supporto generico sin dall'inizio.