Кто отвечает за качество игр: разработчик или тестировщик

Всем привет! Меня зовут Александр Дончук, я руководитель отдела обеспечения качества студии 4A Games, известной по играм «Метро 2033», «Метро: Луч надежды», «Метро: Исход», ARKTIKA.1. Уже 9-й год я занимаюсь тестированием игр и более 3 лет преподаю курс для желающих стать тестировщиками игр в рамках школы Games Academy. С 2019 года мой курс можно прослушать и онлайн на платформе devtodev.

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

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

В статье я постараюсь кратко объяснить суть работы QA и дать определение качеству, расскажу о том, кто же в действительности его создает и как лучше взаимодействовать тестировщикам и разработчикам, чтобы это самое качество неустанно повышать.

Что такое качество

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

Итак, что же такое качество? Хорошо известная всем (я думаю) Международная организация по стандартизации (ISO) имеет целый специальный комитет, определяющий понятие и критерии качества программного обеспечения.

Международный стандарт ISO 8402:1994 гласит: качество программного обеспечения — это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Другими словами, это показатель того, насколько хорошо ваше ПО (в нашем случае игра) отвечает явным и неявным требованиям, предъявленным к нему.

Иллюстрации Каталины Маевской

Пойдем дальше. Международный совет по тестированию программного обеспечения (ISTQB), занимающийся экзаменацией и сертификацией тестировщиков, имеет свой глоссарий, в котором также определяется понятие качества. Согласно ему, качество — это степень, в которой ваше ПО обладает требуемой всеми участниками комбинацией свойств.

Одно из важнейших словосочетаний здесь — «всеми участниками». Естественно, конечная цель разработки — предоставить игроку продукт без ошибок. Но чтобы этого достичь, ваша игра должна соответствовать ожиданиям всех участников процесса: разработчиков, тестировщиков, менеджеров, издателей, маркетологов...

Отдельное внимание хочется уделить критериям качества по той же ISO, особенно одному из них. Итак, согласно ISO, существуют такие 6 критериев качества: функциональность, надежность, практичность, эффективность, мобильность, сопровождаемость.

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

Не изобретаем велосипед, идем к тем же стандартам ISO. ISO 9126 гласит, что сопровождаемость — это 4 основных фактора: удобство для анализа, изменяемость, стабильность, тестопригодность.

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

Что такое тестопригодность

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

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

Кто же в действительности отвечает за качество игры

Лично мое мнение (и я надеюсь, что все читатели этой статьи в итоге согласятся с ним): достичь желаемого качества игры возможно только благодаря слаженной работе всей команды. Не только тестировщики, не только разработчики, не только менеджмент — все должны эффективно взаимодействовать ради желаемого результата. Чтобы получить качественную игру по завершении работы над ней, нужно поддерживать ее качество и в процессе ее создания. Одно без другого невозможно.

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

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

Первый блок советов касается процессов разработки и самих разработчиков.

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

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

2. Code review. Мощнейшая практика для повышения качества вашей игры. Чем качественнее у вас код, тем качественнее в итоге будет ваш продукт. Причем относится это не только к программистам. Дизайнеры пишут скрипты, которые тоже с этой точки зрения можно считать кодом, проводя их review. Как говорится, всего несколько недель регрессии способны заменить часы code review.

3. Smoke test собственных изменений разработчиками. Казалось бы, тестами должны заниматься тестировщики, а не разработчики. Но! Если, например, разработчик отдал код, который не компилируется, или недодал какие-то файлы, в итоге страдает вся компания. Вы не можете работать, это приводит к огромным потерям, которые можно подсчитать даже в денежном выражении. И если с кодом и как минимум его компиляцией все еще довольно просто и на сборку проекта уходит не слишком много времени, то с изменениями, которые вносят гейм-дизайнеры, все намного печальнее. Дизайнер где-то там в середине уровня что-то поменял и сам не проверил, можно ли его банально пройти. В итоге отдается непроходимый контент, тестировщики собирают билд, проводят свой smoke test, берут билд в работу, доходят до сломанного места, где обнаруживается, что билд не проходится. В итоге тратится куча времени, чего можно было бы избежать, если бы дизайнер потратил немного времени на smoke test своих изменений и не отдал такой контент в билд.

