È possibile scrivere software che non ha bisogno di essere continuamente modificato?


23

Ho scritto un sacco di software in molte lingue diverse e ho anche scritto "hardware" per l'uso con FPGA usando Verilog e VHDL.

Tendo a divertirmi a scrivere hardware più del software, e penso che uno dei motivi principali sia che è possibile scrivere hardware "fatto" e che non deve mai essere modificato: si definiscono le interfacce e le funzionalità, si scrive un banco di prova , implementa il modulo hardware, quindi testalo con un simulatore. Quindi puoi fare affidamento su quel modulo hardware come blocco predefinito per creare qualcosa di più grande e migliore: se devi aggiungere una funzionalità a quel modulo, crei un secondo modulo e aggiungi lì la funzionalità. Non butti mai via il modulo originale poiché funziona perfettamente e può ancora essere utile.

Una delle mie principali frustrazioni con il software è che non viene mai "fatto". C'è sempre un'altra funzione da aggiungere. Spesso quando si aggiunge una funzione introduce un bug da qualche altra parte che funzionava bene prima. Ciò non accade nell'hardware purché le interfacce non vengano violate.

Per essere chiari, non sto sostenendo la costruzione di una versione di qualcosa con un elenco di funzionalità e il gioco è fatto per sempre: sono a favore di iterazioni e versioni multiple nel tempo per aggiungere nuove funzionalità. Non voglio solo infilare il codice a sinistra e trovare un bug a destra, e questo sembra accadere dopo aver aggiunto una nuova funzionalità.

È possibile scrivere software in un modo simile in cui l'hardware è "scritto"? Esiste una buona metodologia di sviluppo del software che consente di fare sempre progressi e consente di aggiungere nuove funzionalità senza la necessità di riscrivere il codice esistente e introdurre nuovi bug?


8
Sembra che descrivi OCP
Oded il

Questa roba di principio aperto-chiuso sembra grande! Qualcuno l'ha usato con successo?
Nathan Farrington,

2
@NathanFarrington: la maggior parte dei modelli di design (come descritto da GOF ) segue l'OCP. Un esempio potrebbe essere il modello Metodo modello .
Spoike,

2
@NathanFarrington Il principio aperto-chiuso è un principio comune utilizzato dagli sviluppatori di software nella progettazione del software.
Jesper,

1
Immagino che molti dei programmi che abbiamo usato oggi siano realizzati usando pezzi che sono copie carbone per scrivere un codice scritto 20 anni fa.
Mallow,

Risposte:


16

Forse ha qualcosa a che fare con interfacce e test ben definiti, come l'hardware?

Esattamente i miei pensieri!

I moduli ben progettati con interfacce chiare tendono ad essere essenzialmente perfetti. Pensa a qualcosa come la Stringclasse di Java. È un programma per computer, ma ha un'interfaccia cristallina. Non ci sono bug noti in esso. Fa quello che dovrebbe fare, perfettamente. Certo, è stato ampiamente testato negli ultimi 15 anni e dato che praticamente tutti i programmi usano Strings come elementi di base, qualsiasi bug in esso verrà rapidamente notato. Qualsiasi "stranezza" - non rigorosamente bug, ma dettagli di progettazione di cui è necessario essere a conoscenza - come quelli descritti qui http://www.jwz.org/doc/java.html sono ormai ben noti e quindi possono essere presi in considerazione account.

Il software buggy è in parte un problema culturale: le persone sono abituate al software buggy e, diversamente dall'hardware, in genere il software può essere facilmente risolto in seguito, quindi non deve perfezionarsi inizialmente (o mai, perché ehi, dobbiamo spedire ora, sistemiamo nella prossima versione). Ma in gran parte, si tratta di un vero problema di complessità: la complessità del software è andata costantemente aumentando negli ultimi 50 anni circa, ma il cervello umano è lo stesso. Quando la crescente difficoltà di raggiungere la perfezione e la crescente facilità di aggiustare le cose in un secondo momento (build veloci, automatiche, distribuzione di Internet) si combinano con la pressione del programma e la mancanza di disciplina, il risultato è quello che è.

