È efficiente e una pratica normale avere una classe con migliaia di righe di codice? [duplicare]

2

Attualmente sono in un progetto di sviluppo di prodotti software continuo basato su codice legacy Java . Il codice sorgente è molto complicato, il che è buono e cattivo.

Ma sono sorpreso nel vedere che nel componente principale la maggior parte delle classi contiene migliaia di linee, non un migliaio di righe ma solitamente oltre 5000 linee, in un solo file .java. Di conseguenza, gli sviluppatori, o almeno io, spesso dedicano molto tempo all'utilizzo del debugger con IDE. IMO, tale modo di codifica ha perso lo scopo della programmazione orientata agli oggetti e ha sicuramente bisogno di refactoring

Non so che la causa di dedicare molto tempo al debugging è perché sono un cretino senza esperienza sufficiente o le migliaia di linee di codice in un file .java, ea volte mi sono davvero stufato di un tale tipo di codice. Una volta ho disaccoppiato alcune parti del codice in un file java separato, ma alcuni membri del team hanno criticato questo aspetto con la mancanza di spirito di squadra come scusa.

Domanda:

  • Se il mio obiettivo è diventare un programmatore di livello professionale molto professionale, vale la pena e il valore di lavorare in questo tipo di progetto di sviluppo software?
  • La mancanza di tempo è una scusa per aggiungere centinaia di metodi a una classe Java e centinaia di linee a un solo metodo?

Mi piacerebbe ricevere commenti e opinioni su questo da sviluppatori più esperti.

    
posta Rui 22.11.2018 - 20:05
fonte

1 risposta

7

If my goal is to become a very professional top-level programmer, is it worth and valuable to work in such kind of software development project?

Certamente. Siti come questo spesso parlano dei vantaggi del refactoring, del buon design e di tutte queste linee guida per rendere il software eccezionale. E nel vuoto, a volte non è chiaro perché facciamo suggerimenti o perché tutte queste regole sono in vigore.

Lavorare in un luogo con codice ovviamente errato può aiutarti a capire meglio come è il codice errato; che codice cattivo si sente. Puoi scoprire che tipo di problemi con le persone portano a questi problemi tecnici. E idealmente, puoi fare pratica per risolverli. Puoi avere un'idea di quali cambiamenti rendono il massimo. O per lo meno, puoi davvero apprezzare un ambiente di sviluppo eccezionale.

Is the lack of time an excuse for adding hundreds of methods to one Java class and hundreds of lines to only one method?

È una scusa molto comune. Non è una scusa valida o valida. Come recita il vecchio adagio: "Se non hai il tempo di farlo bene, quando avrai mai il tempo di farlo?"

Scoprirai che la tua azienda no. Scoprirai che la gestione crea quasi invariabilmente una cultura in cui le persone vengono ricompensate per aver raggiunto una scadenza o aver fatto le cose nel modo più rapido / economico possibile. "Non abbiamo tempo" è una scelta. Tutti i tuoi sviluppatori devono fare è dire di no. La direzione non sta per scrivere il codice.

    
risposta data 22.11.2018 - 20:30
fonte