Quanto è "semplice" una vera soluzione KISS? [chiuso]

12

Confesso : ho un problema a "Keep It Simple and Short" per la maggior parte del tempo perché cercare di farlo secondo i libri che ho letto, i modelli di design che ho ascoltato ecc. Mi dà un tale entusiasmo - un entusiasmo proveniente da la sensazione di essere sulla buona strada per una probabile perfezione.

D'altra parte, sì, ciò mi mette in maggiore stress in termini di rispetto delle scadenze a volte ...

Ma ogni volta che mi dico: "La prossima volta mantieniti semplice, stupido!" Trovo molto difficile renderlo "semplice" quando arriverà la prossima volta, perché inizia a sembrare strano ... e scomodo dopo un punto.

Quindi inizio a giudicare la mia comprensione del "semplice" ...

SEMPLICE significa troppo breve per funzionare ma difficile da mantenere ed estendere?

SEMPLICE significa infrangere molti dei principi OOP?

SEMPLICE significa barare?

SEMPLICE significa semplicemente rispettare le scadenze senza essere sordamente? eccetera.

In realtà, cos'è?

La domanda è : puoi scrivere la definizione ESATTA di SEMPLICE in termini di principio KISS? -se c'è.

Grazie!

design-patterns

— pencilCake
fonte

4

È "Keep it simple, stupid!", Non breve. e dopo averlo scritto, ho visto che in realtà lo sai ma non esiste alcun link per eliminare i commenti sul cellulare p.se ...

— yannis,

4

Non ho mai trovato qualcosa di così breve che fosse difficile estenderlo. Ho trovato MOLTE cose che erano mostruosità enormi che erano quasi irraggiungibili perché cambiare una cosa ha rotto tutto il resto.

— Ben Brocka,

1

Penso che l'errore commesso dalla maggior parte delle persone nel cercare di capire i KISS sia che pensano che la soluzione dovrebbe essere così semplice, è evidente . La verità è che trovare una soluzione semplice è tutt'altro che semplice. È davvero difficile !!! Una volta trovato, tutti pensano "oh, è così ovvio , perché non l'ho visto prima?"

— Treb,

2

Un buon KISS è difficile da spiegare o definire con precisione, ma una volta capito bene, lo saprai. Continua a praticare!

— Cascabel,

1

Mi dispiace che questo sia stato migrato qui invece che semplicemente chiuso, ma questo è esilarante fuori tema qui.

35

Impariamo un BACIO francese:

La perfezione è in atto, non è un caso più positivo, ma più è un punto più positivo. - Antoine de Saint-Exupéry

Che è tradotto in:

La perfezione si ottiene, non quando non c'è altro da aggiungere, ma quando non c'è più niente da togliere. - Antoine de Saint-Exupéry

— mouviciel
fonte

2

Dovrebbe essere "La perfezione è quando non c'è nulla da rimuovere"

— normanthesquid,

2

Questa è una grande citazione ma manca di consigli pratici.

— c_maker,

2

Potresti rendere questa risposta più semplice (anche più perfetta) se rimuovi la parte francese. :)

— Phil

1

@Phil: Au contraire, mon ami.

— Gilbert Le Blanc,

14

Scenario

Devi tagliare e pizzicare.

Soluzione A: non KISS

inserisci qui la descrizione dell'immagine

Soluzione B: KISS

inserisci qui la descrizione dell'immagine

Per quanto riguarda una definizione esatta : è difficile definire una scala assoluta per misurare la semplicità. Soprattutto perché la vera semplicità preclude la vera comprensione del problema attuale, e ciò è raramente raggiungibile. Ma diciamo che la soluzione A e B illustrano la differenza tra le soluzioni che tendono rispettivamente all'ipercomplicazione e alla semplicità.

— back2dos
fonte

Questo mi ha fatto sorridere.

— c_maker,

Molto violento, vero?

— NoChance,

2

Non è. Il mio gattino ci dorme. Pertanto non è violento.

— Thomas Eding,

11

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

Mantenere il codice il più semplice possibile, ma non più semplice dipende dal problema da risolvere. Fintanto che il problema da risolvere tende a cambiare, anche il BACIO.

C'è un equilibrio tra sovraingegneria (oh amico, questo sembra un ottimo posto per mettere in mostra le mie capacità di Design Pattern!) E sottoingegneria (se solo avessi usato una fabbrica non avrei questo accoppiamento che mi ha causato 20 modifica del codice ...). L'obiettivo è la manutenibilità.

— P.Brian.Mackey
fonte

1

"Mantieni la tua complessità ciclomatica al valore che dovrebbe essere e nessun altro valore". "Compra una casa con un rapporto prestito / valore il più basso possibile, ma non inferiore". "Mangia una buona colazione come puoi, ma niente di meglio". "Acquista il più basso e vendi il più alto possibile, ma non inferiore / superiore". "Cresci più alto che puoi, ma non più alto". "Rendi i nomi delle variabili il più significativi possibile, ma nessun significato più completo". "Dai la percentuale di sforzo più alta possibile, ma non superiore". "Non c'è" io "in" squadra ", ma ce n'è uno in" superiore "". "Fermati e annusa le rose, ma solo quando ci sono rose". "Scrivi commen

— psr

11

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

SEMPLICE significa troppo breve per funzionare ma difficile da mantenere ed estendere?

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

SEMPLICE significa infrangere molti dei principi OOP?

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

