Gli sviluppatori di software che ignorano la qualità / gli standard sono migliori per l'azienda? [chiuso]

Gli sviluppatori di software che scelgono di non mettere l'ottimizzazione del codice, gli standard e le migliori pratiche come una priorità assoluta, creano un codice più utile di quegli sviluppatori che vogliono preoccuparsi dell'ottimizzazione, dell'implementazione degli standard e delle pratiche di codifica prima di completare le attività in tempo?

Come si confrontano queste diverse metodologie quando si tratta di revisioni individuali delle prestazioni?

Come si confrontano questi stili nelle revisioni tra pari?

Qual è il modo migliore per influenzare il tuo team per implementare più best practice durante l'SDLC?

No, otterranno rispetto solo dal proprietario del progetto del momento.

Saranno spazzati via per anni da:

• futuri manutentori,
• futuri tester,
• futuri proprietari di progetti,
• futuri manager,
• e praticamente chiunque sia coinvolto con la base di codice in futuro.

Potrebbero anche ottenere lo stesso trattamento da:

• gli attuali tester
• gli attuali scrittori di documentazione tecnica.

Falsa dicotomia: le qualità sono ortogonali.

                Alta qualità Bassa qualità

Redditizio ECCEZIONALE ECCEZIONALE

Iffy non redditizio PRIMO FUOCO

No. Le migliori pratiche sono le migliori perché, per definizione , aiutano a portare a termine i progetti in modo più corretto, in meno tempo, con una modifica più rapida lungo la strada, quindi ignorarli è garantito per ridurre i profitti. Ovviamente, i tuoi manager potrebbero prescrivere pratiche che ritengono migliori, ma in realtà non lo sono, oppure potrebbero valutare erroneamente ciò che i clienti pagheranno e cosa no - quindi tutte le scommesse sono disattivate.

Gli standard di codifica sono più difficili; è possibile prescrivere troppi dettagli ai programmatori, il che porta a una riduzione dell'efficienza. Ma con l'esperienza diventa abbastanza facile dire utili linee guida sulla micro-gestione della ritenzione anale, quindi lo stesso vale: le migliori pratiche effettive valgono sempre la pena, di solito le pseudo-migliori pratiche.

L'ottimizzazione del codice di solito non vale la pena, a meno che tu non abbia misurato i tuoi colli di bottiglia, confermato che è necessaria un'ottimizzazione e misurato che il tuo trucco intelligente soddisfa effettivamente la domanda di preformance. Altrimenti (che è principalmente) non vale la pena farlo, e quindi non ottimale.

Sono d'accordo con gli sviluppatori che non si preoccupano dell'ottimizzazione e delle pratiche del codice? No.

Fanno il lavoro che devono fare? Sì.

Un'azienda è fare soldi, e l'unico modo per fare soldi è rilasciare prodotti. Questo di solito significa che i progetti hanno orari rigidi, il che significa che potrebbe essere il modo migliore per fare qualcosa che potrebbe non essere il modo più veloce per fare qualcosa.

Anche se non sono d'accordo con questo stile di sviluppo, può essere considerato rispettabile dall'azienda se i prodotti vengono rilasciati.

No, e troverei il percorso più veloce lontano da detta compagnia che apprezza quei vizi.

Sì e no, che è un po 'appetitoso ma è una buona pratica e non una pratica perfetta. Idealmente dovresti seguirli costantemente, ma ci sarà sempre una situazione in cui l'azienda vuole mettere le sue esigenze prima che i tuoi prodotti abbiano bisogno.

Sarai odiato dai manutentori ma amato dal tuo capo.

Le buone pratiche sono un po 'come il buonsenso, tutti concordano sul fatto che tutti dovrebbero conoscerlo fino a quando due persone non inizieranno a discuterne in dettaglio. Non esistono due persone completamente d'accordo sulla definizione e non esiste una fonte logica di verità che si applica a tutte le situazioni.

