Kiedy tworzyliśmy nasze zespoły, szukaliśmy zasad, które rezonowałyby z naszymi ideami prostoty, modułowości i ciągłego testowania pomysłów poprzez prototypowanie. Odkryliśmy, że prostota ma kluczowe znaczenie, ponieważ złożoność rodzi chaos i katastrofy, zwłaszcza gdy coś idzie nie tak, jak to często bywa.

Inspirację znaleźliśmy na Wschodzie, gdzie czytamy o wynalazcach, którzy stworzyli produkty o niewiarygodnej wytrzymałości, mając ograniczenia związane z brakiem środków finansowych. Najpierw zajęli się podstawami. Następnie przeciągali swoje wynalazki przez brud i błoto i zrzucali je z wysokości.

Teraz zespół natknął się na podobne zasady, filozofię Uniksa, która wywodzi się z laboratoriów Bella pod koniec lat siedemdziesiątych.

W czasopiśmie technicznym systemu Bell, lipiec-sierpień 1978, można przeczytać o zasadach przewodnich, a kilka maksym zyskało popularność wśród twórców systemu Unix, wyjaśniając i promując jego charakterystyczny styl.

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.

Potem oczywiście natknęliśmy się na legendarną książkę „ The Art of Unix Programming” autorstwa Erica Stevena Raymonda .

Chociaż Eric skondensował filozofię Uniksa jako Zasadę KISS

"Niech to będzie możliwie proste"

z jego książki wyciągnęliśmy 17 zasad ,

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.

Generowanie kodu w Matlab Simulink

Zastosowaliśmy również wiele zasad systemu Unix do wytycznych naszych programistów funkcji, inżynierów, którzy używają Matlaba i Simulinka do rysowania schematów sterowania, które z kolei generują kod C. Często słyszymy od programistów, którzy wywodzą się z innych branż, a zwłaszcza tych, którzy kochają C++, że ta metoda jest gorsza, ale po zastosowaniu obu, wyraźnie widzę korzyści płynące z generowania kodu Simulink . W przypadku dużych systemów sterowania, które są stosowane w pojazdach i które mogą skłaniać pojazdy do niepożądanych zachowań, oprogramowanie również musi być dobrze udokumentowane, aw takim zadaniu ta metoda jest trudna do pokonania.
Jednym z powodów jest to, że generator kodu ogranicza możliwe konstrukcje. Innym jest to, że zezwalamy tylko na niektóre bezpieczne biblioteki. I wreszcie, mamy setki skryptów kontrolnych wzorców projektowych w Simulinku, a także kontrole wygenerowanego kodu. Typowy potok kontrolny 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

To narzędzie wykorzystuje trzy podstawowe wskaźniki: złożoność cyklomatyczną McCabe'a, złożoność Halsteada i niespójność. Podstawowa liczba to ważona objętość Halsteada, która bardzo dobrze pasuje do projektu Simulinka. Dokonaliśmy subiektywnej oceny 500 modeli Simulink, w których oceniliśmy ich złożoność od 1 do 10. Po zeskanowaniu tych samych modeli za pomocą tego narzędzia uzyskaliśmy wynik bardzo zbliżony do naszego własnego osądu.

W przypadku niektórych zadań lepiej jest pisać kod za pomocą klawiatury, ale można to łatwo zintegrować z modelami Simulink. W naszych zestawach Software Development Kits, które stworzyliśmy, podkreślamy, że programiści, którzy generują kod, są również odpowiedzialni za kod. To jeden z powodów, dla których pozwalamy tym programistom przesyłać kod do Gerrita, a także pisać testy jednostkowe, które weryfikują skompilowany kod, a nie naciskać „play” w symulacji Simulinka.

Tak więc aspekty filozofii Uniksa, na które kładziemy nacisk podczas projektowania Simulinka, to:

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.

