Под сборкой я подразумеваю собранный APK файл с изменениями, которые внёс разработчик. Обычно, у нас 2 пути: первый — это сразу собрать на телефон приложение и отдать в тестирование, второй — это дождаться сборки пул реквеста и после этого он выкладывается на ресурс, с которого его могут скачать тестировщики и уже начать тестирование.
Разделения по модулям у нас происходит по принципам GRASP, тема довольно таки обширная. Если в двух словах, то мы разбиваем модули по продуктам, а в свою очередь общий функционал выносится в модули более низкого уровня и от него уже наследуются продуктовые модули. Про модульность хорошо было рассказано на Mobius 2018 Piter, у нас подобное разделение
Порой бывало, что разработчик отдавал сборку, предварительно не проверив, поэтому ввели такое жесткое правило
То есть у вас разработчики никак не влияют на новые фичи? То есть обоснованность и возможность реализации не обсуждается?
Разработчики могут влиять на фичи и могут предлагать добавить какой-то функционал, но этот переход выходит за рамки простой фичи, это скорее фундаментальное изменение, поэтому такое решение принимало руководство
То есть до этого разработчик что-то написал, заккомитил и сказал что все ок? Ни проверить, ни потестить?
Альфа тестирование как раз предполагает, что сам разработчик должен протестировать написанную им фичу и только потом коммитить код и отдавать уже тестировщику тестить.
А так убило новведение по использованию push'ей ВМЕСТО СМС. Это уже совсем никуда не годится. Я за СМС оповещения деньги плачу, почему меня принудительно (без каких-либо оповещений) переводят на push-only?
К сожалению, я не могу Вам ответить по поводу таких нововведений, так как это решают совсем не разработчики
Более того, у меня стояло приложение от UI-тестов к моему приложению. Сбербанк-клиент начал кричать что это вирус, все плохо и надо его удалить, иначе в отделение побежите.
Антивирусные проверки с каждым разом становятся всё лучше, к сожалению, сейчас возникают некоторые проблемы, но с каждой версией проверки будут улучшаться
Спасибо большое за совет. К сожалению, мы узнали о Kakao уже после того, как написали свой фреймворк для облегчения написания UI тестов и переходить на другой инструмент уже было нецелесообразно. А так Ваше решение нам очень понравилось
Если бы начинали проект с нуля, то базовый стек выглядел бы следующим образом: Общая архитектура Clean или Hexagonal, мета архитектурные паттерны по надобности, потому что для одной фичи может хорошо зайти MVVM, а для другой достаточно MVP, для БД выбрали бы Room, а для асинхронки скорее всего корутины, т.к. в октябре их уже должны зарелизить в версии 1.0, вероятно, там будут новые интересные возможности добавлены. И для нового проекта точно старался бы не использовать кодогенерацию, потому-что из-за неё страдает скорость сборки
Мы брали в проработку изучение этой проблемы. Были рассмотрены Lombok, AutoValue и Kotlin data class. По итогу остановились на Котлине, не только из-за удобства дата классов, а еще для того, чтобы в дальнейшем полностью перейти на него и начать изучение с небольших шагов, так как команда очень большая и уровень разработчиков разный. Поэтому начали с тестов и дата классов, дальше будем проводить обучение и наращивание кода на котлине.
Вы в курсе, что он не обфусцирует код, а минифицирует?
Он и обфусцирует и минифицирует. В данном случае, запутывание происходит за счёт переименовывания классов, методов и полей, чтобы их было сложнее читать, но не даёт гарантии от того, что нельзя будет разобраться в «мусорных» названиях методов.
А тут есть примеры работы ProGuard
Торчат наружу методы — и чего? Это возможность для кибератаки? о_О'
Проще восстановить API для работы с сервером, точнее, будет лежать уже готовый API, который можно копировать и вставлять к себе в проект.
Что за ересь про тестирование геттеров и сеттеров?
Если поведение геттера и сеттера производит какие то манипуляции с данными, например, конвертация в другой формат, то у нас обязательное требование на тестирование таких методов
Это написано не для разжигания споров, а как раз для того, чтобы они утихли. Этот абзац можно было бы пропустить, если бы не было споров о том, DI это или SL. Многие ссылаются на авторитетное мнение стороннего разработчика из гугла, я же предоставил объяснение от создателя библиотеки. Своё личное мнение по данному вопросу я так же высказал, что это все просто поиск смысла в формулировке, а не в том, что делает либа
Разделения по модулям у нас происходит по принципам GRASP, тема довольно таки обширная. Если в двух словах, то мы разбиваем модули по продуктам, а в свою очередь общий функционал выносится в модули более низкого уровня и от него уже наследуются продуктовые модули. Про модульность хорошо было рассказано на Mobius 2018 Piter, у нас подобное разделение
Порой бывало, что разработчик отдавал сборку, предварительно не проверив, поэтому ввели такое жесткое правило
Разработчики могут влиять на фичи и могут предлагать добавить какой-то функционал, но этот переход выходит за рамки простой фичи, это скорее фундаментальное изменение, поэтому такое решение принимало руководство
Альфа тестирование как раз предполагает, что сам разработчик должен протестировать написанную им фичу и только потом коммитить код и отдавать уже тестировщику тестить.
К сожалению, я не могу Вам ответить по поводу таких нововведений, так как это решают совсем не разработчики
Антивирусные проверки с каждым разом становятся всё лучше, к сожалению, сейчас возникают некоторые проблемы, но с каждой версией проверки будут улучшаться
Мы брали в проработку изучение этой проблемы. Были рассмотрены Lombok, AutoValue и Kotlin data class. По итогу остановились на Котлине, не только из-за удобства дата классов, а еще для того, чтобы в дальнейшем полностью перейти на него и начать изучение с небольших шагов, так как команда очень большая и уровень разработчиков разный. Поэтому начали с тестов и дата классов, дальше будем проводить обучение и наращивание кода на котлине.
Не совсем, это больше было требование отдела безопасности
Да, это ProGuard.
Документация от Google
Он и обфусцирует и минифицирует. В данном случае, запутывание происходит за счёт переименовывания классов, методов и полей, чтобы их было сложнее читать, но не даёт гарантии от того, что нельзя будет разобраться в «мусорных» названиях методов.
А тут есть примеры работы ProGuard
Проще восстановить API для работы с сервером, точнее, будет лежать уже готовый API, который можно копировать и вставлять к себе в проект.
Если поведение геттера и сеттера производит какие то манипуляции с данными, например, конвертация в другой формат, то у нас обязательное требование на тестирование таких методов