Quando abbiamo formato i nostri team, abbiamo cercato principi che risuonassero con le nostre idee di semplicità, modularità e test continui delle idee mediante la prototipazione. Abbiamo scoperto che la semplicità è fondamentale perché la complessità genera caos e disastri, soprattutto quando le cose vanno male, come spesso accade.

Abbiamo trovato ispirazione in oriente, dove abbiamo letto di inventori che hanno realizzato prodotti con un'incredibile robustezza nonostante i vincoli della mancanza di risorse finanziarie. Innanzitutto, hanno fatto funzionare le basi. Successivamente, hanno trascinato le loro invenzioni attraverso terra e fango e le hanno lasciate cadere dall'alto.

Ora il team si imbatté in principi simili, la filosofia Unix, che venne dai laboratori Bell alla fine degli anni settanta.

Dal Bell system Technical Journal, luglio-agosto 1978, si possono leggere i principi guida e diverse massime hanno guadagnato popolarità tra i costruttori del sistema Unix per spiegare e promuovere il suo stile caratteristico.

1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

Poi, ovviamente, ci siamo imbattuti nel leggendario libro " The Art of Unix Programming" di Eric Steven Raymond .

Sebbene Eric abbia condensato la filosofia Unix come KISS Principle of

"Keep it Simple Stupido"

dal suo libro abbiamo estratto 17 regole ,

Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for “one true way”.
Rule of Extensibility: Design for the future because it will be here sooner than you think.

Generazione di codice con Matlab Simulink

Abbiamo anche applicato molti dei principi Unix alle linee guida dei nostri sviluppatori di funzioni, gli ingegneri che usano Matlab e Simulink per disegnare diagrammi di controllo che a loro volta generano codice C. Sentiamo spesso da programmatori che provengono da altri settori, e in particolare da quelli che amano il C++, che questo metodo è inferiore, ma avendoli usati entrambi, posso vedere chiaramente i vantaggi della generazione di codice Simulink . Per i sistemi di controllo di grandi dimensioni, che vengono utilizzati nei veicoli e che possono indurre i veicoli a mostrare comportamenti indesiderati, anche il software deve essere ben documentato e in tale compito questo metodo è difficile da battere.
Uno dei motivi è che il generatore di codice limita i possibili costrutti. Un altro è che consentiamo solo determinate librerie sicure. E infine, abbiamo centinaia di script di controllo dei modelli di progettazione in Simulink, oltre a controlli del codice generato. Una tipica pipeline di controllo Simulink Zuul :

- project:
   name: repo
   check:
    jobs:
     - buildavoidance-nodeless
     - common-gcc_check
     - common-pybuild_diff
     - common-signal_consistency
     - common-cppcheck
     - common-checkscript
     - common-unittests_shared
     - ProjectA-unittests
     - common-simdiff
     - common-mxray
     - common-mxam
     - common-mxam_safety
     - common-ci_of_ci
     - Polyspace code prover

Questo strumento utilizza tre metriche principali, McCabe Cyclomatic Complexity, Halstead Complexity e Incoherence. Il numero principale è il volume ponderato di Halstead che si adatta molto bene al design di Simulink. Abbiamo espresso un giudizio soggettivo su 500 modelli Simulink, classificandone la complessità da 1 a 10. Dopo aver scansionato gli stessi modelli con lo strumento, abbiamo ottenuto un risultato molto vicino al nostro giudizio.

Per alcune attività è meglio scrivere il codice utilizzando una tastiera, ma questa può essere facilmente integrata con i modelli Simulink. Nei nostri kit di sviluppo software, che abbiamo messo insieme, sottolineiamo che gli sviluppatori che generano il codice sono anche responsabili del codice. Questo è uno dei motivi per cui lasciamo che questi sviluppatori inviino il codice a Gerrit e scrivano anche test unitari che verificano il codice compilato e non premono play in una simulazione Simulink.

