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

ответ ясен: тратить деньги на мифические проблемы надежности никто не желает, т.к. "возьмут и так - никуда не денутся". эта философия работает и на иностранных компаниях, за примерами далеко ходить не надо: чего стоит iPhone, который работал, если его держать в рукавице уж этот баг нельзя не заметить на этапе проектирования, если на самом деле озабочен НАДЕЖНОСТЬЮ. и уж тем более проглядеть во время тестирования, какое б оно там ни было - но включали же первые экземпляры в лаборатории?! однако, приняли решение СН,АЧАЛА СОРВАТЬ БАБКИ, а потом ПРЕДЛОЖИТЬ АПГРЕЙД или ЗАПЛАТКУ (патч в виде чехла и т.п.). тем более что за этот патч еще и дополнительные бабки поступят

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

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

Или другой пример. Датчик температуры определяет,к примеру с точностью до 0,125, но реальная функция состоит в том, что бы включить нечто при температуре Х и выключить при У - именно так и поступает человек, при Х - одевается, при У раздевается.

Вообщем, производители МК когда-то чокнули об этом и начали производить МК с большим числом АЦП внутри одного корпуса. Но мне хотелось полнее раскрыть принцип аналогового мышления. Если всё сводится к принятию решения да\нет, то стоит ли перелопачивать гигабайты?


Въедливый! А иначе зачем..?

Конечно, и сомнений быть не может. Отрицание этого факта - либо добросовестный самообман, либо лукавство, в зависимости от мотивов отрицающего.

Это уже вопрос качества тестирования. Грамотно составить тесты ничуть не проще, чем разработать алгоритм и закодировать его.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

У тебя есть опыт разработки контроллера СМА ?
Проблемой может оказаться реализация алгоритма управления мощностью двигателя при отжиме.

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Есть ведь и другие примеры - те же немцы с японцами... А легендарный "Роллс-Ройс" с безупречной ручной сборкой? Качество - не такой уж миф, если ему уделять должное внимание.

Конечно, без заморочек по части имиджа и чести живется легче, и не только у нас, на этот счет и дискутировать бесполезно. Понятно, что нагревать лохов куда прибыльнее, чем корпеть над шедеврами. Вопрос был в другом: что реально могут сделать те, кому действительно важно качество (да и репутация, чего уж греха таить).

Город у нас маленький, все на виду, разок облажаешься - потом долго отмываться придется. Да и ко всем это относится, наверное.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Это очень интересно, но, увы, доступной платформой для таких решений мы сегоня не располагаем. Предмет нашего обсуждения сейчас - как повысить качество кода при помощи тех инструментов, которые нам доступны уже сегодня (и желательно бесплатно)?

Качественный код, это не резьбу нарезать, тут более важен не инструмент, а способности программиста.

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

КАР. Вообще, стоит подумать, речь идёт больше о качественной среде программирования или о защищённой среде зарабатывания для программистов.

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

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

Выходов два: либо использовать среду автоматизированного тестирования, которая выполняет набор регрессионных тестов за секунды, либо вообще забить на тестирование болт. Куда ведет второй выход, понятно без комментариев.

Вообще есть у меня такой недостаток: я часто оцениваю мастера по его инструментам. Если у столяра молоток при каждом ударе соскакивает с ручки, на пиле не хватает зубьев, а лезвие стамески зазубрено, для меня это однозначно плохой мастер. Хороший всегда найдет возможность обзавестись правильными инструментами. Конечно, обратное неверно: ломастер с руками, растущими из тазобедренного сустава, может приобрести новенькие красивые инструменты и не знать, что с ними делать. Поэтому критерий чуть сложнее: 1) инструменты должны быть"правильные"; 2) мастер должен владеть ими в совершенстве. Лишь в этом случае можно говорить о качестве.

Хоть программисты и не нарезают резьбу, но этот критерий работает и для них. Одних способностей мало, нужны средства для их проявления.

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

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

Я сегодня восстанавливал Виндовс на компьютере у человека. Чисто технически, компьютер многократно более быстродейственный моего компьютера, но более новая версия Виндовс у человека, работает заметно медленней той версии Виндовс, что установлена у меня.
Да и вообще, если поставить рядом компьютер 2000 года и компьютер 2010 года, пользовательского различия в скорости работы системы можно не заметить. Я однажды демонстрировал людям, как Виндовс98 на 486 процессоре, загружается и открывает папки/файлы значительно быстрей, чем ВиндовсВиста на Коре2 процессоре. А ведь инструменты разработчика стали значительно совершенней

Вот бы не сказал. Разве нынешние фанерные скрипки лучше тех, которые делал Страдивари? Или, может, современные пианино с корпусами из прессованных опилок лучше тех, старинных, с бронзовыми подсвечниками, которые еще сохранились в некоторых семьях? Или же омерзительные клавишные самоиграйки Citizen, которые продаются чуть не в каждом супермаркете, лучше тех органов, на которых играл свои фуги Иоганн Бах?

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

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

Goldsmith а с какой целью вы интересуетесь ?
надежность для вас отсутствие багов в софте, или качество сборки?

