Hai mai dovuto codificare "male" per la tua squadra? [duplicare]

15

Sono stato sulla strada costante dell'apprendimento di nuovi concetti in OOP, Software Design, Architecture, ecc. Ma ci sono momenti in cui sei in una squadra in cui questi concetti sono estranei a loro e non hanno il tempo o la stessa voglia di imparare come te.

Il problema è che se si progetta il codice in modo "giusto", le persone che codificano con classi 2kLOC non lo capiranno. Sacrificheresti i buoni principi di codifica per supportare la tua squadra? Che dire di uno scenario in cui questo sarà un accordo a lungo termine?

    
posta Jonn 23.09.2010 - 15:34
fonte

2 risposte

14

Benvenuto nel mondo reale.

Ho lavorato con centinaia di sviluppatori diversi in tutto il mondo, in startup e grandi imprese. La stragrande maggioranza di loro non capisce concetti avanzati e non lo farà in futuro. È troppo complicato per padroneggiare qualcosa se non si spende oltre un decennio in quel particolare settore. Pochissimi sono in grado di farlo.

Ecco perché sono davvero sconvolto quando uno dei miei sviluppatori è troppo "pilotato dal CV" e cerca di implementare schemi di progettazione che non fanno nulla di meglio ma gli permettono di inserire qualcosa di nuovo nel suo curriculum (o nel titolo "Architetto"), mentre il resto del team è in lotta per comprendere e mantenere il codice HIS.

Ecco perché penso che un buon sviluppatore non sia il tecnico supperente, ma il più pragmatico del pacchetto:

An excellent developer try to convert a functionnality the business ask by maximizing the ROI.

IMHO, mantenere le cose semplici, è la strada da percorrere. Se vuoi fare le cose "giuste", fallo a casa. Il tuo capo ti sta aspettando qualcos'altro.

    
risposta data 23.09.2010 - 15:46
fonte
5

Penso che ci sia una differenza tra ciò a cui ti riferisci e debito tecnico .

Il debito tecnico si ha quando esegui deliberatamente un'incisione rapida e hacky con la piena consapevolezza che dovrai modificare il progetto in una fase successiva. Simile al debito finanziario questo può essere utile per un progetto, ma è necessario essere consapevoli di esso ed eliminarlo in una fase successiva.

In termini di deliberatamente non usare certe caratteristiche del linguaggio - Sono stato anche io in quella situazione. Ricordo che una volta ho implementato delegati anonimi subito dopo che C # 2.0 è uscito e alcuni mesi dopo ho visto qualcuno che aveva semplicemente cancellato il mio delegato e sostituito con un metodo normale. Semplicemente non hanno capito il codice: - (

Detto questo, non è sempre una brutta cosa. Semplifichiamo .

    
risposta data 23.09.2010 - 15:49
fonte

Leggi altre domande sui tag