Come dovrebbe apparire il mio "esempio di codice"? [chiuso]

Mi piacerebbe vedere Pulisci codice :

Clean code: Software code that is formatted correctly and in an organized manner so that another coder can easily read or modify it.

Ciò significa:

• Funzionalità - Alcuni semplici bit di funzionalità non banali (un gruppo di getter / setter non mostrerebbe che tu sai qualcosa)
• Stile coerente e pulito - Stile popolare o almeno , stili di indentazione, spaziatura e parentesi
• Good Naming - Nomi di qualità: non utilizzare i a meno che non sia l'unico valore di incremento. Non usare nomi di variabili senza senso.
• Altri attributi di Pulisci codice - Buone pratiche su controllo degli errori, condizioni, cicli, metodi di convenienza o metodi di utilità e buon separation-of-concerns (tra metodi). E questo è un buon momento per essere al 100% ASCIUTTO - nessuna ripetizione!

Vuoi inviare loro qualcosa di abbastanza complesso da essere interessante ma abbastanza pulito che un buon sviluppatore possa quasi immediatamente capire cosa sta facendo.

Alcuni dei commenti sopra sembrano riguardare la facilità con cui questo potrebbe essere simulato. * Se vuoi proteggerti da questo, allora puoi inviare una breve descrizione dello scopo e della cronologia del codice nella email.

^{* Per lo meno se l'intervistatore ha chiesto informazioni sui progetti precedenti, allora ti ha chiesto un esempio di questo progetto e ha chiesto cosa ti richiedeva per scriverlo o come si è evoluto , Penso che il processo sarebbe abbastanza a prova di bugiardo. Penso che la maggior parte dei candidati che bevano mostreranno comunque problemi in altre aree.}

Quando stavo cercando lavoro, ho risolto un sacco di domande sul concorso di programmazione ACM, in diverse lingue, e da allora uso quelle per i campioni di codice. Penso che abbiano creato esempi di codice validi perché:

• Hanno risolto problemi impegnativi
• Il problema non richiedeva un'enorme quantità di contesto, inoltre è facile ottenere le domande
• Il codice scritto non presenta alcun rischio IP associato.
• Ogni problema può ragionevolmente esistere in un singolo file e spesso non estremamente lungo, quindi dovrebbe essere facile per chiunque compilare e testare la soluzione e utilizzare i dati di test delle domande.
• Mostra che puoi suddividere un problema complesso in parti più piccole.
• Se ti viene chiesto come funziona qualsiasi aspetto della tua soluzione, ti dà una grande opportunità per dimostrare di sapere di cosa stai parlando, soprattutto se ha molti anni ma puoi rapidamente decifrare cosa sta succedendo.

E poi, il codice che crei dovrebbe essere chiaro, coerente, facile da leggere e facile da capire.

E infine:

• Vale la pena risolverli solo per divertimento ed è una buona pratica.

• Dovrebbe compilare / interpretare l'errore e l'avviso al massimo livello di rigore.
• Non dovrebbe essere il codice standard che scrivi ogni giorno. Rendilo unico e interessante, quindi è ovvio che non l'hai copiato / incollato.
• Dovrebbe avere alcune decisioni progettuali interessanti con commenti che spiegano come / perché li hai creati.
• Punta a non più di 2-3 pagine stampate.
• Dovrebbe essere nella lingua che stai richiedendo.
• Non dovrebbe farmi male al cervello quando lo leggo la prima volta. Chiedi a un amico di consultarlo o di pubblicare su codereview.

Bene, se ti stessi intervistando, mi piacerebbe vedere il tuo codice.

Clean è buono, il problem-solving è buono, ma vero codice è migliore. Un buon programmatore sa quando è stato truffato da un altro programmatore, quindi la fiducia potrebbe andare giù.

Leggere un altro codice utente è come ballare fare sesso: sai quando è la cosa reale, e se l'altra persona la sta fingendo, alla fine si verificherà un disastro. (hai appena realizzato veri nerd che non sanno ballare)

Confida solo su te stesso e sulle tue capacità di codifica . A meno che tu non conosca davvero il tuo intervistatore, non puoi anticipare ciò che si aspetta dal tuo stile / capacità di codifica.

Fai anche attenzione che non sia il codice del tuo attuale datore di lavoro (lo possiedono e non garantisco che non gli piacerà che tu lo condivida). Prendi qualcosa di cui essere orgoglioso e rielaboralo da solo per non essere un datore di lavoro specifico (sbarazzati di qualsiasi riferimento alle loro tabelle di database o nomi di server, ecc.). Qualunque cosa tu faccia non inviare il codice che ha errori o è una tecnica scarsa per il tipo di codice che è (probabilmente rifiuterei qualcuno che ha inviato un cursore quando un'operazione basata su set sarebbe più semplice ed eseguire meglio durante la revisione del codice SQL. Esistono tecniche simili per altre lingue che sono lì per risolvere un problema di problemi relativamente raro che può essere utilizzato per altri problemi più comuni, ma non sono la scelta migliore per quegli altri problemi. La frase aveva senso?)

Vorrei postare il post di Renesis sul codice pulito, ma aggiungerei all'elenco che fornisce test unitari di qualità e ben documentati al codice che invii. Un buon programmatore dovrebbe scrivere test di unità per il loro codice.

Come opinione di qualcuno che richiede campioni di codice nella valutazione dei candidati, ci sono alcune caratteristiche di alto livello (contenuto del codice) e alcune caratteristiche di basso livello (struttura del codice). Funzionalità di alto livello:

1. Identità : il sapore del codice. Se ti stai fatturando come un codificatore UI / HCI, voglio vedere un buon aspetto per qualcosa di visivo quando lo eseguo. Se sei un costruttore di DB, voglio vedere qualcosa di interessante con la rappresentazione o l'analisi dei dati. L'esempio dovrebbe essere qualcosa di orgoglioso di. Se non ne hai almeno uno, non hai identità.
2. Durata : cambi le strategie per diversi problemi? Stai risolvendo problemi interessanti? Il codice o l'approccio potrebbero essere facilmente estesi a un problema simile? Al contrario, mi sento come se guardassi un membro di una comune di culto cargo?
3. Comunicazione : il codice spiega facilmente cosa sta facendo e perché? Questo non significa che il codice deve essere semplice. In effetti, è un vantaggio rendere il codice complesso facile da capire.

Gli aspetti di basso livello sono più semplici:

1. Stile : il codice deve essere pulito, coerente (segue alcune linee guida stabilite) e ben documentato.
2. Packaging : dovrebbero esserci almeno un breve readme, una versione eseguibile e test eseguibili. Il readme dovrebbe dirmi come eseguire questi ultimi due, nonché il motivo per cui stai dimostrando questo particolare esempio di codice.
3. Lingua / e : di solito chiedo a qualcuno un campione nella lingua per la posizione, oltre a quella in cui si sentono più forti. Fornisce una buona idea dei limiti attuali di una persona.

Per un buon candidato, mi aspetto che un campione sia: A) Un piccolo campione a prova di proiettile o B) Una buona parte di un progetto interessante più ampio (ad es. un modulo da un repository personale di Github). Mi aspetto che siano progetti personali o progetti accademici. Se ne inviano uno da un progetto a pagamento, mi aspetto che venga loro dato il permesso di usarlo. Se non ottengo quella nota, li taglierò dai candidati (candidato debole) o glielo chiederò durante l'intervista (candidato strong). Non avere il permesso sarebbe una grande bandiera rossa (probabilmente insormontabile). Per un candidato avanzato, mi aspetto un disclaimer che noti che alcuni dei loro migliori esempi di fonti non possono essere mostrati perché è stato fatto come parte del loro lavoro. Tuttavia, mi aspetto quindi una testimonianza entusiasmante del perché sono orgogliosi di quel design insondabile e di come lo amano come un bambino.