Esiste una buona metodologia di sviluppo del software che consente di fare sempre progressi e consente di aggiungere nuove funzionalità senza la necessità di riscrivere il codice esistente e introdurre nuovi bug?

Probabilmente nessun proiettile d'argento, ma una buona combinazione di migliori pratiche, incluso ma non limitato a:

  • Moduli semplici e autonomi. In altre parole, basso accoppiamento e elevata coesione.
  • Immutabilità. Particolarmente importante con una crescente concorrenza.

Vale la pena notare che entrambi i punti mirano a ridurre la complessità. Questo è il punto chiave. L'entropia tende sempre ad aumentare e, a meno che non lo combattiamo, presto affogeremo nella complessità. È anche interessante vedere che negli ultimi anni, i linguaggi di programmazione si sono evoluti verso l'incoraggiamento o addirittura l'applicazione delle pratiche sopra menzionate. In particolare, l'ascesa dei linguaggi funzionali è proprio questo: le funzioni pure restituiscono sempre lo stesso valore per lo stesso input, non c'è stato in esse. Quindi componi semplicemente funzioni pure che assumono e restituiscono valori immutabili e limitano l'inevitabile mutabilità in piccoli luoghi ben definiti invece di diffonderli ovunque. Dai un'occhiata a: http://clojure.org/state


1
jwz non è del tutto d'accordo sul fatto che la classe String sia priva di bug - jwz.org/doc/java.html

1
Può funzionare come progettato, quindi la domanda è se il design sottostante è rotto. Sono d'accordo, tuttavia, che String è una classe molto affidabile.

1
Risposta eccellente. Ora codice quasi esclusivamente in Python e provo a sfruttare i costrutti di programmazione funzionale. Sì, penso che tu abbia ragione nel dire che l'immutabilità è la chiave. La prima volta che creo un modulo software, anche se lo collaudo, probabilmente ho incasinato l'interfaccia, o forse ha la responsabilità sbagliata o troppi. Quindi faccio un secondo modulo e lascio solo il primo! Posso ancora utilizzare il primo modulo in futuro, se lo desidero, ma non lo cambierò mai, perché sebbene non sia perfetto, funziona. Quindi i linguaggi funzionali con immutabilità potrebbero aiutarti come suggerisci.
Nathan Farrington,

1
@JoonasPulakka: Sì, se c'è un riassunto di una riga del software, potrebbe essere "c'è sempre un altro bug". :-) E penso che sia uno dei punti di Nathan.
Ross Patterson,

1
Joonas, hai vinto. Ho iniziato a studiare Clojure. Sembra il modo migliore per rendere di nuovo divertente la programmazione.
Nathan Farrington,

9

La differenza è quanto è più semplice ed economico modificare il software rispetto all'hardware. Se l'hardware fosse facile ed economico da modificare e spedire ai clienti, lo farebbero.

Penso che se potessi riassumere la mia domanda scarsamente espressa sarebbe qualcosa come "come posso divertirmi di più a scrivere software non introducendo bug nel codice di lavoro e facendo sempre progressi?" Forse ha qualcosa a che fare con interfacce e test ben definiti, come l'hardware?

Dovresti assolutamente verificare lo sviluppo guidato dai test .


Molte risposte alla mia domanda sembrano contenere folklore. È necessariamente più facile trovare e correggere i bug del software piuttosto che progettarli dall'inizio? Quanto costa davvero modificare il software? Probabilmente nessuno lo sa davvero. Per quanto riguarda lo sviluppo basato su test, ha senso testare un software che può essere riutilizzato. Il software diventa quindi un vero e proprio blocco anziché una palla di fango. Ma non ha senso testare il software se cambierà domani. Immagino che mi stavo chiedendo se possiamo effettivamente creare software da blocchi anziché da fango.
Nathan Farrington,

1
@NathanFarrington: credo che ci sia un'enorme differenza nel modo in cui vengono fatte le specifiche e il design hardware / software. La maggior parte dei produttori di hardware ha probabilmente migliori specifiche per ciò che fanno di uno sviluppatore di software il cui client può solo dire "Voglio un programma che faccia questo!" È praticamente garantito per ottenere nuove funzionalità e cosa no.
RCE,

