Come distinguere tra software banale e non banale? [chiuso]

11

Cosa rende davvero banale un programma?

"A meno che il suo software banale" sia usato così spesso nelle discussioni di programmazione. Trovo molto vago, nel senso che non riesco davvero a capire se "qualcosa è essenziale perché il suo software non banale" o "il suo software non banale perché qualcosa è diventato molto essenziale".

Ad esempio, molte volte sulla questione del test unitario, sento "a meno che non sia banale, dovrai testare l'unità".

complexity

— NVM
fonte

9

A giudicare da alcuni dei programmatori con cui ho lavorato, direi che per loro la distinzione si è ridotta a "il tuo codice è banale, il mio codice non lo è".

— PSU

Potresti fornire una discussione di programmazione in cui vedi questa citazione usata? Sembra che ci siano diverse interpretazioni nelle risposte.

— Steven Jeuris,

Controlla la domanda aggiornata.

— NVM,

12

Ho intenzione di uscire su un arto qui e dire:

Un programma banale è uno che non ha un impatto diretto sul business.

Un'azienda manifatturiera considererebbe il suo software di contabilità banale, ma il software che controlla il braccio robotico che muove l'acciaio in ebollizione è fondamentale. Possono gestire bug e inversione di supporto bassa nel primo, ma non nel secondo. Se c'è un problema, hanno bisogno che sia risolto ora .

— Michael K
fonte

Anche se, un'altra risposta ha più punti, mi piace molto questa risposta. Ho posto la domanda perché non sono del tutto sicuro che il lavoro che sto svolgendo sia banale o meno e questo è un modo sicuro per capire se è considerato banale dagli "affari" o no. Per es. il software banale può cavarsela senza test unitari e non dipende in realtà da linee di codice o complessità. Tutto ciò che importa è se è fondamentale per l'azienda o no.

— NVM,

+1, buon punto. I Corporate Overlords a volte hanno idee molto diverse su ciò che conta come "banale". Ho aggiunto alcuni alla mia risposta per riflettere questo.

— FrustratedWithFormsDesigner,

+1 - Penso che questa risposta descriva meglio il contesto del termine come viene applicato nella domanda. L'altra "risposta al punto più alto" è accurata, ma solo in un contesto generale. Sono sicuro che questo lo supererà nei voti positivi, considerato che è considerato.

— Joel Etherton,

2

Quando gli sviluppatori di software dicono banali di solito si riferiscono alla complessità del software, non all'impatto sul business. Uno script che copia alcuni file da A a B sarebbe banale, ma potrebbe comunque avere un impatto diretto sul business se non funziona.

— Jacques B

16

Credo che l'intenzione più comune di questa affermazione sia che un programma abbia le seguenti caratteristiche:

È piccolo.
Breve durata.
Non è necessaria un'ulteriore estensione.
Un solo sviluppatore.

— Steven Jeuris
fonte

2

+1, tutti questi sono cruciali. Sfortunatamente, in un mondo con requisiti in continua evoluzione, a volte dovrete espandere software "banale" oltre la sua vita naturale.

— l0b0

1

Piccolo in termini di LOC, piccolo in termini di dimensioni binarie compilate, piccolo in termini di tempo impiegato per svilupparlo? Inoltre, direi che la breve durata non implica banale e la banale non implica breve durata. Ho visto casi in cui un software con un tempo di inattività di soli 6 mesi era in sviluppo per almeno il doppio ed era un sistema ponte cruciale. Ho visto i sistemi di conversione dei dati che sono stati utilizzati esattamente una volta, ma erano in sviluppo da oltre un anno ed erano tutt'altro che banali. E programmi banali come Minesweeper sembrano avere una durata di vita molto lunga.

— FrustratedWithFormsDesigner,

@FrustratedWithFormsDesigner: piccolo come in, una finestra di 100x100px naturalmente. ; p intendo, piccolo come nelle righe di codice che devono essere scritte, che è proporzionale al tempo impiegato per svilupparlo. La durata della vita non è essenziale, hai ragione, ma spesso è una caratteristica quando si discute di un approccio più avanzato rispetto a un approccio semplice.

— Steven Jeuris,

