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