I programmatori che hanno bisogno di molto "aiuto esterno" - è così male? [chiuso]

Scrivere un intero programma in un metodo è probabilmente sbagliato. Detto questo, l'utilizzo di strumenti già esistenti può sicuramente aiutare ad accelerare i tempi di sviluppo. Spero di aver interpretato erroneamente la tua formulazione in quanto sembra implicare che Python o Django debbano essere guardati dall'alto in basso come aiuto esterno. Entrambi sono strumenti estremamente utili per gli sviluppatori. Penso che possiamo convenire che per la maggior parte dei casi, uno sviluppatore che implementa un elenco collegato da utilizzare invece di utilizzare uno standard fornito è una cattiva idea. Questo può valere anche per cose più complesse, come i socket TCP e forse anche GeoIP.

D'accordo, a volte quando le persone incorporano moduli / librerie esterni in un prodotto, le cose possono diventare disordinate, specialmente quando ci sono più moduli e si inizia ad avere incubi di dipendenza. Questi devono essere gestiti in modo appropriato, e sì, a volte è meglio codificare le cose da soli. Non giudicherei uno sviluppatore su se usano "aiuto esterno", tanto quanto come usano l'aiuto esterno e lo integrano con il resto del sistema.

In generale è considerato buono se il programmatore ha esposizione a una moltitudine di librerie. se riesci a svolgere il compito utilizzando un algoritmo scritto in modo efficiente già disponibile nella libreria, non risparmierai tempo e fatica ?. Ma dipenderebbe dalla situazione se le librerie e le dipendenze oscureranno e non si adattano ai requisiti di progettazione o se l'attività può essere eseguita con una semplice routine. Il risparmio di tempo è sicuramente un fattore.

Preferirei che le persone usassero strumenti esistenti, provati e testati per creare cose piuttosto che uscire e scrivere tutto da zero, con i rischi intrinseci di farlo, il tempo extra necessario per testare cose che possiamo sapere sono testate dal nostro fornitori se lo compriamo, ecc. ecc.

Utilizzare gli strumenti esistenti è buono e consigliato (in realtà, non utilizzare strumenti esterni è spesso un problema con i programmatori junior)

Tuttavia, l'utilizzo di molti di questi strumenti per un progetto relativamente piccolo potrebbe indicare che ogni strumento è eccessivo per ciò a cui è utilizzato e può portare a un sovraccarico di integrazione elevato

Scrivere un programma in un metodo: decisamente negativo (a meno che non si tratti di un programma banale, ma non penso che sia ciò che intendi).

Uso di molte librerie: dipende.

C'è un equilibrio tra re-inventare la ruota e fare zero lavori. Se l'atteggiamento è "a meno che non ci sia una libreria per [x], non la sto implementando", questo è certamente negativo. Tieni a mente che l'altro estremo è (per esempio) "So che jQuery può farlo in tre righe, ma ho intenzione di lanciare le mie [y] funzioni".

Sostanzialmente:

• Usa framework e altre astrazioni dove riducono significativamente gli sforzi e gli errori
• Non utilizzare i framework come modo per evitare di apprendere ciò che implementano
• Non utilizzare la mancanza di un framework come scusa per evitare di affrontare un'attività

Altrimenti sei (IMO) a sbagliare.

Sono assolutamente d'accordo. Mentre mi definisco propenso a "reinventare la ruota" troppo spesso, c'è un punto in cui devi essere in grado di pensare da solo.

La maggior parte dei progetti ha bisogno di una manciata, al massimo, di librerie ben scritte e adatte. Se il tuo progetto risulta essere poco più di una raccolta di widget e codice di altre persone, di solito non è molto buono.

Ci sono ... alcune eccezioni, ma preferirei non accettarlo.

Essere consapevoli di librerie e framework è buono, ma affidarsi quasi interamente a loro, non è un buon segno nella mia esperienza.

Apprezzo molto l'uso di librerie e framework. Tuttavia, esiste un limite in cui vengono utilizzati perché esistono, piuttosto che perché sono necessari. L'uso di diverse librerie geo-spaziali mi porta a credere che siano state abusate.

Di maggiore preoccupazione per me è la natura illeggibile del codice. Alcune caratteristiche che cerco in un buon codice:

• Chiaro codice di facile lettura. (Un manager con una conoscenza minima della lingua dovrebbe essere in grado di capire il codice.)
• Piccoli moduli che hanno uno scopo chiaro e dipendenze limitate. (alta coesione e basso accoppiamento).
• Codice ben formattato che è facile da scansionare.
• Commenti che spiegano cosa viene fatto dove necessario.
• Duplicazione limitata del codice, nessuna duplicazione delle funzionalità.
• Uso coerente delle librerie standard delle lingue.
• Uso appropriato di framework e librerie. (Questi dovrebbero essere standard di progetto / organizzazione.)

Sfortunatamente, ci sono molti sviluppatori che non si sono spinti al valore dei fattori di cui sopra. Non importa quanto sia complesso il problema, dovrebbe essere scomposto in componenti più semplici che vengono assemblati in una soluzione. Qualsiasi componente che rimane complesso dovrebbe avere una ragione documentata per cui è fatto così com'è. (Ci dovrebbe essere un motivo valido.)

EDIT: se l'intera soluzione è lunga meno di 60 righe, potrebbe essere opportuno farlo in un unico metodo. Il file sorgente dovrebbe avere diversi metodi tutti di dimensioni ragionevoli. Se ci sono metodi più lunghi, probabilmente hanno bisogno di ri-factoring. Mi interessa il numero di librerie geo-spaziali utilizzate per un semplice problema. (Tuttavia, ho visto alcuni semplici problemi per i quali la soluzione è molto complessa.)

Un'altra cosa da considerare: il tuo collega usa lo strumento come una stampella per compensare il fatto che non capisce il dominio del problema come dovrebbe? Questa potrebbe essere una buona opportunità per sedersi con lui / lei per capire quali strumenti usano, perché, e avere un'idea di come stanno cercando di affrontare il problema. O davvero non sanno quello che stanno facendo e stanno semplicemente lanciando strumenti al problema. O se lo fanno, allora quella cassetta degli attrezzi potrebbe essere qualcosa che ti piacerebbe aggiungere al tuo set di strumenti.

Quali linee guida di progettazione sono state date a questo programmatore prima che lui / lei iniziasse?

Se non hai messo giù qualcosa, sei altrettanto colpevole quanto il programmatore di creare più spazzatura.

Quanto è stato lungo il singolo metodo? Se erano dieci righe, è molto meglio di quello che questo ragazzo deve aver scritto:

At my previous job, we were porting a UNIX system to Windows NT using Microsoft VC++. A colleague of mine, that was in the process of porting his portion of the code, came to me, looking really upset.

Colleague: "Hey! I hate these Microsoft guys! What a rotten compiler! It only accepts 16,384 local variables in a function!"

(Vedi link )