Sicuramente se ci sono molte modifiche, potrebbe essere necessario cambiare anche alcuni test, ma non è come se il software passasse dall'elaboratore di testi al web server. La funzione "nuovo documento" creerà comunque una nuova funzione e i suoi test dovrebbero essere ancora validi.
RCE,

Hai sottolineato un altro principio chiave: migliori sono le specifiche, meno sono necessarie modifiche lungo la strada. Ma questo non era esattamente quello a cui stavo arrivando nella mia domanda perché puoi aggiungere funzionalità all'hardware prima che sia fatto proprio come il software. Penso che OCP sia stata la vera risposta, purtroppo è un commento, quindi non posso contrassegnarlo come risposta. Un altro punto è stato quello di fare sempre progressi e penso che TDD possa aiutarlo fornendo test di regressione.
Nathan Farrington,

Cambiare software sembra più facile e meno costoso dell'hardware, ma è davvero? Sì, posso fare un cambiamento e praticamente all'istante fare una nuova build con la semplice pressione del mio dito. Tuttavia, la build deve ancora passare attraverso la convalida / QA. Qual è stato il costo opportunità? Cosa avrei fatto invece di correggere questo bug. Cosa avrebbe fatto il controllo qualità se non fossero stati necessari per riconvalidare il software. Sono stati respinti diversi progetti per portare questa soluzione sul mercato? Ci sono molti costi "nascosti" a cui le persone non pensano. Potrebbe essere più semplice, ma non necessariamente meno costoso.
Pemdas,

6

Commenterò alcune delle tue osservazioni, sperando che tu ottenga la risposta da questi commenti.

Una delle mie principali frustrazioni con il software è che non viene mai "fatto".

Questo perché le specifiche della soluzione sono incomplete o perché il piano per fornire miglioramenti non è accurato. Questo può accadere a qualsiasi software di progetto, hardware o altro.

Esiste una buona metodologia di sviluppo del software che consente di fare sempre progressi e consente di aggiungere nuove funzionalità senza la necessità di riscrivere il codice esistente e introdurre nuovi bug?

Naturalmente, la creazione di moduli indipendenti dovrebbe ridurre notevolmente la dipendenza. Questo deve essere considerato quando si progetta il software. È necessario considerare la separazione delle preoccupazioni, i livelli, i livelli, gli oggetti controller, le interfacce, ecc.

"come posso divertirmi di più a scrivere software non introducendo bug nel codice di lavoro e facendo sempre progressi?"

1-Comprendere attentamente i requisiti. Potrebbe essere necessario prendere in considerazione la chiusura dei requisiti prima della progettazione. Se fai uno sviluppo iterativo, non c'è alcuna possibilità di farlo. Alcune metodologie lo incoraggiano, ma personalmente, penso che ciò non vada bene per tutti i tipi di progetto. Costruire software su solidi requisiti consente una progettazione migliore.

2-Fai capire all'utente questa filosofia di lunga durata.

Attuazione a 3 piani con attenzione

4-Design prima del codice.

5-Usa design generico quando appropriato.

6-Usa prototipi come strumento di conferma del progetto.


Questi sono tutti ottimi consigli. Per riassumere i miei pensieri fino a questo punto: (1) rilasciare una GRANDE OFFERTA e fare molti test e QA prima di una versione, (2) rendere i moduli una GRANDE OFFERTA e assicurarsi che abbiano interfacce documentate ben definite con i test per quelli interfacce e asserzioni per vedere se l'interfaccia viene violata e una volta che un modulo viene "rilasciato" non viene mai modificato (OCP).
Nathan Farrington,

4

Come le persone di solito sono molto veloci a sottolineare, uno dei vantaggi del software è che dovrebbe essere facile e relativamente economico da modificare rispetto all'hardware. Questo è particolarmente importante quando ti accorgi in ritardo che hai qualcosa di fondamentalmente sbagliato. Fai lo stesso con l'hardware e perdi un milione di dollari, quindi, come hai detto, usi i tuoi simulatori ecc. E ne provi il bazinga. Penso che sia qui che il paradigma fallisce un po 'quando si passa al software.

