Superare la risoluzione dei problemi lenta a causa della maggiore conoscenza di ciò che potrebbe andare storto [chiuso]


450

Questo mi ha turbato per un po 'di tempo e apprezzerei molto il contributo di altri professionisti.

Breve background: ho iniziato a programmare quando i miei genitori mi hanno comprato il mio primo computer nel 1988 (a 14 anni, adesso ho 39 anni). Ho seguito un paio di altri percorsi di carriera prima di diventare finalmente un programmatore professionista nel 1997. Forse in ritardo, ma è così. Sono ancora felice della mia scelta, amo la programmazione e mi considero bravo in quello che faccio.

Ultimamente, ho notato che più esperienza acquisisco, più tempo mi serve per completare i progetti o determinate attività in un progetto. Non sto ancora diventando senile. È solo che ho visto tanti modi diversi in cui le cose possono andare storte. E le potenziali insidie ​​e trucchi che conosco e ricordo stanno diventando sempre di più.

Esempio fondamentale: era solo "ok, scrivi un file qui". Ora mi preoccupo di autorizzazioni, blocco, concorrenza, operazioni atomiche, indiretta / framework, diversi file system, numero di file in una directory, nomi di file temporanei prevedibili, qualità della casualità nel mio PRNG, carenza di energia nel mezzo di qualsiasi operazione, un'API comprensibile per quello che sto facendo, documentazione adeguata, ecc. ecc. ecc.

In breve, i problemi sono passati da "come posso fare" a "qual è il modo migliore / più sicuro per farlo".

Il risultato è che mi ci vuole più tempo per finire un progetto di un principiante. La mia versione potrebbe essere solida e impenetrabile come so come realizzarla, ma ci vuole più tempo.

L'esempio "crea file" sopra era proprio questo, un esempio. I compiti reali sono ovviamente più complessi, ma meno adatti a una domanda generica come questa. Spero che tu capisca dove sto andando con questo. Non ho problemi a trovare algoritmi efficienti, adoro la matematica, mi piacciono le materie complesse, non ho difficoltà con la concentrazione. Penso di avere un problema con l'esperienza e, di conseguenza, con la paura degli errori (intrinseci o estrinseci).

Passo quasi due ore al giorno a leggere nuovi sviluppi, nuove tecniche, lingue, piattaforme, vulnerabilità della sicurezza e così via. L'enigma è che più conoscenza acquisisco, più lento sono nel portare a termine i progetti.

come lo gestisci?


126
La lezione chiave è: attenersi ai requisiti, non di più . In questo modo non proverai ad implementare funzionalità che non sono necessarie.
mouviciel,

19
Consideri la metodologia di sviluppo agile anziché il modello a cascata. Distribuisci prima grandi cose e consegna il resto in modo iterativo. Questo è un nuovo concetto ma aiuta a ridurre rischi e costi.
Satish

23
Riassumendo i punti di vista e aggiungendo il mio (nel caso manchi): dovresti prendere in considerazione progetti che sono più mission-critical (dal punto di vista aziendale, non dal punto di vista della sicurezza) o che hanno requisiti più elevati di qualità (a basso difetto) rispetto alla ricchezza di funzionalità. In altre parole, cerca progetti in cui le tue migliori competenze sono più apprezzate.
dall'8

13
Quando leggi uno qualsiasi dei libri sulla qualità del codice, l'unico tema clamoroso è mentre può costare di più creare un buon codice in primo luogo, a lungo termine avrà un costo inferiore una volta che avrai preso in considerazione la manutenzione.
James Snell,

6
"Fai la cosa più semplice che potrebbe funzionare." Dopo averlo fatto, decidi se devi preoccuparti di qualcos'altro.
Wayne Werner,

Risposte:


268

Non sei più lento nel completare i progetti. In precedenza, pensavi che i tuoi progetti per principianti fossero realizzati quando in realtà non lo erano. Dovresti vendere questa qualità ai clienti.

"Questa azienda potrebbe farlo in modo più rapido ed economico, ma è davvero fatta? O andrai a caccia di insetti per anni?"

Oltre a ciò, devi conoscere e accettare il vecchio linguaggio: "Perfetto è il nemico del bene".


112
mi ricorda "buono, veloce, economico, scegline due" - quando sapevi di meno ti stavi sacrificando sul "buono", e ora che ne sai di più, ti stai sacrificando sul "veloce".
sevenseacat,

10
@Neil nulla può essere privo di bug. Ci sarà sempre un problema, diventano solo più piccoli o più complessi. Idealmente l'OP dovrebbe trovare un segno in cui si sta completando abbastanza velocemente e lasciando pochi bug sufficienti per essere soddisfatto della sua qualità, e mantenere il cliente felice con costi e tempi
RhysW

