Когда я был маленький , мы изучали в институте пораждение смутного гения Вирта - Модулу-2 . Там яйцеголовые изобрели всякие интерфейсы , эту раздельную компиляцию, сборку, линковку и нам студентам вдалбливали - что сначала интерфейс модуля ,его спецификация , а потом имплементация , прошли годы и яйцеголовые додумались до DI , это эволюция этой идеи (которую эксплуатировали бородатые парни, что писали на Си последние 60 лет в *.h файлах, они жили и не тужили без этого DI пописывая скрипты для линковщика ) короче CA я думаю не может без DI. если у вас нет точки в приложении где , вы собираете все проекты воедино, и говорите как разрешать зависимости у вас точно не CA . А пример . ну за пару строк кода не скажешь , СA Это вот как минимум три Проекта в решении . по проекту на слой. я люблю интерфейсы тоже в отдельный проект выносить (Что бы в имплементации лишнего не тянуть . ) А так, в точке сборке обычно прописываются как разрешать сотни интерфейсов какими имплементациями. И есть где то проект в приложении который содержит все ссылки на проекты за исключением тестовых и интерфейсы которые есть у вас в приложении .
Заменить одну базу на другую? Серьёзно? Вот это один из самых нелепых аргументов в пользу CA. Это вот требуется да сейчас, когда все пересаживаются с Mssql на Postgre SQL. Во первых это специфический случай, никто и не мог подумать что такое произойдёт , других причин для обмена шила на мыло за кучу денег я не вижу. 2 даже с CA и красиво оформленым persistence layer перезд без тестов в интеграции с базой не полетит и приведёт к тоннам трудновылавливаемых багов. Вообще тезис, что готовится к перезду из нового дома в гипотетический дом в будущем нужно на стадии проекта мне кажется сомнительным:)
Вообще Traceabilty это связка требование <->код <-> автотест если в проекте поддерживают информацию о связки код - требование , то связка Требования - Тест может быть востановлена автоматически , при автоматическом сборе покрытия кода. Вообще всё это нужно для упращения регрессионого тестирования, чтобы при изменении требований, и имплементации этих изменений в коде - найти точно то что нужно пере тетестировать. В общем всё это часть науки об управлении изменений требований. А требованиями и их изменениями почти никто не управляет - только в Авиации и critical software . Просто в других областях низкий уровень зрелости программных коллективов и считается что это очень дорого, а на само деле бардак (Печкин "У вас что средств не хватает ?" , Матроскин:" средства у нас Есть! У нас ума не хватает!" ) . Я видел реально как обеспечиавалась Traceabilty - в коде в любом загаловке метода класса , документируется ссылки на требования (обычно это текстовый Trace tag типа REQ123619.25723890.9 ) в любой момен разработчик читая код может найти требование которе имплементируется этим кодом . На код ревью регулярно выставляются замечания типа не обеспечена трасебилити - раззработчик разработал код , а ссылки на требования не проставил или их нет . в тестах , рядом с тестовыми данными , кладётся вместе описания автотеста "Данный тест проверяет REQ123619.25723890.9 часть 3 что при нажатии клавиши смыва и отсутсвии воды в бачке унитаз высвечивает Exception в лог НетВодыException и ничего не смывает " в протоколе теста можно найти записи PASS/FAIL даного теста и быстро найти код , При анализе (ревью ) протоколов теста и анализе покрытия можно посмотреть правдали этот код на эти требования , правдали этот код на эти требования, при фэйле теста можно найти быстро код который изменили и зафэйлил тест . и собстваенно при доработках выделить набор тестов которые нужно написать , перепрогнать на регрессионном тестировании изменений.
Код стандарт должен содержать принятые в компании практики
Типа использовать только такой метод депеденси резолвера и почему. Какие исключения из правил. Или например не должны персональные данные пользователей утекать в логи. И т.д.
Этот набор правил должен постоянно пополняется, а код стандарт постоянно исправляться , как результат анализа часто повторяющихся, багов, рантайм факапов , замечаний ревьеров.
У ревьера должен быть чек лист что и как должно быть проверено на ревью.
Часто ревью быстрее и дешевле тестирования находит потенциальные факапы. Всё это относится к мероприятиям обеспечения качества кода. Возможно часто к ревью надо привлекать тестировщиков и аналитиков.
Да на ревью имхо надо приглашать не только старших но и данных и одноуровневых коллег. Это позволяет выравнивать общий уровень разработчиков в коллективе, позволяет им работать в одном стиле.
Выложите уже ссылку на код в git с хелперами для этого пайплайна. Необязательно дотачивать до совершенства, комьнити и доточит. Тем более вроде у вас всё уже полгода в продакшоне работает. Или по другим причинам код зажали?
Интересно, что в статье ничего не говорится про сбор покрытия клиентского и BE кода. По моему мнению, большое количество мёртвого, не используемого кода становится проблемой для больших проектов, и такая комплексная автоматизация могла бы анализировать и находить участки кода в которые управление не доходит. А это значит либо этот код не нужен — устарел или на него нет ещё теста либо нет требований на этот участок кода.
В 70 годы было полно инженеров, которые чертили за кульманами детали, собирали эти чертежи в сборки, по чертежам вытачивали реальные детали и в конце концов собирали большую ракету, и возникла мысль что также можно поступить и с производством software
Нарисовать sofware requrement (чертёж детали) и написать код по требованиям (выточить деталь) проверить соответствие кода требованиям и будет работать также как как в производстве из железяк.
Но тут возникла проблемка. чертёж детали стал настолько же сложным как и сама деталь. Модель стала сложна так же как её реализация в коде, проверить что реализация соответствует модели можно только если ещё раз её реализовать иначе тесты утопают в бесконечном количестве тестовых примеров и их результатов и вообще не понятно то что зафиксировано в требованиях это то, что нужно непосредственно заказчику.
Все до сих пор в тупике. Ну просто это не работает и всё. Можно покрыть код тестами на 100% по MC/DC но это не даст гарантии что требования реализованые в коде есть имплементация скрытых, потаённых и ещё не высказанных желаний потребителей этого SW.
Есть методики которые позволяют увеличить надёжность того что реализовано( например ). Но цель их не верификационные / валидационные процессы по отношению к артефактам возникшим в процессе разработки и не какое-то формальное доказательство соответствия одного другому, а доскональное изучение человеком в ручном режиме того что делает программный комплекс.
Не правильной дорогой идёте товарищ Билл.
Не верю, что водород полученный от сжигания фекалиев и отправленный в топливную ячейку может возместить хотя бы 0.1% процента энергии потраченной на нагревание и дистилляцию воды из ста грамм мочи или этот унитаз только для твёрдых отходов?
Эта проблема давно решена есть достаточно эффективные ЛОС, в том числе и энергонезависимые. Имхо, нужен ветрокомпрессор с ветроколесом полметра в радиусе который будет кормить аэробные бактерии кислородом которые с удовольствием съедят всю органику производимую 4-5 людьми в сутки. Естественно нужно, изолировать всё это добро от сточных вод, а сливать только отреагировавшее, всё это можно умножить на тёплый климат Индии и подключив анаэробных термофилов (например в первом танке ) можно ещё и метан вырабатывать для плиты, кроме удобрений.
news.google.ru новостной агрегатор? я так понимаю он сразу становится вне Росийского закона, т.к. роскомнадзор его не контролирует. или закон касается только агрегаторов в зоне Ru? Нипонятна…
Кажется вы описали какого-то сферического тестировщика вакууме который в конце концов становится лидером команды. В общем какой-то сомнительный план и черезмерная мотивация. В жизни тестировщик, который тестирует руками не имеет времени на самообучение — он в яме постоянных задач — у него не хватает времени на самообучение. Автоматизированные тесты очень дороги в поддержке, и задач, в которых цена ошибки настолько велика чтобы оплачивать поддержку автотестов не так много и все они либо в банковском секторе либо в критическом по типа авиации /медицины/ атомные станции etc.
И переходить с уровня на уровень практически не возможно- только для очень энергичных электронов — возможно сразу только впрыгивать на потенциальный уровень авто тестировщика например. Но мне кажется это удел ребят которые спрыгнули с энергетического уровня разработчиков кода.
Завидую — очень интерестная работа!
скриншот
RedWave v 1.0.0 приложение RedWaveNodeHost
Вижу на треке вылетевшие точки, предполагаю что датчик принял не основной сигнал от одного из буёв, а отражённый от какого-то подводного препятствия я прав?
как с этим боретесь? ведь если датчик принял отражённый сигнал а не основной — расстояние до датчика будет расчитано с ошибкой.
Я так понимаю на приёмник с буя должна прийти информация об реальном положении буя и времени когда отправлен сигнал, эта вся информация передаётся по звуковому каналу как осуществляется разделенние канала?
Почему буя необходимо четыре вроде для позиционирования достаточно 2? (зная с какой стороны пришёл сигнал )
Когда я был маленький , мы изучали в институте пораждение смутного гения Вирта - Модулу-2 . Там яйцеголовые изобрели всякие интерфейсы , эту раздельную компиляцию, сборку, линковку и нам студентам вдалбливали - что сначала интерфейс модуля ,его спецификация , а потом имплементация , прошли годы и яйцеголовые додумались до DI , это эволюция этой идеи (которую эксплуатировали бородатые парни, что писали на Си последние 60 лет в *.h файлах, они жили и не тужили без этого DI пописывая скрипты для линковщика ) короче CA я думаю не может без DI. если у вас нет точки в приложении где , вы собираете все проекты воедино, и говорите как разрешать зависимости у вас точно не CA . А пример . ну за пару строк кода не скажешь , СA Это вот как минимум три Проекта в решении . по проекту на слой. я люблю интерфейсы тоже в отдельный проект выносить (Что бы в имплементации лишнего не тянуть . ) А так, в точке сборке обычно прописываются как разрешать сотни интерфейсов какими имплементациями. И есть где то проект в приложении который содержит все ссылки на проекты за исключением тестовых и интерфейсы которые есть у вас в приложении .
Заменить одну базу на другую? Серьёзно? Вот это один из самых нелепых аргументов в пользу CA. Это вот требуется да сейчас, когда все пересаживаются с Mssql на Postgre SQL. Во первых это специфический случай, никто и не мог подумать что такое произойдёт , других причин для обмена шила на мыло за кучу денег я не вижу. 2 даже с CA и красиво оформленым persistence layer перезд без тестов в интеграции с базой не полетит и приведёт к тоннам трудновылавливаемых багов. Вообще тезис, что готовится к перезду из нового дома в гипотетический дом в будущем нужно на стадии проекта мне кажется сомнительным:)
Вообще Traceabilty это связка требование <->код <-> автотест если в проекте поддерживают информацию о связки код - требование , то связка Требования - Тест может быть востановлена автоматически , при автоматическом сборе покрытия кода.
Вообще всё это нужно для упращения регрессионого тестирования, чтобы при изменении требований, и имплементации этих изменений в коде - найти точно то что нужно пере тетестировать.
В общем всё это часть науки об управлении изменений требований. А требованиями и их изменениями почти никто не управляет - только в Авиации и critical software . Просто в других областях низкий уровень зрелости программных коллективов и считается что это очень дорого, а на само деле бардак (Печкин "У вас что средств не хватает ?" , Матроскин:" средства у нас Есть! У нас ума не хватает!" ) .
Я видел реально как обеспечиавалась Traceabilty - в коде в любом загаловке метода класса , документируется ссылки на требования (обычно это текстовый Trace tag типа REQ123619.25723890.9 ) в любой момен разработчик читая код может найти требование которе имплементируется этим кодом . На код ревью регулярно выставляются замечания типа не обеспечена трасебилити - раззработчик разработал код , а ссылки на требования не проставил или их нет .
в тестах , рядом с тестовыми данными , кладётся вместе описания автотеста "Данный тест проверяет REQ123619.25723890.9 часть 3 что при нажатии клавиши смыва и отсутсвии воды в бачке унитаз высвечивает Exception в лог НетВодыException и ничего не смывает "
в протоколе теста можно найти записи PASS/FAIL даного теста и быстро найти код , При анализе (ревью ) протоколов теста и анализе покрытия можно посмотреть правдали этот код на эти требования , правдали этот код на эти требования, при фэйле теста можно найти быстро код который изменили и зафэйлил тест . и собстваенно при доработках выделить набор тестов которые нужно написать , перепрогнать на регрессионном тестировании изменений.
Желательно иметь код стандарт и чек-лист реклама
Код стандарт должен содержать принятые в компании практики
Типа использовать только такой метод депеденси резолвера и почему. Какие исключения из правил. Или например не должны персональные данные пользователей утекать в логи. И т.д.
Этот набор правил должен постоянно пополняется, а код стандарт постоянно исправляться , как результат анализа часто повторяющихся, багов, рантайм факапов , замечаний ревьеров.
У ревьера должен быть чек лист что и как должно быть проверено на ревью.
Часто ревью быстрее и дешевле тестирования находит потенциальные факапы. Всё это относится к мероприятиям обеспечения качества кода. Возможно часто к ревью надо привлекать тестировщиков и аналитиков.
Да на ревью имхо надо приглашать не только старших но и данных и одноуровневых коллег. Это позволяет выравнивать общий уровень разработчиков в коллективе, позволяет им работать в одном стиле.
Отличный коммент, только слово "переехай" коробит
Нарисовать sofware requrement (чертёж детали) и написать код по требованиям (выточить деталь) проверить соответствие кода требованиям и будет работать также как как в производстве из железяк.
Но тут возникла проблемка. чертёж детали стал настолько же сложным как и сама деталь. Модель стала сложна так же как её реализация в коде, проверить что реализация соответствует модели можно только если ещё раз её реализовать иначе тесты утопают в бесконечном количестве тестовых примеров и их результатов и вообще не понятно то что зафиксировано в требованиях это то, что нужно непосредственно заказчику.
Все до сих пор в тупике. Ну просто это не работает и всё. Можно покрыть код тестами на 100% по MC/DC но это не даст гарантии что требования реализованые в коде есть имплементация скрытых, потаённых и ещё не высказанных желаний потребителей этого SW.
Есть методики которые позволяют увеличить надёжность того что реализовано( например ). Но цель их не верификационные / валидационные процессы по отношению к артефактам возникшим в процессе разработки и не какое-то формальное доказательство соответствия одного другому, а доскональное изучение человеком в ручном режиме того что делает программный комплекс.
Не верю, что водород полученный от сжигания фекалиев и отправленный в топливную ячейку может возместить хотя бы 0.1% процента энергии потраченной на нагревание и дистилляцию воды из ста грамм мочи или этот унитаз только для твёрдых отходов?
Эта проблема давно решена есть достаточно эффективные ЛОС, в том числе и энергонезависимые. Имхо, нужен ветрокомпрессор с ветроколесом полметра в радиусе который будет кормить аэробные бактерии кислородом которые с удовольствием съедят всю органику производимую 4-5 людьми в сутки. Естественно нужно, изолировать всё это добро от сточных вод, а сливать только отреагировавшее, всё это можно умножить на тёплый климат Индии и подключив анаэробных термофилов (например в первом танке ) можно ещё и метан вырабатывать для плиты, кроме удобрений.
И переходить с уровня на уровень практически не возможно- только для очень энергичных электронов — возможно сразу только впрыгивать на потенциальный уровень авто тестировщика например. Но мне кажется это удел ребят которые спрыгнули с энергетического уровня разработчиков кода.
скриншот
RedWave v 1.0.0 приложение RedWaveNodeHost
Вижу на треке вылетевшие точки, предполагаю что датчик принял не основной сигнал от одного из буёв, а отражённый от какого-то подводного препятствия я прав?
как с этим боретесь? ведь если датчик принял отражённый сигнал а не основной — расстояние до датчика будет расчитано с ошибкой.
Я так понимаю на приёмник с буя должна прийти информация об реальном положении буя и времени когда отправлен сигнал, эта вся информация передаётся по звуковому каналу как осуществляется разделенние канала?
Почему буя необходимо четыре вроде для позиционирования достаточно 2? (зная с какой стороны пришёл сигнал )