È "finchè funziona" la norma? [chiuso]

Ti sei indirettamente imbattuto in quello che secondo me è l'aspetto chiave per essere un buon sviluppatore : colpire l'equilibrio tra " finché funziona " e codice ingegnerizzato ed elegante.

Proprio come in politica, è molto più facile puntare la tua posizione su un'estremità dello spettro rispetto a prendere una posizione sfumata nel mezzo. La maggior parte degli sviluppatori che ho incontrato si dividono in due categorie: codifica di hack da cowboy e astronauti di architettura. Provo a trovare un equilibrio tra i due. Non è così facile come sembra.

Per rispondere più direttamente alla tua domanda, sì, penso che "finché funziona" è spesso la norma. Ma guarda in un altro modo: sei in una posizione eccellente per educare i tuoi colleghi e provare a introdurre alcune pratiche migliori. Ma non andare all'estremo, e ricorda perché stiamo facendo tutto questo: per risolvere i problemi dei nostri clienti.

> > Al mio precedente lavoro, la gente ha avuto l'attitudine finché funziona, va bene.

Potrei essere una minoranza qui ma ho lo stesso atteggiamento e credo fermamente che per riscrivere qualcosa ci dovrebbe essere una chiara evidenza del perché ne abbiamo bisogno. E non intendo qualcosa come "uf, non mi piace come è stato codificato" - ogni sviluppatore ha le sue preferenze sul codice. Ci dovrebbero essere alcuni problemi con la parte che vogliamo riscrivere:

• Problemi di prestazioni
• Sono stati rilevati più errori rispetto a qualsiasi altra parte del sistema
• Gli sviluppatori dedicano più tempo quando lavorano su questa parte
• ecc.

Agile non è responsabile per qualsiasi decisione umana di rilasciare il software buggato; gli umani lo sono.

Detto questo, dai molta importanza alla qualità, ed è buono. Sono sicuro che sei un perfezionista e sei preoccupato per il tuo valore se non raggiungi le ultime tecnologie.

Il problema è che perfezionismo porta a procrastinazione e procrastinazione porta a mediocrità .

Ecco perché le aziende attribuiscono priorità a cose come time to market e utilizzano agile per fornire valore rapidamente e ad un ritmo prevedibile.

Dato che non hai descritto la strategia aziendale della tua azienda, penso che dovresti iniziare facendo una domanda al riguardo ai tuoi manager.

Per essere allineati sui loro obiettivi e piani (che ti hanno assunto per aiutarli a raggiungerli), sarai in una posizione migliore per capire come potresti contribuire a loro invece di concentrarti sui tuoi obiettivi personali e personali.

Sono sicuro che provando a understand il loro valore, sarai in grado di condividere il tuo e questo sarà l'inizio di una proficua collaborazione.

E se scopri che non sanno cosa stanno facendo, la tua unica opzione sarà uscire .

Dipende tutto da cosa stai costruendo. Se stai costruendo un microsito che sarà online solo per un mese, e hai nove giorni per costruirlo: allora sì, a patto che funzioni sarà sufficiente.

Se stai scrivendo gli algoritmi fly-by-wire per il sistema FA-18, allora è meglio che si costruisca il più perfettamente possibile.

Quindi, come nel caso della maggior parte delle risposte tecnologiche ... dipende.

