Come affrontare decisioni di progettazione terribili [duplicato]

Dalle mie esperienze

Direi di essere stato un appaltatore da molto tempo anch'io, più di 20 anni, in genere quando sei un appaltatore, non sei lì per influenzare il cambiamento, sei lì per essere un corpo caldo che riempie un posto e fai ciò che viene detto, a meno che il tuo manager non specifichi qualcosa di specifico.

Non investi

Se non vedono l'errore enorme , allora non preoccuparti. Fai alcuni commenti in i tuoi contributi al codice su come ciò sia cattivo e necessiti di essere refactored per supportare effettivamente l'unione con quei valori in un periodo di tempo ragionevole, e poi dimenticarti di ciò. Potrebbe anche finire su thedailywtf.com e renderti famoso in modo anonimo!

Inizia a pensare a come assicurarti che la tua prossima posizione di contratto sarà molto migliore di quella attuale! Ora hai un'esperienza che ti aiuta a valutare il prossimo gruppo di persone con cui lavorerai la prossima volta che intervisti, per rilevare questo tipo di personalità in futuro.

Non solo vuoi essere consapevole della personalità negativa dell'appaltatore, ma anche della personalità negativa del tuo manager. Se sta per "esplodere" con qualcuno che sta cercando di farlo apparire migliore ed evitare problemi, devi imparare come individuare persone come lui in futuro, così puoi anche evitarli.

Non dovresti esserti scusato

Ora l'altro appaltatore si sentirà giustificato nella sua convinzione che sia corretto, il che non è corretto.

Qualsiasi base libro di teoria del database relazionale abbatterà questa ingenua soluzione errata nel secondo capitolo, se non prima. I campi a più valori sono un chiaro segnale che qualcuno non comprende cosa sono facendo, non valgono la pena di discutere con te.

Se vuoi veramente fare qualcosa per farti sentire meglio

Documenta la tua conversazione con questa persona, perché è così sbagliato, quali problemi causerà e la tua soluzione proposta. Dare questo al dipendente stipendiato e al tuo manager. Non proporre di modificarlo in questo momento se hai una scadenza, ma rendi molto chiaro che non è in scala e renderà sicuramente il tuo manager un brutto aspetto nel prossimo futuro. In questo modo, quando sei andato avanti, puoi stare tranquillo nel fatto che almeno li hai avvisati del disastro che sta per accadere.

La soluzione migliore è sviluppare un alleato nello sviluppatore a tempo pieno. Parlagli dei difetti del design e vedi se è d'accordo. Se riesci a fargli vedere i problemi inerenti al progetto attuale, potresti essere in grado di convincerlo a seguire i tuoi metodi nel prossimo progetto.

Questo è un modo per influenzare la situazione senza causare gravi danni collaterali.

spero che questo aiuti!

Prima di tutto, probabilmente non avresti dovuto scusarti - lo fa solo sentire "più retto". La critica è una parte essenziale di qualsiasi progetto (a tutti, non solo la codifica). In secondo luogo, potresti buttare giù un caso di test rapido per dimostrare quanto sia più veloce il modo corretto di unire i tavoli e chiedergli come, usando le sue liste virgola, potresti scegliere le auto fornite con l'iPod?

Quando ero un consulente la mia regola era che, quando non ero d'accordo con una decisione tecnica, avrei detto loro perché (con argomenti di supporto) esattamente UNA VOLTA se non volevano accettare il mio suggerimento, nessun grosso problema, non lo manterrò.

Questo è un mio piccolo dubbio ..... Mettendo da parte la correttezza della decisione, è stata presa una decisione che non ti piace - ognuno di noi affronterà 100 di questi nella nostra carriera. Sembri rifiutare di accettarlo e andare dietro la schiena della gente, giocando a giochi stupidi per cambiarlo. Questo comportamento indebolirà i rapporti di lavoro non solo tra te e l'altra parte, ma, mentre costringi le persone a prendere posizione in una guerra ineluttabile, tutte le altre relazioni in ufficio. Il tuo comportamento è immaturo e distruttivo. Il tuo lavoro, (quello che sei pagato per fare), è quello di garantire il successo del progetto. Distruggere le relazioni di squadra lo farà 1000 volte più velocemente di una cattiva decisione progettuale.

Quindi come si comporta un consulente maturo. Presentano una discussione sul motivo per cui il design scelto è inferiore e suggeriscono l'alternativa migliore. Dopo una discussione razionale, viene presa una decisione definitiva e impegnata da tutti . Un consulente professionista, per il modo in cui lavorano, ha prove documentate su tutto questo, nel caso in cui .....

Quindi quali sono le tue scelte: a) Crescere ed essere professionale a riguardo, b) essere licenziato o c) dimettersi. Se non puoi fare a), ti preghiamo di fare c) prima di distruggere il progetto.

Per prima cosa hai ragione, questo è un design molto povero. Non chiedere mai scusa per disaccordo professionale, scusarsi solo per il cattivo comportamento da parte tua (urlando nomi di chiamata, ecc.) Non per disaccordi professionali. Ti deve delle scuse per il suo comportamento di non essere disposto ad accettare una differenza professionale di opinioni.