Quindi, gli aspetti della filosofia Unix che sottolineiamo per la progettazione di Simulink sono:

Rule of Modularity: ‘Write simple parts connected by clean interfaces’
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Transparency: Design for visibility to make inspection and debugging easier
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Least Surprise: Pay attention to your expected audience.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Crescere e coltivare alberi . Il primo passo è acquisire un albero, che può essere fatto acquistando un prebonsai (materiale grezzo da potare e cablare) o utilizzando una delle diverse tecniche di coltivazione possibili. Molto importante, tuttavia, è selezionare una specie di albero che si adatti alle tue circostanze.

Tecniche di formazione e stile. Cominciamo con la singola tecnica più importante per il Bonsai; potatura. La potatura è fondamentale per mantenere gli alberi miniaturizzati e per modellarli. L'obiettivo è quello di creare un Bonsai che assomigli il più possibile alla natura. Rimuovi i rami con colpi di scena innaturali. Rimuovi i rami sproporzionatamente spessi dalla cima dell'albero

Cura e manutenzione. Una parte cruciale delle informazioni su come coltivare un Bonsai è la sua manutenzione e cura.

Convertito in modelli Simulink...

Prendi un albero. Pensa al miglior flusso e utilizzo dei sottosistemi prima di implementarli!

Potatura. Man mano che la funzione cresce, usa i sottosistemi per mantenere una dimensione ragionevole. Creare un flusso con il minor numero possibile di diramazioni e linee di segnale. Posizionare i sottosistemi in modo che si alimentino a vicenda. Piccole decisioni potrebbero essere conservate in sottosistemi. Cerca di contenere la segnalazione per evitare gli spaghetti.

Cura e manutenzione. Se il sistema cresce, potrebbe essere necessario modificare l'ordine del sottosistema. Potrebbe anche essere vantaggioso strutturare diversi tipi di logica in diversi sottosistemi. Una buona pratica è lasciare che ogni sottosistema abbia un'unica responsabilità; dovrebbe fare una cosa. Questo a sua volta porta a una buona coesione.

Codice scritto da una tastiera

Quando si tratta di codice scritto da una tastiera, non disponiamo di buoni metodi per analizzare e controllare la complessità del codice nel nostro sistema CI Zuul. L'unica misura che abbiamo ora è la complessità ciclomatica, e questo ci dice più o meno quanto sarà difficile testare. Tuttavia, abbiamo qualcosa in cantiere, e questo viene dal mio collega e compagno Vard Antinyan , che ha studiato l'argomento in modo molto dettagliato.

Come afferma Eric Steven Raymond,

devi essere fedele e perseguire l'eccellenza.

Devi giungere alla conclusione che la progettazione del software è un mestiere che vale tutta l'intelligenza, la creatività e la passione che puoi raccogliere. Altrimenti, verrai ingannato nel percorso facile, nei modi stereotipati di approccio alla progettazione e all'implementazione; ti precipiterai nel codice quando dovresti pensare. Soprattutto se lavori in un ambiente Agile, potresti semplicemente correre nella tua ruota dello sprint e potresti complicare con noncuranza quando dovresti essere

semplificando inesorabilmente

e poi ti chiederai perché il tuo codice si gonfia e il debug è così difficile.

Se qualcuno ha già risolto un problema una volta, non lasciare che l'orgoglio o la politica ti spingano a risolverlo una seconda volta invece di riutilizzarlo.

Se qualcuno dei miei colleghi ha qualcosa di meglio, lo ruberò con orgoglio. E, naturalmente, vogliamo automatizzare tutto ciò che possiamo, a lungo termine farà risparmiare tempo.

La programmazione dovrebbe essere un'arte gioiosa, qualcosa che apprezziamo e di cui siamo appassionati. Se ci manca questo, allora forse dovremmo fare qualcos'altro?

Devi preoccuparti. Devi giocare. Devi essere disposto a esplorare.