Khi chúng tôi thành lập nhóm của mình, chúng tôi đã tìm kiếm các nguyên tắc phù hợp với ý tưởng của chúng tôi về tính đơn giản, tính mô đun và liên tục thử nghiệm các ý tưởng bằng cách tạo nguyên mẫu. Chúng tôi nhận thấy rằng sự đơn giản là rất quan trọng vì sự phức tạp sinh ra hỗn loạn và thảm họa, đặc biệt là khi mọi thứ diễn ra không như ý muốn, như chúng vẫn thường xảy ra.

Chúng tôi tìm thấy nguồn cảm hứng ở phương đông, nơi chúng tôi đọc về những nhà phát minh đã tạo ra những sản phẩm có độ bền đáng kinh ngạc trong khi bị hạn chế về nguồn tài chính. Đầu tiên, họ có những điều cơ bản làm việc. Tiếp theo, họ kéo các phát minh của mình qua bùn đất và thả chúng từ trên cao xuống.

Giờ đây, nhóm tình cờ phát hiện ra những nguyên tắc tương tự, triết lý Unix, xuất phát từ phòng thí nghiệm Bell vào cuối những năm 70.

Từ Tạp chí kỹ thuật hệ thống Bell, tháng 7-8 năm 1978, người ta có thể đọc về Nguyên tắc hướng dẫn và một số câu châm ngôn đã thu hút được sự quan tâm của những người xây dựng hệ thống Unix để giải thích và quảng bá phong cách đặc trưng của nó.

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.

Sau đó, tất nhiên chúng tôi tình cờ đọc được cuốn sách huyền thoại ' Nghệ thuật lập trình Unix' của Eric Steven Raymond .

Mặc dù Eric đã cô đọng triết lý Unix thành Nguyên tắc KISS của

"Giữ cho nó đơn giản ngu ngốc"

từ cuốn sách của anh ấy, chúng tôi đã rút ra 17 quy tắc ,

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.

Tạo mã với Matlab Simulink

Chúng tôi cũng đã áp dụng nhiều nguyên tắc Unix cho hướng dẫn của các nhà phát triển chức năng của chúng tôi, các kỹ sư sử dụng Matlab và Simulink để vẽ sơ đồ điều khiển, từ đó tạo ra mã C. Chúng ta thường nghe các lập trình viên đến từ các ngành khác, và đặc biệt là những người yêu thích C ++, rằng phương pháp này kém hơn, nhưng đã sử dụng cả hai, tôi có thể thấy rõ lợi ích của việc tạo mã Simulink . Đối với các hệ thống điều khiển lớn, được sử dụng trong các phương tiện và có thể khiến các phương tiện thể hiện hành vi không mong muốn, phần mềm cũng cần phải được ghi chép đầy đủ và trong một nhiệm vụ như vậy, phương pháp này rất khó đánh bại.
Một lý do là trình tạo mã giới hạn các cấu trúc có thể. Một điều nữa là chúng tôi chỉ cho phép một số thư viện an toàn nhất định. Và cuối cùng, chúng tôi có hàng trăm tập lệnh kiểm tra các mẫu thiết kế trong Simulink, cũng như kiểm tra mã được tạo. Một đường ống kiểm tra Simulink Zuul điển hình :

- 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

Công cụ này sử dụng ba chỉ số chính, Độ phức tạp chu kỳ McCabe, Độ phức tạp Halstead và Độ không mạch lạc. Số chính là khối lượng Halstead có trọng số rất phù hợp với thiết kế của Simulink. Chúng tôi đã đưa ra đánh giá chủ quan về 500 mô hình Simulink, trong đó chúng tôi đã phân loại độ phức tạp của chúng từ 1–10. Sau khi quét các mô hình tương tự bằng công cụ này, chúng tôi nhận được kết quả rất gần với nhận định của chính mình.

Đối với một số tác vụ, tốt hơn là viết mã bằng cách sử dụng bàn phím, nhưng điều này có thể dễ dàng được tích hợp với các mô hình Simulink. Trong bộ công cụ Phát triển phần mềm mà chúng tôi đã tập hợp lại, chúng tôi nhấn mạnh rằng các nhà phát triển tạo mã cũng chịu trách nhiệm về mã. Đó là một trong những lý do chúng tôi cho phép các nhà phát triển này chuyển mã sang Gerrit và cũng viết các bài kiểm tra đơn vị để xác minh mã đã biên dịch và không nhấn play trong mô phỏng Simulink.

Vì vậy, các khía cạnh từ triết lý Unix mà chúng tôi nhấn mạnh cho thiết kế Simulink là:

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.