10
@Neil "In orario. Con budget limitato. Su Marte. Scegli due."
Dan Neely,

5
@Leonardo: no, la forma di Telastyn è corretta (ed è un detto abbastanza vecchio . Vedi anche YAGNI e "se funziona, non aggiustarlo".
mikołak

3
Questa risposta è una cazzata. Continua, vai e prova a dire a un potenziale cliente che lo farai per 40K anziché 20K ma con 10 volte più qualità e affidabilità. Ti diranno questo: "Il mio budget è di 20.000 e non ho bisogno di quella qualità". Ad un certo punto devi accettare che il 99% dei clienti non si preoccupa davvero della qualità, e qualsiasi qualità ci sarà sarà il tuo investimento personale.
Morg.

179

Sembra che sia tempo che tu ti unisca al lato oscuro: la gestione.

Non sto suggerendo di abbandonare la programmazione e diventare un manager. Ma sembra che tutta l'esperienza che hai citato fino ad ora sia stata di natura tecnica. Nella semplice operazione di scrittura di un file, puoi pensare a 10 diversi aspetti che uno sviluppatore meno maturo non prenderebbe mai in considerazione. Non necessariamente una cosa negativa, ma ...

Il lato oscuro riguarda tutto il valore attuale. Si tratta di fare un investimento minimo per il massimo guadagno (analisi costi-benefici). Nel mondo degli affari tutto si riduce a quanto mi costerà, probabilità di successo, probabilità di fallimento, probabilità di fallimento spettacolare e potenziale guadagno. Fare la matematica; agire in accordo con.

Funziona altrettanto bene quando sei uno sviluppatore: crea un file temporaneo, ignorando le autorizzazioni e le collisioni dei nomi - 5 min. Guadagno netto, il resto del team può iniziare a lavorare su qualsiasi codice dipende dalla presenza di quel file. È una soluzione perfetta? Assolutamente no. Ti porterà al 99%, 95%, forse 90%? Sì, probabilmente lo farà.

Un'altra domanda da porsi: come ti senti riguardo al debito tecnico? Alcune persone pensano che debba essere eliminato. Penso che quelle persone abbiano torto. Proprio come nel mondo degli affari, il debito tecnico ti consente di prendere in prestito "contanti" o "tempo" per consegnare qualcosa prima. Cosa c'è di meglio: una soluzione perfetta in 2 anni o un hack completo che un cliente può utilizzare e acquistare in 4 mesi? Ogni situazione è diversa, ma in alcune situazioni se aspetti 2 anni, il tuo cliente si iscriverà già con la concorrenza.

La chiave è gestire il debito tecnico allo stesso modo in cui un'azienda ben gestita gestisce il debito finanziario. Se non prendi abbastanza, non stai ottenendo un ritorno sull'investimento ottimale. Se prendi troppo, l'interesse ti ucciderà.

Quindi il mio consiglio: inizia a valutare il tuo lavoro in base al fatto che stai massimizzando il tuo valore anziché massimizzare la tua completezza. E se lo pratichi, svilupperai la stessa intuizione che hai già sviluppato nella tua area tecnica.

Come nota a margine, recentemente ho iniziato a fare la tecnica del pomodoro e mi ha aiutato molto. Invece di andare su una tangente di una tangente, concentrati su piccoli intervalli di tempo e poi assegna i pomodoros per il futuro lavoro / ricerca. È incredibile quante volte ho preso appunti per cercare un argomento, ma un'ora dopo, quando è arrivato il momento, ho pensato tra me e me "ci sono almeno altre 3 cose che potrei fare oggi con il mio tempo, che sono tutte più preziose".


9
Quindi secondo te, creare deliberatamente dei bug è accettabile purché si verifichino abbastanza rari?
scai,

87
@scai - scegli le tue battaglie. Sono stato nel settore per 15 anni e non ho visto una versione singola in 3 aziende a cui ho lavorato fino ad oggi, che ha fornito 0 bug. Semplicemente non succede nel mondo reale. Non sto dicendo che hai introdotto intenzionalmente il codice non funzionante, ma c'è un livello di perfezione e correzione dei proiettili che semplicemente non paga
DXM

25
La creazione di un bug "deliberatamente" significherebbe che il bug stesso era intenzionale, il che non è la stessa cosa della consapevolezza della possibilità o dell'esistenza specifica di un bug o incompatibilità. Ho un'app HTML5 che non funziona proprio in IE6, ne sono consapevole, ho persino sospettato che sarebbe stato il caso quando l'ho fatta - è solo che "quelli che contano non importa, e quelli a cui importa non importa ". Puoi consapevolmente costruire un ponte che non resisterà a un attacco nucleare, e va bene.
BrianH,

27
+100 per il tuo introito sul debito tecnico. Come l'OP, ho cercato di eliminare tutti i debiti tecnici. Non avevo mai considerato l'idea che il debito tecnico vada bene, fino a quando l'interesse non inizia a ucciderti. Ora vedo che gestire il debito è molto più importante che eliminarlo. Non ci avevo mai pensato prima. (tra l'altro uso anche la tecnica pomodoro.)
adj7388

