เมื่อเราก่อตั้งทีม เรามองหาหลักการที่สอดคล้องกับแนวคิดเรื่องความเรียบง่าย ความเป็นโมดูลาร์ และการทดสอบแนวคิดอย่างต่อเนื่องโดยการสร้างต้นแบบ เราพบว่าความเรียบง่ายมีความสำคัญเนื่องจากความซับซ้อนก่อให้เกิดความโกลาหลและหายนะ โดยเฉพาะอย่างยิ่งเมื่อเกิดข้อผิดพลาด ซึ่งมักเกิดขึ้นบ่อยครั้ง

เราพบแรงบันดาลใจทางตะวันออก ที่ซึ่งเราอ่านเกี่ยวกับนักประดิษฐ์ที่สร้างผลิตภัณฑ์ที่มีความแข็งแกร่งอย่างเหลือเชื่อในขณะที่อยู่ภายใต้ข้อจำกัดของการขาดแคลนทรัพยากรทางการเงิน อันดับแรก พวกเขามีพื้นฐานการทำงาน ต่อจากนั้น พวกเขาลากสิ่งประดิษฐ์ของพวกเขาผ่านดินและโคลนและทิ้งลงจากที่สูง

ตอนนี้ทีมสะดุดกับหลักการที่คล้ายกัน นั่นคือปรัชญา Unix ซึ่งมาจากห้องทดลองของ Bell ในช่วงปลายยุคเจ็ดสิบ

จาก Bell system Technical Journal, กรกฎาคม-สิงหาคม 1978, เราสามารถอ่านเกี่ยวกับหลักการชี้แนะได้,และคติพจน์หลายข้อได้รับการแลกเปลี่ยนในหมู่ผู้สร้างระบบ 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.

แน่นอนว่าเราไปสะดุดกับหนังสือในตำนาน ' The Art of Unix Programming' โดย Eric Steven Raymond

แม้ว่า Eric จะย่อปรัชญา Unix เป็นKISS Principle of

“ทำให้มันง่ายโง่”

จากหนังสือของเขาเราได้แยกกฎ 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

เรายังใช้หลักการ Unix หลายข้อกับแนวทางของนักพัฒนาฟังก์ชันของเรา วิศวกรที่ใช้ Matlab และ Simulink เพื่อวาดไดอะแกรมควบคุม ซึ่งจะสร้างโค้ด C ตามมา เรามักจะได้ยินจากโปรแกรมเมอร์ที่มาจากอุตสาหกรรมอื่น และโดยเฉพาะผู้ที่ชื่นชอบ C++ ว่าวิธีนี้ด้อยกว่า แต่เมื่อใช้ทั้งสองอย่างแล้ว ฉันเห็นประโยชน์ของการสร้างโค้ด Simulink ได้อย่าง ชัดเจน สำหรับระบบควบคุมขนาดใหญ่ที่ใช้ในยานพาหนะและสามารถกระตุ้นให้ยานพาหนะแสดงพฤติกรรมที่ไม่พึงประสงค์ได้ ซอฟต์แวร์ยังต้องมีการจัดทำเอกสารอย่างดี และในงานดังกล่าววิธีการนี้ยากที่จะเอาชนะ
เหตุผลหนึ่งคือตัวสร้างโค้ดจำกัดการสร้างที่เป็นไปได้ อีกประการหนึ่งคือเราอนุญาตเฉพาะห้องสมุดที่ปลอดภัยบางแห่งเท่านั้น และสุดท้าย เรามีสคริปต์ตรวจสอบรูปแบบการออกแบบหลายร้อยรายการใน 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 ตัวเลขหลักคือปริมาตร Halstead แบบถ่วงน้ำหนักซึ่งเข้ากันได้ดีกับการออกแบบ Simulink เราทำการตัดสินเชิงอัตวิสัยของโมเดล Simulink 500 โมเดล โดยเราให้คะแนนความซับซ้อนตั้งแต่ 1–10 หลังจากที่เราสแกนโมเดลเดียวกันด้วยเครื่องมือแล้ว เราก็ได้ผลลัพธ์ที่ใกล้เคียงกับการตัดสินใจของเราเองมาก

สำหรับงานบางอย่าง การเขียนโค้ดโดยใช้แป้นพิมพ์จะดีกว่า แต่สิ่งนี้อาจรวมเข้ากับโมเดล Simulink ได้อย่างง่ายดาย ในชุดเครื่องมือการพัฒนาซอฟต์แวร์ที่เรารวบรวมไว้ เราเน้นย้ำว่านักพัฒนาซอฟต์แวร์ที่สร้างโค้ดจะต้องรับผิดชอบต่อโค้ดนั้นด้วย นั่นเป็นเหตุผลหนึ่งที่เราปล่อยให้นักพัฒนาเหล่านี้ส่งโค้ดไปยัง Gerrit และเขียนการทดสอบหน่วยที่ตรวจสอบโค้ดที่คอมไพล์แล้ว และไม่กดเล่นในการจำลอง Simulink

ดังนั้น แง่มุมจากปรัชญา Unix ที่เราเน้นสำหรับการออกแบบ Simulink คือ:

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 กล่าวไว้ว่า

คุณต้องภักดีและแสวงหาความเป็นเลิศ

คุณต้องสรุปว่าการออกแบบซอฟต์แวร์เป็นงานฝีมือที่คุ้มค่ากับความฉลาด ความคิดสร้างสรรค์ และความหลงใหลทั้งหมดที่คุณสามารถรวบรวมได้ มิฉะนั้น คุณจะถูกหลอกให้เข้าสู่เส้นทางที่ง่าย วิธีตายตัวในการเข้าถึงการออกแบบและการใช้งาน คุณจะรีบเขียนโค้ดในเวลาที่คุณควรจะคิด โดยเฉพาะอย่างยิ่งถ้าคุณทำงานในการตั้งค่าแบบ Agile คุณอาจแค่วิ่งในวงล้อวิ่ง และคุณอาจทำเรื่องยุ่งยากโดยไม่ได้ตั้งใจในเวลาที่ควรจะเป็น

ลดความซับซ้อนอย่างไม่หยุดยั้ง

แล้วคุณจะสงสัยว่าทำไมโค้ดของคุณขยายใหญ่ขึ้นและการดีบั๊กจึงยากนัก

หากมีคนแก้ปัญหาไปแล้วครั้งหนึ่ง อย่าปล่อยให้ความหยิ่งยโสหรือการเมืองดึงคุณให้แก้ปัญหาเป็นครั้งที่สองแทนที่จะใช้ซ้ำ

ถ้าเพื่อนร่วมงานของฉันมีสิ่งที่ดีกว่า ฉันจะขโมยมันด้วยความภาคภูมิใจ และแน่นอนว่าเราต้องการทำให้ทุกสิ่งที่เราทำได้เป็นไปโดยอัตโนมัติ ซึ่งจะช่วยประหยัดเวลาในระยะยาว

การเขียนโปรแกรมควรเป็นศิลปะที่สนุกสนาน เป็นสิ่งที่เราชื่นชมและหลงใหล ถ้าเราขาดสิ่งนี้ไป เราน่าจะทำอย่างอื่น?

คุณต้องดูแล คุณต้องเล่น คุณต้องเต็มใจที่จะสำรวจ