7 заповедей любого инженера

    Всем привет! Хочу сразу сказать, что все выводы из этой статьи - квинтэссенция опыта моей инженерной (да и не только) деятельности. За свою трудовую деятельность я успел поработать и слесарем(по разным направлениям), и мастером на заводе, и инженером-проектировщиком в сфере ПГС, и системным-администратором, сейчас вот работаю программистом. Считаю, что многое из статьи применимо в принципе к любой трудовой деятельности и не только технической. Разница только в масштабах. По сути, хочу поделиться опытом, и возможно кто-то возьмет его на вооружение.

    В любой работе должна быть система

    Именно этому пункту я отвожу центральное место в работе инженера. Именно его больше всего игнорируют большинство тех инженеров, которых я знаю и это большая боль. Для начала хочу донести, что я подразумеваю под системой. Система - это самый крупный узел в проекте, который состоит из дерева более мелких узлов. Здесь важно понять суть - у каждого она может быть своя: у программиста - набор проектов и их взаимосвязи, у конструктора - сборка его 3D-моделей, у мастера на производстве - агрегаты и трубопроводы, находящиеся в его сфере обслуживания. Другими словами - архитектура.

    Очень часто можно увидеть отсутствие системы в отсутствии системных решений и правил. Я очень часто наблюдал и наблюдаю точечные решения проблем без разработки системного решения. Как вариант, случай из моей практики. "На крупном заводе функционировала система теплоснабжения. Единая магистраль от которой запитывались все отопительные системы цехов (для тех, кто в теме - зависимая схема подключения). Потом заметили, что в одном из цехов прохладнее, чем нужно. Пошли слесаря, покрутили краны, вроде потеплело. Зато в другом месте на заводе стало холоднее. Разрегулировали. Поставили дроссельные шайбы - не помогло. Так слесаря и ходили из цеха в цех, краны крутили."

    Другой пример из IT. Есть такое выражение, "Хороший сисадмин – ленивый сисадмин. Только лень заставит его настроить все раз и навсегда". Всякий раз, когда возникает схожая проблематика, или похожая неисправность, значит вероятно проблема не решена системно. Из IT еще неплохой пример - костыли, быстренько пишешь и задача решается, но... Не системно - локально. Все мы знаем, что происходит дальше - код начинает хромать с нашими костылями. Система сбоит.

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

    Разделяй и только тогда будешь властвовать

    Любая, даже самая сложная система, состоит из менее крупных узлов. В любом случае должна. Ракету не строят монолитным куском. Вместо этого в ней присутствуют блоки. Как и, к примеру, в автомобиле. Он состоит из следующих систем: кузов, трансмиссия, двигатель, электрика и т.п. То есть вышеперечисленные системы даже проектировать могут и, в большинстве случаев, должны разные люди. В итоге получается своего рода конструктор, который потом нужно просто собрать.

    Система может быть очень сложной, но тут нужно определить ее составляющие узлы. Система - является большим узлом, который состоит из других, более мелких, узлов. Эти, более мелкие узлы могут быть также составными узлами или примитивными (неразборными) объектами. То есть большую систему можно и нужно декомпозировать на более мелкие. Если и более мелкие узлы могут быть декомпозированы, то их также стоит раздробить. То есть нужно проектировать иерархию системы. И чем больше эти узлы будут изолированы друг от друга, тем лучше. Например, как вариант решения вышеописанной проблемы в теплоснабжении завода, можно было бы поставить по теплообменнику в каждый цех и регулировать пришлось бы только систему теплоснабжения каждого отдельно взятого цеха, при этом другие участки теплосети не пострадали бы.

    В IT - то же самое. На языке разработки ПО это называется "Сильная связность, слабое зацепление." Похоже на GRASP, не так ли? Пилишь немаленький проект и все запихиваешь физически в один файл-проект IDE-шки. Поначалу многие так делают. Зато потом тестировать подобное решение - так себе удовольствие. Разбиваешь на пакеты, где в одном - бизнес-логика, в другом - представление, в третьем - оставшийся кусок используемого паттерна MV*. И уже совершенно другая картина. Согласны? На моей практике, коллеги по цеху долго не могут выполнить подобную декомпозицию. Банально разбить на подпроекты хоть по какому-то признаку. В результате проект становится жутким Legacy. Думаю многим знакомо "Лучше с нуля все переделать".

    По итогу мы получаем необходимость в построении дерева, в котором видны четкие зависимости. При этом необходимо все воспринимать именно в масштабе проблемы. Своего рода получается своеобразный механизм отлова ошибок: происходит ошибка/аварийная ситуация/поломка и мы понимаем, что поломалось в определенном узле. Иными словами данную систему легче тестировать. Узлы должны быть изолированы друг от друга и должны быть атомарными. В случае с IT - это называется инкапсуляция. И да, многие знают принципы ООП, но уж очень много специалистов, причем достаточно неплохих, пользуются ими крайне неумело.

    Все гениальное просто

    Чем проще агрегат, тем меньше шансов его поломать. Не раз слышал от автомобилистов - "там почти ничего нет, потому и ломаться нечему." Если разрабатывается какая-нибудь конструкция, то стоит ее сделать максимально простой. Чем проще конструкция, тем она будет дешевле в обслуживании, тем меньше внимания ей придется уделить, а лишние узлы не будут вводить в заблуждение. Рассмотренная выше система теплоснабжения - один большой сложный узел, которым было тяжело управлять и его регулярно приходилось чинить.

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

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

    По работе мне приходилось сталкиваться с кодом, который был очень "навороченным". В качестве примера - в одном классе могла быть описана бизнес-логика большей части проекта + графическое представление, в другом классе один только список инициализации был из туевой хучи параметров, в третьем сущности почти все enum положены в один файл. Работать с таким кодом - сущий ад. И действительно - легче переписать с нуля, так как по сути получится как в том анекдоте - только что-то рефачишь - а оно фатально ломается и непонятно почему.

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

    Чистота залог здоровья

    С моей точки зрения, инженер должен действовать аккуратно и расставлять все по полочкам. Тогда и он, и тот, кто придет ему на смену, будут всегда знать, где что лежит. Например у инженера-конструктора все проекты находятся в одном месте, он всегда знает где и что у него лежит, при этом на любой вопрос в его работе он может ответить. У инженера на производстве все эксплуатационные документы хранятся в организованном виде. Если человек работает за компьютером то все его проекты разбиты по строгой иерархии папок, имена файлов осмысленные и пр.

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

    Думаю многие лиды (да и не только лиды) понимают, насколько важен чистый код. Самому же потом поддерживать, а ты не только не помнишь как работает какой-то механизм, но и не знаешь, где посмотреть, чтобы разобраться. Пример из практики, не связанной с разработкой ПО: у инженера на столе лежала кипа проектов, заявлений и пр. бумажек. Минут 10 уходило только на то, чтобы найти нужную. При этом после нахождения кипа не разбиралась. На практике в их работе не было системных решений - были только заплатки. Во время работы на заводе мне в этом плане немного повезло - многие задвижки, вентили и рабочий инструмент, когда я пришел, лежали почти что в строгом порядке. Работать было приятнее.

    Без бумажки ты - бедняжка

    Документация нужна любому инженеру. Составлять документацию не хочется никому. Сколько я видел закатывания глаз от необходимости переделывать документацию из-за того, что что-то в ней не так написано, что были внесены изменения в какой-то проект и да, этот вопрос действительно мучает многих инженеров. Но... Это необходимо. Если не для тебя, то для кого-то другого точно понадобится. По-дефолту человек не обладает такими качествами, как телепатия, поэтому всегда нужно писать как сделать то-то и то-то. Все должно быть прозрачно и ясно. Причем лично для меня в приоритете стоит ясность изложения, нежели соответствие стандартам.

    Заодно пару слов о стандартах. Многие стандарты писались, по моему скромному мнению, именно из тех соображений, что должно быть яснопонятно всем. Делай как написано и будет тебе счастье. К примеру, винты делаем только с левой резьбой и только с таким хим.составом. Как-то спорил с одним инженером, который сказал: "Стандарты писали девочки, которые ничего не понимают в технике." Такое было слышать, как минимум, странно. Обычно стандарты рождаются между институтами, ведущими предприятиями промышленности, а потом согласуются этими предприятиями и выпускают эти согласования в бумажном виде, что и является стандартом. То есть есть они нужны не для того, чтобы насолить студентам инженерных ВУЗов, а для четкого взаимодействия их на практике.

    Возможно, кто-то скажет что я сам себе противоречу, но я немного перефразирую высказывание из манифеста гибкой разработки: "Документ, по которому удобно и можно правильно работать, важнее исчерпывающего соответствия стандарту". Как-то слышал байку, что в одном ВУЗе висел плакат, на котором нужно было найти 3 ошибки, чтобы получить автомат по предмету. И каждый из выпусков находил что-то новое. К чему это я? Соответствие стандарту - не самоцель. К примеру есть сборочный чертеж, который дает однозначное представление о выпускаемом изделии. Это значит, что инженер свою задачу выполнил.

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

    Используй интерфейс как связь между узлами

    Вышеописанное описание стандарта напоминает описание интерфейса. Интерфейс - это своего рода также соответствие стандарту. Порой пройдет достаточно много времени, прежде чем ты понимаешь, как нужно было действительно проектировать интерфейс. С интерфейсами мы сталкиваемся постоянно в реальной жизни. Автомобилист не обязан знать устройство двигателя и уметь в нем ковыряться, если конечно это не вменено ему в обязанность. У него есть интерфейс для вождения - руль, педали, ключ зажигания и пр.

    Для того, чтобы у нас узлы могли спокойно между собой взаимодействовать, необходимо тщательно продумывать именно интерфейс взаимодействия. Причем в очень многих случаях он даже важнее внутреннего устройства механизма, пускай и очень сложного. Автомобилист может ехать как на электрокаре, так и на автомобиле с ДВС. Человеку по большей части все равно, что под капотом. Шестеренкам, которые передают крутящий момент тоже. Не все равно только шестеренкам на то, как они получают этот крутящий момент. А вот это и есть очередной интерфейс. Только не для человека, а для механизма. В вышеописанной системе теплоснабжения интерфейсом мог бы стать теплообменник.

    Еще одним преимуществом интерфейсов я считаю то, что по сути это как контракт на узел. Он должен быть таким-то, чтобы с ним можно было работать. И тем самым мы даем понять другому инженеру, какую ответную часть и как нужно разрабатывать другому инженеру. Я очень часто наблюдал ситуацию, когда разрабатывалась сложная конструкция, а "интерфейсам" не уделялось должного внимания, будь то программный код, продукция машиностроения или проект жилого дома. Найти общий язык с коллегами при этом достаточно сложно.

    95% работы - допиливание 5% проекта или лучшее - враг хорошего

    Во всех сферах, в которых успел поработать, всегда находилось "узкое горлышко" в которое непременно нужно было втиснуться. Речь о юзабельности для бизнеса. К сожалению это наш общий бич. Инженеру ПГС нужно так запроектировать, чтобы в теплоузле разместить оборудование, чтобы и доступ был, и не шумно было, и чтобы температура была допустимая, и денег минимум. Программисту - нужно вписаться в дедлайн, реализовать все хотелки заказчика, и производительность чтобы была, и денег минимум. Системному администратору нужно допилить какой-нибудь jabber-клиент, когда уже все остальное готово, подключить почту внешнего сервиса, чтобы были корректными имена сотрудников, и чтобы это ничего не стоило.

    По-другому можно перефразировать все вышеописанное как впихнуть невпихуемое. И так будет всегда. Ужать захотят всегда, в первую очередь по деньгам, затем "по конструкции", поэтому теперь я всегда пытаюсь проектировать так, чтобы было недолго исправлять. Придется всегда делать лучше. Но оно того стоит. Ведь когда-то отказались в автомобилях от запуска с помощью заводной рукоятки в пользу стартера. Автомобилистам это было нужно. Можете представить, чтобы сейчас стали выпускать такие автомобили с рукояткой вместо стартера? Пускай даже автомобили будут неплохими, их вряд ли будут покупать. Почему? Просто уже неудобно будет пользоваться в сравнении с другими автомобилями.

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

    Вместо заключения

    По большей части данный момент олицетворяет мои фантазии, как инженера. На мой взгляд на данный момент инженерам не хватает инструментов "оркестрирования" их системами. Есть, правда, зачатки данных систем: у разработчиков ПО - это UML-кодогенераторы; у инженеров-проектировщиков ПГС - это BIM, у инженеров-проектировщиков в машиностроении PLM-системы. К сожалению многие из этих "продуктов" очень медленно развиваются, хотя потенциал у них больше, чем даже думают их создатели и их очень не хватает инженерам "высокого уровня".

    Но это происходит по той причине, что конечные пользователи "не умеют их готовить" и, как причина следствие "продукт" не развивается из-за отсутствия фидбека. Из своих нынешних коллег кодогенератор использую только я. Остальные UML рисуют на бумажке, которую потом просто выбрасывают. Следующему разработчику, которому отдают проект, приходится вникать во многие детали и, если проект большой, общую картину он увидит не скоро. А ведь UML более нагляден, нежели банальное чтение кода. Даже для тех, кто далек от разработки. И как плюшки - часто дает возможность для самодокументирования кода.

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

    Своего рода при присутствии недостающего определенного функционала у вышеуказанных систем можно не спускаться до узлов более низкого уровня. Тут мы абстрагируемся настолько, насколько возможно. Своего рода это проектирование "сверху вниз". Мы должны описать своего рода контракт. Инженер, который будет проектировать узел более низкого уровня, будет ограничен в своей рукожопости данными необходимыми для разработки. Хотелось бы видеть больше абстракции в подобных продуктах, где у архитектора системы нет необходимости(или возможности) вникать в детали проектируемых абстракций.

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

    Чуть не забыл - да начнется срач ;)

    Похожие публикации

    Средняя зарплата в IT

    113 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 10 037 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 56

      +3

      А какой срач может начаться, если тут правда жизни написана?) Так или иначе, гуманитарии добиваются чего-либо, только если структурировать умеет свою жизнь. Все мы где-то инженеры)

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

        Можете описать flow разработки с применением подобных генераторов? Например, что происходит, если нужно поправить UML-модель?
          0
          можно не поддерживать согласованность, т.е. генерить один раз в начале вместо «вручную»
          можно перегенерить при изменениях
          но чтобы проектировать исключительно в UML, до этого техника не дошла
          Rational Software пыталась сделать этот flow, но потом пришли хипстеры, водопады обмелели, agile, scrum вот это всё
            0
            Можете описать flow разработки с применением подобных генераторов?
            Описывал как-то протокол передачи данных между CAD-ами. Генерился отдельный пакет не привязанный к API. Было удобно, ибо проект рос и хотелось вытащить из CAD-а все больше данных. При этом, если код не готов, то связь достаточно было просто не прорисовывать на UML. Мне это сильно помогало. К тому же, я показал UML своему руководителю, который не очень был хорош в ООП, и он лучше стал понимать описанную бизнес-логику. «Картинки» более информативны, чем текст.
            Например, что происходит, если нужно поправить UML-модель?
            Если правильно понял вопрос, то перезаписывается код всех исходных файлов.
              0
              Если правильно понял вопрос, то перезаписывается код всех исходных файлов.

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

              По моему опыту реализации генераторов кода в Яндекс.Такси: нужно четко разделять сущности, которые генерятся один раз (например, шаблон нового сервиса в самом минимальном варианте) и которые нужно будет перегенерировать (например, код клиента по OpenAPI описанию). Если вы 100% не будете иметь желания перезапускать генератор при каких-то изменений, то последовательность «сгенерил шаблон, получил артефакт, дописал артефакт руками» позволительна, она не ведет к лишним действиям. Но если вы при каких-то обстоятельствах захотите перезапускать генератор для изменения артефакта, то артефакт категорически нельзя редактировать руками, он должен быть generated only, т.к. в противном случае вам нужно будет совершать лишние действия по «переприменению» ручных изменений. Думаю, не нужно говорить, какая пропасть ошибок скрывается за этим переприменением и какие безумные вещи совершают разработчики, чтобы срезать углы. При таком флоу этап «перезапустить генератор» — это атипичный этап, которого все боятся, непонятно, как выполнять корректно, и для которого нет удобных инструментов.

              К тому же, я показал UML своему руководителю, который не очень был хорош в ООП, и он лучше стал понимать описанную бизнес-логику. «Картинки» более информативны, чем текст.

              UML может быть в проекте не только в случае генерации кода из UML, но и по другому flow. Можно добавлять описание в исходный код, из которого генерить документацию, UML-диаграммы и другие артефакты.
                0
                весь код, который был дописан в исходные файлы, нужно вписывать туда заново
                В моем случае все было не совсем так. Я использовал кодогенератор, который мог хранить в себе реализацию, то есть описал реализацию в IDE, отддебажил и скопипастил ее обратно в UML, дальше генерируй без опаски что-то потерять. Да, двойная работа, но лучшего не имеем, поэтому… Еще помогло, что помимо прочего он поддерживал реверс-инжиниринг. То есть, если соблюсти определенные формальности, то можно было получить UML из исходников. Но, правда, не все так просто было. Да и на некоторых порах было бы достаточно даже просто рыбы кода. Я вообще не лобирую использовать UML-кодогенераторы. Это мне они жизнь упростили, у других может быть негативный опыт. Да и посыл я делал другой — зачатки инструментов есть, но требуют развития.
                А какой кодогенератор использовали Вы? Rational Rose как понимаю?
                  0
                  А какой кодогенератор использовали Вы? Rational Rose как понимаю?

                  Да, его самого. Это было лет 10 назад, причем в процессе учебы в университете, а не в коммерческой разработке, поэтому я предположил, что есть какие-то более удобные флоу, в которых нет шагов с переписыванием кода.
            +2
            Поддерживаю про то, что чтобы начаться «срачу» нужно было бы что-то противоречивое. Мне кажется всем, даже тому человеку со стопкой на столе понятно, что это плохо. Вопрос в том, что многие не могут поднять головы и понять, что они бы сэкономили время себе и людям. И ещё, вот если бы написали как соблюсти эти принципы тут да. Я к сожалению видела и вижу как проекты покрываются костылями, потому что на системное нет времени, а фича нужна, иначе клиент уйдет. И вроде все говорят бизнесу, что когда количество костылей будет большим, вносить изменения будет очень дорого, но я к сожалению ситуации, когда бы бизнес это слышал пока не видела.
              0
              Как я понял Ваш основной вопрос можно сформулировать так: «Как донести бизнесу, что нужно больше времени?» Я бы сказал так: если бизнес это Ваш продакт-менеджер, то нужно просто подождать, пока проблема «вырастет» и до него «дойдет». Иначе он Вас так и будет прокатывать по срокам. Если дело касается бизнеса со стороны клиента, то тут стоит просто показывать почаще, что работа ведется. «Смотрите, на той неделе у нас разработана эта фича. На этой — другая.» При этом клиент будет думать примерно так «Они работают, так как каждый раз что-то показывают. Большая часть проекта готова, поэтому не имеет смысл он них отказываться.» Но опять же — пускай продакт этим занимается. Ну и да, в жизни чуть посложнее, но я пытаюсь придерживаться такой позиции.
              +2
              Какие-то обобщения ради обобщений. Нет бы взять практическую задачу и описать свои мысли применительно к ней.
                +5
                Все, что могло сломаться у этой мясорубки — это стол, к которому она крепилась.


                Ха! Русская женщина преклонного возраста одним махом убивает по 2 такие. Было у родственницы значит 2 мясорубки чуть разные по конструктиву. Помыла она их с мылом и стала собирать. И что-то у нее ножи на место не садились. На помосчъ пришел обух топора… Ножи сели, причем совсем.

                Правило #8: «на каждый условно надежный конструктив найдется свой решительный исполнитель»
                  0
                  Давно было дело, купил дополнительную плашку памяти в комп, а она в слот не лезет. Знакомому в аське пожаловался, тот говорит: «А ты молоточком.»
                    0

                    Помню была в хозяйстве мясорубка ровно как на изображении в статье. Резьба винта, крепящего ручку, была стёрта почти в ноль и ручка частенько слетала в процессе прокрутки мяса.

                    +4
                    Понятие бардака на рабочем месте это понятие сугубо индивидуальное. Если человеку понятно где что у него лежит на столе среди гор бумажных черновиков, заметок или записок на обрывках листка, кучи на вид непонятных папок на компе с названиями new, new1, new123 — не значит что это должно быть понятно любому, севшему за его место. Пытаясь вогнать человека в какие-то свои представления — в конце дня стол должен быть пуст, уходя отвертки вставляй в ячейки, что они у тебя по столу лежат, премии лишу… вы просто замедляете его работу, заставляя искать привычные для него вещи в непривычных местах.
                      0
                      Причём оригинальность этой системы, его родной — показатель творческой личности.
                      +1

                      Так-то все верно, с инженерной точки зрения, но есть одна проблема. Информационные системы постоянно развиваются. Почти любые. Это уже их обязательная характеристика. Развиваются вслед за рынком или государством или потребностями людей. И проектировщик не в силах предугатать куда пойдет развитие. Поэтому спроектировать систему хорошо и правильно "раз и навсегда" просто не возможно. Пока вы ее проектируете и "отливаете" в коде, она уже устаревает. Приходит бизнес и говорит — нам такая система уже не нужна, но на новую денег не дадим, допиливайте эту. Дедлайн — вчера.

                        0
                        На новую денег не дадим, допиливайте эту.

                        Извините, не смог удержаться.
                        И имеем следующий код, после таких фраз
                        image
                        +1
                        Почитайте лучше ТРИЗ Генриха Альтшуллера.
                          0
                          Извините за посягательство на святое, в книге Генриха Сауловича много разумных вещей, но вот читаю его биографию и не вижу историй серийного производства и внедрения.
                            0
                            Я не идиализирую Генриха Сауловича, но кроме него, мало кто писал про теорию изобретательства.
                            Также внедрения и серийного производство в СССР было ряд особенностей.
                            Например:
                            1) Невысокая (одноразовая) оплата за изобретение.
                            2) Необходись включать в соавторы ряд начальников для последующей получения хоть какой-то премии.
                            3) Механизмы планового хозяйства со своими планами и нормами выработки не способствовали росту кол-ва кулибиных, левш и стахановцев.

                            P.S. Даже профильный журнал «Изобретатель и рационализатор» был очень дифицитен.
                              0
                              Вопрос был немного не о том: если Вы разбирали биографию Генриха Сауловича подробнее, чем в вики, что из его изобретений было внедрено? Я списка не нашёл.
                                0
                                О внедрениях конкретных изобретений надо искать в архивах Госплана СССР.
                          0
                          Выскажу свое мнение почему BIM так медленно развиваться, это не из-за отсутствие фидбека от инженеров, открытых писем пишется много и на форумах по конкретным ПО, достаточно вспомнить последнее письмо от британских архитектурных бюро с критикой Autodesk, одного из крупнейших вендоров, но деньги тратят не на разработку и внедрение новых удобных инструмент, а на маркетинг, ведь для компании главный показатель это прибыль.И рост прибыли маркетинг обеспечивает, а то что программы сырая неудобна и не доделанная это не важно.Да у гигантов появляются маленькие конкуренты которые что-то пытаются, но их обычно скупают и они умирают, редко перерастая во что-то работоспособное. Потому в строительстве BIM так и буксует, а еще заказчик пытается экономить, и вместо дорогой и во многих удобной (не вовсем) программы вы покупаете дешевый кривой аналог, или пиратите(что тоже плохо) потому если вендор делает хороший продукт, то он дорогой, его плохо знают, и найти сотрудников под него сложного.
                            0
                            Правило №1
                            Работает — не трогай!
                              0
                              это сомнительно, если долго куда-то не заглядывать то окажется что автор уже умер от старости и никто не знает как изменить
                              в нормальной ситуации у программиста нет времени трогать что-то без причины
                                0
                                Тем более для программиста.
                                Правило №2
                                Лучшее — враг хорошего.
                                Исключение из этих правил — когда программирование хобби и процесс не коммерческий.
                                  0
                                  у вас, наверное, и №3 есть, не стесняйтесь, выкладывайте все
                                    +1
                                    Это и есть Правило № 3: «Не стесняйтесь, выкладывайте все»
                              0
                              … многие знают принципы ООП, но уж очень много специалистов, причем достаточно неплохих, пользуются ими крайне неумело.


                              Простите, но в этом случае это — плохие специалисты.
                                0
                                С другой строны, если эти специалисты создали и выпустили на открытый рынок продающийся прибыльный продукт — то какие же они плохие?
                                  0
                                  Я ровно 10 лет (с 2001 по 2011) успешно продавал отвратительно спроектированный и ужасно реализованный коммерческий продукт. Более того, моей огромной ошибкой было создание гораздо лучше спроектированного и реализованного коммерческого продукта со сравнимым функционалом. Я потратил ресурсы, но проект «не взлетел». Бизнес имеет колоссальную инерцию и почти никогда не потратит денег ради «самой правильной архитектуры» или снижения будущих расходов на сопровождение без конкретной метрики.
                                    0
                                    успешно продавал отвратительно спроектированный и ужасно реализованный коммерческий продукт.


                                    Ну так коли money talks, то все остальное так, не пришей кобыле хвост. Если ради «самой правильной архитектуры» никто не даст ни цента, то может, ну ее в пень, эту архитектуру?
                                      0
                                      Все не так радикально.
                                      Во-первых, иногда получается аргументировать свою точку зрения и найти с заказчиком разумный компромисс.
                                      Во-вторых, хорошая архитектура нужна разработчикам, чтобы не утонуть после написания 80% кода за первых N дней проекта. Иначе на оставшиеся 20% легко можно потратить N^N трудодней.
                                      В-третьих, я утверждал, что программисты, которые «неумело» используют ООП — плохие программисты по определению.
                                      У меня сейчас как раз есть такой проект, где «неумело», т.е. без всякой необходимости, 10-15 уровней наследования UI, а сущности «размазаны» по этому UI в виде набора глобальных переменных.
                                      И это не случайно так получилось, а так «архитектурщики» неумело наархитектурили.
                                0
                                Пускай пока подобных инструментов даже не предвидится в будущем

                                как это не предвидится?
                                В крупных компаниях уже давно придумали PDM системы, типа Windchill или Siemens PLM, которые тесно связаны интеграционно с CAD системами — Creo или NX.

                                В данных системах при грамотной настройке проектирование идёт как раз сверху вниз, декомпозируя каждый отдельный узел. Сотруднику прилетает задание на разработку, например, крышки, он видит только каркас какого-то узла, даже не в курсе куда этот узел в дальнейшем будет применён.
                                Тем самым в проектировании самолёта или автомобиля могут принимать участие разные компании из самых разных стран.

                                PDM системы дорогие. Российский рынок машиностроения почти их не использует, за редкими исключениями. А если использует, то без грамотного внедрения, как Вы говорите — в качестве «файлопомойки». Бюджет ИТ главное освоен, а как работать с системой за сотни млн.руб — неважно.

                                Плюс ко всему в РФ мало компаний, которые могут произвести внедрение таких систем на предприятии. Задача многократно усложняется, когда в руководителях отделов находятся люди, которые не понимают всей важности таких систем, а тем более когда на заводе находятся военные представители, у которых даже компьютеров нет. Работа PDM сводится к нулю, когда всё равно приходится печатать бумажный документ и ногами идти согласовывать его к человеку в форме.

                                  0
                                  PDM системы дорогие. Российский рынок машиностроения почти их не использует, за редкими исключениями.

                                  Сколько примерно фирм? Вроде у интермеха клиентов немало Тыц
                                    0
                                    «не использует» — я имею ввиду крайне малую степень интеграции во все бизнес-процессы.
                                    Купить, установить и запустить систему — это лишь первый этап. Дальше необходимо писать стандарты по работе, проводить обучение, выявлять отсутствующий функционал, производить доработку, сопровождение и так далее.
                                    Везде, где я встречал PDM системы есть разрывы между происходящими процессами всей цепочки проектирования, где-то всё равно что-то делается вручную, ручками, в экселе, на коленке и т.д. А это огромный минус для такой системы, как вы понимаете.

                                    Номинально куплена PDM много у кого, потому как есть установка от высших чинов ВПК, если предприятие большое = должна работать PDM. А как она там работает и работает ли вообще никого не волнует, галочка поставлена.
                                    В бюджет предприятия неохотно хотят закладывать ещё несколько млн.руб в год на поддержку PDM, купили и всё.
                                    0
                                    как это не предвидится?
                                    В крупных компаниях уже давно придумали PDM системы
                                    привет, Илья!
                                    Сами PDM-системы, разумеется, есть. Да и я упомянул их. Но не видел я присутствия в них «оркестрирования». Есть, правда зачатки, но это далеко до оркестрирования. И, да, проектирование действительно идет сверху вниз, но не средствами PDM.
                                    0
                                    Главное правило инженера — «Работает? Не трогай!» — сколько раз мы его нарушали, столько же раз получали катастрофические проблемы) А если серьезно, то меня всегда выручали в трудных ситуациях: знания (саморазвитие непрерывное), накопленный и осмысленный(!) опыт и вера в себя, в то что ты все сможешь — нужны только время и ресурсы. Все остальное было уже вторично
                                      0
                                      Работает? Не трогай.

                                      Это очень спорный принцип. Банки в восторге от него. Сейчас мы имеем тонну кода на Java 1.4- или, прости, господи Cobol. Не очень туда рвутся люди, т.к после пары лет такого экспириенса, смотришь на kotlin, как пещерный человек на летающую тарелку.
                                      +2

                                      У меня есть восьмая заповедь — "Обязательно проверяй себя"

                                        0
                                        Хорошая мысль. Для меня могла бы стать очередной заповедью;)
                                        0
                                        Всегда казалось, что именно ленивые сисадмины городят костыли и не делают документацию (и потом сами даже не помнят, как сети проложили). Потому что им лень думать.
                                          0
                                          Лень — это лишь топливо. Качество костылей будет зависеть от дальновидности человека. Если сисадмин ленивый и у него большой горизонт планирования, то он не будет делать костыль, который завтра придется переписывать.

                                          Другое дело, что админ при тушении «пожара» может вставить плохо сделанный костыль, который будет потом сложно вытащить. Но это уже не вопрос лени, а вопрос готовности к инцидентам.
                                          +1
                                          Опять про эти «волшебные интерфейсы и абстракции». Они все текут, запомните это уже наконец-то! И течь начинают быстрее, чем думает их создатель, какой бы крутой он не был.

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

                                          Если бы было не так, у нас бы были везде, например:
                                          • Одинаковый разъём питания на всё!
                                          • Одинаковое напряжение на всю микроэлектронную логику
                                          • Одинаковая разрядность памяти и процессоров (и физические разъёмы туда же)
                                          • Один язык программирования (пусть даже ваш любимый)
                                          • Одна платёжная система


                                          Все эти и много других вещей придумывали умные люди, и они учли огромное количество нюансов, их системы работали и приносили деньги, но не стали тем самым неменяемым стандартным интерфесом, т.к. всё устаревает и очень быстро меняется. Новые задачи, требования и информация делают интерфейсы в том виде, как про них пишут в книгах (почти как решение всех проблем) невозможными в принципе!

                                          Нужно стремиться к этому, учитывать, но не молиться, иначе это похоже на религию.
                                            0
                                            Я хотел бы чтобы Вы немного оторвались немного от разработки ПО. Есть же к примеру, инженер-конструктор, ему не дают готовую конструкцию — ему дают, к примеру ТЗ и габаритный чертеж. Вот это уже интерфейс. Ему нужно его реализовать.Может это грубо сказано, но в данном случае вышестоящий инженер как бы говорит «сделай это так, а это так, а в остальном мне все равно. Ты — специалист, ты и думай.» Если уйти от проектирования, то теплообменник физически тоже выглядит как реализация интерфейса: можно поставить теплообменник не одной, а другой фирмы, из другого материала и пр., а результат будет примерно тот же.
                                            Пользователь же ОС работает с чем? С программным интерфейсом. Ему в большинстве случаев все равно какие алгоритмы лежат в работе ОС. Но, интерфейс — это то, что он видит, и вот тут ему уже не все равно. Касаемо теплосети — отдельно взятому цеху все-равно, что творится в остальной части теплосети, главное чтобы в теплообменник приходило что нужно. ТЗ может поменяться многократно, думаю Вы с этим тоже сталкивались. Это значит, что интерфейсу с самого начала уделили мало внимания.
                                              0
                                              Если уйти от проектирования,

                                              Это и не предлагается. Предлагается уйти от подхода «сначала продумай всё». Проблема в том, что заранее спроектировать все детали сложной системы не получится, слишком большой уровень неизвестности и изменчивости. То, что инженер сконструировал априорно, либо будет устаревшим на момент реализации, либо вообще не будет соотноситься с реальностью. Для уменьшения уровня неизвестности нужен эксперимент, контакт с реальностью, альфа-версия, как хотите называйте. Поэтому в разработке ПО у нас вместе с водопадом есть agile, одним из принципом которого является «работающий продукт важнее исчерпывающей документации».

                                              То, что вы говорите про «сначала всё продумай» является частью мышления в представлении изготовления продукта, в котором неизвестность маленькая, в нем всё можно просчитать, вычислить и предусмотреть заранее. В этом случае действительно эффективнее будет упорядочить работу по модели водопада и как можно раньше просчитать всё, что можно просчитать (в т.ч. описать интерфейсы, контракты, инварианты и т.п.). Если вы знаете, что в ваших условиях есть большая доля неизвестности и изменчивости, априорные вычисления будут просто неверны, у вас в приниципе недостаточно информации для принятия решения.
                                                0
                                                То, что вы говорите про «сначала всё продумай»
                                                не говорил я такого. И, как мне казалось, я ясно дал понять во фразе «ТЗ может поменяться многократно», что я, напротив, допускаю пересмотр интерфейса и его перепроектирование. Я нисколько не возражаю против принципов Agile. Я очень даже за эти принципы и думаю, что они пригодились бы не только при разработке ПО. Тот же канбан пришел к нам из автомобилестроения.
                                                Ну, видимо не получилось донести мысль. Попытаюсь донести мысль про интерфейсы по-другому. Представьте, что сидят на совещании несколько специалистов разных профилей. Каждый видит свою работу, но не работу другого. Они спроектировали механизм, но «сшить» его не могут, так как дали друг другу плохие «интерфейсы». Со временем они начинают «слышать» друг друга. У них появляется мышление, где начинают лучше продумываться «интерфейсы». Это своего рода точки соприкосновения инженеров. Именно им уделяется мало времени. А зря.
                                                  0
                                                  Sartor в первом комментарии вроде и не предлагал избавляться от интерфейсов и контрактов. В моем сообщении этой идеи тоже не содержится.
                                                    0
                                                    не говорил я такого.

                                                    Вы это сказали тут:
                                                    ТЗ может поменяться многократно, думаю Вы с этим тоже сталкивались. Это значит, что интерфейсу с самого начала уделили мало внимания.

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

                                                      Представлени о ТЗ это несколько устарело. Корректнее будет что- то типа " цикл управления требованиями" или " процесс управления требованиями". Требования всегда меняются. И просто надо на каждые события определенным образом реагировать. Примерно так. Requirement Management вроде это так называется.

                                              –3
                                              >если бардак на рабочем столе
                                              Глубокоуважаемый;-) Аффтар Жжот слышал такой термин, как «творческий хаос»?
                                                –3
                                                >если бардак на рабочем столе, то значит и в голове у человека бардак.
                                                Мистика, фэн-шуй какой-то. «Беспорядок в комнате создаёт преграды и заторы для циркуляции энергии Ци», «поставьте жабу в юго-восточной угол стола, и она принесет вам деньги»
                                                «Чёрная кошка, перешедшая Вам дорогу, приносит несчастье»…
                                                Кстати, по законам той же магии;-), если индивид в противостоянии хаоса и порядка находится на противоположной стороне — монолитовец-эмеркоиновец, «инвольтирован к эгрегору хаоса» или просто chaotic good, то вредоносное влияние на него будет оказывать как раз порядок на рабочем столе(!).
                                                >Как правило и на компьютере…
                                                О, то есть не всегда. Уже прогресс.
                                                  0
                                                  Не путайте порядок ака «творческий хаос», который со стороны выглядит как хаос, но этот порядок помогает своему «владельцу» быстро выполнять свои задачи.
                                                  И хаос, который даже может выглядеть как порядок, но мешает своему автору работать эффективнее.
                                                  Грубо говоря, если автор тратить много времени на поиск чего-либо, то это хаос, как бы он не выглядел.
                                                  0
                                                  Интересные наблюдения! Мне очень близко.
                                                  Все вышесказанное Вами верно и очень широко внедрено и применяется на практике.
                                                  Прежде всего, в виде «системного подхода» в инженерной деятельности.
                                                  Основная информация собрана в стандартах ISO. Но читайте не только «стандарты качества» серии 9000, но и остальные…
                                                  Поэтому про первое правило: скорее нужна не система, а методология. Система, системное мышление — один из элементов такой методологии. Как раз набор элементов и их связи — основа архитектуры методологии. Я использую основы GERAM для своей работы. Основные Ваши идеи — вполне соответствую части GERAM.

                                                  Про разделение: это метод редукционизма. Но не стоит забывать и про холизм. То есть целое — это не сумма всех частей, а еще плюс что-то. Но в целом всегда можно увидеть какие-то части. Причем это сделать можно множеством способов. Которые зависят от цели декомпозиции и от точки зрения. Ну самое важное: объект в модели (как часть целого) возникает при надобности, никакого материального воплощения не имеет, и совершенно неважна природа его возникновения. ISO 81346. Конечно же, потом всегда можно найти или придумать связи объекта в модели с реальностью. Только укажите это, докажите — и вперед.

                                                  Все гениальное — может выглядеть простым. Но не обязательно оно «простое». «Чем проще агрегат, тем меньше шансов его поломать.» — тоже верно только для простых агрегатов. Если система (или агрегат) спроектированы и изготовлены использую понятие «антихрупкость» — то они всегда более надежным. Посмотрите тут в сторону живой клетки. Чтобы реализовать столько функций в течении многих лет — надо как раз иметь свойство «антизрупкости». Сложность же работы клетки поражает… Как и надежность организма из таких клеток.

                                                  Чистота, упорядоченность — это следствие методологии. Одна из ее частей. Может быть хаос, может быть и иерархия. Но только согласно какому-то элементы методологии. То есть важно понимать, что делать и с хаосом и с порядок.

                                                  Насчет документов. Совершенно с Вами согласен. В проектах у нас есть такой принцип: «Вся информация в проекте существует только в виде документов». Это может быть кусок бумаги, обертка от мебели, распечатанный файл, запись беседы… В общем — нет этого чего-то (артефакта) на сервере проекта — нет и в проекте. Ну а суму структуру документации, принципы работы с ней, все детали реализации почерпнули тоже в стандартах ISO. Прежде всего ISO 61355. Принципы многомерной классификации и организации документов, принципы их названий — все это давно придумано для разных отраслей и видов проектов. Причем реализовать все это очень просто связкой PM Wrike и Google Workspace. Или Redmine и какой-то сервер фалов. Или что угодно, что дает возможность хранить все документы и использовать метаинформацию о документах.

                                                  Про «допиливание». Все верно, если плохо сделана параметризация целей проекта. И если не использовать цикл Деминга. Кстати, именно на идеях цикла Деминга построены стандарты ISO. Цикл Деминга, плюс основы инженерии систем (системный подход).
                                                  Если же результат проекта оценивается именно в контексте цикла Деминга, то ничего допиливать не надо. Один элемент системы находится на одном этапе цикла, другой — на другом. На каком именно и как с этим жить — это вопросы между Заказчиком и Исполнителем. Примерно так, если коротко.
                                                  Своего рода при присутствии недостающего определенного функционала у вышеуказанных систем можно не спускаться до узлов более низкого уровня.

                                                  Это реализовано в виде подхода и методологии в том же стандарте ISO 81346. Есть аспект «функции». Есть аспект «продукт». В модели сначала реализуется схема «функций». Потом часть «функций» определяются в виде «продуктов». Причем водной модели могут быть и элементы «функция»+ «продукт», может быть элемент «функция». Это два аспекта, только один из которых обязательный. Но чем ближе к «воплощению», тем больше элементов для которых описано и «функция» и «продукт». Например, в схеме автоматики может быть «Перекачка» (функция на схеме). И есть «Хранение» (тоже функция). В начале проектирования только функции. Потом добавляется аспект «продукт». Для элемента «Перекачка» указывается «Насос типа НШ». А для «Хранения» еще нет такого «продукта». И ничего, все на одной схеме спокойно живет. Реализация такой многомерной методологии есть в нескольких продуктах. Для электрики, автоматики, гидравлики, строительства, механики можно применять ePlan. Есть иные варианты.
                                                  Вопрос именно в методологии, если ее понимать — то работа на PLM системах становится очень простой. Если же пытаться автоматизировать свой «богатый инженерский опыт» на основе ГОСТов, ЕСКД, ЕСТПП и прочего бреда типа 34 стандарта, то все грустно… ГОСТы, ЕСКД, ЕСТПП 34 стандарт — все это прекрасные разработки. Были. Лет 30-40 назад. Теперь же их требования и методология — не более, чем один из малозначительных аспектов в методологии «системного подхода».
                                                    0
                                                    Рад, что Вам оказались близки мои наблюдения:)
                                                    Спасибо за отсылку на материалы. Нужно будет ознакомиться. В личку может скинете также парочку материалов, которые посчитаете полезными?! А про системное мышление мне уже сказали. Не думал, что подобные вещи уже описывались, думал, что это только мой майндсет)
                                                      0

                                                      Всегда рад поделиться информацией и знаниями. Вы увидели и обобщили свой опыт. То, что подобный опыт есть у иных людей — это тоже так. Обычно до подробных обобщений и мыслей на всей земле доходит 200-500 человек одновременно. Мыслят подобно, или похожие проблемы решают. Или магия:) фиг его знает. Лично мне нравится методология, которая собрана в системном подходе и в стандартах ISO. Да и альтернативы нет, если что. Поэтому приходится копать.

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

                                                  Самое читаемое