qual è la differenza tra ingegneria, ingegneria e ingegneria di destra? [chiuso]

Quando stai progettando troppo per risolvere un problema di base, sei over-engineering . Ad esempio, quando si utilizza un pattern factory astratto "just in case" per creare un oggetto molto semplice in cui la business logic è abbastanza semplice da stare in LOC quattro-cinque, si sta pensando troppo al design (e violando KISS e YAGNI).

Tieni presente che non deve necessariamente essere eccessivamente complesso . Un modello di fabbrica astratto non ha nulla di complesso in esso non appena le classi vengono nominate correttamente e gli altri membri della squadra conoscono il modello. Detto questo, sono ancora troppe classi e codice per un problema che può essere risolto senza ricorrere a schemi specifici.

Quando non stai facendo abbastanza, sei under-engineering . Ad esempio, se la maggior parte della base di codice Java è in metodi statici all'interno di classi statiche e la maggior parte è in classi di utilità, non stai pensando abbastanza al design.

Si noti che la sovraingegneria e la sottoprogrammazione sono solitamente eseguite da programmatori inesperti, attraverso due diversi modelli:

• I più inesperti non conoscono abbastanza i modelli di progettazione e tendono a non usarli e a non pensare troppo al design. Lasciano che il loro codice cresca con un design scarso o nullo, trovando il codice più semplice da leggere e capire.

• Un po 'più esperti che hanno iniziato ad apprendere modelli di progettazione hanno la tendenza ad applicare questi modelli ovunque per dimostrare di conoscerli. Dovremmo creare un oggetto? Usiamo un modello di builder con un builder astratto e uno concreto. Hai bisogno di comunicare tra due oggetti? Usiamo il modello dell'adattatore! E, ovviamente, le interfacce fluenti sono divertenti, dal momento che ci fanno scrivere codice come questo:

  Product product = ProductBuilder()
      .setId(39)
      .setPrice(new PriceFactory().usingAmount(59).usingUnit(Unit.Dollar))
      .setTitle("Product 1"),
      .setDescription("Description goes here")
      .getResult()
  

  invece di:

  Price price = new Price(59, Unit.Dollar);
  Product product = new Product(39, price, "Product 1", "Description goes here");
  

Richiede molta più esperienza ed esperienza per trovare il centro d'oro, cioè usare tanto design quanto necessario, ma assolutamente non più. Questo è il termine di ingegneria di destra, anche se non è usato molto nel settore, per una buona ragione.

Over-engineering e under-engineering sono i termini usati per criticare il codice di qualcun altro, come in "Amico, smetti di sovra-ingegnerizzare il tuo codice, riusciamo a malapena a trovare la strada attraverso dozzine di classi aggiunte inutilmente!" D'altra parte, il centro d'oro di right-engineering di uno sviluppatore non sarà necessariamente lo stesso (e di solito non è lo stesso) per gli altri. Una risposta recente mostra quanto non sia ovvio determinare dove porre una frontiera tra l'utilizzo di una fabbrica o lo spostamento del logica in un costruttore. Quindi, non si può affermare che il suo codice sia stato progettato correttamente, perché almeno alcuni dei suoi colleghi non sarebbero d'accordo.

"over engineering" significa migliorare una soluzione quando il costo di migliorarlo è superiore ai benefici di migliorarlo. E "in ingegneria" significa non migliorare una soluzione, quando i benefici di migliorarlo supererebbero i costi. Ora indovina quale "ingegneria giusta" significa ...

Poiché una soluzione "semplice" è stata menzionata ed era in qualche modo correlata a sviluppatori inesperti, mi dispiace, ma gli sviluppatori poco esperti spesso non riescono a trovare una soluzione semplice. Gli sviluppatori esperti trovano una soluzione semplice se ce n'è una, ed è spesso la soluzione "giusta progettata", perché richiede la minima quantità di lavoro per ottenere una soluzione funzionante, è spesso leggibile e mantenibile perché è semplice, spesso (non sempre) è efficiente perché non spreca tempo in una complessità non necessaria.

L'aggiunta di complessità non è eccessiva. L'over-engineering, per definizione, migliora effettivamente il prodotto (non abbastanza per giustificare il costo del miglioramento). L'esempio dato ha appena aggiunto la complessità inutile senza alcun beneficio.

E il codice non è progettato correttamente quando è perfetto. È progettato correttamente quando raggiunge il punto in cui il costo del miglioramento supera i benefici del miglioramento. Se non siamo nemmeno d'accordo sul fatto che un cambiamento sia o meno un miglioramento, allora è molto improbabile che il cambiamento abbia dei benefici che giustificano il lavoro di cambiarlo.

I call the two extremes described "under-engineering" and "over-engineering"

Sembrano riferirsi alla frase nel link sopra:

In my experience there are two developer character type extremes: the ones that always seek and settle with the simplest solution, and the ones that seek the perfect solution, perfect in terms of efficiency, readability or code elegance.

Sembra che questi termini non siano molto usati, li sta usando per spiegare i concetti nel resto del post.

Potrei obiettare che:

The ones that always seek and settle with the simplest solution [...] constantly create mess

Questa è chiaramente non la definizione che do a "soluzione semplice".

Queste sono letture interessanti, grazie. Attualmente sto leggendo un libro intitolato "Just enough Software Architecture", di George Fairbanks. In questo contesto, probabilmente definire over-engineering (troppo ingegnere) come una spesa troppo lunga nella fase di progettazione, sebbene, è possibile programmare anche durante la codifica. Il libro sottolinea un approccio orientato al rischio. Identificare il rischio, stimare il rischio, dare la priorità alle attività e progettare di conseguenza. Potresti trovarlo interessante.