Ekiplerimizi oluşturduğumuzda, basitlik, modülerlik ve fikirlerin prototipleme yoluyla sürekli test edilmesi konusundaki fikirlerimizle uyuşan ilkeler aradık. Basitliğin çok önemli olduğunu gördük çünkü karmaşıklık, özellikle de çoğu zaman olduğu gibi işler ters gittiğinde, kaosa ve felakete yol açar.

Mali kaynaklardan yoksun olmanın getirdiği kısıtlamalar altında inanılmaz sağlamlıkta ürünler yapan mucitleri okuduğumuz doğuda ilham bulduk. İlk olarak, temelleri çalıştırdılar. Sonra, icatlarını kir ve çamurda sürüklediler ve yüksekten düşürdüler.

Şimdi ekip, yetmişlerin sonlarında Bell laboratuvarlarından gelen benzer ilkelere, Unix felsefesine rastladı.

Bell System Technical Journal, Temmuz-Ağustos 1978'den Kılavuz İlkeler hakkında bilgi edinilebilir ve Unix sisteminin kurucuları arasında karakteristik stilini açıklamak ve tanıtmak için birkaç özdeyiş geçerlilik kazanmıştır.

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.

Sonra tabii ki Eric Steven Raymond'un efsanevi kitabı 'The Art of Unix Programming'e rastladık .

Eric, Unix felsefesini KISS İlkesi olarak özetlemesine rağmen

“Basit Tut Aptal”

kitabından 17 kural çıkardık ,

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 ile Kod Üretimi

Ayrıca Unix ilkelerinin birçoğunu fonksiyon geliştiricilerimizin, yani C kodu üreten kontrol diyagramları çizmek için Matlab ve Simulink kullanan mühendislerin yönergelerine uyguladık. Diğer sektörlerden gelen programcılardan ve özellikle C++'ı sevenlerden bu yöntemin yetersiz olduğunu sık sık duyuyoruz, ancak her ikisini de kullanmış biri olarak, Simulink kod üretiminin faydalarını açıkça görebiliyorum . Araçlarda kullanılan ve araçları istenmeyen davranışlar sergilemeye sevk edebilen büyük kontrol sistemleri için yazılımların da iyi belgelenmesi gerekir ve böyle bir görevde bu yöntemi yenmek zordur.
Bunun bir nedeni, kod oluşturucunun olası yapıları sınırlamasıdır. Bir diğeri, yalnızca belirli güvenli kitaplıklara izin vermemizdir. Ve son olarak, Simulink'teki tasarım kalıplarının yüzlerce kontrol komut dosyasına ve üretilen kodun kontrollerine sahibiz. Tipik bir Simulink Zuul kontrol ardışık düzeni:

- 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

Bu araç, McCabe Döngüsel Karmaşıklık, Halstead Karmaşıklık ve Tutarsızlık olmak üzere üç ana ölçü kullanır. Birincil sayı, Simulink'in tasarımına çok iyi uyan ağırlıklı Halstead hacmidir. Karmaşıklıklarını 1-10 arasında derecelendirdiğimiz 500 Simulink modeli hakkında öznel bir yargıya vardık. Aynı modelleri araçla taradıktan sonra kendi yargımıza çok yakın bir sonuç elde ettik.

Bazı görevler için klavye kullanarak kod yazmak daha iyidir, ancak bu, Simulink modelleriyle kolayca entegre edilebilir. Bir araya getirdiğimiz Yazılım Geliştirme kitlerimizde, kod üreten geliştiricilerin de koddan sorumlu olduğunu vurguluyoruz. Bu geliştiricilerin Simulink simülasyonunda oynat düğmesine basmadan kodu Gerrit'e göndermelerine ve ayrıca derlenmiş kodu doğrulayan birim testleri yazmalarına izin vermemizin nedenlerinden biri de budur.

Unix felsefesinden Simulink tasarımı için vurguladığımız yönler şunlardır:

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.