Entra nella testa dello sviluppatore di software medio e quello che hai è una persona molto impegnata con una scadenza incredibilmente stretta. Il suo manager sta dicendo che va bene lasciare alcuni bug perché puoi sempre correggerlo in seguito. I test sono spesso ripensati, ma anche in uno scenario guidato dai test, i test sono ridotti al minimo e il codice è scritto al minimo dei test, e spesso vengono prese scorciatoie in modo da perdere molti dei casi limite. Il sistema può essere accuratamente testato dall'unità, ma raramente viene rigorosamente testato rigorosamente nel suo insieme e altrettanto raramente sottoposto a stress test in misura notevole. Aggiungete a ciò che scrivete software da zero e ci sono poche opportunità di simulare il software prima di impegnarvi a scriverlo, principalmente perché raramente scriviamo software dallo stesso tipo di blocchi che si trovano nell'hardware.

Torna alla domanda del PO. Potresti definire un sistema di blocchi da cui derivare tutto il tuo software? Possibilmente. Sarebbe molto conveniente? Probabilmente no, perché quando si arriva allo sviluppo di un sistema abbastanza robusto di componenti, test e altri accessori per supportare questo idealesistema di programmazione, scopriresti che la concorrenza ti avrebbe già battuto sul mercato, e ancora peggio, dal punto di vista del programmatore medio probabilmente troverai uno stile di sistema di programmazione "cookie-cutter" molto limitante e molto probabilmente molto noioso. Lavoro personalmente su un'API, dove la maggior parte del codice del modulo è stata perfezionata e standardizzata in modo così completo, che tutto ciò che faccio ora è generare un modello di codice e riempire gli spazi vuoti. La maggior parte del mio tempo può essere impiegata per scrivere un semplice codice connettore e per far uscire i moduli il più velocemente possibile. È seriamente insensibile. Ci sono pochissime opportunità di fare qualcosa di più che semplicemente codificare lo stesso genere di cose più e più volte, quindi quando arriva un'altra opportunità di progetto, colgo l'occasione per poter fare QUALCOSA di altro.

Quindi, come puoi fornire software di alta qualità e ben ponderato, e tuttavia divertirti a farlo? Credo che ciò dipenda dalla tua scelta di strumenti e metodologia. Per me la risposta è stata quella di utilizzare una buona API BDD, perché mi ha permesso di creare un codice molto facile da leggere, ma altamente granulare. Sono in grado di creare una serie di test a partire da un numero minimo di metodi riutilizzabili e di descrivere i miei test nella lingua delle specifiche. In questo modo, mi avvicino ad un approccio di sviluppo più articolato, tranne per il fatto che sono responsabile della progettazione e del controllo degli elementi costitutivi. Inoltre, l'output del test individua la parte esatta del test in cui si verifica l'errore, in modo da non dover indovinare se i guasti si trovano nella configurazione o nell'asserzione.

Ottimizzare la tua metodologia aiuta anche. Sono un grande sostenitore dell'applicazione di principi di sviluppo snello e della loro combinazione con molte delle altre tecniche e principi su cui il movimento Agile si batte da molti anni ormai. Avere eliminato la maggior parte delle pratiche dispendiose che trovavo così frustranti ha aiutato moltissimo a rendere lo sviluppo un'attività più piacevole. Mi rimane ancora il problema che a volte - ma si spera non troppo spesso - nel mio codice compaiano bug, tuttavia ora mi ritrovo con più tempo e ancora più incentivo a dedicare più tempo a scrivere test più robusti e puntare a 100 % di copertura del test. Ancora meglio, è davvero bello vedere tutte quelle luci verdi apparire alla fine della mia giornata,


Sono curioso, scrivi che test è importante ma anche paralizzante.
Nathan Farrington,

@NathanFarrington Grazie per averlo sottolineato. Il mio punto era parlare positivamente dei test, ma ci pensavo mentre scrivevo qualcos'altro, quindi è uscito totalmente sbagliato in quel paragrafo! Ho corretto per soddisfare il punto effettivo che stavo cercando di illuminare!
S.Robins,

3

Una delle mie principali frustrazioni con il software è che non viene mai "fatto". C'è sempre un'altra funzione da aggiungere.

