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

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

Otterranno trashed per anni di:

• futuri manutentori,
• futuri tester,
• proprietari di progetti futuri,
• i futuri manager,
• e praticamente chiunque sia coinvolto con il codebase in futuro.

Potrebbero anche ottenere lo stesso trattamento da:

• gli attuali tester,
• gli attuali autori di documentazione tecnica.

False dicotomia: le qualità sono ortogonali.

                High Quality     Low Quality

Profitable         AWESOME       Sketchy

Unprofitable        Iffy         FIRE FIRST

No. Le best practice sono le migliori perché, per definizione , aiutano a far funzionare i progetti in modo più corretto, in meno tempo, con una modifica più rapida lungo la strada, quindi ignorarli è garantito per diminuire i profitti . Naturalmente, i tuoi manager potrebbero prescrivere pratiche che pensano sono le migliori, ma in realtà non lo sono, o potrebbero giudicare male ciò che i clienti pagheranno e quali no - quindi tutte le scommesse sono state annullate.

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 dalla microgestione di ritenzione anale, quindi lo stesso vale: le migliori pratiche attuali sono sempre utili, di solito le pseudo-best practice no.

L'ottimizzazione del codice di solito non vale la pena di fare se non hai misurato quali sono i tuoi colli di bottiglia, confermati che è necessaria un'ottimizzazione e misurati che il tuo trucco intelligente soddisfa effettivamente il requisito 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 del codice e delle pratiche? No.

Svolgono il lavoro che devono svolgere? Sì.

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

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

No, e troverei la via più rapida via da detta società che apprezza quei vizi.

Sì e no, che è un po 'sdolcinato 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.

Best Practices è un po 'come il buon senso, tutti sono d'accordo sul fatto che tutti dovrebbero saperlo fino a quando due persone non cominciano 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 l'inferno Nessun codice di buona qualità / esecuzione non è mai accettabile in questo tipo di lavoro.

Stai scrivendo un sito web usa e getta per una spinta di marketing una tantum (probabilmente non stai facendo questo o non avresti fatto la domanda, ma è più probabile che il satellite)? Allora Hell Sì, porta quel pezzo di peluche fuori dalla porta con ogni mezzo necessario per rispettare la scadenza, il prossimo direttore marketing probabilmente farà comunque qualcos'altro con una compagnia diversa. COSA FAI NON È L'ARTE O LA SCIENZA - OTTIENI PAGATO.

Tutto il resto in mezzo: negoziabile, specialmente finché il dev è agganciato per il supporto iniziale.

Fino alla seconda venuta di qualunque santo essere preferito si verifica e si definiscono 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 è così insignificante da essere usa e getta.

Ogni cosa al di fuori delle best practice etichettate in base alla durata è 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 questo non lo rende una guida immutabile per tutte le situazioni.

Quanto denaro fanno per la società è discutibile. Se c'è un livello di rivisitazione del codice in questione, i costi di manutenzione aumenteranno e qualcuno non sarà felice. Gli elevati costi di manutenzione a lungo termine sono più costosi di quanto non lo facciano in anticipo.

Il grado di rispetto che ricevono è probabilmente specifico del caso. Ad un certo punto, tuttavia, qualcuno lo noterà.

Non preoccuparsi di queste cose potrebbe rendere l'azienda più economica a breve termine, ma potrebbe costare alla società più denaro a lungo termine a più correzioni di bug e codici di manutenzione.

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

Dipende tutto dal cliente.

Un cliente a cui piacciono i lavori veloci e sporchi (e solitamente meno costosi) non si preoccupa di presentare problemi in futuro.

Pensa alla costruzione dell'armadio.

Alcuni pagheranno e apprezzeranno gli armadi personalizzati di buona qualità. A loro non importa la spesa extra dei cassetti in legno massiccio e dell'hardware di prim'ordine. A loro non importa che ci vorrà una settimana o addirittura un mese in più per costruire e installare le cose.