6
Questa risposta rispecchia da vicino la mia esperienza e il debito tecnico. Più che crearlo intenzionalmente, semplicemente affidando il lavoro a personale junior, si ottiene naturalmente un debito tecnico, che deve essere risolto in seguito, educandoli nel processo. Fondamentalmente, una volta raggiunto questo stadio, DEVI investire nella conoscenza dei compromessi e pensare in termini di indebitamento del debito che deve essere rimborsato in seguito. Questo perché DEVI affidare il lavoro a personale junior semplicemente perché c'è solo uno di voi, e anche se ciò che ottieni è di qualità inferiore, puoi offrire ciò che sarebbe impossibile solo per te.
SplinterReality,

94

Ho avuto lo (probabilmente) stesso problema molti anni fa, è durato alcuni anni e l'ho superato. Quindi forse sarebbe di tuo interesse sapere come l'ho raggiunto, anche se non sono sicuro che il mio modo si applicherà anche a te.

Dovresti anche dare un'occhiata qui: Le sette fasi di esperienza nell'ingegneria del software Mostra che la produttività è in gran parte un effetto collaterale del livello di abilità. È possibile che tu sia ancora ad un certo punto tra la fase 3 e la fase 4 sulla tecnologia che stai attualmente utilizzando (la competenza delle competenze dipende dalla tecnologia, puoi essere padrone di alcune tecnologie mentre ne stai ancora imparando altre).

Ora parto con una testimonianza biografica.

Un po 'di contesto. Ho 47 anni. Ho iniziato a programmare alle 12 negli anni '80. Al liceo ho anche lavorato come programmatore di giochi professionali part-time. Fondamentalmente non mi ha procurato così tanti soldi, quanto bastava per comprare hardware, ma mi sono divertito e ho imparato molto. A 18 anni ho iniziato un apprendimento formale di Informatica.

Di conseguenza, quando ho compiuto 20 anni, ogni volta che iniziavo qualsiasi attività di programmazione conoscevo molti modi per risolvere i problemi indicati ed ero molto consapevole dei numerosi parametri e insidie ​​che avevo, nonché degli svantaggi e dei limiti di qualsiasi metodo.

In alcuni punti (diciamo circa 26 anni) è diventato davvero difficile per me scrivere qualsiasi programma. C'erano così tante possibilità aperte che non potevo più scegliere tra di loro. Per alcuni anni (ce la faccio 6) ho persino smesso di programmare e sono diventato un giornalista tecnico.

Non ho mai smesso del tutto di provare a programmare comunque. E ad un certo punto è tornato. La chiave per me era la programmazione estrema, in particolare il principio di Semplicità: "Scrivi la cosa più semplice che potrebbe eventualmente funzionare".

Fondamentalmente mi sono costretto a non preoccuparmi dell'efficienza del codice (quello era il mio principale ostacolo, evitare progetti inefficienti), ma semplicemente andare nel modo più semplice. Mi sono anche costretto a preoccuparmi meno degli errori e a ritardare la gestione degli errori in un secondo momento, dopo aver scritto i test che hanno sollevato l'errore (in realtà è TDD).

È qualcosa che ho imparato mentre scrivevo. Quando non so cosa scrivere, o sapevo che cosa stavo scrivendo era male . Andiamo avanti. In realtà scrivi cose cattive. Alla fine lo correggerò più tardi. O se è davvero così brutto cancellarlo e riscriverlo, ma è più veloce scrivere cose due volte che scrivono qualcosa di perfetto la prima volta.

Davvero è molto probabile che un codice che ritieni buono all'inizio abbia bisogno di miglioramenti tanto quanto uno davvero negativo.

Se segui il percorso della Semplicità otterrai anche un bonus aggiuntivo. Accetti facilmente di rimuovere / modificare il design / la codifica iniziale. Ottieni una mente più flessibile.

