filosofia di sviluppo del firmware nel wrapping delle funzioni

-1

Ho scritto un codice in passato per MCU a 8 bit, realizzando che ogni volta che ho acquisito esperienza, la prossima iterazione sarà con un'API wrapper o qualcosa di più lontano dall'accesso al registro "bare metal". Finisco anche un po 'in ambienti di lavoro, apprendendo la filosofia aziendale dietro un certo stile di codice.

Ma ho visto ambienti di lavoro con un codice ordinato, dovuto alla gestione del codice, alla leggibilità e simili e quindi a tutte le cose positive che ne derivano. Che ha senso dalla mia esperienza.

Poi ho visto il codice di altre aziende, che mostra già un aspetto non molto bello nel file principale, con accesso diretto al registro e funzioni non molto standard, almeno per i driver di basso livello e le INI.

Personalmente tendo ad avvolgere il più possibile, perché alla fine, una volta terminato, il codice è davvero semplice da leggere, conservare e renderlo portatile. E anche lo stack non è un problema, a causa della natura del driver di basso livello. Questo può anche essere facilmente integrato con il codice dell'applicazione, pur mantenendo leggibilità, manutenibilità e portabilità. All -ility. Ho anche appreso quanto sia importante, per i motivi -ilità, avere una libreria e il suo strato HAL.

La domanda è : perché qualcuno dovrebbe essere in ordine nella scrittura del codice se nel prodotto finale nessuno controllerà il tuo codice finché rispetterà i requisiti funzionali? Ci sono opinioni o ragioni a favore o contro l'essere in ordine? Sto parlando di ambienti di codice affidabili, ma senza un particolare processo da seguire (come nessun MISRA-C, DO-178B e né ISO-26262 e simili).

    
posta thexeno 22.11.2017 - 23:49
fonte

2 risposte

1

Il codice ben progettato / scadente è totalmente una questione di manutenzione per te e per la tua azienda e non di funzionalità per il cliente, sebbene il software possa deteriorarsi in una serie di bug non funzionanti (caso peggiore).

Ci sono due estremi. Uno non ha assolutamente alcun design e puro codice spaghetti e l'altro è completamente progettato e non si finisce mai il software perché non è ancora perfetto. Ho visto entrambi e la verità sta nel mezzo. Fai trading dell'uno o dell'altro per progredire al ritmo più veloce che puoi.

Quando la manutenzione inizia a salire, riordinare ma iniziare con la soluzione più semplice che si può ottenere per farlo funzionare all'inizio.

Martin Fowler ha scritto un ottimo articolo su questo argomento. Devi calibrare il punto di equilibrio per te stesso in cui il design ripaga, ma di solito è prima di quanto pensi. Ho lavorato con un sacco di codice sorgente no-design e ho avvolto questa esperienza in una piccola storia .

    
risposta data 28.11.2017 - 10:36
fonte
3

Il tasso di difetti più basso e il time-to-market più veloce sono solitamente più importanti di un utilizzo perfetto dell'hardware.

Tidy, il codice di facile lettura è in genere più facile da scrivere e aggiornare e richiede meno operazioni di debug. Potrebbe essere leggermente meno efficiente (più indiretta), ma l'hardware è economico e il tempo dei programmatori non lo è.

Un'eccezione importante è rappresentata dal codice critico delle prestazioni, in cui potrebbe essere necessario prendere le misure necessarie per spremere l'ultimo bit di prestazioni dall'hardware disponibile. Qui si dovrebbe ricordare che non è possibile alcuna ottimizzazione prima della profilazione, e il percorso critico di solito è una piccola parte dell'intero codebase.

Quindi, un codebase più ordinato è migliore fintanto che non tassano il percorso critico. Ma questa non è una funzione di ordine, è una funzione di un progetto corretto.

    
risposta data 23.11.2017 - 03:13
fonte

Leggi altre domande sui tag