Non sarei d'accordo sul fatto che un basso LOC implica sempre banale. A volte la parte più complicata di un programma, la parte più difficile da correggere, gli algoritmi più difficili, si inserisce in <20 righe di codice. E un programma che consiste principalmente in centinaia di linee di getter / setter generati automaticamente - è quindi non banale anche se non ha nemmeno bisogno di uno sviluppatore per crearlo?

— FrustratedWithFormsDesigner,

1

@FrustratedWithFormsDesigner: credo che tu abbia una diversa interpretazione della domanda rispetto a me. La mia risposta riguarda il fatto di decidere su una soluzione banale rispetto a una complessa. La tua risposta riguarda problemi "difficili" vs "facili" da risolvere. Forse la domanda del PO dovrebbe essere chiarita un po '.

— Steven Jeuris,

14

Buttandolo via completamente, binari e fonti. Se qualcuno se ne accorge, non è stato banale.

— vegai
fonte

6

+1 Mi ha fatto ridere e ha anche senso.

— NVM,

8

Trivial è ...

qualcosa che esiste già, quindi perché reinventare la ruota?
qualcosa che può essere facilmente costruito tramite lo scripting di alcuni altri programmi insieme o scrivendo un piccolo codice che fa un uso pesante delle librerie esistenti che fanno ciò che deve essere fatto.
qualcosa che uno studente universitario CS medio potrebbe svolgere come compito di compiti da piccolo a medio.
qualcosa che ha requisiti dettagliati che potrebbero facilmente adattarsi a un tovagliolo da cocktail.
qualcosa che potresti codificare mentre sei distratto / ubriaco / nel tempo libero di pezzi di 4 o 5 minuti.
qualcosa che potrebbe essere creato con un semplice strumento per generare codice.

In un ambiente aziendale, aggiungerei questi:

qualcosa che agli utenti aziendali non dispiace aspettare un po 'per una soluzione.
qualcosa usato internamente che non ha supporto ufficiale dall'IT.
qualcosa che è prioritario tra le priorità più basse dal business, quando si fa pianificazione e pianificazione delle risorse.

— FrustratedWithFormsDesigner
fonte

4

Definirei un programma banale come uno che potrebbe ragionevolmente essere codificato:

In una sola seduta.
Come un singolo file / modulo (supponendo che tu non stia programmando in Java o in qualche linguaggio che impone una suddivisione super fine dei moduli).
Da qualsiasi programmatore decente "tuttofare", piuttosto che uno specialista.

— dsimcha
fonte

3

Ecco i miei esempi di programmi "banali":

Un progetto "fittizio" che ho impostato e iniziato a programmare solo per provare un pezzo di tecnologia o un codice di esempio. Nessuna intenzione di essere distribuita o addirittura mostrata a nessuno.
Codice demo scritto per presentazioni tecniche.
Un "unico". Intendo un'applicazione rapida che ho dovuto costruire una volta per usarla, perché è una strana situazione di dati che doveva essere spostata in un certo modo, o qualcosa che verrà immediatamente sostituito da qualcosa di più permanente.

— Marcie
fonte

3

Il software trival non esiste, è quando senti i requisiti e le cose che saranno trival quando in realtà è sempre non trival

Ecco una citazione che ho visto su Usenet dieci anni fa, ora è ancora più rilevante.

La complessità di una soluzione software è inversamente proporzionale alla complessità della spiegazione di cosa dovrebbe fare. - Sconosciuto

-1

Un programma che è solo un mucchio di metodi getter / setter. Nessuna logica di programmazione. Forse qualcosa con alcuni anelli.

Questa è la mia definizione di banale.

— davidhaskins
fonte

-1

La nostra definizione operativa è "qualcosa da cui nient'altro dipende".

Purtroppo ci sono stati alcuni prototipi banali che sono diventati prodotti di produzione non banali.

— Wyatt Barnett
fonte

-3

Ho anche sentito che è stato utilizzato nel contesto dell'impatto del programma sulla pianificazione generale del progetto. Se una determinata specifica non cambia la linea temporale della consegna del prodotto, rientra nell'etichetta di banale.

Conoscevo un programmatore che tendeva a usare "banale" come sinonimo di "Non vale nemmeno la pena discutere".

— SQLSuperHero
fonte