Quali sono alcune tecniche che è possibile utilizzare per evitare l'eccessiva ingegnerizzazione tra gli sviluppatori di software? Significa, come fai a tenerli concentrati sulla creazione di soluzioni solo dei requisiti attuali? Senza cercare di anticipare tutti i cambiamenti futuri.
Semplice. Revisione tra pari.
Pensi di poter codificare meglio di me? Portalo! Mostrami il tuo stile semplice. Wow me con quanto sia facile adattarsi come cambiano i requisiti. Mi stupirò di quanto sia facile da capire. E imparerò. Imiterò il tuo stile.
Oppure potresti imparare che ciò che pensi sia il modo migliore in realtà non lo è. Potresti ignorare le preoccupazioni che sono valide. Potrebbe essere necessario riconsiderare il tuo stile.
Come sai che è giusto? Avvicinandoti a ogni recensione desiderosa di imparare e voler insegnare. Se tutto ciò che ti interessa è vincere, sarai evitato perché anche se hai ragione, non stai aiutando.
Pronto per il livello successivo?
Incoraggia gli altri a sentirsi allo stesso modo. Hai notato qualcosa di fico che non sapevi? Lodalo! Fare storie. Premiare persone che ti insegnano cose. Sii il programmatore che desideri fossero.
Quando correggi non renderlo personale. Non vergognarti Non si tratta nemmeno di quanto sia pessimo il codice. Si tratta di quanto potrebbe essere migliore. Non dettare. Chiedi se è meglio così.
Le recensioni sono importanti ma sono difficili per noi. Noi scimmie del codice non siamo andati in questo campo perché siamo bravi con le persone. Mantienilo sul codice e usa tanto tatto e diplomazia quanto puoi raccogliere. Aiuta gli altri a fare lo stesso.
Non è ancora abbastanza?
Qualcuno al tavolo sta cercando di dire qualcosa che non riescono a capire? Ricorda, non siamo major inglesi o oratori pubblici. Comunichiamo al meglio con il codice.
Alcune idee non comunicano bene durante le riunioni. Se ti imbatti in un invito, l'altra parte accoppierà il programma con te per un po '. Stringiti attorno a una tastiera e mostrati a vicenda cosa intendi veramente. Questo è il motivo per cui ho sempre una sedia per gli ospiti e giocattoli da scrivania.
Non sarà facile,
Ma il modo migliore è inviare i tuoi sviluppatori alla business school. In questo modo imparano a capire il "valore" del loro lavoro in modi totalmente diversi.
In realtà direi che è il motivo principale per cui sono un programmatore più efficace di alcuni dei miei colleghi: sono andato alla scuola di business oltre a ricevere un'istruzione di programmazione e mi ha insegnato di più le esigenze del business.
E uno dei maggiori bisogni è la possibilità di vendere cose ...... ieri.
Con l'over-engineering si ritarderà la possibilità di vendere un prodotto indefinitamente, perché ci sarà sempre qualcosa che avrebbe potuto essere fatto meglio.
Ricorda loro che ogni riga di codice che scrivono dovrebbe contribuire a un obiettivo aziendale. Lodali per aver scritto il minor numero possibile di codice.
Tuttavia, dovresti tenere a mente che la facilità di manutenzione contribuisce anche agli obiettivi di business.
Il codice ben architetturale riduce effettivamente le linee generali del codice a lungo termine, non il contrario.
Ben-Architectured > Molto semplice > Mal-architectured
Hehe. Sono appena entrato e non ho visto la versione iniziale della domanda, solo quella modificata che ha solo una riga a sinistra. Ancora posso leggere tra le righe: "Sono così frustrato con questi sviluppatori che non si limitano a farlo funzionare mentre non mi interessa niente altro!".
Ho paura che tu sia venuto nel posto sbagliato. O no, se sei serio. Sembra che tu abbia un problema di comunicazione tra le tue mani. O non capisci che ciò che gli sviluppatori fanno è necessario o che i tuoi sviluppatori non capiscono che non dovranno mai più rivedere quel codice, quindi non ha senso renderlo gestibile.
Parla con loro invece di persone su Internet e vedi dove puoi incontrarti.
Leggi altre domande sui tag design engineering complexity