Ho anche preso l'abitudine di inserire un commento temporaneo nel codice, spiegando cosa non stavo facendo ora e intendevo farlo in seguito quando il codice sarebbe stato funzionale nel normale caso d'uso.

Ho anche partecipato a un XP Dojo praticando code katas con altri programmatori per interiorizzare le pratiche XP. Ha aiutato. Ha reso istintivi i metodi formali sopra indicati. Anche la programmazione delle coppie ha aiutato. Lavorare con i giovani programmatori dà un po 'di slancio, ma con l'esperienza vedi anche cosa non fanno. Ad esempio, nel mio caso, li vedo spesso impegnarsi in progetti troppo complicati e conosco l'incubo del design che può portare a. Andato in quel modo. Fatto quello. Ha avuto problemi.

Il punto fondamentale per me è mantenere il flusso. Essere veloci sta davvero riuscendo a mantenere il flusso.

Ora sono tornato come programmatore professionista e credo di essere sia migliore che più veloce con una comprensione più profonda di ciò che sto facendo. Praticare TDD Potrei essere ancora leggermente più lento di quando ero un giovane toro (e non ho testato nulla), ma non ho nemmeno paura di eseguire il refactoring e certamente dedico molto meno tempo al debug (quasi nessun tempo, rendilo meno del 10% del tempo ).

Riassumendo: ho superato il mio codeblock usando metodi agili (XP), cercando semplicità, poi refactoring e praticando per renderlo istintivo. Ha funzionato per me. Non sono sicuro che possa essere generalizzato a chiunque altro.

In termini di livello di acquisizione delle competenze, ho imparato principalmente ad accettare che ogni volta che cambio tecnologia (imparo nuove lingue, nuove strutture, ecc.), Passerò attraverso una fase in cui rallento. Questo è normale e alla fine lo supererà. Posso anche compensare questo con una buona metodologia e capacità di programmazione per scopi generali e non sarà un problema.


22
+1 per "è più veloce scrivere cose due volte che scrivono qualcosa di perfetto la prima volta"
Brendan Long

2
+1 per la condivisione di una storia personale, che mi aspetto sarà riconoscibile e utile per l'interrogante.
R. Schreurs,

Sono d'accordo, potresti riscontrare il blocco dei programmatori (come il blocco dello scrittore). Non puoi gestire la complessità, quindi fai schifo. La cura è la stessa del blocco dello scrittore; scrivi qualcosa . Non appena avrai qualcosa sullo schermo, ti darà idee su come procedere. Probabilmente ti è stato dato questo consiglio in una forma meno lucida, come "Non preoccuparti di efficienza / errori / qualunque cosa, fai semplicemente qualcosa in fretta". Bene, questa è metà della risposta. L'altra metà è che una volta passato lo schermo vuoto, facendo l' effettiva gestione degli errori, un algoritmo efficiente o qualunque cosa sia semplice.
SeattleCplusplus,

@SeattleCPlusPlus: sono d'accordo che sia semplice per problemi semplici, probabilmente per la maggior parte del codice algoritmico. Non è così semplice quando vuoi ottenere delle buone strutture per le classi. Le regole di refactoring non sono del tutto inutili.
Kriss

41

Una parte importante della programmazione è la gestione e il controllo della complessità e per me personalmente è uno dei problemi principali. Se ignorato, la frequenza delle carenze aumenta o, come nel tuo caso, l'ETA del software finito aumenta notevolmente.

O un aumento delle carenze o una diminuzione dell'ETA

La complessità del software può essere controllata e gestita da molti livelli e modi diversi, ma una buona regola empirica per ottenere qualche prospettiva è questa: "La priorità assoluta di qualsiasi progetto software è la soddisfazione del cliente che è una funzione delle sue aspettative".

In altre parole, la complessità del software dipende in larga misura dalla capacità di controllare le aspettative del cliente.

Quando si adotta quella visione, allora diventano evidenti due punti importanti:

  1. le aspettative del cliente devono essere esplicite (in qualunque forma);
  2. le aspettative dei clienti possono sempre essere modificate e ciò avviene attraverso l'arte della negoziazione.

Il tuo esempio è molto buono, "semplicemente scrivilo" contro "una miriade di altre considerazioni". Pensaci: se qualcuno dovesse scrivere requisiti esaustivi per entrambe le varianti, potrebbe esserci un'equivalenza nelle caratteristiche descritte o no?

Costruire un F16 è diverso dal costruire un Cessna sebbene entrambi possano volare.


24

La semplice risposta è: accettala.