Любые крайности чреваты, а истина всегда где-то между. Сошлюсь опять на свой скромный опыт. Делал плавучку для ST62XX . Конечно, ее оттестировать надо было сверхтщаельно, это не то что команда, выполняемая раз в год, да и то в високосный. Не стал искать жутконаучные средства, тем более инет был у меня медленный и не дома. Написал 2 проги : одна генерировала наборы данных ( полтысячи счел достаточным ), пропускал их через свою МК-прогу в симуляторе, данные скидывал в файл, и второй программой их анализировал. Все ОК! Нашел пару багов, потом все чисто. Поставил в прибор. И уже на первых минутах заметил, что он дурит. Поскольку новыми были эти подпрограммы из библиотеки, ясно, что дело в них. Закинул их опять в симулятор и пошел анализировать, включив голову. Прошел тщательно по всем точкам ветвления - и вот она, подлая. Редко встречающаяся комбинация, но в приборе в реалтайме эта п/п выполняется сотни тысяч раз, и он регулярно на нее натыкался.
Исправил - и доктор больше не нужен.

Конечно, я ретроград, и меня не нужно воспринимать всерьез.



MIF, Вы что, бывали у меня дома ? Впрочем, нет, там про какую-то женщину... Да и кот у меня двухглазый.

Основной мотив отлично сформулировал ARV: репутация, профессиональная честь. Я в сфере электроники и компьютеров кручусь ровно 30 лет (если начать отсчет с того момента, когда на втором курсе впервые переступил порог студенческой научной лаборатории). За это время удалось заработать авторитет и неплохую репутацию. Правда, основной мой опыт накоплен на противоположном от микроконтроллеров полюсе - в области корпоративных систем обработки информации. Полагаю, многие представляют себе уровень ответственности, цену ошибки и, соответственно, величину неприятностей в случае серьезного промаха. К тому же довольные клиенты наперебой расхваливают и рекомендуют всем знакомым, что расширяет горизонты. Что делают недовольные клиенты, тоже всем понятно.

Поэтому, когда вопрос касается качества проекта, для меня гораздо естественнее вопрос: "почему не интересуетесь?".

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

Сразу же оговорюсь: я полностью разделяю точку зрения многих оппонентов насчет того, что далеко не всегда и везде это нужно. Программу "Hello World!" или мигалку светодиодом можно сделать и без инструментов, и они действительно будут отлично работать. Но сегодня даже старшие модели ATmega не уступают по возможностям той же СМ-4, на которой в свое время решались весьма неслабые даже по сегодняшним меркам задачи. Про ARM даже и не говорю - просто фантастика, причем за копейки. Техника вполне позволяет решать более серьезные задачи, но разработка без поддержки - это дорого, медленно и ненадежно.

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

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

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

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

Кстати, при разработке "больших" программ испольтзуется методология Test Driven Design (TDD), при которой тесты пишутся раньше самого кода. На первый взгляд это кажется странновато, но это только на первый взгляд. При ее применении доктор вряд ли потребовался даже единственный раз. Есть прецеденты успешного применения TDD и для микроконтроллерных программ.

P.S. Не так давно на форуме один товарищ делился идеей создать ручной программатор - задавать данные тумблерами, такты генерировать кнопками... Над ним почему-то потешались. А ведь в сущности идея та же - делать вручную рутинные, не требующие особого интеллекта действия, на которые способен обычный жутконаучный программатор. Люди - загадочные существа: смеются над предметом, а повернешь предмет другим боком - воспринимают всерьез. А ведь суть-то остается та же.

Я не представляю себе существование такой мегаинтеллектуальной программы, которая декомпилирует прошивку ( ну, пусть даже по исходникам пробежится, выполнит работу за компилятора и линкера ), при этом невзирая на систему команд - она априори знает все системы, как существующие так и будущие, разберет логику программы ( при этом надо учесть, что у многих программеров эта логика вообще слабо просматривается, сам в молодости этим грешен был ), догадается, в какой точке ветвления какой набор данных должен быть - все это провернет и выдаст на блюдечке : " ошибка в 13-й строке, и вообще нужно было так писать : ...... , эх ты, кулема ! ". Если бы в те времена мне в пределах досягаемости попался такой ярый апологет автоматизации программирования, и я бы у него спросил : а нет ли у вас чего интеллектуального для моего Томсона, у которого даже команды СДВИГ ВПРАВО нет, и он мне ответил : есть, и работает не так глючно, как Протеус или 5-я версия Студии - неужели бы я стал лепить самопал вместо профессионального софта.?А иначе я бросился бы искать этот софт, пробовать - гуано, опять не то! - и опять искать - и так до конца жизни, вернее, до того момента, пока шеф пинком пониже спины не придал бы мне ускорение : мне нужен результат, а не твои заумствования.
Мы останемся при своих мнениях. Станок с ЧПУ - отличная вещь, однако иметь его в каждой слесарной мастерской - это перебор. IMHO .

Quis custodiet ipsos custodes?
любая программа потенциально может содержать ошибки. что будет, если спустя год существования какого-то автоматизированного инструментария тестирования вдруг выяснится, что в нем нашелся баг, который может поставить под сомнение результаты всех тестов, которые были сделаны с его помощью?

я понимаю, что это близко к выяснению, что было раньше - курица или яйцо... вопрос риторический...

Уважаемые Коты!
Прежде чем рассуждать на эту тему, хотелось бы опредлиться с типом ситемы и трбованиям к ее надежности, а бывает даже и безопасности. Т.к. подходы
и затраты могут отличаться весма и весьма существенно. Кроме того надо еще помнить о жизненном цикле ситемы, т.е. сколько времени вы ее обязаны сопровождать, развивать и т.д. Я предлагаю ограничить круг обсуждения проблемы для начала. Как вам такое предложение?

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

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

Здесь никого не вербуют в тоталитарную секту автоматических тестировщиков. Просто тема чуть вышла за привычные рамки: "не прошивается контроллер, что делать???" - "пропаяйте контакты" - "ура, все заработало!!!". Должно же быть какое-то разнообразие.