Stai scrivendo il sistema di guida per un satellite spaziale (probabilmente non lo sei)? Quindi Hell In questo tipo di lavoro non è mai accettabile un codice di scarsa qualità / prestazioni.

Stai scrivendo un sito Web usa e getta per una spinta di marketing di una volta (probabilmente non lo stai facendo o non avresti fatto la domanda, ma è più probabile del satellite)? Quindi diavolo Sì, porta quella lanugine fuori dalla porta con tutti i mezzi necessari per rispettare la scadenza, il prossimo direttore marketing probabilmente probabilmente farà qualcos'altro con un'altra società. Quello che fai non è arte o scienza - fatti pagare.

Tutto il resto: negoziabile, soprattutto finché lo sviluppatore è agganciato per il supporto iniziale.

Fino a quando si verificherà la seconda venuta di qualunque essere santo che preferisci e definirà le pratiche di sviluppo in modo miracoloso, ci sarà spazio significativo per il dibattito su qualsiasi progetto non direttamente responsabile delle decisioni di vita e di morte che non lo è così insignificante da essere usa e getta.

Tutto al di fuori delle migliori pratiche etichettate critiche per la vita è in genere più simile alla politica aziendale, alle specifiche del cliente o all'opinione personale. Molti di loro sono opinioni personali su cui molte persone sono attualmente d'accordo, ma ciò non lo rende una guida immutabile per tutte le situazioni.

Quanti soldi fanno per l'azienda sono discutibili. Se c'è un livello di rivisitazione del codice in questione, i costi di manutenzione aumenteranno e qualcuno non sarà contento. Gli alti costi di manutenzione a lungo termine sono più costosi rispetto a quelli eseguiti correttamente in anticipo.

Quanto rispetto ottengono è probabilmente specifico del caso. Ad un certo punto, tuttavia, qualcuno noterà.

Non preoccuparsi di queste cose può rendere l'azienda più soldi a breve termine, ma potrebbe costare più soldi a lungo termine su più correzioni di errori e codici di manutenzione.

A volte può essere necessario un lavoro rapido e sporco se c'è una fretta con aziende concorrenti per ottenere prodotti simili sul mercato allo stesso tempo, ma i costi futuri di tali azioni dovrebbero essere considerati attentamente.

Tutto dipende dal cliente.

Un cliente a cui piacciono le cose veloci e sporche (e di solito più economiche) non si preoccupa che presenterà problemi in futuro.

Pensa alla costruzione dell'armadio.

Alcuni pagheranno e apprezzeranno gli armadi su misura di buona qualità. A loro non importa il costo aggiuntivo di cassetti in legno e hardware di prima qualità. A loro non importa ci vorrà una settimana o anche un mese in più per costruire e installare le cose.

Molti non lo faranno. Molti opteranno per le cose economiche prodotte in serie di pannelli truciolari che si ottengono da un grande negozio di scatole. Li vogliono installati in 2 giorni. Un piccolo spazio qua e là è perfettamente accettabile. A loro non importa che cadranno a pezzi tra 10 anni.

Quindi, se i tuoi manager lodano lo sviluppatore che lo fa veloce e sporco, allora i tuoi clienti non vogliono l'alta qualità o i manager mentono ai clienti.

Solo il tempo lo dirà. Fai quello che vogliono i manager o trova un altro lavoro.

No, mai. L'ottimizzazione del codice IMO, le migliori pratiche, l' abilità effettiva sono le cose PIÙ importanti da avere in una base di codice; senza di essa il tutto si trasforma in fango e viene tenuto insieme con del nastro adesivo. È un design insostenibile. È come ignorare un tumore perché è piccolo e ora sei in salute; certo che ora sei in salute ma dopo qualche anno diventa terminale perché l'hai ignorato per così tanto tempo.

Non solo non sono d'accordo con gli sviluppatori che non si preoccupano di queste cose, ma ho zero rispetto per l'avvio. Un modo infallibile per farmi considerare di lasciare un'organizzazione, non importa da quanto tempo sono lì, è essere circondato da una squadra in cui sono l'unica persona (se non l'unica in tutta l'azienda) a cui importa sui concetti di ingegneria del software adeguati.

