Pratiche di sviluppo delle applicazioni in un'azienda non software [duplicato]

Suggerimenti:

1. passa il test di Joel . Questo risolverà la maggior parte dei tuoi problemi (come nota: il passaggio non significa che devi controllare tutto, ma se hai un punteggio inferiore, ad esempio, all'80%, dovresti considerare il test fallito).
2. Se non pensi di poter realizzare il # 1, passa comunque il test Joel . Fidati di me, è solo meglio così. (La seconda regola per fight club essere uno sviluppatore ...)
3. Respingi completamente l'idea di "non essere un'azienda di software". Il tuo dipartimento sta sviluppando software? Quindi, per tutti gli intenti e scopi focene intensi , dovresti comportarti come se il prodotto fosse l'applicazione di output. Nessuna eccezione, nessuna scusa: se stai creando software, allora stai costruendo software.
4. Il numero di volte in cui le migliori pratiche di sviluppo del software non sono l'idea migliore sono estremamente rare. Ad esempio: i test unitari sono i migliori a meno che tutta l'applicazione stia facendo la stampa "Hello world". Anche in questo caso, dovresti avere verificato test di integrazione e controllo qualità.
5. Leggi Il mese di Mythical Man . Se riesci a far leggere al tuo capo, fallo andare. Se no, almeno gli fai il favore di dire "Ehi, ho appena trovato un libro davvero fantastico, lascia che te lo dica."

Alcune regole che ho trovato che dovrebbero essere applicate immediatamente:

1. Nessun codice va in produzione che non sia nel controllo di versione. La compilazione deve essere eseguita dal repository centralizzato.
2. Nessun codice non testato in produzione. Nessuna eccezione. Se stai pensando di fare un'eccezione, colpisci te stesso. (Non so del resto del mondo, ma sono stato veramente masterizzato da questo).
3. La conoscenza ridondante è economica. Il lavoro ridondante è costoso - assicurati che ci siano almeno due persone che sono almeno ragionevolmente aggiornate su un dato progetto (la persona che ci lavora e qualcun altro. Se usi la programmazione di coppie, allora dovrebbe essere sufficiente). In questo modo, se qualcuno va in vacanza a Mount McKinley o in qualche altra località lontana, ci sarà un modo per coprire fino a quando quella persona non ritorna. (O peggio, chiamare qualcuno in vacanza (chiamare qualcuno in vacanza, in un modo infallibile per infastidirli)).
4. Nessun codice non documentato - tutti i metodi pubblici devono avere almeno una riga che descriva quello che fanno, anche se si ritiene che il nome sia "auto-documentante".
5. Qualsiasi persona che sta attualmente lavorando su un codice che dovrebbe entrare in produzione dovrebbe essere soggetta a revisione del codice. Ciò è particolarmente vero per le persone che ritengono di non aver bisogno della revisione del codice.
6. Infine ricorda gli acronimi che dovrebbero essere cercati nelle revisioni del codice: DRY , KISS , YAGNI , ecc. .

Per la tua sanità mentale, ricorda PEBKAC , ma non dirlo agli altri.

Suggerimenti

• Cambia architettura

Da un punto di vista della manutenzione le soluzioni basate sul web sono molto più facili da gestire perché controlli il codice sul back-end. Non devi supportare più versioni di un'app e puoi gestire più facilmente i rilasci e distribuire le correzioni. Di nuovo, questo è tutto perché controlli il back-end.

• Scegli le tue battaglie

Sei una società di software perché fai software. Detto questo, potrebbe essere necessario scegliere le battaglie quando si tratta di modificare il processo. Apporta alcune modifiche, documenta i benefici che producono e quindi proponi di più. Troppo cambiamento allo stesso tempo (anche se è tutto per il meglio) può essere disastroso e può rendere la compagnia meno disposta a cambiare. Il cambiamento graduale è molto più facile da accettare, soprattutto se si accumula un track record di successi.

• Le basi

Sistema di controllo della revisione, tracciamento dei bug (suggerisco Redmine), questi sono i principi fondamentali per lo sviluppo. Questi dovrebbero essere facili da spingere perché riguardano l'organizzazione e la protezione delle risorse aziendali.

• Acquista i tuoi colleghi sviluppatori

Sei destinato al fallimento, a meno che tu non abbia incaricato i tuoi colleghi sviluppatori di effettuare l'acquisto per modificare il tuo processo.

• Più avanti

Test automatici, integrazione continua, utilizzo del database, consolidamento delle funzionalità nelle librerie, ecc.

I have been tasked by my manager to propose suggestions and guidelines for our development team. Mind you, I am not optimistic that anyone will actually heed them, but I have to propose them none-the-less. Most of the suggestions I have found are for software companies. I have been informed by other people at my company that such practices would be "overkill" at our work.

Sarei tentato di voler avere alcuni documenti diversi per gestire questo:

• Fine stato: quali sono le cose che ti piacerebbe vedere essere usate che non sono al momento. È qui che puoi avere i sogni grandiosi dello stato alla fine dell'arcobaleno.

• Piani di transizione - Assegna la priorità all'elenco di quali pratiche in termini di quali è probabile produrre i migliori cambiamenti e scrivi un piano per portarli lentamente in un lungo periodo di tempo. Questo è un po 'come la mappa stradale per arrivare a quello stato finale ed è un documento separato perché è dove potresti avere alcuni scontri in termini di come ottenere questo risultato.

• Pericoli dello stato corrente - Qui è dove spieghi perché le transizioni dovrebbero essere fatte per uscire dal caos attuale che hai ora.

Sembra che tu sappia abbastanza bene quali sono i problemi, il problema è far accettare le soluzioni. I processi che hai trovato per lo sviluppo di software per un'azienda IT si applicano a chiunque tenti di scrivere software valido. Il software non può dire se sei un'azienda IT (se è possibile - sei sicuramente una società IT).

Chiedi se il processo corrente sta producendo i risultati che vogliono - se sono a posto con rapporti di analisi che possono essere o non essere precisi prodotti personalizzati da zero ogni volta senza alcuna possibilità di supportarli o riutilizzare il codice oi dati per richieste future, quindi il tuo attuale "processo" (o quasi qualsiasi processo) va bene.

Se una di queste cose è considerata un problema, fare le cose che devi fare risolverle è per definizione non eccessivo.

Seguendo la nozione "scegli le tue battaglie" ...

Il più grande colpo per il tuo buck / sforzo sarebbe un sistema di controllo della versione. Discutere, portare le persone dalla tua parte, convincere la direzione a fornire un seminario di formazione di una settimana per gli sviluppatori su come utilizzare lo strumento. Se riesci a tirarlo fuori, sarai in grado di creare un minimo di ordine nel caos.

Se ci stai ancora lavorando quando finalmente viene utilizzato, puoi affrontare l'introduzione di database e altre cose. Ma onestamente, penso che se vuoi sviluppare come ingegnere del software, l'ambiente ti rallenterà.

Fai del bene, aiutalo, ma usalo come trampolino di lancio per un lavoro migliore.