Мой "основной" язык — Java, так что расскажу как дела обстоят там и почему правы и те люди, которые говорят что синглтон зло, и почему правы вы:
Нарушение принципа единственной ответственности
В Java (и скорее всего в C#) синглтон создает сам себя, хранит сам себя и делает свою бизнес логику. Это ужасно, это отвратительно, это плохо.
НО! В Unity этим занят сам движок. Вы только делаете ScriptableObject и сам движок управляет жизненным циклом синглтона. Про "God Object" поговорим дальше, пока считаем что эта проблема решена.
Singleton невозможно тестировать
Тесная связь
Эти проблемы связанны напрямую. Coupling(т.н. "связывание", оно же "сильная связанность") — это когда объект содержит другой объект. В итоге мы не может протестировать их по одиночке. Юнит тестирование класса аггрегирующего другой класс будет невозможно, т.к. мы будем завязаны на использование внутреннего объекта. Это тоже ужасно, отвратительно и плохо…
Но опять нам на выручку приходит игровой движок, который по совместительству выполняет роль Dependency Injection(внедрение зависимостей, DI).
Многие начинающие программисты на юнити используют его даже не подозревая этого, потому что оно настолько простое. Перетаскивание объектов в скрипты, Изменение их значений через UI — всё это внедрение зависимостей и эта простота не уменьшает возможности.
Хотите синглтон(ScriptableObject)? Пожалуйста! Но будет гораздо разумнее использовать наследование и встроенный DI.
Примеры:
Сделать разные свойства игры для разных сложностей: сделаем игру тетрис, три разных ScriptableObject'а описывающих разные значения высоты и ширины поля и скорости игры. В зависимости от выбранных настроек инжектим разные ScriptableObject'ы.
Сделать разные характеристики для юнитов в стратегии, для последующего теста и менять их только изменяя SO при создании юнита.
Сделать разные AI для разного поведения опонента в экономической стратегии: более агрессивный и более миролюбивый.
Каждый из приведенных выше примеров позволит протестировать разный ScriptableObject отдельно, и заменить их на Mock'и при тестировании классов, которые их используют.
При каждом изменении мы сможем заменить старый SO на новый, оставив старый, на случай "отката", если идея не взлетит.
Проблема с God-Object тоже пропадает при использовании DI.
Уже музыки всего 30 минут в день. В эти 30 минут вы будете ещё слышать не пропускаемую рекламу.
До этих чудесных изменений заметил что малопопулярная музыка очень долго грузится с мобильного. Популярная — мгновенно, с компьютера — мгновенно. С телефона — придётся ждать минимум 20 секунд и, если повезет, то загрузится.
В то же время Google Music и SoundCloud грузят моментально треки любой популярности.
Согласен. Это выглядит как минимум некрасиво. Какого чёрта, тут люди пишут тексты и расшифровки для видео, но приходит цитирую: "крупнейший холдинг в России", у которого нет людей/денег/желания, делать расшифровку видео.
Не делайте из хабры твиттер. Твиттер есть и прекрасно работает. Если вам ближе такой формат, то используйте его.
имхо: лишний раз показывает отношение компании к людям
Жизненно до слёз. Мне постоянно приходят письма что какой-то человек с другого конца света покупает игры и закидывает деньги на свой PlayStation аккаунт.
Возможно, он ошибся и случайно указал мой адрес, а я усталый после работы нажал на кнопку "подтвердить email"…
Ну и письма мне приходят с "Jul 13, 2014". Последняя покупка была 22 Августа этого года.
В первый год я пытался найти человека по личной информации из писем, чтобы попросить его поменять мою почту на свою, но поиск в соцсетях (Facebook) не дал нормального результата.
Зато нашёл сайт клиники для малообеспеченных, у которой совпадает индекс с тем что в профиле, "доску почёта" с именем и фамилией как из профиля. Хз совпадение это или нет, но я понял что по гуглу о человеке можно узнать слишком много...
Речь о нейронках и самообучении.
Да, некоторые комбинации герой-предмет заведомо слабые, но суть RL(Reinforcement Learning) в том, что он может найти удачные моменты даже в случае если для этого придётся чем-то пожертвовать (аналог гамбита). Так что ему в любом случае нужно будет попробовать все вариации предметов, причём не один раз.
По поводу шахмат при обучении ИИ как раз и поиграется со всеми фигурами. Но достаточно быстро(относительно) сделает выводы о выгоде от фигур.
В то же время в Dota 2 где матчи длятся очень долго(особенно для AI с не обученным RL) 115 героев, по 6 слотов у каждого, где может быть один из ~130 предметов, с учётом команды...
Идеально микро появится совсем не скоро… Того же OpenAI обыграли в 1х1 на равных условиях и это с учётом того что учили его одного, только для этого типа игры.
Какие мощности понадобятся для того, чтобы сделать что-то что может конкурировать с командой "любительского уровня" страшно представить.
Про ботов в HotS'е: в доте такое сложно будет провернуть из-за специфики игры. Некоторые способности направлены на длительные дизейблы по врагам стоящим рядом друг с другом, в то время как другие позволяют расправляться с теми, что разрознены. Я понятия не имею, как с этим будут бороться. Поживём — увидим.
2020 год — это мой самый "позитивный" прогноз. Так делаю ставку на 2025-2035.
ral если ты читал про SC2, то по аналогии с StarCraft 2, это тоже самое что управлять всего одним юнитом в стратегии, не задумываясь о ресурсах и создании новых.
Dota 2 — одна из самых командных игр потому что способности одних персонажей, хорошо сочетаются с другими. И в добавок к этому у игроков много разных вещей о которых нужно думать:
Выбор героев. Одни герои лучше сочетаются с другими, другие лучше противостоят определенным героям противника. Выбор из более чем 110 героев 5 героев на команду, команд две. За каждого отдельного персонажа стратегия игры отличается и может ещё изменятся в зависимости от героев противника/их "материального состояния" = В матче с OpenAI герой всегда один и тот же и матч "зеркальный"
Покупка предметов — более 100 разных предметов. У каждого персонажа в игре есть инвентарь на 6 предметов. Как одноразовых "расходников" которые тратятся, так и пассивных(работают постоянно, пока лежат в инвентаре) и активных(которые нужно применять в определенные моменты). Некоторые предметы можно брать на 1-2 героев на команду, т.к. при правильном использовании они дают выгоду всей команде. = В матче OpenAI герои были 1х1 что уже урезает число возможных вариантов с 6 * 5 до 5. Некоторые предметы дорогие, а игра 1х1 часто заканчивается достаточно быстро, поэтому бОльшая часть из предметов недоступна. Вдобавок к этому, OpenAI "искуственно" запретили некоторые предметы. (о причине мне не ведомо)
Принятие решений. В игре персонаж становится гораздо сильнее с дорогими предметами, поэтому часто персонажей делят на роли Core(Основа, которая в будущем должна выиграть игру), которая занимается фармом(процессом убивания вражеских/нейтральных юнитов, для получения денег) и саппортов(помощники, которые делают всё, чтобы их "Основа" чувствовала себя чудесно и мешают "Основе" противника. И тут как раз игра в полной мере раскрывает стратегический потенциал.
Core-игрок должен понимать, когда ему лучше выходить на бой с противником, а когда лучше заниматься добычей денег, должен "чувствовать" игру, чтобы понимать, когда на него могут делать вылазку противники.
Support-игрок должен правильно распределять ресурсы — у него не так много денег, поэтому он должен стараться использовать их максимально эффективно, помогать союзникам и нападать на героев оппонента.
По последнему пункту в OpenAI было ничего общего с командной Dota.
Да, он понимал что ему нужно наносить герой оппоненту и убивать его по возможности, а в свободное время "фармить", но это всего одна линия, с которой, по сути, выходить было нельзя. Распределения ролей тоже не было. Командного взаимодействия тоже не было.
Я уверен, что до 2020 года не будет ничего, что сможет сравниться с людьми по навыку игры Dota 2 и похожие игры, потому что, имхо, это решение требует совершенно нового подхода, которое должно быть на порядок лучше(как минимум, для этой задачи)
Как и сказал JustRoo в доте было много ограничений. Добавлю, что на некоторые моменты модель натренировали специально (например блокинг крипов был "захардкожен", а не бот сам до него "додумался").
Our initial investigations show that our agents perform well on these mini-games. But when it comes to the full game, even strong baseline agents, such as A3C, cannot win a single game against even the easiest built-in AI. For instance, the following video shows an early-stage training agent (left) which fails to keep its workers mining, a task that humans find trivial. After training (right), the agents perform more meaningful actions, but if they are to be competitive, we will need further breakthroughs in deep RL and related areas.
"Принципы" которым учат — это знания людей выраженные в более простой форме.
На хабре была хорошая статья, где автор ML научил играть в шахматы а потом регрессионным анализом достал "стоимость" каждый из фигур, которые были приблизительно равны тем, что "написаны в учебнике".
(хотя для некоторых профессиональных игроков они отличались. я склоняюсь к тому, что это зависит от стиля игры. Например играя против одного игрока ты "боишься" его слонов, против другого лучше "бояться" коня.)
Напомнило Сида Меера и про его фразу смысл которой: "Случайность не подходит для игр, потому что игрок считает, что его обманывают. Поэтому мы ей 'помогаем'".
когда игрок, которому предсказывали 33-процентный шанс выиграть в битве, трижды подряд проигрывал в ней, то он ощущал гнев и недоверие
Сама статья: https://habrahabr.ru/post/320296/
Хороший вопрос.
Первая моя мысль мысль: выгода была бы такой, что ей можно было бы пренебречь, потому что цикл из 10 000 элементов проходится относительно легко.
Вторая что JS страдает при каждом добавлении нового элемента в DOM, поэтому выгода могла быть большой.
Третья: готовым файлом — это как?
Меня беспокоил такой же вопрос.
Решил проверить, сделал примитивный тест на codepen, который просто создает svg с n количеством треугольников.
Браузер на компьютере подвисает на 3-4 секунды от 100 000 треугольников, после чего функционирует нормально.
У телефона такие же проблемы начинаются с 10 000 треугольников (Xiaomi Redmi 3S)
Действительно, я какую-то глупость написал. Думал что под бесполезной работой подразумевается "генерация svg на фронте", но только сейчас понял что для этого нам нужно само изображение "=.=
По поводу отображения svg vs jpeg — это стандартная дилемма: память vs вычисления.
С одной стороны у большинства пользователей уже есть быстрый домашний и (иногда) мобильный интернет, в кафе и торговых центрах есть Wi-Fi и загрузить лишнюю маленькую jpeg не составит труда, но с другой стороны браузеру итак есть что грузить, а тут ещё "лишние" jpeg файлы, пускай и небольшого размера.
С другой стороны вычислительные мощности бОльшей части устройств смогут справиться с выводом 10 фигур, что будет очень кстати для пользователей мобильных устройств.
Да это решение — не панацея, но оно имеет свои плюсы (например стилизация соцсети/сервиса). Думаю особенно красиво это смотрелось бы с специальной задержкой перед показом картинки и последовательным превращением фигур в фотографию.
В остальных случаях, как и сказал TimsTims можно использовать прогрессивный JPEG
можно же и на бэке сделать. Поставить чтобы аватарку нельзя было менять чаще чем раз в 5(10,20, 100500) раз в минуту или делать плейсхолдеры, только когда она "продержалась" 1(2,3,7, 14) дней.
Отправлять svg гораздо дешевле
При нажатии на кнопку отправить, при первом комментарии в теме писать "Вы уверены что хотите оставить этот комментарий? Данная статья является переводом".
Шутки в сторону. В шапке действительно сложно заметить эту плашку. Я мельком глянул шапку на наличие плашки "перевод" (старой — цветной, по привычке). Потом в середине текста снова усомнился и ещё раз попробовал её найти. В конце статьи, когда написали про перевод я уже пристально пытался рассмотреть в шапке плашку и вспомнил что она теперь серая.
Скорее всего зависит от трафика с твоего IP. С динамическим айпишником может на большинстве сайтов капчу требовать и по несколько раз(не просто за какой-то запрос а просто за доступ к сайту).
В каждой компании по своему. На прошлой работе была игровая с теннисом и настольныv футболом. Все играли никто не жаловался.
На новой тоже самое + х-бокс, лаундж зоны и "книжные углы".
Опять же никто не жалуется.
По поводу "лишали привозной воды" советую почитать Трудовой кодекс РФ. Это просто незаконно (пункт о том что работодатель обязан обеспечить питьевой водой).
Ну и, пожалуй, бежать от такого работодателя куда глаза глядят.
С этим никто не спорит. Я говорю что заставлять новичков писать юнит тесты это плохо. Цитата из статьи:
Вы придёте и начнёте с малого — возможно, даже просто минимального тестирования.
Как минимум, потому что лучше девелопера который написал код, юнит тесты не напишет никто.
Поэтому и существует TDD, который не только "гарантирует" что написанный функционал будет покрыт тестами, но и позволяет программисту лучше задуматься о "граничных параметрах".
Мне кажется тут лучше всего подойдёт аналогия с кузнецами "Мастер — подмастерье":
Правильный подход(имхо): Подмастерье смотрит на работу мастера, делает что-то сам. Получается криво. Мастер говорит почему.
Подход из статьи: Мастер говорит подмастерье: "убирай за мной кузницу и полируй продукт". Подмастерье убирает и полирует.
С одной стороны, да он увидит как выглядит правильный продукт, полируя его и какой инструмент для чего используется. Но почему так, ему придётся догадываться самому.
Деньги — я ищу работу. Первое на что я смотрю деньги. Про повышения мы не узнаем пока оно не наступит. Знаю несколько "солидных" компаний, которые живут только на "дешевых студентах", которые боятся уйти. По моим наблюдениям з/п для одного и того же человека в разных компаниях может разниться в 2 раза.
Офис — я ищу работу. Я понимаю что я буду туда ходить и находится там солидное количество времени. Если будет выбор между двумя компаниями, но у одной из них столик для тенниса — я пойду в неё. Как минимум, потому что игровые на работе создают (хотя бы) иллюзию непринужденности.
Работа — писать юнит тесты не любит никто. Процитирую одного человека: "У вас спросят на собеседовании: "любите ли вы писать юнит-тесты", и вы скажете "Конечно люблю" и тут мы улыбнёмся и поймём друг-друга, о том что вы врете. Юнит тесты не любит писать никто."
Не знаю кем бы я был, если бы на первой работе мне бы дали код и сказали "тестируй". Лучший старт:
Тебе дают код
Ты делаешь
Комитишь
Ревью тайм
Пишут двадцать-тридцать пунктов, что нужно исправить
Митинг, на котором тебе говорят, почему это важно
Отношения
Тим билдинг это здорово. Нужно позволить разработчикам общаться друг с другом как им удобно. Активные разработчики, которые пытаются влиться в коллектив лучше, тех которые просто приходят молча на работу и молча смотрят в монитор. (имхо)
Как минимум потому что они будут знать кто чем занимается, и у кого можно будет спросить помощи с такой-то проблемой.
Мой "основной" язык — Java, так что расскажу как дела обстоят там и почему правы и те люди, которые говорят что синглтон зло, и почему правы вы:
В Java (и скорее всего в C#) синглтон создает сам себя, хранит сам себя и делает свою бизнес логику. Это ужасно, это отвратительно, это плохо.
НО! В Unity этим занят сам движок. Вы только делаете ScriptableObject и сам движок управляет жизненным циклом синглтона. Про "God Object" поговорим дальше, пока считаем что эта проблема решена.
Эти проблемы связанны напрямую. Coupling(т.н. "связывание", оно же "сильная связанность") — это когда объект содержит другой объект. В итоге мы не может протестировать их по одиночке. Юнит тестирование класса аггрегирующего другой класс будет невозможно, т.к. мы будем завязаны на использование внутреннего объекта. Это тоже ужасно, отвратительно и плохо…
Но опять нам на выручку приходит игровой движок, который по совместительству выполняет роль Dependency Injection(внедрение зависимостей, DI).
Многие начинающие программисты на юнити используют его даже не подозревая этого, потому что оно настолько простое. Перетаскивание объектов в скрипты, Изменение их значений через UI — всё это внедрение зависимостей и эта простота не уменьшает возможности.
Хотите синглтон(ScriptableObject)? Пожалуйста! Но будет гораздо разумнее использовать наследование и встроенный DI.
Примеры:
Каждый из приведенных выше примеров позволит протестировать разный ScriptableObject отдельно, и заменить их на Mock'и при тестировании классов, которые их используют.
При каждом изменении мы сможем заменить старый SO на новый, оставив старый, на случай "отката", если идея не взлетит.
Проблема с God-Object тоже пропадает при использовании DI.
Как я понял, при наведении мыши мобы иначе подсвечиваются (например красным)
Мое предположение, что автокликеры используют WinApi для кликов/хоткеев, а игра использует DirectInput
Уже музыки всего 30 минут в день. В эти 30 минут вы будете ещё слышать не пропускаемую рекламу.
До этих чудесных изменений заметил что малопопулярная музыка очень долго грузится с мобильного. Популярная — мгновенно, с компьютера — мгновенно. С телефона — придётся ждать минимум 20 секунд и, если повезет, то загрузится.
В то же время Google Music и SoundCloud грузят моментально треки любой популярности.
Согласен. Это выглядит как минимум некрасиво. Какого чёрта, тут люди пишут тексты и расшифровки для видео, но приходит цитирую: "крупнейший холдинг в России", у которого нет людей/денег/желания, делать расшифровку видео.
Не делайте из хабры твиттер. Твиттер есть и прекрасно работает. Если вам ближе такой формат, то используйте его.
имхо: лишний раз показывает отношение компании к людям
Жизненно до слёз. Мне постоянно приходят письма что какой-то человек с другого конца света покупает игры и закидывает деньги на свой PlayStation аккаунт.
Возможно, он ошибся и случайно указал мой адрес, а я усталый после работы нажал на кнопку "подтвердить email"…
Ну и письма мне приходят с "Jul 13, 2014". Последняя покупка была 22 Августа этого года.
В первый год я пытался найти человека по личной информации из писем, чтобы попросить его поменять мою почту на свою, но поиск в соцсетях (Facebook) не дал нормального результата.
Зато нашёл сайт клиники для малообеспеченных, у которой совпадает индекс с тем что в профиле, "доску почёта" с именем и фамилией как из профиля. Хз совпадение это или нет, но я понял что по гуглу о человеке можно узнать слишком много...
Речь о нейронках и самообучении.
Да, некоторые комбинации герой-предмет заведомо слабые, но суть RL(Reinforcement Learning) в том, что он может найти удачные моменты даже в случае если для этого придётся чем-то пожертвовать (аналог гамбита). Так что ему в любом случае нужно будет попробовать все вариации предметов, причём не один раз.
По поводу шахмат при обучении ИИ как раз и поиграется со всеми фигурами. Но достаточно быстро(относительно) сделает выводы о выгоде от фигур.
В то же время в Dota 2 где матчи длятся очень долго(особенно для AI с не обученным RL) 115 героев, по 6 слотов у каждого, где может быть один из ~130 предметов, с учётом команды...
Идеально микро появится совсем не скоро… Того же OpenAI обыграли в 1х1 на равных условиях и это с учётом того что учили его одного, только для этого типа игры.
Какие мощности понадобятся для того, чтобы сделать что-то что может конкурировать с командой "любительского уровня" страшно представить.
Про ботов в HotS'е: в доте такое сложно будет провернуть из-за специфики игры. Некоторые способности направлены на длительные дизейблы по врагам стоящим рядом друг с другом, в то время как другие позволяют расправляться с теми, что разрознены. Я понятия не имею, как с этим будут бороться. Поживём — увидим.
2020 год — это мой самый "позитивный" прогноз. Так делаю ставку на 2025-2035.
ral если ты читал про SC2, то по аналогии с StarCraft 2, это тоже самое что управлять всего одним юнитом в стратегии, не задумываясь о ресурсах и создании новых.
Dota 2 — одна из самых командных игр потому что способности одних персонажей, хорошо сочетаются с другими. И в добавок к этому у игроков много разных вещей о которых нужно думать:
Core-игрок должен понимать, когда ему лучше выходить на бой с противником, а когда лучше заниматься добычей денег, должен "чувствовать" игру, чтобы понимать, когда на него могут делать вылазку противники.
Support-игрок должен правильно распределять ресурсы — у него не так много денег, поэтому он должен стараться использовать их максимально эффективно, помогать союзникам и нападать на героев оппонента.
По последнему пункту в OpenAI было ничего общего с командной Dota.
Да, он понимал что ему нужно наносить герой оппоненту и убивать его по возможности, а в свободное время "фармить", но это всего одна линия, с которой, по сути, выходить было нельзя. Распределения ролей тоже не было. Командного взаимодействия тоже не было.
Я уверен, что до 2020 года не будет ничего, что сможет сравниться с людьми по навыку игры Dota 2 и похожие игры, потому что, имхо, это решение требует совершенно нового подхода, которое должно быть на порядок лучше(как минимум, для этой задачи)
Как и сказал JustRoo в доте было много ограничений. Добавлю, что на некоторые моменты модель натренировали специально (например блокинг крипов был "захардкожен", а не бот сам до него "додумался").
Про SC2 лучше процитировать ребят из DeepMind
"Принципы" которым учат — это знания людей выраженные в более простой форме.
На хабре была хорошая статья, где автор ML научил играть в шахматы а потом регрессионным анализом достал "стоимость" каждый из фигур, которые были приблизительно равны тем, что "написаны в учебнике".
(хотя для некоторых профессиональных игроков они отличались. я склоняюсь к тому, что это зависит от стиля игры. Например играя против одного игрока ты "боишься" его слонов, против другого лучше "бояться" коня.)
Вот, кстати, эта статья: https://habrahabr.ru/post/254753/
Напомнило Сида Меера и про его фразу смысл которой: "Случайность не подходит для игр, потому что игрок считает, что его обманывают. Поэтому мы ей 'помогаем'".
Хороший вопрос.
Первая моя мысль мысль: выгода была бы такой, что ей можно было бы пренебречь, потому что цикл из 10 000 элементов проходится относительно легко.
Вторая что JS страдает при каждом добавлении нового элемента в DOM, поэтому выгода могла быть большой.
Третья: готовым файлом — это как?
Меня беспокоил такой же вопрос.
Решил проверить, сделал примитивный тест на codepen, который просто создает svg с n количеством треугольников.
Браузер на компьютере подвисает на 3-4 секунды от 100 000 треугольников, после чего функционирует нормально.
У телефона такие же проблемы начинаются с 10 000 треугольников (Xiaomi Redmi 3S)
Действительно, я какую-то глупость написал. Думал что под бесполезной работой подразумевается "генерация svg на фронте", но только сейчас понял что для этого нам нужно само изображение "=.=
По поводу отображения svg vs jpeg — это стандартная дилемма: память vs вычисления.
С одной стороны у большинства пользователей уже есть быстрый домашний и (иногда) мобильный интернет, в кафе и торговых центрах есть Wi-Fi и загрузить лишнюю маленькую jpeg не составит труда, но с другой стороны браузеру итак есть что грузить, а тут ещё "лишние" jpeg файлы, пускай и небольшого размера.
С другой стороны вычислительные мощности бОльшей части устройств смогут справиться с выводом 10 фигур, что будет очень кстати для пользователей мобильных устройств.
Да это решение — не панацея, но оно имеет свои плюсы (например стилизация соцсети/сервиса). Думаю особенно красиво это смотрелось бы с специальной задержкой перед показом картинки и последовательным превращением фигур в фотографию.
В остальных случаях, как и сказал TimsTims можно использовать прогрессивный JPEG
можно же и на бэке сделать. Поставить чтобы аватарку нельзя было менять чаще чем раз в 5(10,20, 100500) раз в минуту или делать плейсхолдеры, только когда она "продержалась" 1(2,3,7, 14) дней.
Отправлять svg гораздо дешевле
При нажатии на кнопку отправить, при первом комментарии в теме писать "Вы уверены что хотите оставить этот комментарий? Данная статья является переводом".
Шутки в сторону. В шапке действительно сложно заметить эту плашку. Я мельком глянул шапку на наличие плашки "перевод" (старой — цветной, по привычке). Потом в середине текста снова усомнился и ещё раз попробовал её найти. В конце статьи, когда написали про перевод я уже пристально пытался рассмотреть в шапке плашку и вспомнил что она теперь серая.
Скорее всего зависит от трафика с твоего IP. С динамическим айпишником может на большинстве сайтов капчу требовать и по несколько раз(не просто за какой-то запрос а просто за доступ к сайту).
В каждой компании по своему. На прошлой работе была игровая с теннисом и настольныv футболом. Все играли никто не жаловался.
На новой тоже самое + х-бокс, лаундж зоны и "книжные углы".
Опять же никто не жалуется.
По поводу "лишали привозной воды" советую почитать Трудовой кодекс РФ. Это просто незаконно (пункт о том что работодатель обязан обеспечить питьевой водой).
Ну и, пожалуй, бежать от такого работодателя куда глаза глядят.
С этим никто не спорит. Я говорю что заставлять новичков писать юнит тесты это плохо. Цитата из статьи:
Как минимум, потому что лучше девелопера который написал код, юнит тесты не напишет никто.
Поэтому и существует TDD, который не только "гарантирует" что написанный функционал будет покрыт тестами, но и позволяет программисту лучше задуматься о "граничных параметрах".
Мне кажется тут лучше всего подойдёт аналогия с кузнецами "Мастер — подмастерье":
Правильный подход(имхо): Подмастерье смотрит на работу мастера, делает что-то сам. Получается криво. Мастер говорит почему.
Подход из статьи: Мастер говорит подмастерье: "убирай за мной кузницу и полируй продукт". Подмастерье убирает и полирует.
С одной стороны, да он увидит как выглядит правильный продукт, полируя его и какой инструмент для чего используется. Но почему так, ему придётся догадываться самому.
по первой части не согласен со всем:
Не знаю кем бы я был, если бы на первой работе мне бы дали код и сказали "тестируй". Лучший старт:
Тим билдинг это здорово. Нужно позволить разработчикам общаться друг с другом как им удобно. Активные разработчики, которые пытаются влиться в коллектив лучше, тех которые просто приходят молча на работу и молча смотрят в монитор. (имхо)
Как минимум потому что они будут знать кто чем занимается, и у кого можно будет спросить помощи с такой-то проблемой.