Molti non lo faranno. Molti opteranno per la particella di massa economica prodotta in serie prodotta 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 elogiano lo sviluppatore che lo fa in modo rapido e sporco, i tuoi clienti non vogliono un'alta qualità o i gestori 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 best practice, l'effettiva abilità sono le MOST cose importanti da avere in un codice base; senza di esso tutto si trasforma in melma e viene tenuto insieme con del nastro adesivo. È un design insostenibile. È come ignorare un tumore perché è piccolo e ora sei sano; sicuro di essere in salute ora, ma a distanza di alcuni anni diventa terminale perché lo hai ignorato per così tanto tempo.

Non solo faccio non per concordare con gli sviluppatori che non si preoccupano di queste cose, ma ho zero respect per farle avviare. Un modo sicuro per farmi prendere in considerazione l'idea di lasciare un'organizzazione, non importa quanto breve sia stata, è essere circondato da una squadra in cui sono l'unica persona (se non l'unica persona dell'intera azienda) a cui importa su concetti di ingegneria del software adeguati.

Una buona lettura: link

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

Qualunque cosa tu pensi, non essere un idiota.

EDIT: non sto difendendo nessuna delle posizioni, a seconda dell'attività che potrei appoggiare su entrambi i lati.

Meglio per l'azienda? Dipende.

Per una startup con fondi limitati, fallo e portala a termine, non importa se è disordinata, può essere risolta 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 la stessa cosa che fanno i tuoi colleghi e lascia che la gestione si occupi delle ricadute: non è il tuo lavoro. Se stai aggiustando la merda di altre persone tutto il tempo che sarai visto come lento, e sarai quello che è ancora lì mentre gli altri sono stati promossi sopra di te. Prendi parte al programma o esci mentre puoi se è così brutto.

Dipende dallo sviluppatore e dal progetto / situazione.

I tempi straordinari richiedono misure straordinarie.

Quindi, se ho bisogno di qualcosa consegnato ora, e qualcuno è un java application di livello enterprise eccessivamente ingegneristico che sfrutta non meno di 14 dei più recenti framework buzzword mentre un semplice script python farà il lavoro è peggio dello sviluppatore che taglia angoli e pensa che il codice bacato funzionerà in tempi normali.

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

Nel tuo caso - se ti dà più valore di te perché la velocità è critica, anche dopo aver sostenuto l'aumento dei costi di manutenzione lungo la strada, merita il compenso migliore. Dall'altro lato - se sei bloccato a pulire il suo casino - hai un problema di comunicazione con la gestione.

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

Mi dispiace ma non sarei d'accordo con la maggior parte delle risposte a questa domanda, tranne quella in alto.

Il valore principale del software è che è flessibile.

Non penso che dovresti riscrivere il codice altrui senza una giusta causa. Se devi modificare un modulo per qualsiasi motivo per implementare la tua funzione, ora sei, nel bene o nel male, il proprietario di quel modulo. Cambialo, riscrivilo, riscrivilo tutto.

Mai produrre bassa qualità in termini di flessibilità mai. Non c'è nulla come buttare via qualsiasi cosa nel software. Se il cliente dice che è temporaneo e che non ne ha bisogno dopo una certa data, e non si preoccupano della qualità, dicono "a cattivo" o scrivono che il codice non verrà modificato da te o da qualsiasi altro programmatore una volta viene distribuito alla produzione o hai il diritto di denunciarli.

L'ipotesi più assurda che vedo in alcune di queste risposte è che un codice pulito riduce in qualche modo la velocità di sviluppo. Per qualsiasi progetto di qualsiasi sostanza (superiore a 6 ore di lavoro), il codice pulito velocizza lo sviluppo a lungo termine (qualsiasi cosa maggiore di una settimana). L'ho visto più e più volte.

Il codice di scarsa qualità è irrispettoso nei confronti della professione e dei tuoi colleghi. Scusa ma vero.

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