4. Разработчики должны участвовать в составлении требований тестировщиками. Безусловно, в идеальной схеме разработчики должны отдавать на тестирование фичи уже с документацией и требованиями к ним. Однако зачастую тестировщикам приходится составлять список требований самостоятельно. И ладно еще, если это происходит на основе актуальной документации. Но если документация неактуальна или ее вообще нет, тестировщик никогда не может быть уверен, что требования, которые он составил на основе своих проверок, верны. А значит, задача разработчика — провести review тестов и указать, что данные проверок валидны и фича должна соответствовать им.

Этот набор не самых трудозатратных рекомендаций (пускай smoke test и code review все же потребуют времени, оно с лихвой компенсируется) позволяет разработчикам повысить качество продукта в любой команде и в любой ситуации.

Что делать тестировщикам, чтобы повысить качество игры

Теперь же перейдем к тестировщикам. Главный вопрос, на который хочется дать ответ в этой статье, — «А повышают ли тестировщики качество игр?». Внимание, сейчас будет спойлер: нет, не повышают.

Тестировщики находят ошибки, которые уже попали в ваш продукт. На момент тестирования игра уже обладает каким-то уровнем качества. Сами тестировщики его повысить не могут. У нас для этого нет ни компетенций, ни полномочий. Тестирование — информационный сервис. Тестировщики — люди, которые рассказывают другим заинтересованным людям правду о вашем продукте. Мы ни в коем случае его не ломаем, как можно часто услышать от тех же разработчиков, мол, «я отдал продукт в тестирование, сейчас тестировщики все сломают». Да не ломаем мы ничего! Оно уже сломано. Как однажды полушутя сказал Джеймс Бах, «максимум, что могут сломать тестировщики, — это ваши мечты о продукте». И это абсолютная правда. Мы не ломаем игры, мы рассказываем разработчикам, где они сломаны. Или не сломаны. Не менее важная часть процесса тестирования — убедиться, что все работает так, как задумывалось.

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

И что же получается? Тестировщик ни в чем не виноват? Это злые разработчики делают плохие игры?

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

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

Вторая проблема — недостаток тестировщиков. Да, в большинстве своем игры — крайне сложные системы с буквально неограниченным количеством возможных пользовательских сценариев и вариантов взаимодействия различных механик. Именно поэтому полностью покрыть вашу игру проверками даже теоретически невозможно. Не существует какой-то универсальной схемы, по которой можно вычислить необходимое количество тестировщиков для вашего проекта. На это будет влиять слишком много факторов: объем самой игры, количество механик, платформ, даже жанр и линейность игрового процесса. Однако одним из самых адекватных критериев, от которого можно плясать, я считаю количество разработчиков, чью работу вы будете тестировать. Считается, что здравое соотношение — 1 тестировщик на 4 разработчика. И это то количество, к которому имеет смысл стремиться, уже в дальнейшем делая поправки на специфику вашего конкретного продукта.

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

Игры создаются не одномоментно. Наверняка процесс создания вашей игры разбит на этапы и отчетные периоды. Тестировщикам важно осознавать, на каком этапе вы сейчас находитесь, и указывать только релевантные для этого этапа дефекты. Казалось бы, что плохого в том, что вы заранее напишете о найденных багах? Если они касаются фичи в околофинальном состоянии — ничего. Однако, когда тестировщики начинают описывать дефекты низкой важности на этапе условного драфта, это очень вредно для всей разработки. Тестировщики тратят время на поиск, локализацию и занесение ненужных на данном этапе дефектов. В лучшем случае они просто будут висеть мертвым грузом у вас в баг-трекере, и вам придется регрессить их через какое-то время, когда проект выйдет на финальные этапы. В худшем случае неопытный разработчик возьмется их решать. Чинить миноры в драфте — худшее, что можно придумать. Это потеря времени на совершенно никому не нужную работу. Баги коллизии на ранних этапах игры никого не интересуют — там вся геометрия еще 15 раз переделается. Дергающиеся анимации в сценах, которые еще не утверждены и не анимированы на чистовую, чинить нельзя. Старайтесь максимально избегать таких багов, следить за текущим этапом и осознавать требования и ко всему продукту, и конкретно к тестируемой фиче.

В заключение

Так как тестирование — сервис про коммуникации, старайтесь как можно больше коммуницировать. Именно на общении между разработчиками и тестировщиками строится качество вашей игры. Запрашивайте тестирование, пишите отчеты, наращивайте документацию, утверждайте, спорьте, если это нужно. Это и есть наша работа.