Trồng và chăm sóc cây cối . Bước đầu tiên là mua cây, có thể thực hiện bằng cách mua cây cảnh (vật liệu thô để cắt tỉa và nối dây) hoặc bằng cách sử dụng một trong số các kỹ thuật trồng trọt khả thi. Tuy nhiên, rất quan trọng là chọn một loài cây phù hợp với hoàn cảnh của bạn.

Đào tạo và phong cách kỹ thuật. Hãy bắt đầu với kỹ thuật quan trọng nhất đối với Bonsai; cắt tỉa. Việc cắt tỉa là rất quan trọng trong việc giữ cho cây được thu nhỏ cũng như tạo hình cho chúng. Mục tiêu là tạo ra một Bonsai giống với thiên nhiên nhất có thể. Loại bỏ các nhánh xoắn và rẽ không tự nhiên. Loại bỏ các cành dày không cân xứng khỏi ngọn cây

Chăm sóc và bảo dưỡng. Một phần quan trọng của thông tin về cách trồng cây Bonsai là việc duy trì và chăm sóc nó.

Chuyển đổi sang mô hình Simulink…

Lấy một cái cây. Hãy suy nghĩ về luồng tốt nhất và cách sử dụng các hệ thống con trước khi bạn triển khai!

tỉa cành. Khi chức năng phát triển, hãy sử dụng các hệ thống con để giữ kích thước hợp lý. Tạo một luồng với càng ít nhánh và đường tín hiệu càng tốt. Đặt các hệ thống con để chúng nuôi dưỡng lẫn nhau. Các quyết định nhỏ có thể được giữ trong các hệ thống con. Cố gắng hạn chế tín hiệu để tránh mì spaghetti.

Chăm sóc và bảo dưỡng. Nếu hệ thống phát triển, có thể cần thay đổi thứ tự hệ thống con. Nó cũng có thể hữu ích để cấu trúc các loại logic khác nhau trong các hệ thống con khác nhau. Một thực hành tốt là để cho mỗi hệ thống con có một trách nhiệm duy nhất; nó nên làm một việc. Điều này lần lượt dẫn đến sự gắn kết tốt.

Mã được viết bằng bàn phím

Khi nói đến mã được viết bằng bàn phím, chúng tôi không có bất kỳ phương pháp tốt nào để phân tích và xác định độ phức tạp của mã trong Zuul hệ thống CI của chúng tôi. Phép đo duy nhất chúng tôi có bây giờ là độ phức tạp của Cyclomatic và điều đó ít nhiều chỉ cho chúng tôi biết mức độ khó của việc kiểm tra. Mặc dù, chúng tôi có một số thứ đang được chuẩn bị, và đó là từ đồng nghiệp và đồng chí của tôi, Vard Antinyan , người đã nghiên cứu rất chi tiết về chủ đề này.

Như Eric Steven Raymond nói,

bạn phải trung thành và theo đuổi sự xuất sắc.

Bạn phải đi đến kết luận rằng thiết kế phần mềm là một nghề thủ công xứng đáng với tất cả trí thông minh, sự sáng tạo và niềm đam mê mà bạn có thể tập hợp được. Nếu không, bạn sẽ bị lừa vào con đường dễ dàng, những cách tiếp cận thiết kế và triển khai rập khuôn; bạn sẽ lao vào viết mã khi bạn nên suy nghĩ. Đặc biệt nếu bạn làm việc trong môi trường Agile, bạn có thể chỉ chạy trong guồng quay nước rút của mình và bạn có thể bất cẩn làm phức tạp hóa vấn đề khi lẽ ra bạn nên làm.

không ngừng đơn giản hóa

và sau đó bạn sẽ thắc mắc tại sao mã của bạn phình to và việc gỡ lỗi lại khó đến vậy.

Nếu ai đó đã giải quyết vấn đề một lần, đừng để niềm tự hào hoặc chính trị lôi kéo bạn giải quyết vấn đề đó lần thứ hai thay vì sử dụng lại.

Nếu bất kỳ đồng nghiệp nào của tôi có thứ gì đó tốt hơn, tôi sẽ lấy trộm nó một cách tự hào. Và tất nhiên, chúng tôi muốn tự động hóa mọi thứ có thể, nó sẽ tiết kiệm thời gian về lâu dài.

Lập trình phải là một nghệ thuật thú vị, một thứ mà chúng ta đánh giá cao và đam mê. Nếu chúng ta thiếu cái này, thì có lẽ chúng ta nên làm cái gì khác?

Bạn cần quan tâm. Bạn cần phải chơi. Bạn cần sẵn sàng khám phá.