Se questo ti frustra, considera una carriera diversa. Sul serio.

Il punto del software è poter aggiungere funzionalità. L'intero motivo dell'invenzione del "software" è stato innanzitutto quello di poter aggiungere funzionalità.

Spesso quando si aggiunge una funzione introduce un bug da qualche altra parte che funzionava bene prima.

Questo è un problema di qualità.

Ciò non accade nell'hardware purché le interfacce non vengano violate.

Questo è vero anche nel software.

Esiste una buona metodologia di sviluppo del software che consente di fare sempre progressi e consente di aggiungere nuove funzionalità senza la necessità di riscrivere il codice esistente e introdurre nuovi bug?

Sì. Devi effettivamente praticare l'assicurazione della qualità.


1
A proposito, non sto cercando di trollare, e sì forse non sono tagliato per il software. Ma tu dici che "il punto del software è poter aggiungere funzionalità". É davvero? von Neumann ha inventato un software per essere in grado di costruire un computer in grado di calcolare più di una funzione matematica senza ricablare le sue unità logiche e aritmetiche. Sono curioso di sapere da dove provenga questa filosofia delle funzionalità software. L'hardware ha funzionalità, ma lo scopo dell'hardware non è quello di aggiungere funzionalità.
Nathan Farrington,

Presumo per qualità che intendi test. Sì, la mia intuizione afferma che sono necessari test approfonditi per produrre software di qualità. Ma penso che vada oltre. Nell'hardware, un modulo potrebbe contenere un bug. Ma quando aggiungi nuovo hardware, non introduce nuovi bug in un modulo hardware esistente. Alla fine tutti i bug in tutti i moduli possono essere trovati e corretti. Ma nel software, spesso il codice viene modificato (i moduli vengono modificati) anziché aggiunto, il che può introdurre bug. Immagino che stavo cercando una metodologia di sviluppo software puramente additiva.
Nathan Farrington,

Ora ho un commento più intelligente sulla tua risposta. Il motivo per cui mi sono lamentato del fatto che il software non sia mai stato "fatto" è probabilmente perché ho sempre usato un approccio molto lento alle versioni. Una nuova funzionalità equivale alla prossima versione, senza test di regressione e QA molto piccolo. Se le pubblicazioni fossero un GRANDE AFFARE, scommetto che le mie lamentele sul software che non sarebbe mai stato fatto sarebbero andate via.
Nathan Farrington,

@NathanFarrington: Turing ha inventato un software per violare i codici Enigma in continua evoluzione. "per garanzia di qualità intendi test". Falso. Intendo la garanzia di qualità: ogni aspetto dello sviluppo dovrebbe avere standard di qualità che dovrebbero essere soddisfatti. Il test è un modo (limitato) per valutare la qualità di un tipo di artefatto. "il codice è cambiato ... che può introdurre bug". Corretta. Questo è un fallimento dell'assicurazione della qualità, non una caratteristica intrinseca del software.
S. Lott,

Stiamo decisamente andando fuori tema. Secondo questo link , il Colosso di Turing non era universale (in senso informatico) e non utilizzava programmi memorizzati (software).
Nathan Farrington,

2

È possibile scrivere software in un modo simile in cui l'hardware è "scritto"? Esiste una buona metodologia di sviluppo del software che consente di fare sempre progressi e consente di aggiungere nuove funzionalità senza la necessità di riscrivere il codice esistente e introdurre nuovi bug?

Vi consiglio di esaminare i " metodi formali " per verificare la correttezza di progetti e software. Gli strumenti di simulazione che usi per la progettazione hardware stanno cercando di fare qualcosa di simile. Non credo che gli strumenti per i metodi formali siano in qualche modo vicini all'essere utili nell'industria in questo momento, e le uniche industrie che hanno forti incentivi per essere prive di difetti sono avionica e medicina (abbastanza interessante, la FDA afferma chiaramente che "il software è diverso dall'hardware "su quel link). Inoltre, se stai sviluppando con Verilog / VHDL, ti stai attaccando con la logica binaria. Ciò riduce drasticamente la complessità. Non ci sarà un hardware equivalente a un problema Y2K.