Ağaçları büyütün ve yetiştirin . İlk adım, bir prebonsai (budanacak ve kablolanacak kaba malzeme) satın alarak veya birkaç olası yetiştirme tekniğinden birini kullanarak yapılabilecek bir ağaç elde etmektir. Bununla birlikte, çok önemli olan, koşullarınıza uyan bir ağaç türü seçmektir.

Tren ve stil teknikleri. Bonsai için en önemli tek teknikle başlayalım; budama. Budama, ağaçların minyatür kalmasında olduğu kadar şekillenmesinde de çok önemlidir. Amaç, doğaya olabildiğince benzeyen bir Bonsai yaratmaktır. Doğal olmayan bükülmeler ve dönüşler ile dalları çıkarın. Ağacın tepesinden orantısız kalın dalları çıkarın

Bakım ve bakım. Bir Bonsai ağacının nasıl yetiştirileceğine ilişkin bilgilerin çok önemli bir kısmı, bakımı ve bakımıdır.

Simulink modellerine dönüştürüldü…

Bir ağaç al. Uygulamadan önce alt sistemlerin en iyi akışını ve kullanımını düşünün!

Budama. İşlev büyüdükçe, makul bir boyutu korumak için alt sistemleri kullanın. Mümkün olduğunca az dal ve sinyal hattı içeren bir akış oluşturun. Alt sistemleri birbirlerini besleyecek şekilde yerleştirin. Küçük kararlar alt sistemlerde tutulabilir. Spagetti'den kaçınmak için sinyal vermeyi deneyin.

Bakım ve bakım. Sistem büyürse, alt sistem sırasının değiştirilmesi gerekebilir. Farklı alt sistemlerde farklı türde mantık yapılandırmak da faydalı olabilir. İyi bir uygulama, her bir alt sistemin tek bir sorumluluğa sahip olmasına izin vermektir; tek bir şey yapmalı. Bu da iyi bir uyum sağlar.

Klavye ile yazılan kod

Bir klavye tarafından yazılan kod söz konusu olduğunda, CI sistemimiz Zuul'da kod karmaşıklığını analiz etmek ve geçitlemek için iyi bir yöntemimiz yok. Şu anda sahip olduğumuz tek ölçüm Döngüsel karmaşıklıktır ve bu aşağı yukarı bize test etmenin ne kadar zor olacağını söyler. Bununla birlikte, boru hattında bir şeyimiz var ve bu , konuyu ayrıntılı olarak araştırmış olan meslektaşım ve yoldaşım Vard Antinyan'dan .

Eric Steven Raymond'un belirttiği gibi,

sadık olmalı ve mükemmelliğin peşinde koşmalısınız.

Yazılım tasarımının toplayabileceğiniz tüm zekaya, yaratıcılığa ve tutkuya değecek bir zanaat olduğu sonucuna varmalısınız. Aksi takdirde, kolay yola, tasarım ve uygulamaya yaklaşmanın basmakalıp yollarına kandırılacaksınız; düşünmeniz gereken zamanda kodlamaya koşacaksınız. Özellikle Çevik bir ortamda çalışıyorsanız, sprint çarkınızda koşabilir ve ne zaman olmanız gerektiğini dikkatsizce karmaşıklaştırabilirsiniz.

acımasızca basitleştirme

ve sonra kodunuzun şişmesinin ve hata ayıklamanın neden bu kadar zor olduğunu merak edeceksiniz.

Birisi bir sorunu zaten bir kez çözmüşse, yeniden kullanmak yerine gururun veya siyasetin sizi ikinci kez çözmeye sürüklemesine izin vermeyin.

Meslektaşlarımdan herhangi birinin daha iyi bir şeyi varsa, onu gururla çalarım. Ve tabii ki yapabileceğimiz her şeyi otomatikleştirmek istiyoruz, bu uzun vadede zaman kazandıracak.

Programlama, takdir ettiğimiz ve tutkulu olduğumuz keyifli bir sanat olmalıdır. Bundan yoksunsak, belki başka bir şey yapmalıyız?

İlgilenmen gerek. Oynamalısın. Keşfetmeye istekli olmalısınız.