compromesso efficienza-semplicità

3

Il CTO mi ha chiamato per informarmi di un nuovo progetto e nel processo mi ha detto che il mio codice è strano.

Ha spiegato che i miei colleghi hanno difficoltà a capire a causa dei concetti e delle tecnologie troppo complessi, spesso nuovi, che non hanno familiarità con. Mi ha chiesto di mantenere una semplice base di codice e di pensare agli altri che erediteranno i miei cambiamenti.

Ho dedicato molto tempo alla padronanza di LINQ e alla codifica thread-safe. Tuttavia, gli altri non sembrano preoccuparsi né sono impressionati da qualcosa di diverso dal loro stipendio.

Devo mantenerlo semplice (stupido), solo perché gli altri non hanno familiarità con le migliori pratiche e una codifica efficiente? O dovrei continuare a fare ciò che trovo migliore e scrivere il codice a modo mio?

    
posta sarepta 29.05.2014 - 22:58
fonte

5 risposte

7

Scriviamo codice da leggere per altri umani. Le nuove tecnologie hanno lo scopo di rendere il codice più facile da leggere, non più difficile. Esistono buoni e cattivi modi per utilizzare le nuove tecnologie. Se stai cercando di scrivere codice "impressionante", lo stai facendo male.

Sospetto che non sia solo l'uso delle tecnologie che riguardano le persone. Se il modo in cui stai usando LINQ ha fatto un'enorme differenza nella leggibilità, molto probabilmente i tuoi colleghi non si lamenterebbero con il CTO. Dicevano: "Wow, sembra davvero pulito, anche se non lo capisco appieno, questo mi fa venir voglia di imparare meglio". Non dare per scontato che tu possa introdurre una nuova tecnologia e ottenere automaticamente il codice di un calibro superiore. Fai una sfida per rendere l'utilizzo della nuova tecnologia un aspetto pulito e accattivante.

Prendi questa mia risposta , ad esempio. Volevo evidenziare una soluzione in stile funzionale poiché nessun altro l'ha fatto. Penso che la programmazione funzionale spesso produca un codice superiore, ma la mia prima bozza era terribilmente illeggibile, anche se era concisa e buona -commented. Questo mi ha infastidito, quindi ho fatto un altro tentativo. La mia seconda bozza richiede ancora una conoscenza di base della programmazione funzionale, ma è molto più bella, se posso dirlo anch'io.

Il mio punto è che se si mettono più sforzi per scrivere codice più pulito, i tuoi colleghi saranno più entusiasti della nuova tecnologia. Se non riesci a scrivere il codice LINQ che è più facile da leggere rispetto al "vecchio stile", non dovresti usarlo in quella situazione. Se non riesci a capire se è più facile da leggere, chiedi una revisione del codice.

    
risposta data 29.05.2014 - 23:40
fonte
6

Mi vengono in mente tre cose.

Primo: "semplice" non è "stupido". La semplicità è il predecessore dell'eleganza.

Secondo: nel tuo lavoro, la cosa più importante da fare è essere un giocatore di squadra. Il tuo capo è un giocatore di squadra. Il lavoro consiste nel tenere unita la squadra, il che significa rendere comprensibile il codice per i compagni di squadra e renderlo parte del team. È bene che tu cerchi di educarti e di migliorare le tue capacità. Ma all'interno di una squadra significa anche: assumere la responsabilità e condividere le tue conoscenze.

Terzo: se ritieni che la conoscenza generale e il livello di abilità dei tuoi compagni di squadra non sia sufficiente, parlane con il tuo capo, offri aiuto, formazione, recensioni di codici, presentazioni, ecc. Discuti le possibilità, i pro e i contro dei tuoi abilità addizionali.

Non dimenticare mai: tienilo semplice. Sempre. Mai sofisticato Questo rovina il lavoro efficiente. Il tuo obiettivo principale deve essere: combinare competenze e semplicità di alto livello. Che è l'arte della programmazione. In effetti, è l'arte di tutto.

    
risposta data 29.05.2014 - 23:41
fonte
4

Questa è una situazione difficile.

In primo luogo, non entra in una relazione negativa con il tuo capo o con i tuoi colleghi di lavoro. Soprattutto, sii positivo, riconoscendo i loro tratti di valore ed essendo di aiuto.

Quindi, vedi cosa puoi fare per esporre i tuoi colleghi a nuove tecniche. Se necessario, includi le spiegazioni nel tuo codice, in modo che le persone possano seguirti. Appello ai loro motivi superiori. Non dire " Tu dovresti fare questo e così", dì "Questo è ciò che I faccio e perché lo faccio". Non predicare.

E quando è la cosa giusta da fare - Compromesso.

In altre parole, essere un leader .

    
risposta data 29.05.2014 - 23:11
fonte
1

Mi sembra che tu abbia ricevuto un feedback legittimo dal tuo manager. Non prenderne nulla sarebbe un'occasione persa per te. Se il tuo modo di è giusto o meno, i tuoi colleghi stanno lottando. Se stanno lottando, la compagnia avrà difficoltà e tu lotterai a fornire tonnellate di supporto quando tentano di eseguire il debug, estendere o mantenere il tuo codice.

Sicuramente fai tutto il possibile per supportarli come sviluppatori migliori, ma cogli l'opportunità di rivedere le tue pratiche di codifica. Chiediti:

  • Sto sovra-ingegnerizzando questo?
  • Sto ottimizzando troppo presto o troppo (perché progettare per supportare un milione di utenti se sai che la base utente sarà sempre molto più piccola)?
  • Sto cercando di apparire "intelligente" con la mia soluzione? Non lasciare che l'ego ti guidi in inutili complessità o oscurità

Mi sorprendo a essere colpevole di tutte queste cose di tanto in tanto e trovo a chiedermi queste domande che aiutano a mantenere il mio codice semplice. Ricorda solo che semplici ed efficienti non si escludono a vicenda.

    
risposta data 30.05.2014 - 23:25
fonte
0

Per quanto le nuove tecnologie siano grandiose ed efficienti a volte, l'efficienza diminuisce se il tuo team deve dedicare ore a cercare di capire il tuo codice.

Il codice semplice, strutturato e semplice è il più semplice da mantenere, il che rende il team e il business più efficienti, quindi più redditizi.

Implementare o semplicemente stare al passo con le nuove tecnologie / metodi sono sicuramente importanti, ma se si arriva al costo di fare le cose, è necessario concentrarsi di più su come far allenare chiunque altro, altrimenti nessuno vince.

In definitiva, è la chiamata dei tuoi capi, il che significa che dovrai convincerlo che è il migliore per il business.

    
risposta data 30.05.2014 - 13:35
fonte