Мне кажется, Bookvarenko говорит про гигайбайт веса САМОГО Юнити. Среды разработки. Что, кажется, правда — у меня сейчас со всеми модулями папка с редактором (без Mono) весит 6 с небольшим гигабайт.
С другой стороны, я совершенно не понимаю, как это может иметь какое-то серьёзное значение.
А мои собранные на Юнити игры весят по 25-30 мегов на мобилки и 400 под десктоп (со всеми ресурсами).
Это такое весьма абстрактное «проще». Имплементировать это может быть чуть-чуть сложнее, а экономия памяти будет сколько, сотня-другая килобайт? При том, сколько памяти занимают игры на Unity сами собой это абсолютно не принципиальная разница.
Пару раз видел когда это приводило к всплескам ярости «Хабр не для рекламы!» и занижению как статьи так и кармы. Я не очень в восторге от такой перспективы, так что если счастливее меня прямые упоминания не сделают — постараюсь их избежать (:
Очень хочется определиться с начальным уровнем аудитории. Это кто-то, понимающий хоть что-то в программировании и ему не надо будет объяснять что такое класс или условный оператор, или это человек, впервые севший за компьютер? Пока не могу однозначно решить.
Дааа, самому бы сначала не полениться и разобраться со ScriptableObject до конца т.т
А то, в принципе-то, необходимости в них нет, они просто делают удобнее, поэтому как до некритичной темы я постоянно ленюсь до них добраться. Так что это ошибка новичка, которую я делаю всё время (:
Я уже поплакал из-за того как плохо построил этот комментарий. Надо было его сначала раз 10 перечитать, скорее всего решил бы ничего не писать :-D
У QA (как, впрочем, и у рядового разработчика) есть однозначный технический потолок, пробить который достаточно сложно. Можно уйти в тим-лиды, можно углубиться в смежные области (например, аналитику и безопасность), а без этого профессиональный рост (и рост заработной платы) начинают сильно замедлятся. Именно про такие шаги я и писал (:
Мы в Badoo примерно так и разрабатываем. Разработчик берёт задачу из пула, если задача с ходу не ясна — к нему присоединяется QA-инженер (если всё понятно сразу — QA подключается уже после первого resolve) и дальше они работают над задачей сообща, включая все возможные циклы reopen'ов.
Непосредственно над каждой задачей архитектора нет, но есть код-ревью, во время которого сообща решаются любые архитектурные вопросы.
Никогда ещё не работал в физически распределённой команде, у нас разработка и тестирование работают совместно всегда. Очень интересно узнать, как что работает при вашей схеме :)
Тестировщик, слепо следующий написанным кем-то другим кейсам — это самое начало карьеры тестировщика. Как программист, который переводит написанный кем-то другим алгоритм в код. Такие практики имеют право на существование, но кажутся мне менее эффективными (хоть и потенциально более надёжными), чем программисты, сами разрабатывающие свою систему и тестировщики, сами прорабатывающий план тестирования компонента.
К сожалению, программисты-новички так тестировщиков и видят. Спасательный круг, который их выручит от пендюлей руководства.
И уже от руководства зависит, будет ли меняться такое отношение. Если во всех багах винят только тестировщиков — программисты будут становиться всё расслабленнее и проект рано или поздно увязнет. Если ответственность распределяется поровну (или в некоторых случаях даже преимущественно на разработчика), то и сами разработчики начинают меньше уповать на тестирование вместо самих себя.
Подозреваю, что лайкают мемасики, хотя в душе надеюсь, что все-таки статью (:
С другой стороны, я совершенно не понимаю, как это может иметь какое-то серьёзное значение.
А мои собранные на Юнити игры весят по 25-30 мегов на мобилки и 400 под десктоп (со всеми ресурсами).
Так что я не совсем могу понять эту претензию (:
Но да, так, конечно, делать правильнее.
А то, в принципе-то, необходимости в них нет, они просто делают удобнее, поэтому как до некритичной темы я постоянно ленюсь до них добраться. Так что это ошибка новичка, которую я делаю всё время (:
Виталий, это низко.
У QA (как, впрочем, и у рядового разработчика) есть однозначный технический потолок, пробить который достаточно сложно. Можно уйти в тим-лиды, можно углубиться в смежные области (например, аналитику и безопасность), а без этого профессиональный рост (и рост заработной платы) начинают сильно замедлятся. Именно про такие шаги я и писал (:
Непосредственно над каждой задачей архитектора нет, но есть код-ревью, во время которого сообща решаются любые архитектурные вопросы.
И уже от руководства зависит, будет ли меняться такое отношение. Если во всех багах винят только тестировщиков — программисты будут становиться всё расслабленнее и проект рано или поздно увязнет. Если ответственность распределяется поровну (или в некоторых случаях даже преимущественно на разработчика), то и сами разработчики начинают меньше уповать на тестирование вместо самих себя.