In tutti i sistemi ci sono compromessi tra affidabilità, robustezza, sicurezza, velocità, costo dell'hardware, costo di sviluppo, time to market, il nome. Non sarai sempre d'accordo su come il cliente effettua tali compromessi, ma non sei tu a prendere quelle decisioni. Tutto quello che puoi fare è fornire un'opinione ponderata. Lo sviluppo del software copre l'intera gamma, dalla "mia pagina web personale" a "avviare il reattore nucleare", e il codice deve essere scritto di conseguenza. Se un incidente significa "ricaricare la mia pagina web personale", a chi importa davvero se ciò accade? Ma se un crash significa "Chernobyl", allora la tua preferenza per il codice solido è, se non altro, un po 'casuale per i miei gusti.

Ci sono alcuni client che accetteranno felicemente il codice di livello "Proof of Concept" e lo eseguiranno nei loro sistemi live, e spesso hanno amministratori di sistema che sono abituati a questo. IME i loro sistemi di solito non sono disponibili per circa un'ora nel mezzo della notte mentre si verificano numerosi riavvii programmati. Ma hanno preso la decisione aziendale che è così che vogliono rotolare. Idealmente perché il loro campo è così rapido che un codice di alta qualità non sarebbe mai pronto, ma spesso perché non riescono a vedere il valore (se un sistema "funziona" non lo notano mai, quindi quel sistema non rappresenta valore per i soldi). Se ti dà troppo fastidio, cerca di evitare quei clienti.

Tenersi aggiornati è il tempo che tutti noi dobbiamo spendere, o almeno dovremmo spendere. A volte questo ti farà lavorare, altre volte manterrà la tua mente in buona forma. Ad ogni modo, prova a godertelo.


4
Quel po '"un po' casual per i miei gusti" nel tuo confronto di Chernobyl ha reso la mia giornata. In realtà ho riso ad alta voce :)
Zilk

16

Sembra che le tue abilità siano molto utili per lo sviluppo di sistemi mission-critical di altissima qualità, come applicazioni correlate a finanza / trading, radiodiffusione, aerospaziale, difesa ...

Gli errori in questo tipo di applicazioni sono molto costosi e impiegano persone che la pensano come te in quanto puoi occuparti di tutti i casi.


15

La verità è che i sistemi moderni stanno diventando sempre più complessi. Il computer ora è simile al gioco "Jenga" in cui tutti questi pezzi si basano su molti altri. Estrai il pezzo sbagliato e hai un errore, estrai un pezzo corretto / necessario e potresti ancora produrre un errore. Più complesso è il sistema, più tempo è probabile che passi a pensare a modi per rendere il tuo codice più robusto e, si spera, anche più sicuro. La velocità sarebbe buona, ma penso che la velocità abbia un ruolo importante in questi giorni quando si sente nelle notizie che la società "XYZ" è stata violata e che sono stati rubati 6 milioni di numeri di carte di credito dei clienti.

I tuoi clienti potrebbero non voler sentire che il loro programma deve essere sicuro, robusto, ecc. Ma potresti dire loro che la loro auto non ha bisogno di cinture di sicurezza e airbag né la loro casa ha bisogno di serrature e porte ... perché chi vuole sentire tutto quello?

Se stai pensando troppo, stai affrontando le cose nel modo giusto, tranne per il fatto che devi scegliere una strategia che sembra "concreta" e seguirla.


9

Sembra che tu sia consapevole della tua tendenza a pensare a tutto ciò che può andare storto.

Gli sviluppatori cauti con esperienza spesso imparano a seguire il mantra YAGNI, non ne avrai bisogno, quando provano a tornare a un flusso di lavoro snello, agile e produttivo dopo essere stati troppo soffocati nelle erbacce dell'analisi della modalità di fallimento-impazzita.

Tuttavia, se stai davvero scrivendo qualcosa in un dominio in cui quel livello di assistenza non è inferiore a quanto richiesto dalla professionalità, allora dovresti capire che la tua "velocità", la tua "produttività", in termini netti, è misurabile da quanto bene ( o danno) che stai facendo alla tua azienda, ai tuoi clienti, alla suite di software o alla famiglia di prodotti che stai costruendo o gestendo.

Ricordati di:

  • Includere il costo totale di manutenzione, il costo totale di proprietà e il costo totale dell'implementazione e della manutenzione delle soluzioni quando si considerano i cambiamenti nel proprio approccio. Andare più veloce e fare più errori può o meno migliorare le cose.

  • Se lavori in una buona compagnia, probabilmente puoi discuterne nel tuo team e con il tuo supervisore, senza che si tratti di una mossa di limitazione della carriera. Se non ci riesci, ora è un buon momento per scoprirlo e trovare un nuovo lavoro.


