Come dovrei convalidare il codice quando non c'è nessuno per fare la revisione del codice? [duplicare]

Le storie degli utenti dovrebbero essere scritte insieme al cliente.

Sei il cliente?

Se è così, allora accetta le tue storie. In caso contrario, pianificare il tempo di revisione / scrittura con il cliente.

Se stai sviluppando un sistema online per la tua azienda, ciò implicherebbe che qualcuno oltre a te debba avere un'idea di come dovrebbe funzionare almeno a livello di interfaccia utente. Questo sarebbe il livello in cui il tuo lavoro può essere rivisto da altri all'interno dell'azienda.

Sfortunatamente, ciò significa che nessuno può rivedere il tuo codice. Una possibilità è che puoi rivedere il tuo codice. Potrebbe essere utile tornare indietro e guardare il codice una settimana circa dopo averlo terminato, e vedere se riesci ancora a capirlo. In alternativa, puoi provare a far assumere alla tua azienda un altro sviluppatore.

Come unico sviluppatore, penso che devi solo lasciar perdere (speranzosamente) alcune delle tecniche professionali che i team più grandi hanno. Ma puoi fare alcuni sostituti!

Devi sempre usare i repository. Probabilmente dovresti fare più test di prima (dal momento che non c'è altra persona in grado di cogliere errori).

Se sei in grado, fai in modo che ogni funzione o aggiunta sia un set / banco di lavoro separato (o ramo in git), in modo da poter creare alcune funzionalità, testarlo e quindi ignorarlo per 1-2 settimane (probabilmente è più lungo) . Quindi leggi l'intero scaffale. Ora: se non hai problemi a capire immediatamente ogni riga di codice, considerala accettabile codice revisionato (come 1 persona penso che sia il meglio che puoi fare). Se ci sono parti del codice in cui non capisci immediatamente ogni aspetto del codice, dedica un po 'di tempo in più per vedere se puoi renderlo più semplice o più comprensibile.

Meglio di tutto quanto sopra è quello di indurre il tuo capo ad assumere un altro programmatore e un peer review reciproco.

Buona fortuna!

Benvenuti nel mondo della microgestione.

Il luogo in cui il capo perde denaro e i tecnici preparano il caffè per gli altri

La maggior parte delle tecniche di sviluppo agili che hai imparato fino ad ora, in questo momento diventano non applicabili. Il problema principale è che in assenza di un team di sviluppo, ciò che rimane è forse "programmazione estrema". Il mio consiglio è di renderlo chiaro all'azienda (indipendentemente dalle dimensioni di questo), questa situazione è sostenibile solo se il software è sviluppato a livello amatoriale. Questo non ha nulla a che fare con il tuo ruolo, puoi continuare a sviluppare applicando tutte le tecniche che conosci, ma solo a livello di progettazione e sviluppo del software. Continua, forse, a sviluppare usando TDD, disegnando casi d'uso in UML, ecc. Ma un prodotto ha bisogno di più membri da sviluppare, eseguire il debug, ottimizzare, implementare, pubblicizzare ...

Do not forget that the development of a product, must pass through a strong criticism, survive this, and then have its path of continuous integration. as programmers, we do not digest well the criticism of others and we often need a brilliant idea from others, BUT when they are not there, we become omnipotent and all the errors becomes ours.

Credo che il capo (come definito), abbia un rifiuto alla spiegazione di un tecnico, questi normalmente portano alla necessità di spendere soldi, e in un'azienda in cui non esiste un budget definito per il dipartimento tecnico, questo può generare conflitti tra amministratori e tecnici.

My advice is to invest in training managers, without giving much explanation and even in small projects, organize your work ready to welcome new members in the development team.

Alcuni suggerimenti

1. Usa sempre repository , forse un bel progetto su github, con il tuo codice organizzato come Super Project
2. Dedica il tuo tempo a definire almeno quali sono le pietre miliari delle richieste che ti vengono fatte;
3. Organizza la tua pietra miliare in semplici fogli di calcolo online , ora non hai bisogno di grandi project manager, diagrammi di Gantt, controllo delle risorse, flussi di denaro, ecc.
4. Sempre comunica l'avanzamento del tuo lavoro tramite e-mail e allega lo stato del tuo traguardo in PDF;

Penso che il metodo che scegli oggi, debba mostrare cosa fai e quanto tempo passi.

ultima considerazione

se mostri a un Boss, 10 milestone , 3 di questi sono stati codice di scrittura e l'altro diviso tra, debug, design , installa, prova, in quel momento hai un ottimo strumento per dialogare con l'amministrazione ...

in quel momento, parli la loro lingua.

I'm not just the only developer, but the only IT person at all. I'm inclined to have my coworkers and/or boss...

A volte in quella situazione è utile invitare un amico anche se non sa assolutamente nulla dei computer. Potresti incontrarti a casa, o in un altro posto, e puoi mostrargli il tuo codice, oppure può mostrarti il suo codice. Nella mia esperienza è stato mio amico, e di solito ha colpito un pezzo di codice, in seguito ho trovato spesso un errore.

Un buon approccio può anche essere quello di provare a dimenticare in qualche modo cosa fa il codice. Basta dormire, fare una passeggiata o addirittura cambiare il progetto. Quando dimentichi completamente l'attività completata, prova a rientrare nel progetto, leggi il codice e ricostruisci lo scopo del codice. Cerca di capire di nuovo il codice, vedrai molte nuove idee e persino errori in esso. Non aspettare troppo a lungo, però!

Questo approccio può essere applicato anche quando scrivi un articolo.

Per valutare il tuo codice puoi utilizzare strumenti automatici come PMD , Findbugs , Sonar , ecc. Quale di questi ha una serie di regole che valutano il tuo codice rispetto alle migliori pratiche e modelli di design. Ti permettono anche di creare nuove regole per abbinare i tuoi modelli e la progettazione dell'architettura. Puoi eseguirli integrati sul tuo IDE, su un server CI (come Jenkins ) o su un semplice script batch.

Non sono perfetti, ma possono dare un aiuto mentre non hai un altro sviluppatore per rivedere il tuo codice. Sono gratuiti e possono essere programmati per funzionare ogni notte in modo da ottenere un rapporto nuovo ogni mattina. :)