Infine, per quanto alcune persone rimproverano che "Oh, qualcuno potrebbe semplicemente ottenere un esempio di codice da Internet", la contro-argomentazione è che la maggior parte delle persone che non capiscono un buon codice di qualità di produzione non la capisce nemmeno quando loro lo vedono. Inoltre, si può sempre Google una linea distintiva per il codice da controllare. Inoltre, nella migliore delle ipotesi, rubare il codice otterrà un candidato a un colloquio in cui si metteranno in imbarazzo ("Allora, perché l'hai fatto in questo modo ...?").

Come ultima nota sul codice del precedente impiego: non farlo. Dal punto di vista delle risorse umane, chiedere codice da un precedente impiego è inappropriato e una bandiera rossa sulla società. Entrambi avreste responsabilità legale (cioè, potreste essere entrambi citati in giudizio) e questo dimostra che non hanno idea di cosa stiano facendo. Il codice fatto per un precedente datore di lavoro non dovrebbe mai essere dato a meno che il codice sia già pubblicamente disponibile o se si dispone di un permesso esplicito da parte del datore di lavoro. Peggio ancora, in una grande azienda, il tuo capo diretto potrebbe non avere il potere di darti il permesso, quindi divertiti con il dipartimento legale in quel caso? Sono sicuro che saranno felicissimi di esporre il loro IP per un dipendente in uscita.