YAGNI mi ha salvato durante questa fase. Questa risposta richiede più voti. Il problema di "Sono troppo lento" non deve essere semplicemente accettato; ci sono momenti in cui è OK sacrificare un'architettura perfetta per farla uscire rapidamente.
Roman Starkov,

7

L'unica cosa che posso vedere è: "Stai diventando sempre più prezioso".

Come e quando ottieni più esperienza impari sulle cose che dovresti evitare, e questo è ciò che ti rende migliore di altri.

Una cosa che avresti notato che il tuo codice sarebbe ora più sicuro e più gestibile.

  • L'unica cosa che devi fare è spiegare al tuo cliente perché ci è voluto del tempo e come sarebbe stato utile per loro.
  • Devi mostrare loro la profondità delle tue conoscenze.
  • Devi dire loro perché l'hai fatto, cosa hai fatto e come sarebbe importante per loro e per i loro affari.

Il mio suggerimento sarebbe di concentrarmi su questa parte.


7

in caso di dubbio impostazione predefinita per citare male Knuth ...

"L'ottimizzazione precoce è la radice di tutti i mali."

Ecco cosa suggerirei, poiché sembra che tu abbia un problema che di volta in volta ho ...

Ciò che funziona davvero per me ...

  1. Scrivi i test unitari, come se tutto il codice fosse stato fatto.
  2. documentare l'interfaccia.
  3. implementare l'interfaccia.

cosa hai veramente fatto:

  1. elaborare i requisiti dei livelli del modello
  2. impostare davvero la divisione del lavoro, quali oggetti sono responsabili di cosa
  3. mettersi al lavoro in un ambiente quando si può effettivamente scorrere il codice di lavoro, il che rende le cose molto più veloci e più accurate ...

fare affidamento anche su affermazioni nei primi sviluppi ... quindi capire quali rimedi devono essere implementati e non scrivere codice non raggiungibile o difficile da testare.


Sembra lo zio Bob, il ragazzo SOLIDO.
Warren P

6

Penso che dovresti attenerti ai tuoi standard di codifica, ma assicurati di essere aggiornato con i tuoi clienti. Molti clienti non sanno cosa ci vuole / costi per costruire un buon software. Fa parte del lavoro dello sviluppatore professionista educarli.

Che tu sia agile o a cascata, ottieni una sorta di accordo dal cliente su cosa si aspettano che faccia l'applicazione. Troppi sviluppatori (OK forse più venditori) sono colpevoli di sandbagging . "Non hanno detto di volere un sito Web altamente sicuro." Nella maggior parte dei casi, è perché non è stato chiesto loro. "Ti dispiace se il tuo sito di e-commerce viene violato?" Naturalmente a loro importa e perché lo costruiresti per permettere a chiunque di penetrare nella sicurezza? Devi educarli.

Assicurati solo di fare solo ciò che il cliente ti sta pagando. Parte del tuo servizio è la tua esperienza. I clienti si aspettano che tu sappia le insidie ​​senza che debbano chiedere. Spetta a loro includere il requisito. Potresti voler passare clienti che vogliono qualcosa di economico.


In realtà hai appena preso l'esempio del peggio: il software web, in cui i php noobs sono ufficialmente competitivi. Il prezzo è un fattore estremamente importante e quando fornisco software di alta qualità, i miei clienti pagano per il software e io pago per l'alta qualità.
Morg.

6

Pensa alle conseguenze pratiche di un bug rispetto a tutti gli altri problemi che devono essere risolti.

Considera le seguenti conseguenze della creazione di un pezzo di codice scritto male:

  1. L'intero database viene scaricato ogni due mesi. 48 ore di inattività durante il ripristino dei backup.
  2. I record dei clienti vengono reticolati. $ 200 di ordini vengono spediti ai clienti sbagliati al mese.
  3. Un ordine viene bloccato in uno stato errato una volta alla settimana. Ordinare le navi ma il magazzino deve chiamare l'helpdesk ogni volta che succede.
  4. Dopo circa due settimane, l'app si arresta in modo anomalo e l'utente deve reinserire i dati per 2 minuti.
  5. Una volta al mese, l'app si blocca all'avvio. L'utente deve terminare il processo e ricominciare.

Il primo è ovviamente inaccettabile. # 2 - # 5 può o non può essere, a seconda della natura dell'azienda. # 2 - # 5 devono essere valutati nel contesto di altri problemi che l'azienda sta affrontando.

