Понятно, что там где нет code-review все будет очень плохо, сам работал без него однажды
Использовать дефолтные настройки не очень правильно, потому что у разработчиков могут быть разные IDE с разными дефолтными настройками. Разумно иметь единый источник правил, чтобы у всех разрабов был единый формат кода (был случай, когда поменял одну строку, но переформатировался весь файл).
"Спецификация дизайн", опечатался немного (спецификация или дизайн-ревью), но подразумевал спецификацию решения, или дизайн ревью решения. Какая-то активность, результатом которой будет описание технического решения, которое устроит остальных разработчиков, системных аналитиков или архитекторов (смотря какая команда)
Кажется разумным автоматизировать все, что можно автоматизировать: линтеры/форматтеры кода и прочие плюшки, которые делают код красивым. Чтобы не тратить на это время при ревью.
Иметь набор договоренностей и стайлгайды, которым следует команда. Но они могут пересматриваться
Делать какую-то спецификацию дизайн разумно, если делается что-то новое. Можно выделить отдельным этапом во флоу разработки, и еще на этапе анализа понять как делать.
Именно бизнес-полопёку лучше получать из интеграционных тестов, или е2е-тестов, так как они отображают юзер-кейсы. А вот суть того, как работает конкретный метод/функция можно узнать из юнит-теста. Конечно, в первую очередь стоит смотреть на документацию/ТЗ и на сам код. Самый частый кейс, когда тест рассматривается в качестве документации, если он упадет, тогда описание теста как раз скажет, как работал код.
Полностью согласен с тем, что тесты - это не цель разработки и, тем более, не религия. В статье я хотел сказать, что тесты - это инструмент, который помогает совершать меньше ошибок, и им нужно научиться пользоваться.
Покрыть тестами полностью приложение нельзя, и большим ограничением, чем математика, выступают сроки и требования к системе. Если пишем прошивку для самолета или кардиостимулятора - нужно больше тестов, если у нас лендинг - ему тесты могут и вовсе не нужны. Если же требования допускают вольность, то тут стоит обратиться к договоренностям, чтобы тесты или их отсутствие не стали проблемой
Как уже сказал @ws233 тесты часто похожи, например, если у нас есть два сервиса суть которых только делать запрос на бэкенд, но с разными url-ами, то их тесты будут практически копиями. Также часть тестов могут быть параметризированными, если считать их за несколько. А некоторые тесты делаются копированием, например, если проверяем функцию, которая на вход может принять строку, null и undefined, в таком случае два последних кейса будут копией, только разные входные аргументы.
Могут быть и сложные legacy-моменты, когда проще переписать код и только потом написать тесты, или же при написании тестов зависимости настолько запутанны, что их невозможно замокать. В таких случаях написать 5 тестов за день может быть рекордом, но в остальных случаях, можно запросто написать 15-20 тестов без проблем.
Я бы добавил еще вопрос о том, как можно еще обезопасить форму от перебора. И как вариант - capcha при нескольких неправильных попытках входа. Также можно следить за количеством неудачных попыток (или количеством попыток входа в секунду или за промежуток времени) и вводить какое-то временное ограничение на вход, например "следующую попытку входа можно осуществить через 5 минут"
Помню, как решал подобную проблему, была таблица, и в каждой строке было выпадающее меню, которое подписывалось на событие resize и scroll для закрытия (писали на Angular без использования onPush). При 10-20 записях все было хорошо, но при 100 записях все начинало тормозить, любое событие resize или scroll вызывало фриз на 1,7-1,8 секунды. Договорился с аналитиками, что можно заменить все на css, принеся в жертву открытие на клик мыши. Стало работать за 2-3мс. (Сейчас я бы там все переписал по нормальному, но тогда это было тоже крутое ускорение)
Как вариант можно циклом вычислять разницу, способ конечно примитивный, но работать будет.
let sub = function(a,b){
let result = 0;
let start = b;
let end = a;
if (a >= b) {
for (let i = start; i<end; i++) {
result++;
}
}
else {
for (let i = end; i<start; i++) {
result--;
}
}
return result;
}
Весьма интересна ситуация, когда автомобиль попадает из одной страны в другую, где разнонаправленные движения. Из Франции (правостороннее) автомобиль через паромную переправу попадает в Англию (левостороннее). И если автопилот обучается, то что с ним будет при таком переходе, если для человека такой переход может быть сложен и привести к неочень хорошим последствиям?
В принципе идея хорошая, правда конечно она не спрогнозирует целый ряд правонарушений, такие как хакерские атаки и тому подобное. Но, в принципе, имея довольно большую статистику, хороший алгоритм обработки этих данных, а если повезет то и какую-нибудь нейронную сеть, то можно делать довольно большую кучу прогнозов из разных областей.
Если придумать наиболее безболезненную процедуру идентификации пользователей, то тогда это не должно вызвать проблем. Если трезво взвесить всю ситуацию, то скорее всего будет меньше анонимности в сети, да и можно будет вычислить физическое расположение человека. Если вы бандюган, то увы, вам не понравиться такое стечение обстоятельств, ну а если вы простой гражданин, то за вами наверное никто не захочет следить. Из сильных минусов системы можно выделить только процесс идентификации пользователя, а второе — хранение учетных данных пользователя, где и кем неизвестно и в каких условиях тоже, поживиться базой данных о большом количестве пользователей куда интересней, чем взламывать каждого по отдельности. С другой стороны, все же плюсы есть: возможность отслеживания местоположения человека в реальном времени, для спец.служб. Ну и бесплатный сыр бывает только в мышеловке.
Но возможно, если делают систему, которая тормозит за человека в экстренной ситуации, но возможно, что появятся и системы, которые не дадут в какой-то ситуации перестроиться, не даст автомобилям «притираться» друг с другом и тому подобное (хотя в данном случает поворот руля компьютером опасен, можно такое проследить по отзывам о Ладе Калине с электроусилителем руля от Махачкалинского завода АвтоВАЗа), но можно и сделать систему, которая будет моргать лампочками и звуком ругаться на действия водителя, тоже мера сыграет какую-то роль. В общем, что-нибудь придумают, чай не дураки там работают.
Немного странный вариант акцентуации на матери ребенка или же опыт проводился в неполных семьях, так как при воспитании ребенка участвует как мать, так и отец. Так же хотелось бы узнать какие игры использовались по жанрам, так как если ведется общение, то это какой-нибудь майнкрафт или террария, потому что трудно представить проведения опыта с детьми, которые играют в Counter-Strike1.6 с целью выявления его умственных способностей.
А интересно, голос владельца как-то обрабатывается, а то придет пират с попугаем, и попугай начнет кричать «I'll pay with google», а лицо капитана совпадет с базой и все, покупай биг-мак из-за птицы. В принципе система может получить большое количество различных розыгрышей, при должном уровне подготовки.
И интересно, каков уровень энергопотребления, так как не всегда и не все отключают различные «потребители энергии» (типа wi-fi), насколько такое приложение сократит время использования устройств.
Скорее всего автомобили подъедут с разными расстояниями и скоростями, и в разные временные интервалы (конечно это секунды), и если человека это заставит затупить задуматься, то для компьютера это скорее всего будет обычное вычисление по правилам системы.
Ну, утверждать я не берусь, это было предположение. Просто, если бы в телефоне был бы бэкдор, то скорее всего был бы узкий круг специалистов, которые о нем бы знали и скорее всего они бы уже вскрыли бы этот конкретный аппарат и не поднимали бы такого шума. И можно сказать, что у Apple есть большой штат специалистов по взлому разных мастей. Но держать какие-то средства взлома внутри компании, я не вижу смысла, так как велика вероятность, что он покинет пределы компании, попав в сервисные центры, а там может через "плохих специалистов" получить распространение. Но как с этим делом обстоят дела на самом деле в Apple я не знаю.
А делать как вариант прошивку с бэкдором и без него, как-то странно. Кроме одного варианта, если использовать обновление, которое отключит средства защиты внутри телефона после обновления, но это тоже потенциально опасно. И скорее всего, если есть возможность отключить обновления на заблокированном аппарате, то обновить его будет трудно. Смысла нет в создании бреши, которая погубит весь продукт
Ответ был не Вам, а общим комментарием к статье)
Понятно, что там где нет code-review все будет очень плохо, сам работал без него однажды
Использовать дефолтные настройки не очень правильно, потому что у разработчиков могут быть разные IDE с разными дефолтными настройками. Разумно иметь единый источник правил, чтобы у всех разрабов был единый формат кода (был случай, когда поменял одну строку, но переформатировался весь файл).
"Спецификация дизайн", опечатался немного (спецификация или дизайн-ревью), но подразумевал спецификацию решения, или дизайн ревью решения. Какая-то активность, результатом которой будет описание технического решения, которое устроит остальных разработчиков, системных аналитиков или архитекторов (смотря какая команда)
Кажется разумным автоматизировать все, что можно автоматизировать: линтеры/форматтеры кода и прочие плюшки, которые делают код красивым. Чтобы не тратить на это время при ревью.
Иметь набор договоренностей и стайлгайды, которым следует команда. Но они могут пересматриваться
Делать какую-то спецификацию дизайн разумно, если делается что-то новое. Можно выделить отдельным этапом во флоу разработки, и еще на этапе анализа понять как делать.
Приветствую! Спасибо что заметил баг и не промолчал! Я передал его команде разработки мобильного приложения.
Рекомендую заводить баги через чат поддержки или через обратную связь в мобильном приложении, так точно он попадет к разработчикам раньше)
Именно бизнес-полопёку лучше получать из интеграционных тестов, или е2е-тестов, так как они отображают юзер-кейсы. А вот суть того, как работает конкретный метод/функция можно узнать из юнит-теста. Конечно, в первую очередь стоит смотреть на документацию/ТЗ и на сам код. Самый частый кейс, когда тест рассматривается в качестве документации, если он упадет, тогда описание теста как раз скажет, как работал код.
Полностью согласен с тем, что тесты - это не цель разработки и, тем более, не религия. В статье я хотел сказать, что тесты - это инструмент, который помогает совершать меньше ошибок, и им нужно научиться пользоваться.
Покрыть тестами полностью приложение нельзя, и большим ограничением, чем математика, выступают сроки и требования к системе. Если пишем прошивку для самолета или кардиостимулятора - нужно больше тестов, если у нас лендинг - ему тесты могут и вовсе не нужны. Если же требования допускают вольность, то тут стоит обратиться к договоренностям, чтобы тесты или их отсутствие не стали проблемой
Как уже сказал @ws233 тесты часто похожи, например, если у нас есть два сервиса суть которых только делать запрос на бэкенд, но с разными url-ами, то их тесты будут практически копиями. Также часть тестов могут быть параметризированными, если считать их за несколько. А некоторые тесты делаются копированием, например, если проверяем функцию, которая на вход может принять строку, null и undefined, в таком случае два последних кейса будут копией, только разные входные аргументы.
Могут быть и сложные legacy-моменты, когда проще переписать код и только потом написать тесты, или же при написании тестов зависимости настолько запутанны, что их невозможно замокать. В таких случаях написать 5 тестов за день может быть рекордом, но в остальных случаях, можно запросто написать 15-20 тестов без проблем.
Я бы добавил еще вопрос о том, как можно еще обезопасить форму от перебора. И как вариант - capcha при нескольких неправильных попытках входа. Также можно следить за количеством неудачных попыток (или количеством попыток входа в секунду или за промежуток времени) и вводить какое-то временное ограничение на вход, например "следующую попытку входа можно осуществить через 5 минут"
Помню, как решал подобную проблему, была таблица, и в каждой строке было выпадающее меню, которое подписывалось на событие resize и scroll для закрытия (писали на Angular без использования onPush). При 10-20 записях все было хорошо, но при 100 записях все начинало тормозить, любое событие resize или scroll вызывало фриз на 1,7-1,8 секунды. Договорился с аналитиками, что можно заменить все на css, принеся в жертву открытие на клик мыши. Стало работать за 2-3мс. (Сейчас я бы там все переписал по нормальному, но тогда это было тоже крутое ускорение)
И интересно, каков уровень энергопотребления, так как не всегда и не все отключают различные «потребители энергии» (типа wi-fi), насколько такое приложение сократит время использования устройств.
А делать как вариант прошивку с бэкдором и без него, как-то странно. Кроме одного варианта, если использовать обновление, которое отключит средства защиты внутри телефона после обновления, но это тоже потенциально опасно. И скорее всего, если есть возможность отключить обновления на заблокированном аппарате, то обновить его будет трудно. Смысла нет в создании бреши, которая погубит весь продукт