In che modo "semplice" è una vera soluzione KISS? [chiuso]

Impariamo un BACIO francese:

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. — Antoine de Saint-Exupéry

Che è tradotto in:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. — Antoine de Saint-Exupéry

Scenario

Devi tagliare e pizzicare.

Soluzione A: non KISS

SoluzioneB:BACIO

Come per una esatta definizione: è difficile definire una scala assoluta per misurare la semplicità. Soprattutto perché la vera semplicità preclude la vera comprensione del problema in questione, e raramente è raggiungibile. Ma diciamo che le soluzioni A e B illustrano la differenza tra le soluzioni che tendono rispettivamente alla supercomplicazione e alla semplicità.

"Rendi le cose il più semplici possibile, ma non più semplici" -Einstein

Mantenere il codice il più semplice possibile, ma non più semplice dipende dal problema da risolvere. Finché il problema da risolvere tende a cambiare, così fa KISS.

C'è un equilibrio tra l'over-engineering (oh uomo questo sembra un ottimo posto per mettere in mostra le mie abilità di Design Pattern!) e sotto-engineering (se solo avessi usato una fabbrica non avrei questo accoppiamento che mi ha causato per fare 20 modifiche al codice ...). L'obiettivo è la manutenibilità.

Semplice non significa rompere i buoni principi di programmazione. In realtà, significa più del contrario.

Does SIMPLE mean too short that it works but hard to maintain and extend?

No. Essere difficili da mantenere ed estendere sono un grande sintomo di complessità. In effetti, trovo che rendere il codice estensibile porti a un codice più semplice, dal momento che non si affronta ogni singolo caso per cominciare, è possibile mantenere il codice base più semplice.

Does SIMPLE mean breaking many of the OOP principles?

No. La maggior parte dei principi OOP è progettata per mantenere il codice più pulito e più organizzato, che alla fine è più semplice.

Does SIMPLE mean cheating?

No. scrivere duro per mantenere il codice & hack con il pretesto di mantenere le scadenze.

Does SIMPLE mean just keeping the deadlines without no dealy? etc.

No. le scadenze e la semplicità del codice sono due questioni separate. Scrivere un codice semplice non richiede più tempo per scrivere (sebbene sia un malinteso comune).

Questo è molto difficile da spiegare perché semplice non significa la stessa cosa per tutti.

Esempio. Alcuni sviluppatori pensano che ?: sia semplice, ma altri pensano che un'istruzione if sia migliore. Quando sei giù a questo livello, non puoi accontentare tutti.

In generale, significa semplice senza complessità . Per comprendere la semplicità, dobbiamo comprendere la complessità.

Ci sono due tipi di complessità:

Essential complexity refers to a situation where all reasonable solutions to a problem must be complicated (and possibly confusing) because the "simple" solutions would not adequately solve the problem. -- Wikipedia

Accidental complexity is complexity that arises in computer programs or their development process (computer programming) which is non-essential to the problem to be solved. -- Wikipedia

Puoi verificare la complessità essenziale con le seguenti domande:

Questa soluzione è semplice? Posso spiegarlo al mio peer in un paio di minuti e lo ottengono? C'è una soluzione più semplice al problema? Se sì, ci sono dei compromessi tra la soluzione complicata e quella semplice? Possiamo vivere con quei trade-off? Ad esempio, molti programmatori commettono un errore di micro ottimizzazione di tutto e la loro soluzione (e anche il codice) diventa eccessivamente complicata.

Verifica la tua complessità accidentale:

Il codice è semplice? Se torno indietro in tre mesi, quanto tempo impiegherò per costruire il contesto nel mio cervello in modo da poter apportare il cambiamento che devo apportare? Tutto nel mio codice sorgente ha uno scopo chiaro e trasmette efficacemente questo scopo a me e agli altri sviluppatori ? Quanto è difficile testare il mio codice? Di solito, più il tuo codice è complicato, più difficile è il test dell'unità, quindi di solito uso questo come una misura della complessità. Di solito vuoi classi e metodi piccoli, ben definiti e focalizzati. Gli schemi di progettazione solitamente ti aiutano a raggiungere anche questi.

Se ti accorgi di voler utilizzare un modello di progettazione solo perché hai appena letto su di esso, probabilmente introdurrà una complessità accidentale. Se ti accorgi di voler inserire qualcosa perché pensi che sia "intelligente", probabilmente introdurrà una complessità accidentale.

Spero che questo aiuti e non dimentichi: Semplice non significa FACILE .

Ho sempre pensato che i principi alla base del collegamento X11 ( ) meritassero attenzione. Non riesco sempre in questo obiettivo.

In particolare, continuo a dover ricordare a me stesso ... "Non aggiungere nuove funzionalità a meno che non si conosca un'applicazione reale che lo richiederà." E "Se è possibile ottenere il 90 percento dell'effetto desiderato per il 10 percento del lavoro, utilizzare la soluzione più semplice."

Question is: Can you write the EXACT definition of SIMPLE in terms of KISS principle? -if there is.

No.

Semplice - in questo particolare contesto è l'esatto opposto del complesso. Semplice non significa necessariamente: ogni persona stupida deve capirlo - ma devi assicurarti che tu possa capirlo, anche se non l'hai scritto da solo.

La complessità potrebbe essere raggiunta con un duro tyo per capire i riferimenti - sbarazzarsi di quelli! Molti file / classi collegati tra loro - assolutamente impossibile! E codice complicato (significato: loop concatenato, più livelli ITE, ecc.) - nessuno vuole leggerlo.

A mio parere: è molto semplice aggiungere un'altra funzione, nelle classi è anche possibile aggiungere funzioni private, quindi non si scherza con l'interfaccia. Quindi, perché non utilizzare questo vantaggio e limitare le funzioni / procedure a 50 linee. Forse anche meno. Ottieni alcuni nomi significativi. In questo modo si rendono obsoleti molti commenti. In questo modo le tue funzioni sono facili da leggere, facili da modificare / estendere.

Ovviamente ... le ultime frasi avrebbero funzionato come: Nelle classi c'è la disponibilità a definire le funzioni private, basta usare questa possibilità per dividere le funzioni in 50 fodere, quindi è molto più leggibile (non dimenticare buoni nomi, quindi non è necessario commentare così tanto.

BUT: È molto più semplice (!) leggere tutto se c'è un arresto completo che mostra: ho finito un pensiero, procediamo con il prossimo.

Questo è quello che definirei semplice.