У меня давно была идея написать статью о комбинации и заимствовании подходов к разработке из программирования с инженерным проектированием.
В данной статье пойдет речь не о системах управления персоналом, не о программах для контроля цикла производства изделия, не об каких - то мегапланах, 1с и прочем - пойдет речь именно о проектировании и об подходе инженеров к проектированию, ведущих инженеров к проектированию и проверке.
Кто то может быть не знает что такое ООП - это расшифровывается как объектно - ориентирование программирование.
То есть есть некий объект, который является экземплярам конкретного класса.
Сейчас подробно о самом ООП рассказывать не буду. В этой статье будет, так сказать, положено начало моей идеи смешивания программирования и конструирования.
Сейчас все инженера-проектировщики пользуются программами для проектирования.
Рассмотрим мою идею на работе инженера-конструктора.
Все они работают в 3д программах проектирования - сначала рисуются модели, они далее собираются в сборки, потом готовятся чертежи - это в кратце.
Сейчас отвлечемся на программирование - кто не знает, в мире программирования в порядочных компаниях существует code-review, так сказать, когда кто то более опытный проверяет твой код, проверяет, как программист назвал файл, как названы имена переменных, функций.
Также в программировании применяется система контроля версий - программа, с помощью которой можно отслеживать изменения.
Причем конечный продукт получает те или иные изменения только после одобрения написанного кода проверяющим - таким образом продукт получается без ошибок и прочего.
Теперь вернемся в мир инженерии.
С чем я столкнулся - каждый инженер по своему называет файлы. С ошибками, в беспорядочном месторасположении. Файлы называются в стиле "деталь 1, деталь деталь, деталь крышка" - куда, к чему они относятся мы никогда не узнаем, не поймем. Плюс нет конкретной структуры папок. Хаос.
Посмотрим глубже.
При построении 3д-деталей многие люди просто "забивают" на ошибки, которые выдает программа. О том что некоторые грани потеряли родителя (он нужен при перестроении), отвалились контрольные размеры и т.п. - причем там все выделяется красным, подсвечивается и т.п.
Из-за этого очень трудно что - то исправлять.
Я имел плохой опыт работы с этим - мне как-то попалось изделие, где в каждой детали были какие-то ошибки и вместо того, чтобы воспользоваться возможностью автоперестроения деталей при увеличении длины на 3 миллиметра приходилось вручную все детали двигать! Это заняло очень много времени! Если бы модель была без ошибок и корректно построена, то такого не пришлось бы делать.
Моя идея в том, чтобы внедрить контроль на уровне построения 3д моделей - и ко всему прочему использовать систему контроля версий, чтобы в конечный продукт не попало какой-нибудь ерунды.
То есть должен либо ведущий инженер, либо начальник отдела проверять сами 3д модели и сборки, как они построены. нарисованны и образмеренны перед тем как по ним что то изготавливать. Плюсом является еще и тот факт, что при корректно сделанной модели ее поддержка, так же как и корректно написанный код, будет намного проще и удобнее, понятна новым людям и не надо будет долго вникать в суть изделия.
Я надеюсь, что моя идея ясна из этой короткой статьи. В следующей статье объясню идею классов и объектов - как это можно использовать в конструировании.
