Когда мы формировали наши команды, мы искали принципы, которые соответствовали бы нашим представлениям о простоте, модульности и постоянном тестировании идей путем создания прототипов. Мы обнаружили, что простота имеет решающее значение, поскольку сложность порождает хаос и катастрофы, особенно когда что-то идет не так, как это часто бывает.

Мы нашли вдохновение на востоке, где читали об изобретателях, которые создавали продукты с невероятной надежностью в условиях ограниченных финансовых ресурсов. Во-первых, у них заработали основы. Далее они протащили свои изобретения по грязи и слякоти и сбросили их с высоты.

Теперь команда наткнулась на похожие принципы, философию Unix, пришедшую из лабораторий Bell в конце семидесятых.

В Техническом журнале системы Bell за июль-август 1978 г. можно прочитать о Руководящих принципах, а среди разработчиков системы Unix получили распространение несколько принципов, объясняющих и продвигающих ее характерный стиль.

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.

Затем мы, конечно же, наткнулись на легендарную книгу Эрика Стивена Рэймонда «Искусство программирования в Unix» .

Хотя Эрик сформулировал философию Unix как KISS Principle of

"Держать его просто глупо"

из его книги мы извлекли 17 правил ,

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

Мы также применили многие из принципов Unix к рекомендациям наших разработчиков функций, инженеров, которые используют Matlab и Simulink для рисования управляющих диаграмм, которые, в свою очередь, генерируют код C. Мы часто слышим от программистов из других отраслей, и особенно от тех, кто любит C++, что этот метод хуже, но, использовав оба, я ясно вижу преимущества генерации кода Simulink . Для больших систем управления, которые используются в транспортных средствах и которые могут вызвать нежелательное поведение транспортных средств, программное обеспечение также должно быть хорошо документировано, и в такой задаче этот метод трудно превзойти.
Одна из причин заключается в том, что генератор кода ограничивает возможные конструкции. Другое дело, что мы разрешаем использовать только определенные безопасные библиотеки. И, наконец, у нас есть сотни скриптов проверки шаблонов проектирования в Simulink, а также проверки сгенерированного кода. Типичный конвейер проверки 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

Этот инструмент использует три основных показателя: цикломатическая сложность Маккейба, сложность Холстеда и несогласованность. Первичное число — это взвешенный объем Холстеда, который очень хорошо согласуется с дизайном Simulink. Мы сделали субъективную оценку 500 моделей Simulink, где мы оценили их сложность от 1 до 10. После того, как мы отсканировали те же модели с помощью этого инструмента, мы получили результат, очень близкий к нашему собственному мнению.

Для некоторых задач лучше писать код с помощью клавиатуры, но это легко интегрируется с моделями Simulink. В наших комплектах для разработки программного обеспечения, которые мы составили, мы подчеркиваем, что разработчики, создающие код, также несут ответственность за этот код. Это одна из причин, по которой мы позволяем этим разработчикам отправлять код в Gerrit, а также писать модульные тесты, которые проверяют скомпилированный код, а не нажимать кнопку воспроизведения в симуляции Simulink.

Итак, аспекты философии Unix, которые мы подчеркиваем при проектировании Simulink:

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.

Выращивайте и выращивайте деревья . Первый шаг — приобрести дерево, что можно сделать, купив пребонсай (грубый материал, который нужно обрезать и связать проволокой) или используя одну из нескольких возможных техник выращивания. Однако очень важно выбрать породу дерева, которая соответствует вашим обстоятельствам.

Техники тренировки и стиля. Давайте начнем с самой важной техники бонсай; обрезка. Обрезка имеет решающее значение для сохранения миниатюрности деревьев, а также для придания им формы. Цель состоит в том, чтобы создать бонсай, максимально похожий на природу. Удаляйте ветки с неестественными поворотами. Удалите непропорционально толстые ветки с верхушки дерева.

Уход и обслуживание. Важной частью информации о том, как выращивать дерево бонсай, является уход за ним.

Преобразовано в модели Simulink…

Получите дерево. Подумайте о наилучшем потоке и использовании подсистем, прежде чем внедрять!

Обрезка. По мере роста функции используйте подсистемы, чтобы сохранить разумный размер. Создайте поток с как можно меньшим количеством ответвлений и сигнальных линий. Расположите подсистемы так, чтобы они питали друг друга. Небольшие решения могут храниться в подсистемах. Старайтесь сдерживать сигнализацию, чтобы избежать спагетти.

Уход и обслуживание. Если система растет, может потребоваться изменение порядка подсистем. Также было бы полезно структурировать различную логику в разных подсистемах. Хорошей практикой является возложение на каждую подсистему единой ответственности; он должен делать одну вещь. Это, в свою очередь, приводит к хорошей сплоченности.

Код, написанный клавиатурой

Когда дело доходит до кода, написанного с помощью клавиатуры, у нас нет хороших методов анализа и ограничения сложности кода в нашей CI-системе Zuul. Единственное измерение, которое у нас есть сейчас, — это цикломатическая сложность, и это более или менее просто говорит нам, насколько сложно будет ее тестировать. Хотя у нас есть кое-что в разработке, и это от моего коллеги и товарища Варда Антиняна , который очень подробно изучил эту тему.

Как утверждает Эрик Стивен Рэймонд,

вы должны быть лояльны и стремиться к совершенству.

Вы должны прийти к выводу, что проектирование программного обеспечения — это ремесло, которое стоит всего ума, творчества и страсти, которые вы можете проявить. В противном случае вы попадете на легкий путь, стереотипные подходы к проектированию и реализации; вы броситесь в кодирование, когда должны думать. Особенно, если вы работаете в Agile-системе, вы можете просто бежать в своем спринтерском колесе и небрежно усложнять то, что вам нужно.

безжалостно упрощая

а потом вы будете удивляться, почему ваш код раздувается, а отладка так сложна.

Если кто-то уже решил проблему один раз, не позволяйте гордыне или политике втянуть вас в решение ее во второй раз, а не повторное использование.

Если у кого-то из моих коллег есть что-то лучше, я с гордостью украду это. И, конечно же, мы хотим автоматизировать все, что можем, это сэкономит время в долгосрочной перспективе.

Программирование должно быть радостным искусством, чем-то, что мы ценим и чем увлечены. Если нам этого не хватает, то, может, стоит заняться чем-то другим?

Вам нужно заботиться. Вам нужно играть. Вы должны быть готовы исследовать.