SEMPLICE significa barare?

No. scrivere duro per mantenere il codice e gli hack con il pretesto di rispettare le scadenze è.

SEMPLICE significa semplicemente rispettare le scadenze senza essere sordamente? eccetera.

No. le scadenze e la semplicità del tuo codice sono due questioni distinte. Scrivere un semplice codice non richiede più tempo per scrivere (anche se è un malinteso comune).

— GSto
fonte

Forse pensi che soffra di questo malinteso, ma penso che la soluzione ideale ideale non sia sempre la prima cosa che ci viene in mente, quindi a volte inizialmente ci vuole più tempo per scrivere un codice più semplice - poi in seguito fai quel tempo e altro da non dover affrontare la complessità.

— Cascabel,

6

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 ifun'affermazione sia migliore. Quando scende a questo livello, non puoi piacere a tutti.

In generale, mezzi semplici senza complessità . Per comprendere la semplicità, dobbiamo comprendere la complessità.

Esistono due tipi di complessità:

La complessità essenziale si riferisce a una situazione in cui tutte le soluzioni ragionevoli a un problema devono essere complicate (e forse confuse) perché le soluzioni "semplici" non risolverebbero adeguatamente il problema. - Wikipedia

La complessità accidentale è la complessità che si presenta nei programmi per computer o nel loro processo di sviluppo (programmazione per computer) che non è essenziale per il problema da risolvere. - Wikipedia

Puoi verificare la complessità essenziale con le seguenti domande:

Questa soluzione è semplice? Posso spiegarlo al mio collega in un paio di minuti e loro lo ottengono? Esiste una soluzione più semplice al problema? Se sì, ci sono dei compromessi tra la soluzione complicata rispetto a quella semplice? Possiamo vivere con questi compromessi? Ad esempio, molti programmatori commettono un errore nell'ottimizzare tutto e la loro soluzione (e anche il codice) diventa eccessivamente complicata.

Verifica della complessità accidentale:

Il codice è semplice? Se ci ripenso tra tre mesi, quanto tempo ci vorrà per costruire il contesto nel mio cervello in modo da poter apportare il cambiamento che devo fare? Tutto nel mio codice sorgente ha uno scopo chiaro e lo trasmette efficacemente a me e agli altri sviluppatori ? Quanto è difficile testare il mio codice? Di solito più complicato è il tuo codice, più difficile sarà il test unitario, quindi di solito lo uso come misura di complessità. Di solito vuoi classi e metodi piccoli, ben definiti e focalizzati. I modelli di progettazione di solito ti aiutano a raggiungere anche questi.

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

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

— c_maker
fonte

1

+1 per definire la semplicità in termini di complessità essenziale e accidentale.

— Zach,

2

Ho sempre pensato che i principi dietro X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) valessero la pena di essere ascoltati. Non riesco sempre a raggiungere questo obiettivo.

In particolare, continuo a dover ricordare a me stesso ... "Non aggiungere nuove funzionalità a meno che tu non sia a conoscenza di qualche applicazione reale che lo richiederà." E "Se riesci a ottenere il 90 percento dell'effetto desiderato per il 10 percento del lavoro, usa la soluzione più semplice. "

— nwahmaet
fonte

1

La domanda è: puoi scrivere la definizione ESATTA di SEMPLICE in termini di principio KISS? -se c'è.

No.

— Jeremy
fonte

3

Non sono sicuro che questa dovrebbe essere una risposta. Se non riesci a dare una definizione del genere, non dovresti rispondere a IMHO. Se ritieni che una definizione esatta sia impossibile in generale, dovresti approfondire i motivi.

— back2dos,

Ciò che amo di questa risposta è che segue il principio KISS alla lettera! +1

— Treb,

semplice può essere davvero complicato a volte.

— GSto

@ back2dos è il reclamo più forte; Non vado in giro a pubblicare risposte "Non lo so".

— Jeremy,

0

Semplice: in questo particolare contesto è esattamente l'opposto del complesso. Semplice non significa necessariamente: ogni persona stupida deve capirlo - ma devi assicurarti di poterlo capire, anche se non l'hai scritto tu stesso.

La complessità potrebbe essere raggiunta da riferimenti difficili da capire - sbarazzati di quelli! Molti file / classi collegati tra loro - assolutamente no! E codice complicato (significato: loop concatenati, più livelli ITE, ecc.) - nessuno vuole leggerlo.

A mio avviso: è molto facile aggiungere un'altra funzione, nelle classi è anche possibile aggiungere funzioni private, quindi non si scherza con l'interfaccia. Quindi perché non usare questo vantaggio e limitare le funzioni / procedure a 50 righe. Forse anche meno. Ottieni alcuni nomi significativi. In questo modo rendi la maggior parte dei commenti obsoleti. In questo modo le tue funzioni sono facili da leggere, facili da modificare / estendere.

Certo ... le ultime frasi avrebbero funzionato come: nelle classi c'è la disponibilità per definire le funzioni private, basta usare questa possibilità per dividere le funzioni in 50 linee in modo che sia molto più leggibile (non dimenticare i bei nomi, quindi non è necessario commentare così tanto).

MA: È molto più semplice (!) Leggere tutto se c'è un fullstop che mostra: ho finito un pensiero, continuiamo con il prossimo.

Questo è ciò che definirei semplice.

— Philipp Wendt
fonte