Saat kami membentuk tim, kami mencari prinsip yang sesuai dengan ide kami tentang kesederhanaan, modularitas, dan pengujian ide secara terus-menerus dengan pembuatan prototipe. Kami menemukan bahwa kesederhanaan sangat penting karena kompleksitas menimbulkan kekacauan dan bencana, terutama ketika terjadi kesalahan, seperti yang sering terjadi.

Kami menemukan inspirasi di timur, di mana kami membaca tentang penemu yang membuat produk dengan ketangguhan luar biasa sementara di bawah kendala kekurangan sumber daya keuangan. Pertama, mereka membuat dasar-dasarnya berfungsi. Selanjutnya, mereka menyeret penemuan mereka melalui tanah dan lumpur dan menjatuhkannya dari ketinggian.

Sekarang tim menemukan prinsip yang sama, filosofi Unix, yang berasal dari laboratorium Bell di akhir tahun tujuh puluhan.

Dari Jurnal Teknis sistem Bell, Juli-Agustus 1978, orang dapat membaca tentang Prinsip-Prinsip Panduan, dan beberapa pepatah telah mendapatkan pengakuan di antara para pembuat sistem Unix untuk menjelaskan dan mempromosikan gaya karakteristiknya.

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.

Kemudian tentu saja kami menemukan buku legendaris ' The Art of Unix Programming' oleh Eric Steven Raymond .

Meskipun Eric memadatkan filosofi Unix sebagai Prinsip KISS

“Tetap Sederhana Bodoh”

dari bukunya kami mengekstraksi 17 aturan ,

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.

Pembuatan Kode dengan Matlab Simulink

Kami juga menerapkan banyak prinsip Unix pada pedoman pengembang fungsi kami, para insinyur yang menggunakan Matlab dan Simulink untuk menggambar diagram kontrol yang pada gilirannya menghasilkan kode C. Kami sering mendengar dari programmer yang berasal dari industri lain, dan terutama mereka yang menyukai C++, bahwa metode ini lebih rendah, tetapi setelah menggunakan keduanya, saya dapat dengan jelas melihat manfaat pembuatan kode Simulink . Untuk sistem kontrol besar, yang digunakan dalam kendaraan dan yang dapat mendorong kendaraan untuk menunjukkan perilaku yang tidak diinginkan, perangkat lunak juga perlu didokumentasikan dengan baik, dan dalam tugas seperti itu metode ini sulit dikalahkan.
Salah satu alasannya adalah pembuat kode membatasi kemungkinan konstruksi. Lainnya adalah kami hanya mengizinkan pustaka aman tertentu. Dan terakhir, kami memiliki ratusan skrip pemeriksaan pola desain di Simulink, serta pemeriksaan kode yang dihasilkan. Pipa pemeriksaan Simulink Zuul yang khas:

- 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

Alat ini menggunakan tiga metrik utama, McCabe Cyclomatic Complexity, Halstead Complexity, dan Incoherence. Nomor utama adalah volume Halstead berbobot yang sangat cocok dengan desain Simulink. Kami membuat penilaian subjektif dari 500 model Simulink, di mana kami menilai kerumitannya dari 1–10. Setelah kami memindai model yang sama dengan alat tersebut, kami mendapatkan hasil yang sangat dekat dengan penilaian kami sendiri.

Untuk beberapa tugas, lebih baik menulis kode dengan menggunakan keyboard, tetapi ini dapat dengan mudah diintegrasikan dengan model Simulink. Dalam Kit Pengembangan Perangkat Lunak kami, yang telah kami kumpulkan, kami menekankan bahwa pengembang yang membuat kode juga bertanggung jawab atas kode tersebut. Itulah salah satu alasan kami mengizinkan pengembang ini mendorong kode ke Gerrit dan juga menulis pengujian unit yang memverifikasi kode yang dikompilasi, dan tidak menekan tombol putar dalam simulasi Simulink.

Jadi, aspek filosofi Unix yang kami tekankan untuk desain Simulink adalah:

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.