Спасибо всем, кто дочитал.

LinkedIn

37 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

А что, тестировщики уже научились проверять качество софта ? (Сарказм)
Да? А критерии где? Нету?
Вот то-то же
Disclaimer: имеется в виду средний по палате тестировщик, а не инженеры nasa

Релиз менеджер конечно, который гонит релиз к какой-то абстрактной и не мотивированной дате, и пофиг на баги и недоделки.

Можна припустити, що то дата, коли стане хоч якось зрозуміло, чи буде хоч якийсь прибуток в результаті

Качество продукта — это ответственность всех вовлеченных в его создание. Всех. Включая тех, кто пишет требования, менеджеров и т.д. Иное понимание этого факта ущербно для продукта.

Плохой тестировщик, плохой, не хочет обеспечивать качество игры, только доументацию себе наращивает и мучает бедного программиста, футакимбыть, фу, пусть уходит.

В такой момент важно спросить у этого разработчика: «А как, по-твоему, мы будем это проверять?» И если он не может дать вразумительного ответа, такую фичу делать нельзя. Она не будет работать сама и будет негативно влиять на качество работы других фич, которые могут с ней пересекаться.

Разработчики Heroes III плачут читая эти строки :)

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

Всё там правильно написано. Если тестируемая система — это чёрный ящик, и он достаточно большой, то никакой ручной тестировщик его нормально не проверит. Вывод — нужно давать тестировщикам читы, консоль и прочие обычные в геймдеве инструменты.

та даже и без геймдева. если логика включает в себя «где-то для каждого сотого пользователя делаем А» через рандом-генератор, то для тестирования надо объяснить, как этот самый генератор подкрутить.

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

речь не о сложности, а о тестопригодности. Нельзя пропускать нетестопригодные фичи

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

как быть с малотестопригодными движками типа того же Unity где если разработка ведётся набрасыванием компонентов в инспектор? С этим Gui и прочей лабудой довольно сложно что-то проверить, если только не переписывать префабы, инспектор и прочую лабуду так чтобы она целиком и полностью была в твоих руках а не из под кривого API. Ну и хотелось бы увидеть игродела который бы не сидил и молился на убирание аллокаций и микрооптимизаци а думал про тестабилити и качество.

Запускаете игру, играете. Опционально — проходите по заранее написанному чеклисту. Всё как и обычно, никаких секретов нет.

Если же вы адепт секты «единственное тестирование — это автоматическое», то геймдев — это не для вас, простите. Он может пошатнуть вашу веру. Ну можете почитать про Unity Test Runner, если очень хочется.

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

Т.е. вмсто того чтобы прогнать за 20 мин на Ci полный тест сюит надо убивать сутки на ненадёжное ручное тестирование и вылов гейзенбагов? Вы дядя конечно оригинал.

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

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

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

Вы не понимаете, о чем пишете

 Я то всё как раз перкрасно понимаю, это вы меня неправильно понимаете.

почему автотестами невозможно и нецелесообразно покрыть всю игру

Потому что хреновая инфраструктура и культура разработки, в геймдеве её нет (ну на уровне всяких вебмастеров или вайтишнегов-фрилансеров вот вот из под туториалов от индусов под тильду-вп или что там ещё на пыхапэ), а попытки внедрить что-то для повышения надёжности и тестабилити всегда расценивается как саботаж, ибо «мы делаем игру а не технологию». Ну и потому что ваша игрулька НЕ является чем-то где надёжность играет хоть малую капельку какой-то роли и то на что нужно обращать внимание. Забагованный ужас это стандарт даже для ААА, и всё потому что конечный кастомер это пипл который всё схавает, а не большая контора с кучей злобных юристов. Вот тот висящий в воздухе куст или фсмка туториала/квеста вышедшая за своё предпологаемое фазовое пространство не будет стоить вам половину годовой зарплаты команды.

почему автотестами невозможно

большую её часть ВОЗМОЖНО. Ваше состояние игры в каждый момент это какой-то здоровый индуктивный тип, а тесты это в большинстве случаев РАЗРЕШИМЫЙ предикат, и пофиг на то что конструкция этих двух штук для удержания в мозгах требует их размером с кита. Принципиально нового там ничего нет, следовательно автотесты можно написать распологая неограниченными когнитивными ресурсами.

Другое дело, что в вашей инфраструктуре это сделать не в 2 строчки кода, то да, это у вас уже НЕВОЗМОЖНО. Это

