Новый тренд в интернетах: поклонение кондовости и тупости
Вот последний пример: http://vit-r.livejournal.com/739457.html
"Уравнение шредингера вредно, потому что не сводится к арифметике первого класса, а наши индусы-контракторы буквы и значки не понимают".
Не очень понимаю, откуда этот луддизм в последнее время вылез, неосиляторы что-ли решили занятся своим job security?
"Уравнение шредингера вредно, потому что не сводится к арифметике первого класса, а наши индусы-контракторы буквы и значки не понимают".
Не очень понимаю, откуда этот луддизм в последнее время вылез, неосиляторы что-ли решили занятся своим job security?
no subject
вот тут вы и попались! поздравляю, вы сели в лужу, публично.
1. можно легко написать тесты, покрывающие НЕКОТОРУЮ часть функциональности. Типа, "для галочки" - у нас тоже есть тесты, как у всех других пацанов.
2. во многих случаях - очень сложно написать тесты, покрывающие все возможные сценарии. Конечно, если у вас задача - посчитать число Пи с точностью миллион знаков после запятой, как можно быстрее - то тестирования несложно - вы просто сравниваете результат работы функции с эталонным. НО ТАК БЫВАЕТ ДАЛЕКО НЕ ВСЕГДА. Взять например шутер Crysis, в команде разработчиков которого я работал 4 года. Вы можете повторить ваш тезис "тестирование легко автоматизируются" - в отношении таких шутеров? Любые игровые сценарии? Вы понимаете что их - квинтиллионы?
3. кроме тестирования - то есть нахождения ошибок - еще есть такая весч как багфиксинг. И здесь вам скорость процессора нисколько не поможет. Только квалифицированные программисты способно БЫСТРО и ПРАВИЛЬНО фиксить баги. Более того - если у вас дофига легаси кода, с дурной архитектурой - то ситуация может быть запущено до такого состояния, что даже высококлассы спецы завязнут в бесконечных багфиксах, и легче будет просто с нуля переписать .
так что все эти байки "через 5 лет программистов будут учить в ПТУ" - мы уже слышали давным давно.
no subject
Гемдева это тоже касается.
И ещё вопрос не в том, чтобы заниматься багфиксингом, а чтобы писать так, чтобы минимизировать количество багов, запущенных в систему изначально. Особенно это касается нетривиальных побочных эффектов.
no subject
ок, расскажи мне как *легко* тестируются шутеры. с интересом послушаю.
no subject
no subject
хорошо, попробуем таки тебя разговорить - тесты бывают, среди прочих, внутренние (скажем, юнит тесты) и внешние, функциональные.
тему внутренних тестов обсуждать не будем. Сосредоточимся на внешних тестах, имитирующих действия игрока. Различных вариантов там получаются квинтилионы, потому что игрок может пойти за 10 минут игры совершенно разным образом, и в каждый раз все может нафиг закрэшится, из-за некого уникального сочетания конктерной игровой ситуации. Как здесь будем "ЛЕГКО" тестировать? В общих чертах плиз, саму идею.
no subject
no subject
Автоматика может вывести, что вот эта спека и вот эта имплементация в чём-то взаимно непротиворечивы.
Всё остальное (а оно вообще работает так, как мы хотели?) - работа команды грамотных тестировщиков.
no subject
С другой стороны, для игрушек не нужно особое качество, так что проще посадить толпу дешёвых игрунов, чтобы они тыкали кнопочки.
no subject
Но сейчас отсутствие профессиональных QA (в команде или на аутсорсе) способно серьёзно угробить качество и продажи. Новоэнтерпрайзный подход "решаем всё количеством дешёвых обезьянок" здесь не работает.
no subject
никто не спорит, но это вообще-то и есть главное преимущество ФП которое ты так не любишь.
no subject
А практика показывает, что функциональшина выигрывает в мелочах, которые спокойно покрываются правильной культурой производства, но при этом просирает глобальную картину.
no subject