Idealmente, # 2 - # 5 non accadrà mai e poi mai. Nella vita reale, con priorità contrastanti, le persone che firmano il tuo stipendio potrebbero desiderare che tu lavori su altre cose piuttosto che scrivere un codice perfetto che non ha mai e poi mai avuto problemi. Non saranno impressionati se il n. 5 viene risolto a spese di non correggere un bug più grave in un altro programma.


5

La soluzione è creare una raccolta di librerie con funzioni di uso comune che è possibile riutilizzare in tutti i progetti. Ad esempio, ho una libreria .NET StringFunctions.dll che esegue operazioni come codifica, crittografia, decrittografia, valutazione delle espressioni regolari, ecc. In questo modo, non devo riscrivere continuamente cose che non cambiano.

Avere un wrapper per le attività di creazione dei file ha anche molto senso. La tua libreria potrebbe esporre un metodo chiamato GetFile () che esegue tutti i controlli per te e restituisce null o un file (o qualunque cosa tu ritenga utile).


4

Penso che tu debba imparare a decidere quanto bisogna fare per quale progetto. Alcuni progetti possono essere banali e non hai davvero bisogno di passare tutto quel tempo a perfezionarlo. Non tutto avrà bisogno di una crittografia solida, né tutto sarà ridimensionato a milioni di utenti.

Scrivere un programma che può scalare bene per più di un milione di utenti richiederà tempo ed esperienza che hai ora, ma se sai che la tua applicazione non verrà utilizzata da più di 1000 utenti al massimo, non ha senso spendere tutto quella volta perfezionandolo.

Penso che questa sia una fase importante della tua carriera di programmatore e ora devi passare al livello successivo, che ha a che fare con la maturità e non con la programmazione. Devi essere in grado di decidere correttamente su quanto tempo e codice dovrebbero essere sufficienti per ogni particolare progetto.

E come tutto il resto, puoi farlo anche con la pratica. Quindi prova a decidere questo prima di iniziare un progetto, a volte anche mentre ci stai già lavorando, con l'esperienza lo supererai anche tu. Potrebbero esserci alcuni successi e mancanze all'inizio ma con il tempo lo perfezionerai (processo decisionale, non codice).


3

@Zilk, non sono un grande programmatore e sto programmando dal 1998. Anche adesso sto affrontando questo problema. Ma quello che ho realizzato è che alla fine la qualità conta. Se muoio oggi, qualcuno dovrebbe essere in grado di riprendere quello che sto facendo ora da dove sono partito. Tali dovrebbero essere gli standard di programmazione (universali).

Mi sono spostato da sviluppatore a architetto ora. Passare alla direzione sta cambiando la linea. Se vuoi continuare con la tua passione, puoi passare a diventare architetto.

Inizialmente come Technical Architect -> Solution Architect -> Enterprise Architect -> Chief Architect e così via.

Come architetto guiderai le persone verso il successo. Persone come te che programmano da decenni quegli anni di esperienza che puoi utilizzare per guidare gli altri.

Come un uccello più in alto, vola più terra che può vedere, così è la tua esperienza.

Consentitemi anche di dirvi che programmare un'implementazione corretta è importante piuttosto che programmare un'implementazione errata più velocemente. Recentemente uno dei miei ragazzi ha programmato qualcosa di sbagliato e costa un sacco di soldi in banca. Naturalmente avevamo consegnato in tempo prima ma non era utile! Mi è stato dato il ruolo di guida anche se lo stesso junior avrebbe codificato quel problema non si sarebbe verificato. Sto dando questo esempio per sottolineare che anche dare una buona guida è importante. Alcuni chiamano questo lavoro come consulenza.


3

Un'altra opzione è: smettere di scrivere codice, invece vendi la tua esperienza nello individuare i problemi in anticipo.

In altre parole, diventa un consulente .

Molte organizzazioni sono felici di pagare dollari costosi (se non il massimo) per qualcuno per individuare i problemi prima di spendere mesi per creare il codice che crea i problemi. È risaputo che correggere un bug nella progettazione è più economico / semplice rispetto agli ordini di grandezza che risolverlo dopo che è stato codificato, testato e distribuito.

Non scriverai più codice e probabilmente ti mancherà, ma allora sembra che le linee di codice effettive non siano il tuo punto di forza, ma nel sapere quali righe di codice dovrebbero essere scritte e quali no.

Concentrati sui tuoi punti di forza.
(beh, se è quello che ti piace ...)


2

La mia migliore raccomandazione per te è: blocchi.

Crea un building block di cui ti puoi sempre fidare, creane uno per la tua API, smetti di perdere tempo a scrivere sempre la stessa cosa. Pensa a ogni problema una volta e risolvilo una volta per tutte.

