Новый тренд в интернетах: поклонение кондовости и тупости

[metaclass]

Вот последний пример: http://vit-r.livejournal.com/739457.html
"Уравнение шредингера вредно, потому что не сводится к арифметике первого класса, а наши индусы-контракторы буквы и значки не понимают".

Не очень понимаю, откуда этот луддизм в последнее время вылез, неосиляторы что-ли решили занятся своим job security?

Comments

[oldmann.livejournal.com]

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

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

[metaclass.livejournal.com]

Так не работает же пара обезъян сама по себе - к ним нужно железо, облака, админ для облаков, менеджер, который их палкой пиздить будет, бизнес-аналитики, тестеров взвод, чтобы совсем уж чернуху не творить и прочий персонал.

[oldmann.livejournal.com]

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

[orleanz.livejournal.com]

" тестирование легко автоматизируются

вот тут вы и попались! поздравляю, вы сели в лужу, публично.

1. можно легко написать тесты, покрывающие НЕКОТОРУЮ часть функциональности. Типа, "для галочки" - у нас тоже есть тесты, как у всех других пацанов.

2. во многих случаях - очень сложно написать тесты, покрывающие все возможные сценарии. Конечно, если у вас задача - посчитать число Пи с точностью миллион знаков после запятой, как можно быстрее - то тестирования несложно - вы просто сравниваете результат работы функции с эталонным. НО ТАК БЫВАЕТ ДАЛЕКО НЕ ВСЕГДА. Взять например шутер Crysis, в команде разработчиков которого я работал 4 года. Вы можете повторить ваш тезис "тестирование легко автоматизируются" - в отношении таких шутеров? Любые игровые сценарии? Вы понимаете что их - квинтиллионы?

3. кроме тестирования - то есть нахождения ошибок - еще есть такая весч как багфиксинг. И здесь вам скорость процессора нисколько не поможет. Только квалифицированные программисты способно БЫСТРО и ПРАВИЛЬНО фиксить баги. Более того - если у вас дофига легаси кода, с дурной архитектурой - то ситуация может быть запущено до такого состояния, что даже высококлассы спецы завязнут в бесконечных багфиксах, и легче будет просто с нуля переписать .

так что все эти байки "через 5 лет программистов будут учить в ПТУ" - мы уже слышали давным давно.

[vit-r.livejournal.com]

Тестирование легко автоматизируется. Если его делать не по-стартаперски, а правильно.

Гемдева это тоже касается.

И ещё вопрос не в том, чтобы заниматься багфиксингом, а чтобы писать так, чтобы минимизировать количество багов, запущенных в систему изначально. Особенно это касается нетривиальных побочных эффектов.

[orleanz.livejournal.com]

" Тестирование легко автоматизируется. Если его делать не по-стартаперски, а правильно.

ок, расскажи мне как *легко* тестируются шутеры. с интересом послушаю.

[vit-r.livejournal.com]

Я видел, как делаются и тестируются системы, эти самые шутеры по сложности превышающие. На этой основе и делаю свои выводы. Рассказывать про "как" - история долгая и не для такого формата.

[orleanz.livejournal.com]

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

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

тему внутренних тестов обсуждать не будем. Сосредоточимся на внешних тестах, имитирующих действия игрока. Различных вариантов там получаются квинтилионы, потому что игрок может пойти за 10 минут игры совершенно разным образом, и в каждый раз все может нафиг закрэшится, из-за некого уникального сочетания конктерной игровой ситуации. Как здесь будем "ЛЕГКО" тестировать? В общих чертах плиз, саму идею.

[vit-r.livejournal.com]

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

[justy-tylor.livejournal.com]

Тестирование игр и пользовательских интерфейсов принципиально нельзя полностью автоматизировать.

Автоматика может вывести, что вот эта спека и вот эта имплементация в чём-то взаимно непротиворечивы.

Всё остальное (а оно вообще работает так, как мы хотели?) - работа команды грамотных тестировщиков.

[vit-r.livejournal.com]

Базовая ошибка в том, что тестирование предназначено не для доказательства правильности работы, а для поиска ошибок. Второе очень хорошо автоматизируется.

С другой стороны, для игрушек не нужно особое качество, так что проще посадить толпу дешёвых игрунов, чтобы они тыкали кнопочки.

[justy-tylor.livejournal.com]

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

Но сейчас отсутствие профессиональных QA (в команде или на аутсорсе) способно серьёзно угробить качество и продажи. Новоэнтерпрайзный подход "решаем всё количеством дешёвых обезьянок" здесь не работает.

[orleanz.livejournal.com]

" писать так, чтобы минимизировать количество багов,

никто не спорит, но это вообще-то и есть главное преимущество ФП которое ты так не любишь.

[vit-r.livejournal.com]

Для всякого "есть" нужно доказательство.

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

[vinslivins.livejournal.com]

да что вы говорите :)

[trueblacker.livejournal.com]

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

[justy-tylor.livejournal.com]

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

[tzirechnoy.livejournal.com]

>массовая дешевая компьютеризация отменила
> необходимость приставлять к каждой ЭВМ по паре десятков
> нехуёвых математиков.

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

[ng67.livejournal.com]

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