Здравствуйте, Erop, Вы писали:
L>>Всегда можно выбрать подход и базис для тестирования, даже если полноценное тестирование на макете провести по каким-то причинам нельзя. E>Что-то можно, но в целом не получится без "прогонов в железе"
Симуляторы и эмуляторы изобрели даже не в прошлом веке.
E>То, что ты пишешь — всё правильно, если доступно.
Почти все доступно почти всегда. Было бы желание.
Re[26]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
L>>Скорее, где поленились остальные 90% хоть как-то формализовать E>Что значит "поленились"? Дорого или вообще не понятно как...
Поленились — значит поленились. "Дорого" — годная отмаза. Только на круг выходит почему-то дороже. А "или вообще непонянтно как" — так нужно нанимать людей, которым понятно, "как".
E>Давай ты расскажешь как ловца писем террористов на 100% формализовать?
Извини, но теперь только за деньги. Мне мое время нынче слишком дорого, чтобы бесплатно заниматься тем, за что людям платят хорошие деньги.
Даже если задача на 100% не формализуется, это не повод не попытаться формализовать ее на достижимые 80(79, 65, 95)%.
Re[31]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
E>>Часто это просто готовый Фреймворк...
L>Тогда, простите, что тут тестировать? Фреймворк?
Работу фильтра...
Я про то и говорю, что есть задачи, где юнит-тестирование малоактуально...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[31]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Какая из? AI на базе некоего абстрактного фреймворка или kick_ass_washing_machine?
Давай возьмём задачу сделать прототип ловца писем терроритстов на лазаньи на глубоких нейросетях?
Что бы ты там юнит-тестами и вообще тдд разрабатывал?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[34]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
E>Но мы же не про железо, а про рулящее им ПО?..
ПО никакого отношения к успешности стиральной машины не имеет. Конечно, плохим ПО можно испортить очень хорошую вещь, но в принципе хорошие стиральные машины до сих пор могут не иметь вообще никакого ПО.
Re[33]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Совершенно серьезно. Ты ж хочешь юнит-тест на основе критерия "юзеру нравится". Дай мне юзера, которого можно закоммитить в репозиторий — будет тебе и такой тест
Не, я хочу тест того, что юзеру понравится, и разработку направлять в эту сторону.
А юнит-тест и вообще TDD юзать или чего иного -- вопрос осознанного выбора уже. IMHO тут юнит-тесты малополезны.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[34]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
E>Это, скорее всего, must have, но это уже вопрос проектирования. И все эти запчасти, скорее всего есть уже готовые вообще.
Воот. Must Have!
и эти мастхевы есть вполне формализуемые критерии. Без удовлетворения которых тестировать конечный продукт вообще смысла нет.
Из таких мастхевов почти любой программный продукт обычно состоит чуть менее, чем полностью.
Re[29]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
E>>Что-то можно, но в целом не получится без "прогонов в железе" L>Симуляторы и эмуляторы изобрели даже не в прошлом веке.
Симуляторы/эмуляторы чего? ТТ-движка и системы рулей?
L>Почти все доступно почти всегда. Было бы желание.
Вопрос цены/точности эмуляции...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[32]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
L>>Возможно, только не в ту сторону, о которой ты подумал.. Тем более, что имхо сканирует не фотошоп, а драйвер сканера. E>Фотошоп управляет драйвером. E>Так скока типов датчиков? Сканеров тысяч 5 есть, если не больше...
Фотошоп управляет одним унифицированным драйвером. Извини, младенцев обижать врослым людям не пристало.
Re[30]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
L>>Симуляторы и эмуляторы изобрели даже не в прошлом веке. E>Симуляторы/эмуляторы чего? ТТ-движка и системы рулей?
Да. Даже если этот симулятор на 100% наивен и не отражает и 5% реального положения дел, он полностью себя оправладет, когда поможет выяснить, что скорости реакции алгоритма на данные от датчиков не хватает. Или показать, что в некоторых условиях алгоритм выдает слишком грубые команды, что приведет к дестабилизации и разрушению. Или что интервал ожидания фидбека слишком короткий. Дофига всяких забавностей можно выяснить на основе наивных симуляторов. И это всегда дешевле, нежели потом ковыряться ножичком в обугленных останках изделия.
К примеру, промышленный симулятор Боинга не умеет симулировать поведение самолета в случае отказа всех двигателей. Но почему-то пилотов не перестают на нем тренировать.
L>>Почти все доступно почти всегда. Было бы желание. E>Вопрос цены/точности эмуляции...
Найти ошибку с помощью самого наколенного симулятора всегда дешевле.
Re[34]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, _hum_, Вы писали:
__>>>кстати, "дебаггинг" не только работа под дебагером, но и просто поиск ошибок в коде. L>>Если же вести "просто поиск", то зачем тогда ждать компиляции?
__>потому что их надо исправить и проверить, что после исправления все заработало, как надо
И как же это "проверить" осуществляется?
Re[27]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, _hum_, Вы писали:
__>>тоже, можно примеры, когда он лишний?
E>Ну вычматы, например...
и в каком смысле он там лишний? вот, например, какой-нить метод ньютона у вас при реализации расходится. ну, и? какие там тесты помогут вам выявить ошибку в знаке (описку) ?
Re[27]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, Erop, Вы писали:
E>>Про пред/пост-условия что-то слышал?
L>Мы, кажется, на разных языках говорим. Юнит-тесты делают намного больше, нежели ты можешь добиться от самых хитрых ассертов.
landerhigh,а можно в двух словах объяснить, чем все-таки тесты принципиально отличаются от "навороченных ассертов"? (не беря во внимание TDD, ибо это уже совсем из другой оперы)
Re[27]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
E>>Ты правда не можешь понять, что надо написать, пока не написал тесты?
L>Нет, я обоснованно считаю написание кода без тестов напрасной работой.
1) Понятие "тесты" оч. широкое. Мы всё ещё о юнит-тестах или о любом способе запустить разрабатываемый код?
2) Ты сделал несколько иное утверждение, что понять что и зачем делать, без тестов нельзя...
L>Мы, кажется, на разных языках говорим. Юнит-тесты делают намного больше, нежели ты можешь добиться от самых хитрых ассертов.
Тем не менее, примерно ту же задачу — фиксацию пред/пост условий и контроль стабильности, они таки решают...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[33]: Долгая компиляция на с++ - смерть для больших проект
E>>Давай ты расскажешь как ловца писем террористов на 100% формализовать?
L>Извини, но теперь только за деньги. Мне мое время нынче слишком дорого, чтобы бесплатно заниматься тем, за что людям платят хорошие деньги.
угу-угу... Я и говорю, что слишком дорого
L>Даже если задача на 100% не формализуется, это не повод не попытаться формализовать ее на достижимые 80(79, 65, 95)%.
Мы всё ещё о ТДД и юнит-тестах?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[35]: Долгая компиляция на с++ - смерть для больших проект
Здравствуйте, landerhigh, Вы писали:
L>ПО никакого отношения к успешности стиральной машины не имеет. Конечно, плохим ПО можно испортить очень хорошую вещь, но в принципе хорошие стиральные машины до сих пор могут не иметь вообще никакого ПО.
Не могут, так как хорошие алгоритмы движения барабана — один из аспектов "хорошести" машины...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Долгая компиляция на с++ - смерть для больших проектов?
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, _hum_, Вы писали:
SaZ>>>Когда работал в Варгейминге (проект wot blitz), да и не только там, у нас в команде была позиция, которая так и называлась — build engineer. Собственно сейчас, средствами CMake, танчики собираются под всё (ios/win/android + все десктопы). У всех стоит IncrediBuild. 20 минут — полная пересборка проекта (без конвертации ресурсов).
__>>и вы считаете это естественным? а что будет через пару лет, когда объем проектов во много раз возрастет?
SaZ>Конечно. Свою карьеру я начинал в Епаме. Там для нашего проекта была целая команда билд инженеров. А ещё devops-ы есть.
то, что есть де-факто, не значит, что это естественно раньше наверное тоже отдельные должности были по набиванию перфокарт, и что?
SaZ>В вашем же случае получается так: вы заранее знаете о том, что сложность проекта будет нелинейно расти в течение нескольких лет, но всё равно не хотите выделить должные ресурсы на проработку архитектуры.
нет, не так. я НЕ ЗНАЛ, что скорость роста времени компиляции от роста проекта такая нелинейная, потому это и вызывало во мне соответствующие вопросы — в первую очередь, как же тогда большие проекты разрабатываются.
SaZ>>>Если у вас в одиночку получился столь большой проект, что вас парит время комипляции — то что-то тут не то. Или плохо накодили или не туда двигаетесь. Где-то тут, несколько лет назад, пробегал этюд товарища Nikov (правда для C#). Как обычным дженериком на 5 аргументов нагенерить 25 метров кода и ждать компиляции более 7 минут. Жаль не могу найти.
__>>ну и? что в таком случае делать? __>>да и вообще, почему программиста должны заботить проблемы компилятора, и он должен знать все эти нюансы с тем, где он как-то там проходит, что подключает и проч., чтобы не дай бог не ввести его в глубокую рекурсию.
SaZ>В вашем понимании программист — это кодер. Таких, конечно, не должны заботить проблемы компилятора. Такие обычно делают всякие несложные фронтэнды на пхп/асп на аутсорс. SaZ>В моём понимании программист — это инженер. Это человек, который способен спроектировать и реализовать систему, которая будет работать. А при наличии требований к масштабированию — спроектировать хорошую архитектуру.
в моем понимании тоже. обратите внимание, вы НИГДЕ не указали, что программист должен знать особенности компиляции. всюду участвуют только особенности языка и исполнителя (машины). промежуточное звено, ака компилятор, вынесен вами за скобки.
вот об этом я и говорю, почему разработчик должен зависет и знать особенности выносимого за скобки, чтобы реализовать нормальную работающую систему?
ну это сродни тому, что повар должен уметь разбираться, как работает микроволновка (на каком клистроне, как испускающем волны, в каких местах узлы стоячих волн и проч.), чтобы приготовить вкусное блюдо.
SaZ>Например, в серьёзном геймдеве (да и не только) нечего ловить, если вы не знаете, что такое thiscall / fastcall / stdcall и т.п, если не понимаете, зачем нужен и когда нужен inline. Если не знаете, что такое кэш-мисс или конвеер команд в процессоре. Вроде бы это всё и не нужно, чтобы писать код на С++, но специалист тем и отличается от кодера-любителя, что понимает, как работает система.
это тоже все относится к языку и исполнителю алгоритма, но никак не к компилятору.
