Devo scrivere un sacco di codice boilerplate se continuo a lavorare usando Java? [chiuso]

Stiamo parlando di cose molto diverse qui. Sostituire il codice di caldaia con un modo completamente diverso di fare le cose, come la riflessione, può essere peloso. Possono esserci davvero ottime ragioni per non farlo anche se semplifica la programmazione per te , come la perdita di sicurezza e protezione dei tipi, i costi di runtime, maggiori costi di comprensione e manutenzione per gli altri, ecc. o non è il caso nella tua situazione, ma potrebbe essere.

Tuttavia, semplificare la generazione del codice boilerplate è un'altra cosa. Se è abbastanza ripetitivo da poter essere completamente automatizzato, allora direi di sì, assolutamente dovrebbe essere automatizzato. Ci sono troppe cose che possono andare storte mantenendo tali basi di codice a mano, e solo troppo sforzo risparmiato per non farlo. E se i colleghi non riescono nemmeno a capire come funziona un generatore di codice, allora, non dovrebbero essere colleghi di lavoro nel mio libro.

Questa domanda riporta a questa vecchia citazione:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. [Brian W. Kernighan]"

In un ambiente di squadra questo dovrebbe essere ampliato in modo che se la persona più intelligente del team scrive il codice più intelligente che possono, la persona più stupida del team non ha alcuna speranza di debugarlo.

Ho appena notato questa citazione:

Simplicity is prerequisite for reliability. [Dijkstra]

Non credo che l'uso del codice "boiler plate" sia correlato a un particolare linguaggio, ma piuttosto che sia una decisione progettuale. Per qualsiasi ragione, l'azienda per cui si sta lavorando ha fatto questa scelta, possibilmente in relazione alla facilità di manutenzione o facilitando il supporto operativo delle applicazioni. 'Reflection is evil' è solo una riflessione su queste ragioni, un mantra facile da ricordare e da mettere in pratica.

Prima di tutto, puoi avere il codice standard nel software scritto in qualsiasi lingua. Non è specifico per Java. Ho scritto e lavorato con grandi applicazioni java che avevano quasi zero codice boilerplate.

Come in ogni altro software, potrebbe esserci qualche semplice codice di codice qui e là. Ma di solito, è piccolo e non è proprio un problema scrivere le linee in più, né nuocere alla leggibilità. D'altra parte, può aiutare il debug, la manutenzione, ecc ...

Detto questo, l'obiettivo di tutto il codice sorgente dovrebbe essere quello di cercare semplicità e facilità di comprensione. Se il codice è eccessivo e hai una soluzione molto più semplice, che porta a un codice più leggibile, manutenibile e comprensibile, quindi, con ogni mezzo, fallo. Dimostralo al tuo superiore, che è più semplice, più sicuro, meno codice, ecc. E se è davvero così ovvio, la sua decisione dovrebbe essere ovvia.

Ora, d'altra parte, se vuoi creare un costrutto inflessibile e super complicato, solo per salvare un paio di righe, allora sono d'accordo con il tuo capo. Potrebbe essere una fonte di più complessità che tenta di risolvere. Ricorda che non codifichi per te stesso, codifichi per gli altri.

Una cosa è inventare un nuovo linguaggio che viene tradotto nella lingua di destinazione (pensa coffeescript- > javascript) e una cosa completamente diversa per avere un generatore che crea solo la prima versione di un file sorgente.

Il primo è costoso e difficile da realizzare e dovrebbe essere lasciato a persone che sanno come progettare e implementare le lingue.

Il successivo è utile in ambienti in cui è richiesto un codice hotplugged ridondante, e in genere non è molto difficile da progettare e realizzare. L'utilizzo di un tale strumento genera un codice boilerplate che sembra essere stato scritto a mano, solo un po 'più coerente e senza errori di battitura. Una volta generato, il file sorgente viene ulteriormente elaborato, modificato, adattato, esteso ecc. Il file di input per il generatore è una tantum; non viene fatto alcun tentativo per consentire viaggi di andata e ritorno ecc.

Per rispondere alla tua domanda: scegli la seconda opzione, non preoccuparti di provare la prima.