Il grosso problema è che le cose sono complesse. E non puoi eliminare la complessità, puoi solo spostarla.


1

è possibile scrivere hardware "fatto" e che non ha mai bisogno di essere modificato: si definiscono le interfacce e le funzionalità, si scrive un banco di prova, si implementa il modulo hardware, quindi si prova a testarlo usando un simulatore. Quindi puoi fare affidamento su quel modulo hardware come blocco predefinito per creare qualcosa di più grande e migliore: se devi aggiungere una funzionalità a quel modulo, crei un secondo modulo e aggiungi lì la funzionalità. Non butti mai via il modulo originale poiché funziona perfettamente e può ancora essere utile.

Nel mondo del software, chiamiamo quel "modulo" una libreria e lo usiamo allo stesso modo. Molte librerie sono costruite al punto da funzionare bene, quindi siedono con soddisfazione facendo i loro lavori senza alcuna modifica fino a quando Something Important porta alla prossima revisione. Pensa a loro come a un software impregnato di resina epossidica :-)

Una delle mie principali frustrazioni con il software è che non viene mai "fatto". C'è sempre un'altra funzione da aggiungere. Spesso quando si aggiunge una funzione introduce un bug da qualche altra parte che funzionava bene prima. Ciò non accade nell'hardware purché le interfacce non vengano violate.

Fesserie. Forse sei personalmente migliore di molte altre persone "hardware" non saldanti, ma ho visto un numero qualsiasi di cattivi progetti di circuiti, chip non funzionanti ( ad esempio , il famoso problema Intel "f00f"), ma questo non lo fa parlare al campo nel suo insieme. E man mano che gli articoli finti diventano "più morbidi", i problemi diventano più difficili da prevenire.

È possibile scrivere software in un modo simile in cui l'hardware è "scritto"? Esiste una buona metodologia di sviluppo del software che consente di fare sempre progressi e consente di aggiungere nuove funzionalità senza la necessità di riscrivere il codice esistente e introdurre nuovi bug?

Sì. Non usiamo molto queste metodologie. Tendono ad essere estremamente costosi da gestire e alla maggior parte dei programmatori non piace lavorare entro le loro restrizioni. Ma quando è coinvolta la vita umana, per esempio, beh, sì, cerchiamo di non uccidere gli utenti.

Un ultimo punto: il software ha un modello finanziario diverso dall'hardware, persino dall'hardware programmato. La maggior parte dei software non consumer e anche alcuni software consumer sono venduti in un modo che incoraggia il cambiamento. Quando puoi dire a un'azienda "Pagaci $ 10.000 ora più il 18% all'anno", puoi essenzialmente rivendere il prodotto ogni pochi anni. Ma per giustificare tale commissione, è necessario dare al cliente le modifiche che desidera. Hmm ... il pensiero della curva di hardware obsolescenza di Apple, forse questo non è una differenza, dopo tutto - l'hardware fa solo che tu veramente ri-acquistarlo!


Non ho mai detto di essere migliore di chiunque altro. ;-) Quando l'hardware ha un bug, diventa una novità. Quando il software ha un bug, ummm, wait ha sempre dei bug. Quali metodologie sono quelle che non usiamo perché sono troppo costose e non divertenti?
Nathan Farrington,

0

come posso divertirmi di più a scrivere software non introducendo bug nel codice di lavoro e facendo sempre progressi?

Mi piacerebbe trovare una risposta definitiva alla tua domanda. Ma la realtà è che non esiste un modo semplice per farlo, ecco perché la programmazione estrema e le tecniche TDD stanno diventando così popolari. Devi abbracciare il cambiamento, perché accadrà. Non so se è più divertente in questo modo, ma sicuramente molto meno stressante ;-)

http://en.wikipedia.org/wiki/Extreme_Programming

Quando interagisci con l'hardware, l'hardware ha bisogno di valore x e questo è tutto (in teoria), ma quando interagisci con le persone oggi hanno bisogno di x, e domani possono aver bisogno di y, ecc. È così, cambiano i requisiti di affari e persone . Perché persone! = Macchine, quindi il codice che non cambia MAI la maggior parte delle volte non è possibile.

