Возможно я не точно выразился. Мы знали как устроен источник сигнала, знали, что генератор сигнала изолирован от трубопровода и клапана.
В статье я хотел сказать, что было очень сложно диагностировать дефекты в клапане. Для этого приходилось полностью снимать характеристики в различных условиях, отслеживать изменение характеристик по мере износа клапана и т.д.
Чтобы разобраться с клапаном, мы сначала довели до ума всё остальное.
Повторюсь, оптроны ставились не ради гальванической развязки, это был хак. Первичный генератор сигнала устроен так, что гальваническая развязка там не нужна. Втыкать развязку повсеместно «на всякий случай» и в ущерб метрологическим характеристикам не вижу смысла.
Он не для формирования выхода из сна. В статье указано, что он формирует ворота, управляющие таймером. Триггер позволяет остановить/запустить таймер не пробуждая микроконтроллер. Это позволило значительно снизить погрешность измерений.
С компаратором мы можем точно задать на каком уровне напряжения будет запущен таймер. Для оптрона это не так, он откроется когда откроется. Можно сказать, что скорее всего он будет открываться на одном и том же напряжении, но это не совсем так. Компаратор однозначно лучше с точки зрения повторяемости. К тому же, на первой схеме стоял стабилитрон, который задирал уровень открытия. Он там играл страховочную роль, чтобы избежать ошибочного срабатывания, вызывающего переворачивание выходного сигнала со смещением (из-за дополнительных всплесков после открытия/закрытия). Так вот, во второй схеме задирать уровень не обязательно, т.к. микроконтроллер сам управляет выходным сигналом. Был разработан функционал программной самодиагностики, восстанавливающий работоспособность схемы в случае ошибки. Отсутствие стабилитрона очень важно, т.к. чем выше уровень — тем более пологий фронт, тем больше погрешность.
Нет, развязка была связана с особенностями сигнала (отрицательное напряжение), этот момент обошли оптроном. Во второй схеме этот же момент решается смещением. Девайс прошёл все испытания и используется. Жалоб на наводки и подобные странности пока не поступало.
Железо-электроника: подать сигнал с обоих на два входа осциллографа; понаблюдать полчаса, не скачут ли фронты.
Были скачки фронтов, но такое исследование проводилось когда команда была сильно разобщена. Схемотехник говорил, что клапан даёт нестабильный/некачественный сигнал, конструктор говорил, что так-то оно так, но надо бы обрабатывать и такой сигнал тоже. Схемотехник понимал, что для этого будут нужны компараторы, а почему он их не хотел, я уже писал в статье. В общем ему было проще наехать на конструктора и сказать, чтобы он чинил клапан. Потом пришли мы, показали, что компаратор можно и проблема отвалилась.
Электроника-софт: подать меандр на пин прерывания, понаблюдать полчаса, не сходит ли контроллер с ума.
В течение получаса в среднем мы в любом случае получим нормальные показания для меандра. А то, что значения для каждого импульса отличаются на 2-5% — можно было сказать, что генератор меандра косячит. Мы могли запилить свой генератор и провести тестирование, но заказчику больше понравился вариант с человеком-оркестром, который в короткий срок проанализировал проект, показал где косяки и как их исправить.
Кстати упустил момент в статье, программист также считал, что смещение допустимо, даже если вносит погрешность. Когда-нибудь всё равно усреднится и всё будет норм. Только вот испытания были не столь долгосрочны и ничего не усреднилось, так что заказчик увидел, что расходомер не работает
Это не всегда так. В частности в этом проекте ключевой фигурой был инженер-конструктор. Именно он придумал расходомер и принимал ключевые решения. Программист и схемотехник играли роль помощников, которые должны были добавить к устройству мозги, преобразующие показания клапана в осмысленные числа. Почему так сложилось, что проектом руководит человек, ничего не понимающий в программировании — тема отдельного разговора.
В сложившейся ситуации человек-оркестр не брал руководство на себя, он лишь решил возникшие проблемы в реализации и коммуникации внутри проекта. Проектом продолжал руководить инженер-конструктор.
Программист рассуждал довольно просто. Микроконтроллер всегда просыпается в равных условиях. Т.е. запускает один и тот же осциллятор, включает одну и ту же периферию, так что и задержка должна быть равномерной. К тому же, просмотрев даташит, программист увидел, что задержка довольно таки небольшая. Он не рассчитывал, что она внесёт столь ощутимый вклад, чтобы обсуждать этот вопрос с метрологом. Всё-таки чтобы понимать что важно с точки зрения метрологии, а на что можно забить, нужно иметь какое-то представление о погрешностях и как их правильно считать.
Один мой коллега тоже так говорит. Однако, он еще не создал такого монстра, и вряд ли создаст.
Тут есть определенные проблемы, которые можно перечислять довольно долго. Одна из них заключается в том, что разработчики перестанут понимать друг друга. Смотрю я ревью, например, с хорошо отформатированным кодом, и говорю, строки с 130 — 140 — такие-то проблемы. Разработчик смотрит в свой код, а у него 100 строк в этом файле. Или еще кейс: просит меня разработчик помочь ему разобраться в моем коде — смотрит в мой монитор и говорит: а у тебя все не так, я ему говорю: пойдем посмотрим у тебя, раз не так. смотрю в его файл и тоже ничего не понимаю, потому что у парня помимо всяких своих прихотей по настройке внешнего вида ide, длина строк 55 символов вместо 120, к примеру. Ну это из самого безобидного)
Соответсвенно постоянно надо мапать 1 стиль на другой, разводить зоопарк из стилей. По моему личному убеждению — поддержка единого кодстайла на 1 проекте — вещь необходимая и обсуждению не подлежит. У всех разработчиков свой бекграунд, кто-то пришел из руби, кто-то из пхп, кто-то вообще пишет под настроение… если каждый будет вносить бедлам в проект — в команде будет много холиваров. Это не конструктивно и вредит разработке. Это долгий диспут, я считаю.
В общем, да это есть идея, но она крайне сырая и мы вряд ли можем ожидать ее воплощения в ближайшие годы. Ну и опять же, если не указывать разработчику, что его кодстайл далек от идеала, он не станет интересоваться бестпрактисами, оптимизацией выполнения и прочим.
Это философия, на мой взгляд. Кто-то любит чистоту и порядок, а кому-то плевать. Но тех кому плевать — обычно мало. Опять же, те, кто любит чистоту, делятся на тех, кто будет ее наводить, и на тех, которые терпеть не могут убирать. Первые берут веник, вторые — покупают робот-пылесос. Если вам плевать, с чем работать — то можете хоть минифицированный код писать;) В конечном итоге любой код должен быть человекочитабельным и однородным. По моему, оправдывать неряшливость отрешенностью — ну не ок. Но если вы познали дзен — ждем статьи о том, как не беспокоится об оформлении кода и как этого достичь)
Если я верно понял — Standard — 3й в списке пресетов. Набрать 2 команды и выбрать Standard в списке из 3х пунктов — не сложно. ESLint более универсален, он модульный, настраиваемый и мощный. Если вам нужна поддержка разного кодстайла в разных проектах — он нужен. Если у вас 1 стиль для всего — можно конечно же ограничится 1 библиотекой
Оформив весь код по единым правилам вы не повысите его качество.
Я писал, что единое оформление освобождает ресурсы разработчика и дает возможность замечать плохой код. И при ревью, и при разработке. Если такой код попадает в продакшн — очень жаль того, кто это пропустил/написал. Все же код нужно читать, а не просматривать.
Мозг так не работает. Он быстро обучается замечать важное и игнорировать несущественное.
К сожалению, действительность далека от желаний. На моем опыте ряд проектов, которые требовали погружения и понимания, и отсутствие оформления кода затягивало процесс разработки. Возможно, мы рассуждаем о проектах разной сложности. Если проект не сложный — согласен, игнорировать можно
Смотрите какая идея во всем этом — не подстраиваться под «хочу — пишу, хочу — нет» конкретного человека, а форматировать исходный код всегда до коммита, чтобы разработчик всегда видел отклонения, всегда видел принятый кодстайл. Настойка оформления кода и сам кодстайл вынесен за рамки ответственности программиста и присутствует независимо от его предпочтений.В конечном итоге программист будет следовать ему со временем. Плюс ко всему — например я провожу ревью через гитлаб. Если код который я вижу в гитлабе, отформатирован так же как в редакторе или IDE, с которым я работаю — мне нужно лишний раз настраиваться на чтение(об этом я писал в статье).
Да, это один из вариантов воркэраунда кодстайла для вебшторма, я упомянул тот, с которым приходилось сталкиваться чаще — а именно импорт из .jscsrc. и да, папку .idea после настройки нужно закомитить, чтобы не заниматься настройкой на других машинах.
Самое массивное с чем я сталкивался — это изменение окончания строк во всем файле. это выглядит стремно и я обычно такое возвращаю обратно и помогаю перенастроить гит(как правило это он), на сохранение текущих концов строк.
Если форматирование настроено изначально, то массивных изменений быть не должно. Если же делается глобальное форматирование — то как правило есть требование такие вещи делать в отдельных коммитах или отдельными мр, чтобы не блокировать и не усложнять кодревью.
В статье я хотел сказать, что было очень сложно диагностировать дефекты в клапане. Для этого приходилось полностью снимать характеристики в различных условиях, отслеживать изменение характеристик по мере износа клапана и т.д.
Чтобы разобраться с клапаном, мы сначала довели до ума всё остальное.
Были скачки фронтов, но такое исследование проводилось когда команда была сильно разобщена. Схемотехник говорил, что клапан даёт нестабильный/некачественный сигнал, конструктор говорил, что так-то оно так, но надо бы обрабатывать и такой сигнал тоже. Схемотехник понимал, что для этого будут нужны компараторы, а почему он их не хотел, я уже писал в статье. В общем ему было проще наехать на конструктора и сказать, чтобы он чинил клапан. Потом пришли мы, показали, что компаратор можно и проблема отвалилась.
В течение получаса в среднем мы в любом случае получим нормальные показания для меандра. А то, что значения для каждого импульса отличаются на 2-5% — можно было сказать, что генератор меандра косячит. Мы могли запилить свой генератор и провести тестирование, но заказчику больше понравился вариант с человеком-оркестром, который в короткий срок проанализировал проект, показал где косяки и как их исправить.
Кстати упустил момент в статье, программист также считал, что смещение допустимо, даже если вносит погрешность. Когда-нибудь всё равно усреднится и всё будет норм. Только вот испытания были не столь долгосрочны и ничего не усреднилось, так что заказчик увидел, что расходомер не работает
В сложившейся ситуации человек-оркестр не брал руководство на себя, он лишь решил возникшие проблемы в реализации и коммуникации внутри проекта. Проектом продолжал руководить инженер-конструктор.
Тут есть определенные проблемы, которые можно перечислять довольно долго. Одна из них заключается в том, что разработчики перестанут понимать друг друга. Смотрю я ревью, например, с хорошо отформатированным кодом, и говорю, строки с 130 — 140 — такие-то проблемы. Разработчик смотрит в свой код, а у него 100 строк в этом файле. Или еще кейс: просит меня разработчик помочь ему разобраться в моем коде — смотрит в мой монитор и говорит: а у тебя все не так, я ему говорю: пойдем посмотрим у тебя, раз не так. смотрю в его файл и тоже ничего не понимаю, потому что у парня помимо всяких своих прихотей по настройке внешнего вида ide, длина строк 55 символов вместо 120, к примеру. Ну это из самого безобидного)
Соответсвенно постоянно надо мапать 1 стиль на другой, разводить зоопарк из стилей. По моему личному убеждению — поддержка единого кодстайла на 1 проекте — вещь необходимая и обсуждению не подлежит. У всех разработчиков свой бекграунд, кто-то пришел из руби, кто-то из пхп, кто-то вообще пишет под настроение… если каждый будет вносить бедлам в проект — в команде будет много холиваров. Это не конструктивно и вредит разработке. Это долгий диспут, я считаю.
В общем, да это есть идея, но она крайне сырая и мы вряд ли можем ожидать ее воплощения в ближайшие годы. Ну и опять же, если не указывать разработчику, что его кодстайл далек от идеала, он не станет интересоваться бестпрактисами, оптимизацией выполнения и прочим.
Я писал, что единое оформление освобождает ресурсы разработчика и дает возможность замечать плохой код. И при ревью, и при разработке. Если такой код попадает в продакшн — очень жаль того, кто это пропустил/написал. Все же код нужно читать, а не просматривать.
К сожалению, действительность далека от желаний. На моем опыте ряд проектов, которые требовали погружения и понимания, и отсутствие оформления кода затягивало процесс разработки. Возможно, мы рассуждаем о проектах разной сложности. Если проект не сложный — согласен, игнорировать можно
Если форматирование настроено изначально, то массивных изменений быть не должно. Если же делается глобальное форматирование — то как правило есть требование такие вещи делать в отдельных коммитах или отдельными мр, чтобы не блокировать и не усложнять кодревью.