Se sei l'unico operatore IT, non ha molto senso convincere qualcuno a controllarti il codice. Nessuno avrà idea di cosa significhi e indicherà solo cose banali come gli errori di ortografia.

Fai ampio uso dei test unitari. Presta attenzione agli avvertimenti del compilatore e considera l'utilizzo di strumenti di qualità automatica del codice (ma preparati a ignorare o disattivare molti avvisi inutili da loro).

Solo preoccuparsi di chiedere alle persone intorno a te se il tuo codice fa o meno quello che vogliono. Se è confuso, o non funziona per loro, risolvilo. Se sono felici, il tuo codice deve essere OK.

Quando lavori in piccole aziende, è normale indossare molti cappelli. Prendi l'esempio più estremo, quando l'azienda viene creata per la prima volta, hai ancora ruoli di sviluppatore, tester, analista, vendite, contabilità, marketing ecc ..., ma probabilmente solo 2 o 3 persone condividono il lavoro.

In questo caso, è abbastanza probabile che tu stia facendo l'analisi di ciò che è necessario, sviluppo, test, distribuzione, mantenimento e supporto. Mentre è preferibile che ci siano più persone che coprono questi ruoli sia dal punto di vista della qualità che della continuità aziendale, in una piccola azienda che potrebbe essere un lusso costoso.

Il miglior consiglio che posso dare è di essere sempre chiaro su quali sono i ruoli, e di pensare come se steste eseguendo ognuno di questi ruoli quando stai eseguendo i loro compiti sul progetto. Con il passare del tempo questo processo diventerà più fluido e ti sentirai più a tuo agio nel pensare in anticipo e nel gestire le responsabilità in competizione.

Se fossi al momento il tuo manager, sarei interessato a vedere se è possibile passare alla sfida che ci attende e assumerne la proprietà.