Cuando formamos nuestros equipos, buscamos principios que resonaran con nuestras ideas de simplicidad, modularidad y prueba continua de ideas mediante la creación de prototipos. Descubrimos que la simplicidad es crucial porque la complejidad genera caos y desastre, especialmente cuando las cosas salen mal, como sucede a menudo.

Encontramos inspiración en el este, donde leímos sobre inventores que fabricaron productos con una solidez increíble bajo las limitaciones de la falta de recursos financieros. Primero, hicieron funcionar lo básico. A continuación, arrastraron sus inventos por la tierra y el barro y los dejaron caer desde las alturas.

Ahora el equipo tropezó con principios similares, la filosofía Unix, que provino de los laboratorios Bell a finales de los años setenta.

Del Bell system Technical Journal, julio-agosto de 1978, se puede leer acerca de los Principios rectores, y varias máximas han ganado popularidad entre los constructores del sistema Unix para explicar y promover su 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.

Luego, por supuesto, nos topamos con el legendario libro ' El arte de la programación Unix' de Eric Steven Raymond .

Aunque Eric condensó la filosofía de Unix como KISS Principio de

"Mantenlo simple, estúpido"

de su libro extrajimos 17 reglas ,

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.

Generación de código con Matlab Simulink

También aplicamos muchos de los principios de Unix a las pautas de nuestros desarrolladores de funciones, los ingenieros que usan Matlab y Simulink para dibujar diagramas de control que, a su vez, generan código C. A menudo escuchamos de programadores que vienen de otras industrias, y especialmente de aquellos que aman C++, que este método es inferior, pero después de haber usado ambos, puedo ver claramente los beneficios de la generación de código de Simulink . Para los grandes sistemas de control, que se utilizan en vehículos y que pueden provocar que los vehículos muestren un comportamiento no deseado, el software también debe estar bien documentado, y en tal tarea, este método es difícil de superar.
Una razón es que el generador de código limita las construcciones posibles. Otra es que solo permitimos ciertas bibliotecas seguras. Y por último, tenemos cientos de scripts de comprobación de los patrones de diseño en Simulink, así como comprobaciones del código generado. Una canalización de comprobación típica de 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

Esta herramienta utiliza tres métricas principales, la complejidad ciclomática de McCabe, la complejidad de Halstead y la incoherencia. El número principal es el volumen de Halstead ponderado que encaja muy bien con el diseño de Simulink. Hicimos un juicio subjetivo de 500 modelos de Simulink, donde calificamos su complejidad del 1 al 10. Después de escanear los mismos modelos con la herramienta, obtuvimos un resultado muy cercano a nuestro propio juicio.

Para algunas tareas, es mejor escribir el código usando un teclado, pero esto puede integrarse fácilmente con los modelos de Simulink. En nuestros kits de desarrollo de software, que hemos elaborado, destacamos que los desarrolladores que generan código también son responsables del código. Esa es una de las razones por las que permitimos que estos desarrolladores envíen el código a Gerrit y también escriban pruebas unitarias que verifiquen el código compilado y no presionen reproducir en una simulación de Simulink.

Entonces, los aspectos de la filosofía Unix que enfatizamos para el diseño de Simulink son:

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.

Plantar y cultivar árboles . El primer paso es adquirir un árbol, lo que se puede hacer comprando un prebonsái (material áspero para podar y alambrar) o utilizando una de las varias técnicas de cultivo posibles. Sin embargo, es muy importante seleccionar una especie de árbol que se adapte a sus circunstancias.

Técnicas de tren y estilo. Comencemos con la técnica más importante del bonsái; poda. La poda es crucial para mantener los árboles miniaturizados y para darles forma. El objetivo es crear un bonsái que se parezca lo más posible a la naturaleza. Retire las ramas con giros y vueltas poco naturales. Retire las ramas desproporcionadamente gruesas de la parte superior del árbol.

Cuidado y mantenimiento. Una parte crucial de la información sobre cómo hacer crecer un árbol Bonsai es su mantenimiento y cuidado.

Convertido a modelos Simulink…

Consigue un árbol. ¡Piense en el mejor flujo y uso de los subsistemas antes de implementarlo!

Poda. A medida que crece la función, utilice subsistemas para mantener un tamaño razonable. Cree un flujo con la menor cantidad posible de ramas y líneas de señal. Coloque los subsistemas para que se alimenten entre sí. Las pequeñas decisiones podrían mantenerse en subsistemas. Trate de contener la señalización para evitar los espaguetis.

Cuidado y mantenimiento. Si el sistema crece, es posible que sea necesario cambiar el orden de los subsistemas. También podría ser beneficioso estructurar diferentes tipos de lógica en diferentes subsistemas. Una buena práctica es dejar que cada subsistema tenga una sola responsabilidad; debería hacer una cosa. Esto a su vez conduce a una buena cohesión.

Código escrito por un teclado

Cuando se trata de código escrito por un teclado, no tenemos buenos métodos para analizar y controlar la complejidad del código en nuestro sistema CI Zuul. La única medida que tenemos ahora es la complejidad ciclomática, y eso más o menos nos dice lo difícil que será probar. Aunque tenemos algo en preparación, y eso es de mi colega y camarada Vard Antinyan , quien ha investigado el tema con gran detalle.

Como afirma Eric Steven Raymond,

tienes que ser leal y buscar la excelencia.

Tienes que llegar a la conclusión de que el diseño de software es un oficio que vale toda la inteligencia, creatividad y pasión que puedas reunir. De lo contrario, será engañado por el camino fácil, formas estereotipadas de abordar el diseño y la implementación; se apresurará a codificar cuando debería estar pensando. Especialmente si trabaja en un entorno Agile, es posible que simplemente corra en su rueda de velocidad y que se complique descuidadamente cuando debería hacerlo.

simplificando implacablemente

y luego se preguntará por qué su código se hincha y la depuración es tan difícil.

Si alguien ya resolvió un problema una vez, no deje que el orgullo o la política lo lleven a resolverlo una segunda vez en lugar de reutilizarlo.

Si alguno de mis compañeros tiene algo mejor, se lo robaré con orgullo. Y, por supuesto, queremos automatizar todo lo que podamos, ahorrará tiempo a largo plazo.

La programación debe ser un arte alegre, algo que apreciemos y que nos apasione. Si nos falta esto, ¿quizás deberíamos hacer otra cosa?

Tienes que preocuparte. Necesitas jugar. Tienes que estar dispuesto a explorar.