Dipende dalla compagnia. Tuttavia, molte aziende hanno una strong concorrenza e una pressione del tempo. Questa è una ragione tipica. Un altro sarebbe un grande carico di lavoro, potenzialmente senza abbastanza personale. (Esistono alcune buone ragioni per essere sotto organico, che non sono necessariamente colpa dell'azienda.) Detto questo, alcune organizzazioni non sono riuscite a uscire da un sacchetto di carta bagnato.

Penso che la regola 80/20 si applichi qui. Fondamentalmente, devi sopportare l'80% schifoso e arrivare al 20%. Tuttavia, renditi conto che anche loro dovranno fare dei compromessi. Negli affari, di solito non importa che tu abbia assolutamente ragione. È importante che tu ce l'abbia adesso.

if the only professional development here is reading the latest MS Press technology book, then what have you built in 10 years but a superficial knowledge of various technologies?

Sarebbe un po 'schifoso, ma potrebbero esserci stati alcuni fallimenti spettacolari da notare in quel decennio. Ho visto molti posti in cui posso ricordare cose piuttosto specifiche che mi sono piaciute lavorare lì o che non mi piacciono e quindi mi farebbe domande sul fatto di averlo di nuovo nel mio nuovo posto di lavoro. A volte può esserci la nuova pratica da provare come se un'azienda tentasse di implementare Scrum o adottasse un approccio basato sul Test-Driven che potrebbe essere un'opportunità, ma non necessariamente vedere come uno sviluppo professionale in quanto non in un'impostazione formale in classe.

Conosco vari luoghi in cui il "finché funziona" è comune insieme a varie strategie di codifica dei cowboy. In un paio di start-up ho visto questo tipo di mentalità che può avere senso se la società è così giovane che stanno ancora cercando di scovare l'idea di cosa stanno veramente cercando di fare. In altre aziende in cui ho lavorato c'è stato più processo e una maturità che può essere abbastanza buona, anche se non è facile trovarla, temo. In alcuni posti ho avuto alcuni processi che ho avuto modo di vedere e dire, "Mi piace quello, lo ricorderò per le situazioni lavorative successive" e altri dove vorrei andare "Non mi piace molto. per cercare di evitarlo in futuro. " C'è qualcosa da dire per trovare un buon lavoro come trovare il trattamento giusto per alcune condizioni mediche dove possono esserci decine di idee diverse ma non si sa quali combinazioni funzioneranno per un determinato paziente.

Ho lavorato in un negozio come questo per un po 'proprio nel momento in cui li stava raggiungendo. C'erano applicazioni di due o tre anni con bug noti che non potevano letteralmente risolvere. Pensa a un loop lungo di 4.000 linee con un calcolo in esecuzione per larghezze e altezze del layout. Fissare un pezzo di codice per riparare un problema in una istanza comporterebbe venti problemi altrove perché i precedenti sviluppatori avevano problemi simili a quelli della banda regolando arbitrariamente i risultati dei calcoli con numeri magici. Il codice non può essere descritto come qualcosa di diverso da quello tossico.

Alla fine mi è stato consegnato un nuovo progetto che il mio capo mi ha detto potrebbe usare questo codice esistente per gestire i layout. In qualche modo l'ho convinto a lasciarmi "alterare" così mi ha dato un po 'di tempo in più. Ho usato il tempo per scrivere invece una libreria ben progettata per aiutare con il layout. Insetti in questo nuovo progetto mi hanno letteralmente impiegato 10 secondi per risolverlo. Potrei identificare i problemi prima ancora di guardare il codice per vedere cosa è andato storto.

Ho pensato che questo avrebbe comportato una svolta per il mio manager, ma tutto quello che ho ottenuto è stato una pacca sulla spalla e in sostanza mi ha detto che "Anche il tuo modo di lavorare funziona".

Da allora ho iniziato a lavorare per un altro negozio e le cose vanno meglio qui. Il punto è che non puoi cambiare idea. Vai a lavorare da qualche altra parte.

Continuo a sperare che nell'economia ci sia una sorta di processo evolutivo, che prima o poi mette fuori gioco quelle aziende. Ma forse il ritmo elevato del progresso tecnologico produce troppe nuove nicchie, quindi anche i concorrenti deboli possono ancora trovare abbastanza "cibo".

Se vuoi aumentare le tue possibilità di lavorare in un buon posto, cerca un'azienda che ha un prodotto che vendono a molti clienti invece di scrivere qualcosa di nuovo ogni poche settimane. Dovrebbe esserci più interesse nell'avere una buona base di codice e poter aggiungere nuove funzionalità senza rompere il codice esistente in ogni momento.

Mi ricorda il mio compagno maggiore del college. Stava prendendo una classe di progettazione VLSI, e per i suoi primi compiti è venuto fuori con un componente che era dell'ordine di micrometri di larghezza e un miglio di lunghezza. Le simulazioni sono passate perfettamente.

La sua risposta ai suoi critici è stata: "Tutto quello che so è che la mia merda funziona".

Una norma abbastanza buona è Principio di Pareto

Ho esperienza in un progetto con la regola 80-20 e ha funzionato molto bene. Penso che le risposte a questa domanda "Dove si disegna linea per il tuo perfezionismo " può anche essere utile.

The term "Pareto principle" can also refer to Pareto efficiency. The Pareto principle (also known as the 80-20 rule, the law of the vital few, and the principle of factor sparsity) states that, for many events, roughly 80% of the effects come from 20% of the causes. Business management thinker Joseph M. Juran suggested the principle and named it after Italian economist Vilfredo Pareto, who observed in 1906 that 80% of the land in Italy was owned by 20% of the population; he developed the principle by observing that 20% of the pea pods in his garden contained 80% of the peas. It is a common rule of thumb in business; e.g., "80% of your sales come from 20% of your clients". Mathematically, where something is shared among a sufficiently large set of participants, there must be a number k between 50 and 100 such that "k% is taken by (100 − k)% of the participants". The number k may vary from 50 (in the case of equal distribution, i.e. 100% of the population have equal shares) to nearly 100 (when a tiny number of participants account for almost all of the resource). There is nothing special about the number 80% mathematically, but many real systems have k somewhere around this region of intermediate imbalance in distribution. The Pareto principle is only tangentially related to Pareto efficiency, which was also introduced by the same economist. Pareto developed both concepts in the context of the distribution of income and wealth among the population.

Link a Source

When I asked for a rewrite of some code I had written while we were essentially exploring the spec, they denied it. I wanted to rewrite the code because code was repeated in multiple places, there was no encapsulation and it took people a long time to make changes to it.

Senza offesa, ma come manager ho letto questa affermazione in qualche modo sulla falsariga di:

"Quando ho chiesto di essere pagato due volte per riscrivere un codice che ho già scritto, la mia azienda non voleva pagare. Volevo i soldi extra per ripulire il casino che avevo fatto quando l'ho scritto la prima volta e i miei colleghi erano arrabbiati con me per aver reso le loro vite difficili. "

Se si tratta del tuo codice di cui ti lamenti, non hai molto su cui stare.

UPDATE

Capisco che questo POV sia impopolare. Ma, non credo che sia affatto incongruente anche con le responsabilità e gli atteggiamenti di uno sviluppatore professionista.

Se scrivi un codice pulito per cominciare (e c'è una moltitudine di ragioni per farlo - indipendentemente dal fatto che pensi che il tuo codice vedrà l'uso della produzione o meno), allora avrai questo problema molto meno regolarmente.

Se includi codice pulito e tempo di refactoring nelle tue stime, avrai anche la pianificazione per mantenere ordinato il codebase. Se, a causa della pressione programmata, non si ottiene il tempo necessario, le stime future dovrebbero aumentare a seguito del debito tecnico sostenuto.

Ad un certo punto, le tue stime future (o incertezze che circondano le tue stime) ti daranno il potere di argomentare per una riscrittura (quando il tuo manager ti supplica di accelerare il processo). In caso contrario, accetta che l'azienda abbia accettato la tua stima e preferisca pagare il costo in corso piuttosto che una sostituzione. Questa è una decisione puramente commerciale, non tecnica.

Ricorda che il tempo per negoziare i programmi è prima che hai scritto il codice - non dopo. Dopo che il codice è stato scritto (e "funziona"), i clienti, i manager e i dirigenti non vogliono vedere un'altra fattura per "manutenzione" che si avvicina o supera il costo originale. Se ti senti strongmente coinvolto nel modo in cui pensi che il business dovrebbe, sentiti libero di riscriverlo nel tuo tempo libero - questo è ciò che stai chiedendo all'azienda di fare.

Dal punto di vista del tuo manager, offrirti un programma per riscrivere mette il suo asino in linea. Quando non si riesce a consegnare, o aumentare la produttività fino a quanto si dice - allora è quello che ha lasciato la borsa. Rispetto all'inconveniente relativamente minore dell'ascoltare lamentarsi, indovina quale preferirà.

Se questo è il tipo di lavoro che puoi ottenere, concentrati solo sulla scrittura di codice migliore ogni volta, piuttosto che tornare indietro e riscrivere il vecchio codice. Esiste ancora un intervallo di qualità che puoi spostare all'interno del regno dell'incollaggio di pacchetti di terze parti.

Se hai tempo e vuoi migliorare il codice di un componente esistente che gestisci, non puoi farlo senza chiedere il permesso, a condizione che funzioni? Calcola il tempo nelle stime per il prossimo progetto che utilizza il componente.

Per la programmazione di livello inferiore, se non riesci a ottenere la soddisfazione dell'apprendimento dal tuo lavoro, allora forse è il momento di guardare a un progetto open source?

q303, ho trovato la tua domanda interessante e ho sentito che potresti trovare questo La domanda dei programmatori vale la pena leggere, su come convincere i manager a consentire agli sviluppatori di affrontare il debito tecnico.

Penso generalmente, sì, è la norma. Comprendi che il software funzionante ma non ottimale è molto meglio del software non funzionante. C'è anche l'argomento che la definizione di "lavoro" potrebbe variare in base alla percezione e ai pregiudizi di ogni individuo. Quando si implementa un nuovo sistema, c'è sempre qualcuno che dirà di aver sentito che il vecchio sistema era migliore. E quando parli con uno sviluppatore, è probabile che sia riluttante ad ammettere di aver lavorato su software scadenti.