нецелесообразно

но никак не не

невозможно

Вторая причина по которой у вас автотестов нет и ближайшее время не предвидится, никто не собирается тотально огораживать ВООБЩЕ ВЕСЬ код игры от инфраструктуры так чтобы его можно было бы протестировать отдельно, то что есть это полная противоположность — прибивание гвоздями логики к инфраструктуре. «зато быстро», и пофиг что теперь нужно для тестирования чего-то тестировать всё вместе.

И третья причина общая масса из геймдевелоперов не обладает достаточными компетенциями для того чтобы сделать инфраструкутуру для тестирования которая таки позволит убрать большую часть ручного тестирования. И пожалуйста, не надо мне задавать вопросов, «как ты будешь тестировать gui на мобилках» и «как ты протестируешь остутствие рассинхронизации в мултиплеере» т.д. и т.п. большинство из таких вопросов решаемые и при том не шибко сложные, но не в 3 строчки на $testFrameworkName.

Так что не «невозможно», а лень, не понятно как, не понятно зачем. А главное — не понятно куда потом девать орду нанятых ручников.

или тупо долго и дорого.
а оно — «и так сойдет».
что не отменяет резонности вашей позиции, это да.

и всё же, вы не понимаете. Я согласен с некоторыми аргументами, но общий посыл про «не делаете потому что лень» — в корне ошибочен.
Я не знаю, с чего вы взяли, что автотестов «нет и не предвидится». Они есть, активно используются, где это целесообразно, дают отличные результаты.
Но покрыть ВСЮ ИГРУ автоматизированными проверками невозможно в силу околобесконченого количества возможных пользовательских сценариев. Я не могу представить, сколько ресурсов необоходимо иметь в тестировании и сколько времени на это уйдет. Ваша игра не выйдет примерно никогда с таким подходом.
И еще один важный момент — игра в разработке — постоянно изменяющаяся среда. Поддерживать такое количество тестов — та еще задачка.

околобесконченого количества возможных пользовательских сценариев

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

Ваша игра не выйдет примерно никогда с таким подходом.

"мы делаем игру а не технологию"!

Поддерживать такое количество тестов

помогает хороший уровень абстракции и инфраструктура, ни того не другого у вас нет и в ближайшие лет 20 не будет.

мне жаль, что ваш опыт с игровыми разработчиками заставляет вас думать о них, как о «бездумно хреначащих вайтишнегах-фрилансерах». Безусловно, вы умнее всей многомиллиардной индустрии и лучше знаете, как надо работать. За сим удаляюсь, вы слишком категорично мыслите и мне непрятен ваш оскорбительный тон в адрес моих коллег по индустрии. Пойду дальше бездумно хреначить, пока не прошло 20 лет и меня не заменили тест-фреймворком от Ивана Камышана.

и мне непрятен ваш оскорбительный тон в адрес моих коллег по индустрии.

Они это заслужили по праву. Особенно такие которые пишут вот такое: github.com/...​version/src/Game.cpp#L707

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

качество во всей индустрии

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

Вы не смогли разобраться с префабами в Юнити,

Я могу прямо сейчас задвинуть десятка 3 таких полностью обоснованных предъяв. Вот только смысла в таких предьявах никакого нет. Стоит различать не

разобраться

и не пытаться

разобраться

Ради чего мне досконально изучать ваш юнити? Я не геймдев и тем более не юнити геймдев. Я прекрасно знаю, что этот ваш движок не разрабатывался компетентными в области разработки языков и систем программирования людьми. Я сомневаюсь что хотя бы у одного юнитбоя есть PhD по языкам\компиляторам. Утверждение о том, что некомпетентный человек не в состоянии сделать лучше коллектива компетентных, думаю довольно очевидное. По этому, ожидать того, что хоть что то в этом движке сделано хорошо не приходится, учитывая тот факт что он делался не как технология ради совершенства технологии, а на продажу. Де факто, это какой то кусок кода на котором можно произвести какой-то продукт. Ну так и РАДИ ЧЕГО его изчать? Что принципиально нового мне даст его изучение? Что юнитбои «пошли на компромисс» и «приняли архитектурные решения»? Мне не нужно в этом убеждатся, свидетельств этого и так достаточно.

И ещё раз повторю если посыл до вас не дошёл, ценность инструмента не в том что в нём надо сидеть и разбирать все его костыли и фичи, а в том что не надо.

