Quando formamos nossas equipes, procuramos princípios que ressoassem com nossas ideias de simplicidade, modularidade e teste contínuo de ideias por meio de prototipagem. Descobrimos que a simplicidade é crucial porque a complexidade gera caos e desastre, especialmente quando as coisas dão errado, como costumam acontecer.

Encontramos inspiração no oriente, onde lemos sobre inventores que fizeram produtos com uma robustez incrível sob as restrições da falta de recursos financeiros. Primeiro, eles fizeram o básico funcionar. Em seguida, eles arrastaram suas invenções pela terra e lama e as jogaram das alturas.

Agora a equipe tropeçou em princípios semelhantes, a filosofia Unix, que veio dos laboratórios Bell no final dos anos setenta.

No Bell system Technical Journal, julho-agosto de 1978, pode-se ler sobre os Princípios Orientadores, e várias máximas ganharam aceitação entre os construtores do sistema Unix para explicar e promover seu estilo característico.

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.

Então, é claro, nos deparamos com o lendário livro ' The Art of Unix Programming' de Eric Steven Raymond .

Embora Eric tenha condensado a filosofia Unix como Princípio KISS de

"Mantenha isso simples, idiota"

de seu livro extraímos 17 regras ,

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.

Geração de código com Matlab Simulink

Também aplicamos muitos dos princípios do Unix às diretrizes de nossos desenvolvedores de funções, os engenheiros que usam Matlab e Simulink para desenhar diagramas de controle que, por sua vez, geram código C. Muitas vezes ouvimos de programadores que vêm de outras indústrias, e especialmente aqueles que amam C++, que este método é inferior, mas tendo usado ambos, posso ver claramente os benefícios da geração de código Simulink . Para grandes sistemas de controle, que são usados ​​em veículos e que podem levar os veículos a exibir um comportamento indesejado, o software também precisa ser bem documentado e, em tal tarefa, esse método é difícil de superar.
Uma razão é que o gerador de código limita possíveis construções. Outra é que permitimos apenas certas bibliotecas seguras. E, finalmente, temos centenas de scripts de verificação dos padrões de projeto no Simulink, bem como verificações do código gerado. Um pipeline de verificação Simulink Zuul típico:

- 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

Essa ferramenta usa três métricas principais, McCabe Cyclomatic Complexity, Halstead Complexity e Incoherence. O número principal é o volume Halstead ponderado que se ajusta muito bem ao design do Simulink. Fizemos um julgamento subjetivo de 500 modelos Simulink, onde classificamos sua complexidade de 1 a 10. Após digitalizarmos os mesmos modelos com a ferramenta, obtivemos um resultado muito próximo do nosso próprio julgamento.

Para algumas tarefas, é melhor escrever o código usando um teclado, mas isso pode ser facilmente integrado aos modelos Simulink. Em nossos kits de Desenvolvimento de Software, que montamos, destacamos que os desenvolvedores que geram código também são responsáveis ​​pelo código. Essa é uma das razões pelas quais permitimos que esses desenvolvedores enviem o código para Gerrit e também escrevam testes de unidade que verificam o código compilado e não pressionam o play em uma simulação do Simulink.

Portanto, os aspectos da filosofia Unix que enfatizamos para o design do Simulink são:

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.

Crescer e cultivar árvores . O primeiro passo é adquirir uma árvore, o que pode ser feito comprando um pré-bonsai (material bruto a ser podado e aramado) ou usando uma das várias técnicas de cultivo possíveis. Muito importante, no entanto, é selecionar uma espécie de árvore que se adapte às suas circunstâncias.

Técnicas de treino e estilo. Vamos começar com a técnica mais importante para Bonsai; poda. A poda é crucial para manter as árvores miniaturizadas, bem como para moldá-las. O objetivo é criar um Bonsai que se assemelhe o máximo possível à natureza. Remova galhos com voltas e reviravoltas não naturais. Remova galhos desproporcionalmente grossos do topo da árvore

Cuidado e manutenção. Uma parte crucial das informações sobre como cultivar uma árvore de Bonsai é sua manutenção e cuidado.

Convertido para modelos Simulink…

Pegue uma árvore. Pense no melhor fluxo e uso dos subsistemas antes de implementar!

Poda. À medida que a função cresce, use subsistemas para manter um tamanho razoável. Crie um fluxo com o mínimo possível de ramificações e linhas de sinal. Posicione os subsistemas de modo que eles se alimentem. Pequenas decisões podem ser mantidas em subsistemas. Tente conter a sinalização para evitar espaguete.

Cuidado e manutenção. Se o sistema crescer, pode ser necessário alterar a ordem do subsistema. Também pode ser benéfico estruturar diferentes tipos de lógica em diferentes subsistemas. Uma boa prática é deixar que cada subsistema tenha uma única responsabilidade; deve fazer uma coisa. Isso, por sua vez, leva a uma boa coesão.

Código escrito por um teclado

Quando se trata de código escrito por um teclado, não temos bons métodos para analisar e bloquear a complexidade do código em nosso sistema de CI Zuul. A única medida que temos agora é a complexidade ciclomática, e isso mais ou menos nos diz o quão difícil será testar. Embora tenhamos algo em andamento, e isso é do meu colega e camarada Vard Antinyan , que pesquisou o assunto em grande detalhe.

Como afirma Eric Steven Raymond,

você tem que ser leal e buscar a excelência.

Você precisa chegar à conclusão de que o design de software é um ofício que vale toda a inteligência, criatividade e paixão que você puder reunir. Caso contrário, você será levado ao caminho fácil, formas estereotipadas de abordar o design e a implementação; você se apressará em codificar quando deveria estar pensando. Especialmente se você trabalha em um ambiente Agile, você pode simplesmente correr em sua roda de corrida e pode complicar descuidadamente quando deveria estar

simplificando implacavelmente

e então você se perguntará por que seu código incha e a depuração é tão difícil.

Se alguém já resolveu um problema uma vez, não deixe que o orgulho ou a política o suguem para resolvê-lo uma segunda vez, em vez de reutilizá-lo.

Se algum dos meus colegas tiver algo melhor, vou roubá-lo com orgulho. E, claro, queremos automatizar tudo o que pudermos, isso economizará tempo a longo prazo.

A programação deve ser uma arte alegre, algo que apreciamos e pelo qual somos apaixonados. Se nos falta isso, talvez devêssemos fazer outra coisa?

Você precisa se importar. Você precisa jogar. Você precisa estar disposto a explorar.