Inoltre, come ho detto nella mia risposta precedente / cancellata, cerca di evitare cambiamenti che non sono importanti facendo riflettere le persone prima di iniziare a scrivere codice. Coinvolgere maggiormente gli utenti nel processo decisionale, ecc. Chiarire i costi delle modifiche, pianificare di più, ecc. Quelli non sono "modi di codificare", sono modi di "non codificare" perché, se si considerano i requisiti, ci saranno meno cambiamenti e più divertimento.


1
Buona risposta. Ho fatto la programmazione estrema. Sembra l'esatto contrario di quello che stavo cercando, in cui l'intera direzione del progetto può cambiare settimanalmente a seconda del capriccio del cliente. Non sono contrario alle versioni iterative, ma non voglio che la 2a versione introduca bug che non erano presenti nella 1a versione. E hai ragione sul fatto che il design iniziale può risparmiare sforzi a lungo termine.
Nathan Farrington,

Come dico sempre, il codice migliore non è un codice. :-)
H27studio

0

È possibile scrivere software in modo simile?

Sì. Fai solo attenzione se stai sviluppando hardware, testa tutto ciò che puoi e il tuo software sarà di qualità simile.

a proposito, non hai sentito parlare di bug HW? Molto più cattivo di qualsiasi bug SW e più difficile da correggere (non solo l'aggiornamento del software)


1
Sì, anche l'hardware ha dei bug, persino hardware ben collaudato come i processori. Un buon hardware è progettato in modo tale che i bug hardware possano essere corretti nel software! Il motivo della mia domanda originale è che ho scritto un sacco di software ma sono sempre stato sconcertato da quanto sia facile introdurre bug e quanto sia stato disordinato il sistema nel suo insieme. Sono un tipo di persona pulito, quindi la metodologia di sviluppo dell'hardware mi è sempre sembrata più naturale. Potrebbe anche avere qualcosa a che fare con l'ambito.
Nathan Farrington,

1
@NathanFarrington Il software è generalmente più complesso di un HW. HW è testato più accuratamente. SW può cambiare più facilmente, quindi le persone tendono a non prestare troppa attenzione.
BЈовић,

0

Vorrei anche sottolineare che i bug del software nell'hardware possono spesso uccidere le persone. Pertanto, viene prestata maggiore attenzione per determinare accuratamente i requisiti e testarli ampiamente in anticipo. E questi requisiti non devono cambiare fino a quando non lo fa l'hardware. E poiché il nuovo hardware potrebbe richiedere una riscrittura, sospetto che neanche la cruft si accumuli così tanto.

I requisiti aziendali, d'altra parte, cambiano costantemente, a volte è difficile ottenere un requisito in produzione prima che venga richiesto un cambiamento. A volte, ho dovuto cambiare il requisito più volte prima che arrivasse alla produzione. Questo è il risultato di diverse cose. In primo luogo, gli stakeholder del progetto sul lato aziendale sono spesso meno interessati a passare il tempo a definire accuratamente ciò che vuole perché è "occupato" e "importante" e le persone non moriranno e le famiglie lo faranno causa o lo faranno gettare in prigione se soffia la sua parte del processo. In secondo luogo, le parti interessate del progetto tendono ad avere effettivamente un'idea migliore di ciò che vogliono che faccia l'hardware in quanto è meno astratto per loro. Non sanno davvero cosa vogliono fino a quando non lo vedono. Che è meno di un problema con l'hardware.


Hai un punto valido. I tipi di cose che tradizionalmente realizziamo nell'hardware sono ben compresi: processori, controller USB, endpoint PCI Express, controller di memoria, ecc. Quindi inseriamo tutta la logica aziendale dell'applicazione nel software. Forse mentre ci arrampichiamo allo stack del software, le cose diventano più disordinate e meno comprese?
Nathan Farrington,

-1

Esistono strumenti di alto livello con molti "mattoni" finiti, come li chiami tu, che puoi combinare in applicazioni. I mattoni sono pezzi finiti da usare, devi solo combinarli insieme. Forse pensi che sia più facile ... fino a quando il tuo cliente non ti chiederà alcune modifiche strane e inaspettate.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.