Захар Кущенко

Такие решения нужно принимать исходя из доступных ресурсов. Умеете хорошо рисовать - выбирайте 2D, умеете хорошо моделить - выбирайте 3D. Двадэшные спрайты сильно быстрее и дешевле в производстве, чем модели, но анимировать их может быть сложнее, тут зависит от технологии: скелетная анимация или спрайтовая. Кроме анимации технология влияет на скорость итерации, если, например, захотите поменять одежду персонажу, то со спрайтовой анимацией придется перерисовывать все атласы, со скелетной такого может и не быть, но всё зависит от используемых инструментов. С трёхмерными моделями в плане анимаций проще, при желании вообще можно найти готовые, но тридешность тянет за собой кучу других проблем: большая нагрузка на видеокарту, стилистические ограничения, возня с освещением и т. п. Если говорить про квесты, то часто идут на компромисс: героев моделят, а задники рисуют плоскими. Ещё иногда фоны моделят, но потом рендерят в текстуру и дорисовывают в фотошопе.

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

В excel есть встроенный язык программирования если что - VBA.
Но зачем такие сложности с голосом?
Если вводите руками, то сканер и хорошая OCR вам поможет.
На сколько я понимаю, вводите из накладных или счетов, т.е. из стандартизированных форм, можно взять ABBYY FineReader Form настроить в нем свою форму + потоковый сканер и вводится все будет практически на автомате, со скоростью работы сканера. FineReader умеет сохранять в разнообразные форматы dbf, csv, ... в excel, по моему, то же умеет, но это и не обязательно.
Если форма с которой вводите не соответствует форме в Excel, то нужно будет в вашей Excel таблице написать макрос импорта из полученных форм.
Все это в итоге будет быстрее и дешевле, чем писать на шарпе голосовую вводилку информации.

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

PS: Во многих банка бумажные платежки именно так попадают в обработку, правда для банков есть специализированная версия FineReader Form - FineReader Bank там уже есть готовые шаблоны банковских форм.

Я тут анализировал... Такой себе говноанализ проводил, периодически сканируя если есть возможность и код читаем, т.к. часто бывает его налепят так, что как ни танцуй вокруг него с телефоном - он не считывается из-за очень мелкого размера, крайне хренового качества, или что-то "налазит" на него и т.д.
И пришел я к такому выводу: коды эти сами по себе достаточно полезны и удобны, как механизм/метод передачи определенных объемов информации, но не приживаются они по ряду причин, а именно:
- Многие, если не большинство, людей вообще не шурупают что это за гребаный квадрат и с какой стороны к нему подходить.
Решение: добавлять рядом краткую информацию о том, как его считать и почему это удобно.
- Бесполезный контент! Наверно 80-90% всех кодов несут в себе абсолютно бесполезную хрень, типа урла на какой то убогий сайт, который никому не нужен. Получается, что отсканил код - нашару залил себе говна в телефон в виде, как получается, уже и сюда проникшего спама! Типа вот мы какие современные, хз че его туда зашифровать, а давайте что попало. Люди сканят и: агааа! А вот вам, хлебните говнеца и от нашей компании!))
Решение: публиковать только действительно полезную информацию. Иначе нах.
- Ну и к тому же, самое главное на мой взгляд, это неизвестность! Почему кто-то должен сканить код, не зная вообще нужна ему инфа из него или это будет очередной глоток свежего говнеца но только уже от другой компании!))
Решение: указывать, какая информация зашифрована в коде, чтобы человек понимал будет ли она полезна для него или нет.

А вообще конечно, придерживаясь этих правил (экий я! уже и в "правила" эту простыню записал:))) возможно qr-коды и стали бы популярней. Например, вместо того шлака, который есть сейчас в них, можно шифровать визитку со многими параметрами, которую отсканил и в телефон уже занесен контакт со всеми номерами тел., почтой, названием организации, адресом и др. GPS координаты, если кто юзает тел. как навигатор, основные технические характеристики товара, если это магазин обычный да и вообще валом ещё полезных вариантов... Но у нас почему-то вместо этого туда шифруют потоки калловых масс... идем то в ногу со временем, епта!))

We are animals.
Да все просто - зеленых пикселей раза в 2 больше, чем остальных! А почему? Особенность зрения приматов :-)
Для самообразования - www.cambridgeincolour.com/ru/tutorials-ru/camera-s...

Программист-уборщица? =)

Code Review

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

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

Кроме code review, есть такая вещь, как стандарты. Она заключается в том, что существует некий общепринятый документ, который декларирует, как писать код, сколько делать отступов, табы или пробелы и т.д. Нередко он декларирует интерфейсы и тому подобное. В мире PHP это набор стандартов PSR. И все без исключений следуют этому стандарту.

Кроме этого существует ряд вспомогательных инструментов, таких как анализаторы кода, которые проверяют код на наличие потенциальных ошибок и прочие моменты. В мире PHP это Mess Detector и CodeSniffer.

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

Слежение за качеством кода это обязанность каждого разработчика.

Осознание этого приходит с повышением квалификации разработчика.

приходится менять
Переменная += 1;
на
Переменная++;

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

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

обычно этот гемор на тимлиде