Cose che ogni programmatore Java dovrebbe sapere

da java Code geek

A ui-programmazione , uno dei nostri JCG siti partecipante al programma, articoli su "Le cose ogni programmatore dovrebbe sapere" sono occasionalmente inviati. Come indicato nel dell'autore primo post , i 97 cose che ogni programmatore dovrebbe sapere progetto, perle di saggezza per i programmatori raccolti da professionisti di primo piano. La collezione è volto semplicemente a contenere molteplici prospettive e varia su che cosa è che i collaboratori al progetto sentire i programmatori dovrebbero sapere. Questo può essere qualsiasi cosa, dal codice orientata consulenza alla cultura, dall'uso algoritmo per il pensiero agile, dalla implementazione del know-how alla professionalità, dallo stile alla sostanza, eccIn questo articolo mettiamo a disposizione una sintesi dei primi 27 "Cose ogni programmatore dovrebbe sapere "! Allora, li inizio, senza ulteriori indugi ...

1. Agire con Prudenza da Seb Rose

Anon "Qualunque cosa vi impegnate, agire con prudenza e considerare le conseguenze"

Non importa quanto sia comodo un programma appare all'inizio di una iterazione, non si può evitare di essere sotto pressione per qualche tempo. Se vi trovate a dover scegliere tra "facendo bene" e "lo fa veloce" è spesso appello a "fare in fretta" con l'intesa che tornerai e risolvere in un secondo momento.Quando si effettua questa promessa a te stesso, la tua squadra, e il vostro cliente, sul serio. Ma troppo spesso la successiva iterazione porta nuovi problemi e si diventa concentrata su di loro.Questo tipo di lavoro differita è conosciuto come debito tecnico e non è tuo amico. In particolare, Martin Fowler chiama questo debt deliberata tecnico nella sua tassonomia del debito tecnico , che non deve essere confuso con involontario debt tecnico . debt tecnica è come un prestito: è beneficiarne nel breve termine, ma si deve pagare gli interessi sui finché non è completamente ripagato. Collegamenti in codice rendere più difficile per aggiungere funzionalità o refactoring del codice. Essi sono terreno fertile per difetti e casi di test fragile. Più a lungo si lascia, peggio è. Con il tempo di andare in giro a intraprendere la correzione originale ci può essere un intero stack di non-proprio-destra scelte di design a strati sulla parte superiore del problema originale rendendo il codice molto più difficile da refactoring e corretta. In effetti, è spesso solo quando le cose sono così male che si deve risolvere il problema, che in realtà si va indietro per risolvere il problema. E da allora è spesso così difficile da risolvere che davvero non può permettersi il tempo o il rischio. Ci sono momenti in cui è necessario indebitarsi tecniche per rispettare una scadenza o implementare una fetta sottile di una caratteristica. Cerca di non essere in questa posizione, ma se la situazione lo richiede assolutamente, poi andare avanti. Ma (e questo è un grosso MA), è necessario tenere traccia debito tecnico e pagare di nuovo rapidamente o le cose vanno in rapida discesa. Non appena si effettua la decisione di compromesso, scrivere una carta di un'attività o di log nel proprio sistema di tracciamento per assicurarsi che non venga dimenticato. Se si programma di rimborso del debito nella successiva iterazione, il costo sarà minimo. Lasciando il debito non pagato matureranno interessi e che gli interessi devono essere monitorati per rendere visibile il costo. Questo metterà in risalto l'effetto sul valore di business del debito tecnico del progetto e consente la definizione delle priorità del rimborso. La scelta di come calcolare e monitorare l'interesse dipende dal particolare progetto, ma traccia la si deve. Pagate i debiti tecnici il più presto possibile. Sarebbe imprudente fare altrimenti.

Corso Java - Corsi Java - Corsi programmazione Java

Corso programmazione Android - Certificazione Android