2009-08-21 6 views
6

Sono un grande sostenitore dei metodi agili quando si lavora su team e/o progetti di grandi dimensioni.Lavorare da solo su piccoli progetti: Cowboy Coding The Way To Go?

Tuttavia, per i progetti più piccoli, quando lavoro da solo, di solito avvio il progetto scrivendo test di unità, documentando ampiamente, refactoring. Mentre il tempo scorre, mi fermo perché mi sento come se stessi perdendo tempo. Trovo che la codifica da cowboy con uno spin agile (testare spesso, scrivendo codice leggibile dall'uomo) spesso funzioni molto bene per me su piccoli progetti solisti che non mi aspetto che gli altri debbano lavorare.

Altre persone condividono il mio sentimento? O pensi che uno non dovrebbe mai attenersi alle loro pistole (prendilo? Cowboy)?

Quindi la vera domanda: ci sono delle metodologie agili che sono particolarmente adatte a un progetto solista? (Altro che il mio metodo del "cowboy agile" di cui sopra)

risposta

4

Agile è una filosofia, non una prescrizione. Usi i pezzi che si adattano al tuo stile di sviluppo, al tuo progetto e alle tue esigenze aziendali.

Penso che la tua proposta di "testare spesso, scrivere codice leggibile da un uomo" sia un approccio perfettamente adatto per realizzare un buon software in una squadra solista per piccoli progetti.

+0

Anche se deve essere piuttosto flessibile, lasciare fuori alcuni pezzi di Agile è completamente folle. Se non ti rifatti, stai semplicemente buttando fuori dal finestrino tutto il design. Se non si esegue il test, non è possibile effettuare correttamente il refactoring. Agile è come una ruota in cui una pratica spesso abilita il prossimo - spezza la catena e tutto cade a pezzi - poi viene aggredita. –

+0

Non sono d'accordo con la tua affermazione secondo cui "tralasciare alcuni pezzi di Agile è completamente folle". In effetti, in realtà penso che quel tipo di vista sia in qualche modo dannoso. Ogni organizzazione e ogni progetto avranno esigenze specifiche, ed è importante valutare quali strumenti e tecniche vi aiutano ad arrivare. Fortunatamente, il refactoring è uno dei più facili da scegliere (il che potrebbe essere il motivo per cui pensi sia sciocco metterlo da parte), quindi i progetti più agili fanno davvero il tempo per una sorta di periodici tentativi di refactoring. –

1

codifica Cowboy e il processo agile non sono la stessa.

Per quanto riguarda i piccoli progetti personali, ovviamente ci sono molte cose che potrebbero essere eccessive. Lo sviluppo agile, le iterazioni brevi, la frequente revisione del codice e il codice di auto-documentazione sono la strada da percorrere.

+0

Devo ammettere che sono colpevole di lunghe iterazioni quando arrivo in questa modalità. Di solito mi sorprendo prima che sia troppo tardi. – snicker

2

Si potrebbe desiderare di guardare di c2.com Solo Programming Xp Workarounds. Cardboard Programmer è uno per qualche motivo che ho trovato particolarmente divertente. Potresti forse scrivere con un cartone di Jon Skeet accanto a te?

+2

Sento meravigliose opportunità commerciali qui. Chi sarà il primo a ottenere un accordo esclusivo con Jon? ;) –

+0

Non froget the Rubber Ducking: http://c2.com/cgi/wiki?RubberDucking –

+0

Ero solito parlare con il cane, in realtà, quindi trovo la validità in questo. – snicker

0

Attualmente sto lavorando da solo su un progetto ASP.NET (anche se non piccolo). Uso TDD parecchio, e trovo che non impiegare più tempo per sviluppare TDD, infatti risparmio tempo.

Questo è principalmente dovuto al fatto che la suite di test unitari rende molto veloce sia il test che il debug del sistema. Per esempio. quando una funzione non funziona come previsto, è molto più veloce collegare il debugger al processo NUnit, piuttosto che avviare il server Web in modalità di debug, navigare verso la pagina corretta (prima passando la schermata di login), ecc. Quindi, non avendo i test unitari, avrei speso molto più tempo a testare e debuggare.

E i test di unità anche mi aiutano la creazione di un sistema ben progettato, come mi costringe a creare un design più debolmente accoppiati.

0

Direi che il numero di persone che lavorano al progetto non è l'unico fattore da considerare. Penso che il motivo per cui trovi l'Agile completo (documentazione, refactoring, unit test .......... probabilmente non sono proprio Agile però, sono stati in giro per molto tempo) per essere tempo -salvare è perché i progetti solisti tendono ad essere piccoli progetti.

Per progetti di dimensioni maggiori che si estendono su più di mezzo anno, mi aspetterei davvero che un processo adeguato ti aiuterebbe davvero. Puoi visitare qualche codice che scrivi 5 mesi prima. Senza documentazione, è uguale al lavoro di altre persone. Senza test, hai la paura di cambiarlo come cambiare il codice di altre persone.