Наличие «PhD по языкам\компиляторам» у человека показывает только то, что у него было время протирать штаны в вузе, а не то, что этот человек — хороший разработчик.

Я считаю, что разработчик — тот кто может решать практические задачи и получать за это деньги. Александр Нескин — разработчик. Кира Рудик — разработчик. Алекс Шевченко и Макс Литвин — разработчики. А ДОУ целиком состоит из теоретизирующих нёрдов, которые никогда не достигнут таких высот и не заработают столько денег, как Алекс или Кира.

Причем фундаментальная ошибка заключается в отнесении себя к некой категории «небыдла». Дело в том, что разработка ПО никогда не являлась самоцелью. Использование небыдлоязыка или красивого архитектурного решения оправдано до тех пор, пока его применение находит отражение в потребительских качествах продукта, и имеет тем большую ценность, чем большей аудитории улучшение потребительских качеств будет доступно и понятно. Т.е. я хочу сказать, что продукт должен быть наоборот максимально быдло-ориентирован, учитывать его интересы, сделан под него. Это касается и разработки средств и библиотек, а также к выбора средств разработки. CMS система, написанная на PHP и работающая на нищебродских хостингах обладает гораздо большим рыночным потенциалом, чем какая-нибудь астральная фигня на лисповском uncommon web-е. Если эта еще и интегрируется с SAP а также имеет маркетинговую поддержку от производителя, но позволяет разработчикам самостоятельно зарабатывать на лицензиях (т.е. получать деньги фактически ничего не делая) — то её потенциал еще выше. Деньги всегда были и будут в «быдло-технологиях», то, что произошло с Viaweb (кстати, «илитность» его заключаась только в выбранном языке, сам проект — типичное веб-добро для быдла) — нелепая случайность, одна на весь мир, возникнувшая на перегретом американском IT-рынке до краха доткомов. Так что учите PHP и Node.JS, вся ваша математическая фигня и небыдлоязыки никому даром не нужны.

аличие «PhD по языкам\компиляторам» у человека показывает только то, что у него было время протирать штаны в вузе,

ну это только Ваше личное мнение.

Я считаю, что разработчик — тот кто может решать практические задачи

Ящитаю. Аргументный аргумент. Видите ли дело в том, что разработка прикладного по, разработка библиотек, разработка систем програмирования и компиляторов это РАЗНЫЕ области разработки где компетенции и специфика РАЗЛИЧНА. Это примерно то же отличие что и между рабочим который собирает изделия из деталей, инженера, который эти детали разрабатывает, физика который адаптирует законы открытые математиком. Естественно, что рабочий не сможет делать работу физика или математика, а работу инженера сделает хреново.

из теоретизирующих нёрдов,

Видали, читатель этого поста, он Вас нердом обозвал. За себя говорите, будьте добры.

Причем фундаментальная ошибка заключается в отнесении себя к некой категории «небыдла»

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

Дело в том, что разработка ПО никогда не являлась самоцелью

Бред же. Теоретическое CS только этим и занималось, при том ещё до того как вы начали клепать своё велью.

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

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

А по теме — я прекрасно знаю как эти самые

небыдлоязыка или красивого архитектурного решения

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

находит отражение в потребительских качествах продукта

и

улучшение потребительских качеств будет доступно и понятно

если прочитать инструкцию по применению.

Т.е. я хочу сказать, что продукт должен

опять разговоры за продукт по техническим вопросам.

лисповском uncommon web-е

экзотический != хороший.

Деньги всегда были и будут в «быдло-технологиях»

Поиск гуглга быдлотехнология? Или же автопилот теслы быдлотехнология? ПО марсохода быдлотехнология?

Так что учите PHP и Node.JS, вся ваша математическая фигня и небыдлоязыки никому даром не нужны.

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

Да, конечно, задач типа вэпсайт обувному магазину и «заказал фрилансеру вордпресс» больше чем там где надо включать голову, но от этого они не исчезнут.

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

Игры нынче фальшивые
Качественные но не радуют

Возможно, ваше увлечение к играм просто прошло. Любая игра, даже «кинцо» или мобильный фримиум, требует большого внимания к процессу, и людям с работой его поддерживать сложнее.

Тогда бы меня перестал радовать первый Данжон Кипер например.

Це старість.

Мене вже от BMW так не тішить, як раніше...

Не качественные, некоторые радуют.

Подписаться на комментарии