Impostazione di una guida di standardizzazione dello sviluppo per programmatori interni / fornitori

Question

Impostazione di una guida di standardizzazione dello sviluppo per programmatori interni / fornitori

#1 da (4 voti)
#2 da (0 voti)

0

Recentemente sono stato assunto da una grande multinazionale per dirigere lo sviluppo mobile per il loro team di vendita / assistenza. In una compagnia di quasi 10.000 persone sono, almeno in America, l'unico sviluppatore mobile. Stanno testando le acque e la fase 1 (temp-to-hire) è andata abbastanza bene per loro.

Ora stanno pensando di espandersi ad altri sviluppatori per le loro altre operazioni di vendita / team di supporto e sono stato incaricato di assistere / guidare la stesura di una guida alla standardizzazione per la programmazione iOS.

Sono un grande sostenitore nel dare alle persone la libertà di lavorare nel modo in cui più si sentono a proprio agio ma, allo stesso tempo, sono stato il creatore e il destinatario di grande palle di fango . Avendo imparato attraverso l'esperienza ho diversi standard che seguo religiosamente come commentare, a volte quasi tutte le righe - solo cose brevi ma sufficienti per far sapere a qualcun altro cosa sta succedendo e usando il marchio #pragma - DESCRIZIONE per bloccare metodi come mentalità, indentazione, denominazione classi con un prefisso per evitare conflitti nello spazio dei nomi, ecc. ecc.

Quindi immagino che quello che sto cercando non sia quello di dire a un altro programmatore come dovrebbero scorrere attraverso un array, ma piuttosto una standardizzazione di base in modo che chiunque possa entrare nel progetto di qualcun altro e orientarsi con poca curva di apprendimento. Mi piacerebbe vedere in quale altro modo le persone usano per mantenere il controllo su un gruppo di sviluppo software.

development-process ios

posta PruitIgoe 19.02.2013 - 17:46

fonte

2 risposte

Leggi altre domande sui tag development-process ios

La licenza Apache o la licenza GPL proteggeranno i miei marchi? Domanda memcached di base

score 4 · Answer 1

Una guida per la standardizzazione è buona e buona, ma deve essere accompagnata da altro - chiunque può ignorare un documento. Spesso le persone iniziano con buone intenzioni a seguire un documento, ma possono spesso cadere per strada.

Implementare cose come recensioni di peer code, o uno strumento come FXCop per il controllo della progettazione del codice come parte del processo di compilazione può aiutare questo tipo di cose.

score 0 · Answer 2

"Standard di processo" è VALE oltre l'ambito di qualsiasi risposta possibile qui. L'esito finale dipende molto dal settore e dai clienti che supporti. CMMI è necessario se vuoi fare un lavoro di governo. All'altro estremo, guarda in Agile. Molto probabilmente, cadrai da qualche parte tra i 2 approcci. Tuttavia, tieni presente che, per quanto tu possa definire meticoloso il tuo processo di sviluppo, la tua grande palla di fango sarà evitata solo se hai sviluppatori di qualità. E i tuoi sviluppatori di qualità eviteranno quella grossa palla di fango anche senza un processo. Tuttavia, avere un processo definito è ancora valido perché almeno avere un piano e dei passi da seguire faranno almeno spingere le persone a tentare di fare le cose correttamente e coerentemente; anche se non sono in grado di farlo con qualsiasi qualità.

"Gli standard di codifica" possono essere trovati su Internet per qualsiasi lingua di scelta. Le uniche parole di cautela che aggiungerò è che più regole hai meno probabilità di seguire lo standard. Quindi scegli le regole più importanti e lascia perdere. Inoltre, hai davvero bisogno di uno strumento che aiuti a far rispettare gli standard di codifica. E non intendo uno che darà semplicemente degli avvertimenti. Prendi uno che aiuti a correggere automaticamente i problemi (es. ReSharper è ottimo), allora puoi avere più regole perché lo sviluppatore non ha bisogno di ricordarle tutte ed è abbastanza facile rispettare le regole con un paio di clic del mouse . Se usi uno strumento che sputa solo gli avvertimenti, la gente smetterà di usare lo strumento perché non penserà che lo sforzo per correggere gli avvertimenti valga il guadagno.