Come si accerta la qualità del codice di un potenziale datore di lavoro prima di prendere una posizione? [chiuso]

Nella mia esperienza prima di iniziare a lavorare per un'azienda non hai l'opportunità di consultare la base di codice (ho chiesto e per motivi di riservatezza tutti hanno sempre detto di no, penso che sia giusto), quindi durante il processo di intervista cosa pensi che siano le domande più importanti da porre per scoprire in che stato si trova il codice (dopotutto, se è un cane, allora sarai sui poveri sfortunati che devono percorrerlo ogni giorno)?

AGGIORNARE:

Una lista di controllo: Chiedi;

• Quello che pensano del codice di base. E quando lo fai, presta molta attenzione alle espressioni facciali e al tempo necessario per rispondere. [Anon]
• Qual è il livello CMM dell'azienda [DPD] (e se senti il ​​livello 5 correre nell'altro modo [Doug T])
• Quale ciclo di vita usano [DPD] (E se senti "Agile", è quando inizi a porre alcune domande penetranti per cercare di capire se per "Agile" significano "Agile o" codifica da cowboy "[Carson63000])
• Quali strumenti usano per valutare la qualità del codice? [DPD]
• Quali strumenti usano per lo sviluppo? [DPD] (Cerca strumenti di refactoring e server di generazione continua)
• Quale sistema di codice sorgente (controllo versione) usano e un buon follow-up è chiedere perché lo usano. [Zachary K].
• Come sono le loro procedure di test? [Karl Bielefeldt] (Cerca in particolare i team che utilizzano framework di derisione e pongono l'accento su test di unità automatici approfonditi attraverso framework consolidati come NUnit / JUnit; non lasciarti scoraggiare da team che non utilizzano TDD di sviluppo guidato dai test, ma sii diffidare se non considerano i test integrali e la pietra angolare del solido sviluppo del software. Cerca team con tester dedicati.)
• Quali tipi di incarichi vengono assegnati ai nuovi sviluppatori? A sviluppatori esperti? [Karl Bielefeldt]
• Quante persone lavorano su un progetto? [Karl Bielefeldt]
• È consentito il refactoring? Incoraggiato? [Karl Bielefeldt]
• Quali processi di qualità o modifiche all'architettura sono in esame o sono state apportate di recente? [Karl Bielefeldt]
• Quanta autonomia hanno le persone sui loro moduli? [Karl Bielefeldt]
• Svilupperai nuovi progetti (sviluppo greenfield) o progetti legacy (sviluppo brownfield)? (Lo sviluppo di Greenfield è generalmente più divertente e ha meno problemi in quanto non si sta pulendo con gli errori di qualcun altro).
• Il tasso di turnover dei dipendenti è elevato nell'organizzazione o nel team? (Ciò indica spesso una qualità inferiore del codice) [M.Sameer]
• Alcuni problemi di programmazione personali; ma evita di sembrare un coglione. [Sparky]
• Come collaborano gli sviluppatori e in che modo le conoscenze sono condivise tra il team? (Questo dovrebbe corrispondere alla tua personalità; direi che un mix di lavoro solista e di coppia è probabilmente il migliore, con il rapporto che corrisponde alle tue esigenze sociali)
• Quanto è vicino il loro database alla 3a forma normale (3NF) e se devia dove e perché? (Se dicono "3NF ???", vattene. In caso contrario, e potrebbero esserci buone ragioni per non farlo, allora scopri cosa sono).

NOTA: ho accettato la risposta di Anon perché dopo circa una settimana la comunità pensa che sia la migliore - penso che questo suggerisca che è solo qualcosa per cui in qualche modo devi sviluppare un sesto senso. Ma penso che tutti abbiano avuto qualcosa di prezioso da dire.

Invece di chiedere di vedere il loro codice, chiedi cosa ne pensano della base di codice. E quando lo fai, presta molta attenzione alle espressioni facciali e al tempo necessario per rispondere.

Quindi applica la tua conoscenza dei gesti non verbali della tua cultura per interpretare ciò che stanno realmente dicendo. Per un'azienda nordamericana, quanto segue dovrebbe essere accurato:

• Una piccola scrollata di spalle e una rapida risposta di "potrebbe essere meglio": probabilmente è abbastanza buono.
• Una lunga pausa, il respiro, forse una piccola risata: non è piacevole, e le persone che stai intervistando non si sentono a proprio agio nel dirtelo.
• Occhi alzati, risposta rapida di "fa schifo": potrebbe essere buono, potrebbe essere cattivo, ma ci sono giochi politici in corso. A meno che tu non sia pronto per giocare a quel gioco o essere un tranquillo nessuno, stai lontano.
• Sopracciglia alzate o contratte: non capiscono la domanda e la base di codici è quasi sicuramente putrida.

Naturalmente, se hai problemi con la comunicazione interpersonale, questo potrebbe non funzionare per te.

Sono sorpreso che tu l'abbia persino chiesto. Nessuna azienda ti mostrerà mai il codice prima di aderire. Nemmeno ai consulenti hanno richiesto il processo, a meno che non abbiano firmato un accordo di riservatezza.

Ecco cosa puoi chiedere per scoprirlo.

• Qual è il livello CMM dell'azienda (idealmente 5)
• Qual è il processo che viene seguito nel tuo futuro progetto (A proposito, chiederlo è positivo perché dimostra che sei interessato a "questo" lavoro e non a qualsiasi lavoro)
• Quale ciclo di vita usano (non giudicare se non senti "Agile". Potrebbero avere un motivo valido per usare i modelli della vecchia scuola)
• Chiedi se utilizzano strumenti e metriche per verificare la qualità del codice. E se sì quale (se usano almeno uno strumento per le metriche e un altro per la qualità, è un buon segno).
• Nota anche quali strumenti usano. Se si tratta di uno strumento costoso come Resharper invece di alcuni strumenti freeware, allora sono seri sulla qualità.

1. Chiedi loro se usano il controllo del codice sorgente.
   • Nessun controllo del codice sorgente? -> codice molto probabilmente di merda
2. Chiedi loro con quale frequenza eseguono le revisioni del codice.
   • Nessuna revisione del codice? -> il codice potrebbe essere sospetto (ma non necessariamente così, specialmente se si tratta di una piccola squadra composta da sviluppatori decenti).
3. Chiedi loro se come testano e implementano prima di andare in produzione?
   • Nessun ambiente di test? Distribuzione diretta in produzione? -> codice molto probabilmente di merda.
4. Chiedi loro se eseguono l'integrazione continua (.ie. Eseguendo build con Hudson)
   • Nessuna integrazione continua? -> Il codice potrebbe essere sospetto, ma non necessariamente.
5. (Relativo al n. 3), chiedi loro se il loro ambiente di test è separato dal tuo ambiente di sviluppo?
   • Il test è dev? -> non è un buon segno, non a meno che non siano veramente a corto di contanti, ma quanto sarebbe costoso un box extra?
6. Chiedi loro se rivedono un elenco di azioni prima di distribuirle in produzione.
   • Nessuna revisione delle azioni prima dell'implementazione della produzione? -> Bad juju.
7. Chiedi loro quanti passaggi sono necessari per realizzare una build.
   • Più di 3? -> Juju tipicamente cattivo.
8. Prendono (o indovinano) metriche di codice come la complessità ciclomatica o LCOM (una misura della coesione di classe).
   • Sì? -> probabilmente (ma non certamente) un buon segno per quanto riguarda la loro qualità del codice.
   • No, ma capiscono i concetti (almeno la complessità ciclomatica)? -> difficile da dire
   • Pensano che la complessità ciclomatica sia un piatto esotico o afrodisiaco del Timbuktu (in altre parole, non sanno cosa sia)? -> possibile cattivo juju.
   • Pensano che sia merda irrilevante (o qualche altro comportamento del genere)? -> scappa.
9. Chiedi loro come tengono traccia dei bug.
   • Tracciano il numero di bug rispetto ad alcune metriche (.ie. Per progetto, numero di moduli modificati o numero di richieste di requisiti / modifiche, qualcosa!)? -> buon segno circa il loro codice (e il loro processo software).
   • Fanno quello sopra e tentano di prevedere il numero di possibili bug che potrebbero incontrare in un progetto futuro (o in corso) sulla base di una metrica prevista (numero di richieste di modifica, dimensioni del progetto, ecc.)? -> molto buon segno.
   • Tengono traccia dei bug solo per la risoluzione dei bug? -> difficile da dire
   • Nessun tracciamento coerente? -> scappa.

Sarebbe dalla cima della mia testa. Noterai che alcune delle mie domande riguardano il processo di sviluppo del software e non solo la codifica. La qualità del successivo è una funzione diretta della qualità del primo.

Detto questo, quando fai queste domande, procedi con cautela. Studiali e selezionane alcuni al momento di un'intervista.

Un paio di cose da tenere a mente. Un buon team di sviluppo sarà lieto di sentire una persona intervistata porre queste domande ... purché vengano poste con tatto. Fallo in modo sbagliato e darai all'intervistatore un'impressione di arroganza e perfezionismo. Non importa quanto sia bravo un team di sviluppo, nessun gruppo è perfetto e tutti hanno problemi da risolvere, compromessi in termini di qualità e simili. Vogliono un giocatore di squadra con un debole per la qualità, non un perfezionista dirompente. Quindi sii attento.

Inoltre, potrebbero esserci casi in cui hai un team di brave persone che per circostanze esterne devono lavorare con un codice di qualità scadente (potrebbero essere sviluppatori junior o hanno semplicemente ereditato un mucchio di merda su cui ora devono lavorare con un numero limitato risorse dedicate per migliorare la qualità.) Puoi lavorare con codice di merda e avere comunque una buona esperienza lavorativa se le persone intorno a te sono anche brave persone (sia a livello personale che professionale). Dai loro l'impressione sbagliata quando fai le domande e potrebbero semplicemente evitare di assumerti del tutto (rubandoti l'opportunità di lavorare con brave persone in una situazione molto difficile e stimolante).

• tra l'altro, credo fermamente che uno sviluppatore di software abbia dovuto lavorare almeno una volta con un qualche tipo di codice oltre ogni speranza (o quasi oltre ogni speranza). Sopravvivi a questo e fai un buon lavoro, questa è una lezione preziosa.

Potresti anche incontrare un gruppo di sviluppo di merda con persone di merda. Ovviamente allora, il loro codice sarà di merda e si adatteranno a una qualsiasi di queste domande. Potrebbero disprezzarti per aver posto loro domande difficili (e quindi potrebbero farti un favore), o ti assumeranno perché hanno bisogno di te (anche se sono / saranno incapaci di lavorare con te).

Quando ciò accade, devi chiederti se hai bisogno di questo lavoro così male. A volte lo fai e devi fare un tuffo in un mucchio di merda di spaghetti. A volte non lo fai (nel senso, puoi permetterti di non farlo).

Queste sono le cose che devi prendere in considerazione quando / se scegli di chiedere a un intervistatore la qualità del loro codice e dei loro processi software.

Invece della reale qualità del codice, preferirei cercare un'azienda in cui l'importanza della qualità del codice sia ben compresa.

Ad esempio, supponiamo che la società A abbia manager che credono che "pianificare è tempo perso" e "possiamo risolvere i problemi di progettazione in un secondo momento (ad es. Quando l'inferno si blocca. Avremo tempo)". Anche se quella società avesse una buona base di codice ora, non la avrebbero a lungo. E sarai colui che (sarà costretto a) peggiorare le cose.

D'altra parte, supponiamo che la società B abbia una base di codice errata, ma la direzione capisce che la qualità del codice sta causando tutti quei bug e ritardi, vedono la necessità di un cambiamento e sono disposti a fare qualcosa al riguardo (ad es. Su larga scala refactoring o addirittura riscrivere). Quell'azienda migliorerà la sua base di codice e tu potrai aiutarli a farlo accadere.

So dove mi piacerebbe lavorare.

C'è una probabilità del 99,9% che non sarai in grado di vedere il codice prima di iniziare. (A meno che non lancino prodotti software gratuiti ovviamente)

Quindi cosa puoi fare, vorrei chiedere il processo, in generale un buon processo produrrà un buon codice. Vorrei iniziare con il test Joel e chiedere informazioni sul metodo di sviluppo. Vai anche oltre le basi. Ad esempio, chiedo sempre quale sistema di codice sorgente usano, quindi un buon follow-up è chiedere perché lo usano.

Il posto in cui ho lavorato con un codice di altissima qualità non ha praticamente permesso a due terzi degli sviluppatori di toccare il codice. Gli altri hanno invece scritto script di test automatizzati per la scatola nera. Se ti sei dimostrato degno di cambiare il codice reale, i requisiti erano così estremamente specificati che in pratica non era altro che una trascrizione nel codice sorgente. Gli script di test erano in realtà più divertenti da scrivere.

I posti in cui ho visto il codice di qualità più bassa erano esattamente il contrario: solo i programmatori relativamente non addestrati o non addestrati hanno mai toccato il codice, di solito perché era uno strumento non direttamente correlato al prodotto dell'azienda, o ritenuto sperimentale.

I posti più piacevoli in cui lavorare hanno un equilibrio. Ai nuovi sviluppatori vengono assegnati incarichi reali, ma sono guidati. Esiste un buon dipartimento di controllo qualità e un processo di revisione tra pari per rilevare i tuoi errori. Non sei punito per aver commesso errori, ma ci si aspetta che li ripari e impari da loro. Di tanto in tanto, un modulo mal scritto cade nelle crepe, ma non vieni criticato per aver speso tempo a migliorare la qualità del codice quando ti imbatti in quelli. La società nel suo complesso si impegna costantemente per trovare nuovi modi per migliorare il codice.

Pertanto, le domande che vorrei porre per valutare la qualità del codice sono:

• Come sono le tue procedure di test?
• Quali tipi di incarichi vengono assegnati ai nuovi sviluppatori? A sviluppatori esperti?
• Quante persone lavorano su un progetto?
• È consentito il refactoring? Incoraggiato?
• Quali processi di qualità o modifiche all'architettura sono in esame o sono state apportate di recente?
• Quanta autonomia hanno le persone sui loro moduli?

Come dicevano @DPD e @Zachary, processo e SDLC sono fattori molto importanti ma voglio aggiungere altri fattori che secondo la mia esperienza hanno un impatto significativo sulla qualità del codice:

• Chiedi se hai intenzione di lavorare nello sviluppo in un progetto relativamente più recente o nel mantenimento di un'applicazione legacy. Le applicazioni legacy tendono ad essere meno pulite rispetto al nuovo progetto.
• Cerca di sapere se il tasso di turnover del dipendente è elevato nell'organizzazione o nel team. Ciò probabilmente ridurrà anche la qualità del codice.

Si noti che un processo aiuta molto, ma non darà l'immunità totale contro i fattori di cui sopra. Quando molti sviluppatori trasmettono un progetto, ognuno ha una mentalità diversa. L'architetto e lo sviluppatore non seguiranno esattamente il modo in cui i loro predecessori hanno portato ad alcune incoerenze.

Il mio atteggiamento è questo, il codice è codice, se è male, beh, è ​​una sfida renderlo migliore. Se va bene, beh, è ​​una sfida ancora più difficile renderlo migliore!

La cosa più importante per me è se voglio lavorare per l'azienda e le persone con cui ho l'opportunità di interagire. Il codice può essere modificato, le persone non possono ...

Dico leggermente scherzando, intervista con me .

Normalmente uso un bug reale (già corretto) nella nostra base di codice come test di intervista, quindi vedi un po 'di codice reale. Codice generalmente leggermente complicato, e contiene un bug.

Incoraggio tutti a utilizzare questa tecnica, poiché sai già che il bug è reale, il problema è reale e sai quanto tempo è stato necessario per trovare e correggere.

Il bello è che puoi avere un problema misurabile.

Ho usato un problema molto difficile come ultima domanda del colloquio per separare gli esperti da quelli piuttosto bravi.

La pertinenza per la domanda del PO è che tutti coloro che partecipano a un colloquio fisico possono vedere del codice. (Nulla con contenuti riservati dell'azienda)

Se non potessi usare questa tecnica, per dire, parolacce nella base di codice, allora il test funziona, poiché i potenziali dipendenti chiederanno "posso vedere il codice" e la risposta sarebbe "oh, non puoi pieno di parolacce ".

Ovviamente, la risposta standard "è tutto un segreto aziendale" è il totale enigma.
La mia prova: per il mio precedente datore di lavoro, una parte non riservata di un prodotto militare era il campione di codice per l'intervista. [Fortunatamente non classificato]

Lascio il problema di determinare la qualità dei progetti classificati prima di lavorare lì a qualcuno più intelligente di me. Suggerisco che sia comune che classificare sia sinonimo di libero controllo.

È dubbio che ti faranno vedere il loro codice, ma potresti essere in grado di avere un'idea di come potrebbe essere se gli dai un compito di programmazione. Molti posti offrono agli intervistati un compito di programmazione da portare a casa che possono usare per misurarti. Restituisci il favore - aspettati uno di loro in modo da poter valutare meglio in cosa potresti essere coinvolto.

Chiedi cosa è necessario per il codice per renderlo nella build di produzione. Se ottieni "uhh ... il dev lo commette ..." allora è quasi sicuramente spazzatura.

Ci sono un certo numero di cose che hanno la tendenza ad aumentare la qualità del codice (ovviamente, non ci sono garanzie).

• Analisi statica (in .NET si tratta di cose come fxcop / stylecop)
• Un sottoinsieme (o set completo) della suite di test - unità / integrazione / regressione / manuale ecc.
• Compilazione del compagno (un altro sviluppatore del team costruisce le modifiche per vedere se ci sono problemi dipendenti dalla macchina / utente - a volte anche con un buon equilibrio
• Revisione del codice

Questi possono aiutare a migliorare non solo la forza del codice, ma anche la qualità del codice.

Chiedi loro informazioni sui test unitari. Se lo prendono sul serio, l'intervistatore avrà probabilmente delle opinioni precise sull'argomento e sarà lieto di condividerle. Se le risposte sono vaghe, è un grande segnale di avvertimento.

Se si tratta di un negozio Java, chiedi loro quale libreria ORM stanno utilizzando. Se si sono fatti da soli, allora potrebbe andare in entrambi i modi: potrebbe fare schifo o potrebbe andare bene. Se non ne usano nessuno, corri subito alla porta.

Questo è un compito difficile perché ci sono così tante diverse cattive pratiche di codifica, che non sarai mai in grado di prevederle tutte.

Purtroppo non puoi. Nessuna azienda ti permetterà di vedere il loro codice (ma ti chiederanno di vedere il TUO codice ...), e ci sono possibilità che se fai loro delle domande sull'ambiente o verrai completamente mentito ("Controllo della versione? Certo .. usiamo ... uhh ... pensando Sub .. Sub-qualcosa ") o inganniamo sulla qualità (" Stiamo usando l'ultimo e il più grande .NET 4 "solo per scoprire che mentre usano .NET 4 loro ' lo sto scrivendo come .NET 1.1).

Sono stato bruciato da questo molte volte in passato e devo ancora trovare un buon modo per valutare la qualità. Di solito il modo migliore è usare il proprio giudizio e se si riduce ad esso, lasciare immediatamente se è peggio di quanto pensassi; potresti finire con una cesta di lavoro ma manterrai la tua sanità mentale.