Uprawiaj i pielęgnuj drzewa . Pierwszym krokiem jest pozyskanie drzewka, co można zrobić kupując prebonsai (surowy materiał do przycięcia i zadrutowania) lub korzystając z jednej z kilku możliwych technik uprawy. Bardzo ważne jest jednak, aby wybrać gatunek drzewa, który pasuje do twoich warunków.

Trenuj i stylizuj techniki. Zacznijmy od najważniejszej techniki Bonsai; przycinanie. Przycinanie ma kluczowe znaczenie w utrzymaniu miniaturyzacji drzew, a także w ich kształtowaniu. Celem jest stworzenie Bonsai, które jak najbardziej przypomina naturę. Usuń gałęzie z nienaturalnymi skrętami. Usuń nieproporcjonalnie grube gałęzie ze szczytu drzewa

Opieka i utrzymanie. Kluczową częścią informacji o tym, jak uprawiać drzewko Bonsai, jest jego pielęgnacja i pielęgnacja.

Konwersja do modeli Simulink…

Zdobądź drzewo. Pomyśl o najlepszym przepływie i wykorzystaniu podsystemów przed wdrożeniem!

Przycinanie. Gdy funkcja rośnie, używaj podsystemów, aby zachować rozsądny rozmiar. Utwórz przepływ z jak najmniejszą liczbą odgałęzień i linii sygnałowych. Układaj podsystemy tak, aby wzajemnie się zasilały. Drobne decyzje można przechowywać w podsystemach. Staraj się zawierać sygnalizację, aby uniknąć spaghetti.

Opieka i utrzymanie. Jeśli system się rozrasta, może być konieczna zmiana kolejności podsystemów. Korzystne może być również ustrukturyzowanie różnego rodzaju logiki w różnych podsystemach. Dobrą praktyką jest przypisanie każdemu podsystemowi jednej odpowiedzialności; powinien zrobić jedną rzecz. To z kolei prowadzi do dobrej spójności.

Kod napisany przez klawiaturę

Jeśli chodzi o kod pisany za pomocą klawiatury, nie mamy dobrych metod analizy i bramkowania złożoności kodu w naszym systemie CI Zuul. Jedyny pomiar, jaki mamy teraz, to złożoność cyklomatyczna, a to mniej więcej mówi nam, jak trudno będzie to przetestować. Chociaż mamy coś w przygotowaniu, i to od mojego kolegi i towarzysza Varda Antinyana , który bardzo szczegółowo zbadał ten temat.

Jak stwierdza Eric Steven Raymond,

musisz być lojalny i dążyć do doskonałości.

Musisz dojść do wniosku, że projektowanie oprogramowania to rzemiosło warte całej inteligencji, kreatywności i pasji, na jakie cię stać. W przeciwnym razie zostaniesz zwiedziony łatwą ścieżką, stereotypowymi sposobami podejścia do projektowania i wdrażania; rzucisz się do kodowania, kiedy powinieneś myśleć. Zwłaszcza jeśli pracujesz w środowisku zwinnym, możesz po prostu biegać w kole sprinterskim i możesz beztrosko komplikować, kiedy powinieneś

bezlitośnie upraszczając

a potem będziesz się zastanawiać, dlaczego twój kod się rozrasta, a debugowanie jest takie trudne.

Jeśli ktoś już raz rozwiązał problem, nie pozwól, aby duma lub polityka wciągnęły cię w rozwiązanie go po raz drugi zamiast ponownego użycia.

Jeśli któryś z moich kolegów ma coś lepszego, ukradnę to z dumą. I oczywiście chcemy zautomatyzować wszystko, co możemy, na dłuższą metę zaoszczędzi to czas.

Programowanie powinno być radosną sztuką, czymś, co cenimy i czym się pasjonujemy. Jeśli tego nam brakuje, to może powinniśmy zrobić coś innego?

Musisz dbać. Musisz grać. Musisz być chętny do eksploracji.