Nessuno riuscirà a raggiungerlo, sicuramente non i principianti che impiegano l'80% del loro tempo a eseguire il debug del codice che fallisce per casi angolari che non comprendono.

Soprattutto, non risolvere i problemi che non possono verificarsi, ad esempio autorizzazioni errate.

Se le autorizzazioni sono errate, qualcosa è già sbagliato e dovresti risolverlo piuttosto che rendere il tuo programma a prova di proiettile.

Ad un certo punto devi semplicemente non spararti al piede invece di controllare sempre se l'hai fatto o no.

Invece di dedicare tempo alla documentazione, dedica del tempo a rendere il tuo codice auto-documentante e il più breve possibile. Sostituisci tutte quelle funzioni duplicate. Riduci la tua libreria, rinomina le cose con precisione.


1

Non essere troppo duro con te stesso. Stai lavorando in una professione di crescente complessità, che richiede più intelligenza umana, conoscenza ed esperienza che mai.

La potenza di elaborazione del computer sta rallentando - forse presto in fase di stallo - portando alla necessità di introdurre chip multi-core, numeri alimentati dalla gpu, parallelismo, ecc. Ci sono solo così tanti transistor che possono essere posizionati su un chip.

Pertanto, i grandi progressi attuali e futuri verranno dai programmatori: algoritmi avanzati e codice più efficiente.

Se guardi a GTA 4 e GTA 5 le differenze sono sorprendenti. Entrambi funzionano sullo stesso hardware. Questo è il risultato di alcune pratiche di programmazione molto intelligenti e avanzate che semplicemente non erano richieste o disponibili 10 anni fa.

Potrebbe anche significare che programmatori esperti potrebbero diventare più preziosi in futuro, proprio come altre professioni come l'ingegneria in cui i picchi di guadagno si verificano in genere alla fine della carriera.


1

Proprio come te, ho iniziato a programmare all'età di 14 anni, anche quando ho avuto il mio primo computer (anche se a quel punto avevo studiato per alcuni mesi). Tuttavia, sono "solo" 33 ora. :-)

Il mio suggerimento è che, quando sviluppi qualcosa, prendi ognuna di quelle preoccupazioni (permessi dei file, numero di file in una directory, ecc.) E poi usi tutta la tua vasta esperienza per rispondere ad alcune domande a riguardo, con questo spirito:

  • Quanto tempo ci vorrebbe per gestire correttamente quel problema nel tuo codice?
  • Se non lo gestisci correttamente, quanto è probabile che questa cosa ti morda in seguito?
  • Se ti morde, quali sono le conseguenze?

Armato di quelle risposte, un ragazzo così esperto non avrà problemi a prendere una decisione saggia. ;-)

È responsabilità dei "veterani" come te elaborare questo tipo di requisiti, e ciò implica sia identificare ciò che può andare storto sia decidere a quali potenziali problemi dovresti prestare attenzione.


1
La reazione del PO è che tutti i potenziali problemi osservati devono essere prevenuti. Questo potrebbe essere vero quando stava iniziando come programmatore junior (perché i potenziali problemi che identificava di solito significavano un enorme miglioramento della qualità), molto probabilmente non è più vero: come spiega @igorrs: non concludere automaticamente che ogni il potenziale problema che vedi deve essere prevenuto - decidi consapevolmente se è necessario. Questo è il vantaggio che hai rispetto ai programmatori junior: possono solo prevenire ciò che possono vedere, mentre puoi prevenire ciò che effettivamente ha bisogno di essere prevenuto.
Astrotrain,

0

Conoscere tutti i possibili criteri durante lo sviluppo di app è la cosa più importante nello sviluppo di un prodotto di qualità. Stai andando bene in questo. Una cosa che puoi fare è, puoi classificare il requisito in livello di qualità, quindi mappare il livello con la scadenza indicata. In questo modo è possibile rispettare facilmente la scadenza del progetto.


0

Nelle parole di Edsger Dijsktra: "Se il debug è il processo di rimozione dei bug del software, allora la programmazione deve essere il processo per inserirli." Stai solo facendo meno di quest'ultimo, quindi devi fare meno del primo. È solo una questione di imparare a passare il tempo a codificarlo nel modo giusto. Sono ancora un programmatore relativamente giovane (leggi 20ish) e aspiro di essere in grado di programmare qualcosa completamente giusto una volta. Un'ora di pianificazione e 10 minuti di programmazione è molto meglio di 10 minuti di pianificazione, un'ora di programmazione e tre di debug.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.