우리는 팀을 구성할 때 단순성, 모듈성, 프로토타이핑을 통한 아이디어의 지속적인 테스트라는 아이디어에 공감하는 원칙을 찾았습니다. 우리는 복잡성이 혼돈과 재앙을 낳기 때문에, 특히 일이 잘못될 때 단순성이 중요하다는 것을 알게 되었습니다.

우리는 동양에서 영감을 얻었는데, 그곳에서 우리는 재정 자원이 부족한 제약 조건 하에서 놀라운 견고성을 지닌 제품을 만든 발명가에 대해 읽었습니다. 첫째, 그들은 기본적인 작업을 수행했습니다. 다음으로, 그들은 그들의 발명품을 흙과 진흙을 통해 끌고 높은 곳에서 떨어뜨렸습니다.

이제 팀은 70년대 후반 Bell 연구소에서 나온 유사한 원칙인 Unix 철학을 우연히 발견했습니다.

1978년 7월-8월 Bell 시스템 기술 저널에서 Guiding Principles 에 대해 읽을 수 있으며 몇 가지 격언이 Unix 시스템의 특징적인 스타일을 설명하고 홍보하기 위해 Unix 시스템 구축자들 사이에서 통용되었습니다.

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.

그러다 우연히 Eric Steven Raymond의 전설적인 책 'The Art of Unix Programming'을 우연히 발견했습니다 .

Eric은 Unix 철학을 KISS의 원리 로 압축했지만

"간단하게 유지 바보"

그의 책에서 우리는 17가지 규칙을 추출 했습니다.

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.

Matlab Simulink로 코드 생성

우리는 또한 Matlab과 Simulink를 사용하여 C 코드를 생성하는 제어 다이어그램을 그리는 엔지니어인 함수 개발자의 지침에 많은 Unix 원칙을 적용했습니다. 우리는 종종 다른 업계에서 온 프로그래머들, 특히 C++를 사랑하는 사람들로부터 이 방법이 열등하다는 말을 듣 습니다 . 차량에 사용되며 차량이 원치 않는 동작을 나타내도록 유도할 수 있는 대형 제어 시스템의 경우 소프트웨어도 잘 문서화되어야 하며 이러한 작업에서 이 방법을 능가하기 어렵습니다.
한 가지 이유는 코드 생성기가 가능한 구조를 제한하기 때문입니다. 다른 하나는 특정 안전한 라이브러리만 허용한다는 것입니다. 마지막으로 Simulink에는 수백 개의 설계 패턴 검사 스크립트와 생성된 코드 검사가 있습니다. 일반적인 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

이 도구는 McCabe Cyclomatic Complexity, Halstead Complexity 및 Incoherence의 세 가지 기본 메트릭을 사용합니다. 기본 숫자는 Simulink 설계와 매우 잘 맞는 가중 Halstead 볼륨입니다. 우리는 500개의 Simulink 모델에 대해 주관적인 판단을 내렸고 복잡성을 1-10으로 등급을 매겼습니다. 동일한 모델을 도구로 스캔한 후 우리의 판단과 매우 유사한 결과를 얻었습니다.

일부 작업의 경우 키보드를 사용하여 코드를 작성하는 것이 더 좋지만 Simulink 모델과 쉽게 통합될 수 있습니다. 우리가 함께 만든 소프트웨어 개발 키트에서는 코드를 생성하는 개발자도 코드에 대한 책임이 있음을 강조합니다. 이것이 우리가 개발자들이 Simulink 시뮬레이션에서 재생을 누르지 않고 Gerrit에 코드를 푸시하고 컴파일된 코드를 확인하는 단위 테스트를 작성하도록 허용한 이유 중 하나입니다.

따라서 Simulink 설계에 대해 강조하는 Unix 철학의 측면은 다음과 같습니다.

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.

