-
Qualsiasi sciocco può scrivere codice che un computer può capire. I buoni programmatori scrivono codice che gli umani possono capire.
-
Se sei un lead tecnico, devi essere codificatore.
-
La completezza è nemica della comprensibilità.
-
Una delle cose che ho cercato di fare è cercare regole più semplici o alla base di un design buono o cattivo. Penso che una delle regole più preziose sia evitare la duplicazione. "Una volta e solo una volta" è la frase di Extreme Programming.
-
...se hai paura di cambiare qualcosa è chiaramente mal progettato.
-
Quando utilizzare lo sviluppo iterativo? È necessario utilizzare lo sviluppo iterativo solo su progetti che si desidera avere successo.
-
L'integrazione continua è una pratica di sviluppo software in cui i membri di un team integrano frequentemente il loro lavoro, di solito ogni persona si integra almeno quotidianamente, portando a più integrazioni al giorno. Ogni integrazione è verificata da una build automatizzata (test incluso) per rilevare gli errori di integrazione il più rapidamente possibile. Molti team trovano che questo approccio porta a problemi di integrazione significativamente ridotti e consente a un team di sviluppare software coeso più rapidamente.
-
Ora sono una persona piuttosto pigra e sono pronto a lavorare abbastanza duramente per evitare il lavoro.
-
Non posso scegliere se qualcuno è offeso dalle mie azioni. Posso scegliere se mi interessa.
-
Quando in realtà ti siedi a scrivere del codice, impari cose che non hai ottenuto pensando a loro in termini di modellazione...c'è un processo di feedback lì che puoi davvero ottenere solo dall'esecuzione di alcune cose e vedere cosa funziona
-
Perché comporre sinfonie è difficile? Non lo so. Solo poche persone al mondo possono farlo bene. E penso che sia il caso del design upfront. È molto difficile fare bene.
-
Mai negli annali dell'ingegneria del software era tanto dovuto da così tanti a così poche righe di codice
-
Trovo che la scrittura di test unitari aumenti effettivamente la mia velocità di programmazione
-
In quasi tutti i casi, Ia € ™m contrario a mettere da parte il tempo per refactoring. A mio avviso il refactoring non è un'attività che si riserva il tempo di fare. Il refactoring è qualcosa che fai tutto il tempo in piccole esplosioni.
-
Il confronto con un'altra attività è utile se ti aiuta a formulare domande, è pericoloso quando lo usi per giustificare le risposte.
-
Un modello è un'idea che è stata utile in un contesto pratico e probabilmente sarà utile in altri.
-
Quindi spero Ia € ™ ve chiarito che imporre metodi agili è una bandiera molto rossa.
-
È impossibile non notare Ruby on Rails. Ha avuto un enorme effetto sia all'interno che all'esterno della comunità Ruby... Rails è diventato uno standard a cui si confrontano anche strumenti ben consolidati.