Una buona lettura: http://www.joelonsoftware.com/items/2009/09/23.html

Ma IMHO, le migliori pratiche di un uomo sono un altro incubo per uomini. E ogni base di codice non banale sarà un incubo per un estraneo.

Qualunque cosa tu pensi, non essere un cretino a riguardo.

EDIT: non sto difendendo nessuna delle posizioni, a seconda del compito che potrei appoggiare ad entrambe le parti.

Meglio per l'azienda? Dipende.

Per una startup con fondi limitati, fallo e fallo là fuori - non importa se è disordinato, che può essere risolto in seguito quando ci sono più risorse.

Per un prodotto maturo in cui ci sono molti utenti che si affidano alla qualità del software, tutto dovrebbe essere fatto "correttamente".

Meglio per il singolo sviluppatore? In realtà è irrilevante. Fai semplicemente lo stesso di quello che fanno i tuoi colleghi e lascia che il management gestisca le conseguenze, non è il tuo lavoro. Se stai aggiustando la merda di altre persone tutto il tempo, sarai visto come lento e sarai quello che è ancora lì mentre gli altri sono stati promossi sopra di te. Vai con il programma o esci mentre puoi se è così male.

Dipende dallo sviluppatore e dal progetto / situazione.

Tempi straordinari richiedono misure straordinarie.

Quindi, se ho bisogno di qualcosa di consegnato ora, e qualcuno è un'ingegneria java di livello enterprise che sfrutta non meno di 14 dei più recenti framework di parole d'ordine mentre un semplice script Python farà il lavoro è peggio dello sviluppatore che taglia gli angoli e pensa codice buggy funzionerà in tempi normali.

Parte dell'essere uno sviluppatore è essere flessibile. Non dovresti essere schiavo dei tuoi strumenti e seguire ciecamente le pratiche: ci sarà sempre un caso in cui ti mancheranno. Sapere quando infrangere e piegare le regole è una delle cose che derivano da molta esperienza e sono preziose.

Nel tuo caso, se offre più valore di te perché la velocità è fondamentale, anche dopo aver preso in considerazione l'aumento dei costi di manutenzione lungo la strada, merita una compensazione migliore. Dall'altro lato - se sei bloccato con la pulizia del suo pasticcio - hai un problema di comunicazione con la gestione.

È caso per caso. Tranne lo stile di codifica - non ci sono scuse lì.

Mi dispiace ma dovrei essere in disaccordo con la maggior parte delle risposte a questa domanda, ad eccezione di quella in alto.

Il valore principale del software è che è flessibile.

Non penso che dovresti riscrivere il codice di altre persone senza giusta causa. Se devi modificare un modulo per qualsiasi motivo per implementare la tua funzione, ora sei, nel bene e nel male, il proprietario di quel modulo. Cambialo, riscrivine un po ', riscrivi tutto.

Non produrre mai bassa qualità in termini di flessibilità mai. Non esiste nulla come buttare via qualcosa nel software. Se il cliente dice che è temporaneo e che non ne avrà bisogno dopo una certa data e non si preoccupano della qualità, dì "cattivo" o scrivi per iscritto che il codice non verrà modificato da te o da nessun altro programmatore una volta viene distribuito alla produzione o hai il diritto di denunciarli.

Il presupposto più scarso che vedo in alcune di queste risposte è che un codice pulito in qualche modo riduce la velocità di sviluppo. Per qualsiasi progetto di qualsiasi sostanza (più di 6 ore di lavoro) il codice pulito accelera lo sviluppo a lungo termine (qualcosa di più di una settimana). L'ho visto più e più volte.

Un codice di qualità scadente è irrispettoso nei confronti della professione e dei colleghi. Scusa ma vero.

Quindi no alla scarsa qualità, in termini di flessibilità, mai!