나무를 키우고 가꾸 십시오. 첫 번째 단계는 나무를 구하는 것인데, 이는 분재(가지치기 및 철사로 엮을 거친 재료)를 구입하거나 가능한 여러 재배 기술 중 하나를 사용하여 수행할 수 있습니다. 그러나 매우 중요한 것은 상황에 맞는 수종을 선택하는 것입니다.

훈련 및 스타일 기술. 분재에 가장 중요한 단일 기술부터 시작하겠습니다. 전정. 가지치기는 나무를 작게 유지하고 모양을 만드는 데 중요합니다. 목표는 가능한 한 자연에 가까운 분재를 만드는 것입니다. 부자연스러운 뒤틀림이 있는 가지를 제거하십시오. 나무 꼭대기에서 불균형하게 두꺼운 가지를 제거하십시오.

관리 및 유지 관리. 분재 나무를 키우는 방법에 대한 정보의 중요한 부분은 유지 및 관리입니다.

Simulink 모델로 변환…

나무를 얻으십시오. 구현하기 전에 하위 시스템의 최상의 흐름과 사용에 대해 생각하십시오!

전정. 기능이 커짐에 따라 서브시스템을 사용하여 합리적인 크기를 유지하십시오. 가능한 한 적은 수의 분기와 신호선으로 흐름을 만듭니다. 서로 공급되도록 하위 시스템을 배치합니다. 작은 결정은 하위 시스템에 보관할 수 있습니다. 스파게티를 피하려면 신호를 억제하십시오.

관리 및 유지 관리. 시스템이 커지면 하위 시스템 순서를 변경해야 할 수도 있습니다. 서로 다른 하위 시스템에서 서로 다른 종류의 논리를 구성하는 것도 도움이 될 수 있습니다. 좋은 방법은 각 하위 시스템에 단일 책임을 부여하는 것입니다. 그것은 한 가지 일을 해야 합니다. 이것은 차례로 좋은 응집력으로 이어집니다.

키보드로 작성된 코드

키보드로 작성된 코드의 경우 CI 시스템 Zuul에서 코드 복잡성을 분석하고 게이팅하는 좋은 방법이 없습니다. 현재 우리가 가지고 있는 유일한 측정은 순환 복잡성이며, 이는 테스트하기가 얼마나 어려운지를 어느 정도 알려줍니다. 그러나 우리는 파이프라인에 무언가를 가지고 있으며 그것은 내 동료이자 동지인 Vard Antinyan 이 그 주제를 매우 자세하게 조사한 것입니다.

Eric Steven Raymond가 말했듯이,

당신은 탁월함에 충성하고 추구해야 합니다.

당신은 소프트웨어 디자인이 당신이 소집할 수 있는 모든 지능, 창의성, 열정의 가치가 있는 기술이라는 결론에 도달해야 합니다. 그렇지 않으면 설계 및 구현에 접근하는 쉬운 길, 틀에 박힌 방식으로 속아 넘어갈 것입니다. 생각해야 할 때 코딩에 몰두하게 될 것입니다. 특히 애자일 환경에서 작업하는 경우 스프린트 휠에서 실행될 수 있으며 부주의하게 복잡해질 수 있습니다.

끊임없는 단순화

그런 다음 코드가 부풀어 오르고 디버깅이 어려운 이유가 궁금할 것입니다.

누군가가 문제를 이미 한 번 해결한 경우, 자존심이나 정치 때문에 문제를 재사용하지 않고 두 번째로 해결하도록 하지 마십시오.

동료 중 누구라도 더 좋은 것이 있으면 자랑스럽게 훔칠 것입니다. 물론 우리는 가능한 모든 것을 자동화하고 싶습니다. 그러면 장기적으로 시간이 절약될 것입니다.

프로그래밍은 즐거운 예술이어야 하며 우리가 감사하고 열정적이어야 합니다. 이것이 부족하다면 다른 일을 해야 하지 않을까요?

당신은 관심이 필요합니다. 당신은 재생해야합니다. 기꺼이 탐구해야 합니다.