Menanam dan memelihara pohon . Langkah pertama adalah mendapatkan pohon, yang dapat dilakukan dengan membeli prebonsai (bahan kasar untuk dipangkas dan disambung) atau dengan menggunakan salah satu dari beberapa teknik penanaman yang memungkinkan. Namun, yang sangat penting adalah memilih spesies pohon yang sesuai dengan keadaan Anda.

Melatih dan gaya teknik. Mari kita mulai dengan satu teknik paling penting untuk Bonsai; pemangkasan. Pemangkasan sangat penting untuk menjaga miniatur pohon dan juga untuk membentuknya. Tujuannya adalah untuk membuat Bonsai sedekat mungkin dengan alam. Hapus cabang dengan tikungan dan belokan yang tidak wajar. Hapus cabang-cabang tebal yang tidak proporsional dari bagian atas pohon

Perawatan dan pemeliharaan. Bagian penting dari informasi tentang cara menanam pohon Bonsai adalah pemeliharaan dan perawatannya.

Dikonversi ke model Simulink…

Dapatkan pohon. Pikirkan aliran terbaik dan penggunaan subsistem sebelum Anda menerapkannya!

Pemangkasan. Saat fungsi tumbuh, gunakan subsistem untuk mempertahankan ukuran yang masuk akal. Buat aliran dengan sesedikit mungkin cabang dan garis sinyal. Tempatkan subsistem sehingga mereka saling memberi makan. Keputusan kecil dapat disimpan dalam subsistem. Cobalah untuk menahan pensinyalan untuk menghindari spageti.

Perawatan dan pemeliharaan. Jika sistem tumbuh, perubahan urutan subsistem mungkin diperlukan. Mungkin juga bermanfaat untuk menyusun jenis logika yang berbeda dalam subsistem yang berbeda. Praktik yang baik adalah membiarkan setiap subsistem memiliki satu tanggung jawab; itu harus melakukan satu hal. Ini pada gilirannya mengarah pada kohesi yang baik.

Kode yang ditulis oleh keyboard

Ketika berbicara tentang kode yang ditulis oleh keyboard, kami tidak memiliki metode yang baik untuk menganalisis dan menghitung kompleksitas kode di sistem CI Zuul kami. Satu-satunya pengukuran yang kita miliki sekarang adalah kompleksitas Cyclomatic, dan itu kurang lebih hanya memberi tahu kita betapa sulitnya untuk menguji. Meskipun demikian, kami memiliki sesuatu yang sedang dalam proses, dan itu dari kolega dan kawan saya Vard Antinyan , yang telah meneliti subjek ini dengan sangat rinci.

Seperti yang dikatakan Eric Steven Raymond,

Anda harus setia dan mengejar keunggulan.

Anda harus sampai pada kesimpulan bahwa desain perangkat lunak adalah keahlian yang layak untuk semua kecerdasan, kreativitas, dan hasrat yang dapat Anda kumpulkan. Jika tidak, Anda akan tertipu ke jalan yang mudah, cara pendekatan desain dan implementasi yang stereotip; Anda akan terburu-buru melakukan pengkodean saat Anda seharusnya berpikir. Terutama jika Anda bekerja dalam pengaturan Agile, Anda mungkin hanya berlari di roda sprint Anda, dan Anda mungkin membuat rumit secara sembarangan ketika seharusnya

menyederhanakan tanpa henti

dan kemudian Anda akan bertanya-tanya mengapa kode Anda membengkak dan debugging begitu sulit.

Jika seseorang pernah memecahkan masalah sekali, jangan biarkan kesombongan atau politik menyedot Anda untuk menyelesaikannya untuk kedua kalinya daripada menggunakannya kembali.

Jika ada rekan saya yang memiliki sesuatu yang lebih baik, saya akan mencurinya dengan bangga. Dan tentu saja, kami ingin mengotomatiskan semua yang kami bisa, ini akan menghemat waktu dalam jangka panjang.

Pemrograman harus menjadi seni yang menggembirakan, sesuatu yang kita hargai dan sukai. Jika kita kekurangan ini, mungkin kita harus melakukan sesuatu yang lain?

Anda perlu peduli. Anda harus bermain. Anda harus bersedia untuk mengeksplorasi.