Ora, se qualcuno mi ha detto questo, è come avrei presentato la mia argomentazione a lui se non fosse stato inizialmente convinto. Avvia una tabella di test veloce con 10.000.000 di record con un ID in una colonna e un elenco numerato delimitato da virgola in un'altra e una seconda tabella di ricerca a cui i numeri si riferiscono con un ID e una descrizione. Quindi creare la corretta struttura normalizzata. Ora fai la stessa cosa con un design relazionale corretto. Non dimenticare di creare indici appropriati. Ora scrivi il codice per trovare tutti gli id nella tabella 1 che hanno un valore di test3 (che equivale a 3 nell'elenco delimitato, ma devi fare il join alla tabella di ricerca per sapere che) con la struttura mal progettata. Scrivi il codice usando la struttura normalizzata. Confronta il codice, il tempo impiegato per scrivere il codice e il tempo necessario per eseguire il codice. Entrambi sappiamo che sarà più breve e impiegherò meno tempo a scrivere e ad esibire meglio. Mostra i risultati al PM e dimostra che il cattivo design sta causando uno sviluppo più lento del progetto e peggiorerà quando verrà implementato. Se questo non lo convincerà, allora non sarà nulla e dovrai trovare un contratto migliore APPENA POSSIBILE perché questo progetto ha una probabilità del 0% di successo.

Un pensiero - nel caso in cui questa situazione si deteriori, tieni un file da qualche parte elencando le cose che pensi che stia sbagliando. Probabilmente non avrai mai bisogno di usarlo, ma potrebbe diventare importante se questo si intensifica.

Assicurati che non possa trovarlo!

Sembra che tu sia bloccato tra una pietra e un luogo duro. Stai ovviamente cercando di fare la cosa giusta ma i tuoi collaboratori non sono d'accordo con te. Le tue due opzioni da quello che hai detto sono pienamente note su come hai cercato di farlo bene e di tenere la bocca chiusa o cercare un nuovo lavoro. Le persone in luoghi elevati prendono decisioni sbagliate che devono essere affrontate a volte.

Se il design è pessimo e sei entrambi consulenti, devi portarlo all'attenzione dei clienti e esprimere la tua preoccupazione che questo potrebbe finire per essere un software che è costoso da mantenere.

Quindi spetta al cliente decidere dove vuole mettere i propri soldi. Se vanno con il cattivo design, beh, almeno glielo hai detto, e quindi è un tuo dovere professionale fare il miglior lavoro che puoi in queste circostanze.

TBH il suo design non è eccezionale ma in realtà non è così male. Normalizzare tutto può portare a una pletora di tavoli che diventano difficili da tenere traccia di. La serializzazione degli attributi in una stringa semplifica il salvataggio e il caricamento degli oggetti. Vedete un tipo di cosa simile in cui gli oggetti vengono serializzati su xml e memorizzati in una colonna blob.

Il vero problema è come ti occupi delle differenze, devi superarla. Non ti piace come ha fatto qualcosa, sfortuna. Sembra che tu sia il ragazzo più giovane della squadra. In 10 anni, quando sei il capo, puoi passare attraverso la tua soluzione anche quando altri non ti piacciono.

Fino ad allora, hai il minimo potere e influenza. Passa il tuo tempo a preoccuparti di qualcosa di più importante, ad esempio come ottenere un aumento o un lavoro da qualche altra parte.

La sua soluzione è ovviamente una cattiva scelta di design. È ovvio anche per me, che non ha quasi mai lavorato con un database. Posso vedere immediatamente le restrizioni imposte da questa soluzione e non riesco a vedere alcun valore aggiunto.

Non capisco perché non puoi convincerlo con semplici prove. Come ho detto, non sono presente nei database, ma di recente ho avuto una situazione simile alla tua, con un collega che doveva progettare un database. Sono stato in grado di dirgli i pro ei contro di entrambe le soluzioni e convincerlo che nella nostra situazione, una soluzione era migliore.

È davvero un problema di comunicazione, qui. O hai litigato con lui in modo tale da sentirsi attaccato, oppure è molto testardo e non è in grado di ricevere critiche.

Devi avere qualcuno a cui ti riferisci direttamente. È ora di aumentarlo e vedere come vuole procedere. Se non lavori per un'azienda che è seriamente intenzionata a prendere in seria considerazione le problematiche relative al talento degli sviluppatori, vai altrove.

In realtà, potrebbe benissimo avere ragione. Quello che ha fatto è quello che chiamerei "inlining" una relazione.

Immagina di sapere che esiste un limite ragionevole al numero di proprietà che una macchina può avere, puoi sicuramente inserirle come una colonna di ogni riga di auto.

Si suppone che una tabella delle relazioni separata sia nel caso in cui il numero di proprietà non possa essere anticipato.

Come è migliore il suo design, diverse ragioni: - A causa dell'allineamento, la sua lettura sarà massicciamente migliore della tua. (Non dovrà leggere l'indice della tabella delle relazioni) - Quando aggiungi e rimuovi proprietà all'auto, la posizione della riga per una relazione può essere frammentata in tutta la tabella delle relazioni. Di nuovo, influisci sul tempo di lettura se recuperi avidamente le proprietà.