Поддерживаю. Все как написано так и есть. Самое смешное, что если ты можешь исправить замечание, то старое приложение уже не обновить. Надо выкладываться только с новым app id, что ведёт к потере всех оценок. Тоже бы предпочел платить $100, но иметь человеческую поддержку.
c их сайта
«Покупай ключи на нашем сайте и запускай их на Playkey.
Если у тебя уже есть ключ к доступной у нас игре,
активируй его на нашем сайте и играй!»
Но в этом и плюс стандартного механизма. Пользователю будет предлагаться запостить ссылку в ту соц. сеть/приложение, которым он пользуется, а не в то, которым пользуются разработчики.
Если посмотреть топовые приложение, то можно увидеть, что мало кто из них интегрируется с помощью SDK с другими соц. сетями. Для простого постинга ссылок — это перебор.
> не ясно как уменьшить время, которое тратится на обзор?
По факту мы это сделали с помощью автоматизации(Sonar, Confluence) рутинных действий, возникающих при проведении инспекций кода: отправка кода на ревью, отслеживания исправления дефектов, обсуждение спорных мест, автоматическое нахождение очевидных дефектов, вычисление различных метрик (сложность кода, количество комментариев, количество замечаний на класс и тд). Github, кстати, делает часть описанных вещей.
В итоге, остается только ручная проверка. При ней уже смотрится какая задача стояла и как она была реализована (логика, тесты). Без этого все равно никак.
Я не утверждаю, что утилиты — это наше все. Однако, они дают хорошую отправную точку в анализе кода.
> что делать с недобросовестным обзором?
Недобросовестный обзор бесполезен, его можно выкинуть.
Если это делается намеренно, то это саботаж. Надо разбираться в причинах.
Если разработчик говорит, что с твоим кодом все ОК, то это означает, что он теперь отвечает за этот код так же как за свой со всеми вытекающими из этого последствиями.
вы правильно сказали «очень сильно зависит от команды». Если это 3 опытных программиста то объем замечаний минимален и достаточно посмотреть коммиты. Но часто в команде есть всегда неопытный программист, за кодом которого необходимо внимательно следить и проверять, что все замечания были исправлены. Тут уже помощь специальных средств ощутима
Руководству нет необходимости знать о внутренностях проекта, углубляться в технические решения. Для них как раз высчитываются свои метрики, например, размер технического долга (http://www.sonarqube.org/evaluate-your-technical-debt-with-sonar/). Так, если он постоянно растет, то это сигнал о проблемах на проекте. Также Sonar поддерживает SQALE (http://en.wikipedia.org/wiki/SQALE).
Архитекторам (или техническим лидерам) уже предоставляется больше интересной для них информации. Они, естественно, уже в курсе деталей проекта (архитектуры, установленных правил). Sonar с легкостью покажет проблемные местах в проекте (содержащих большое количество замечаний), подозрительные зависимости, недостаток комментариев, недостаток покрытия кода тестами, дублирование кода. Вся эта информация им необходима для отслеживания того, что архитектура проекта развивается в правильном направлении и соблюдаются установленные стандарты кодирования.
Даже если код не ваш, то наличие в нем замечаний с приоритетом critical очень тревожный звоночек. Дальше можно обратить внимание на зависимости — присутствие в них циклов обычно говорит о проблемах в архитектуре. Отсутствие комментариев грозит тем, что на исправление багов или добавление функционала вы будете тратить больше времени, чем при их наличии.
есть один важный момент, с которыми пришлось столкнуться.
jmdns использует мультикаст, но не все андроид устройства его поддерживают.
Пытались также использовать WiFi-direct, но он нормально так и не заработал у нас. Обнаружение устройств работало отлично. А вот если происходило несколько коннектов/дисконнектов то устройства в итоге переставали подключаться друг другу. В итоге перешли на использование jmdns
1. именование у вас не единообразно — где-то «currentTimeMillis», где-то «default_timeout».
2. ну и оно у вас вообще компилируется?? В имени класса выпишете, через «с», а в конструкторе через «s»:
public class Caсhe<K, V> {
…
public Cashe(long default_timeout) throws Exception {
3. Странный у вас hashCode(). В чем смысл того, что вы прибавляете «43*7» к hashCode() ключа?
public int hashCode() {
int hash = 7;
hash = 43 * hash + (this.key != null? this.key.hashCode(): 0);
return hash;
}
Поддерживаю. Все как написано так и есть. Самое смешное, что если ты можешь исправить замечание, то старое приложение уже не обновить. Надо выкладываться только с новым app id, что ведёт к потере всех оценок. Тоже бы предпочел платить $100, но иметь человеческую поддержку.
«Покупай ключи на нашем сайте и запускай их на Playkey.
Если у тебя уже есть ключ к доступной у нас игре,
активируй его на нашем сайте и играй!»
Видимо, покупаешь игру + платишь за время.
Интересно глянуть его с вашим приложением и без него. Особенно строчку с awake.
Я думаю, если приложение все ночь будит устройство каждые 5 минут (проснуться+слазить в интернет), то батарейка должна заметно садится.
А вообще пройдитесь checkstyle, pmd, findbug. Настройте автоформатирования кода в IDE. Посмотрите как оформлены другие библиотеки на github.
Но в этом и плюс стандартного механизма. Пользователю будет предлагаться запостить ссылку в ту соц. сеть/приложение, которым он пользуется, а не в то, которым пользуются разработчики.
Если посмотреть топовые приложение, то можно увидеть, что мало кто из них интегрируется с помощью SDK с другими соц. сетями. Для простого постинга ссылок — это перебор.
По факту мы это сделали с помощью автоматизации(Sonar, Confluence) рутинных действий, возникающих при проведении инспекций кода: отправка кода на ревью, отслеживания исправления дефектов, обсуждение спорных мест, автоматическое нахождение очевидных дефектов, вычисление различных метрик (сложность кода, количество комментариев, количество замечаний на класс и тд). Github, кстати, делает часть описанных вещей.
В итоге, остается только ручная проверка. При ней уже смотрится какая задача стояла и как она была реализована (логика, тесты). Без этого все равно никак.
Я не утверждаю, что утилиты — это наше все. Однако, они дают хорошую отправную точку в анализе кода.
> что делать с недобросовестным обзором?
Недобросовестный обзор бесполезен, его можно выкинуть.
Если это делается намеренно, то это саботаж. Надо разбираться в причинах.
Если разработчик говорит, что с твоим кодом все ОК, то это означает, что он теперь отвечает за этот код так же как за свой со всеми вытекающими из этого последствиями.
вы правильно сказали «очень сильно зависит от команды». Если это 3 опытных программиста то объем замечаний минимален и достаточно посмотреть коммиты. Но часто в команде есть всегда неопытный программист, за кодом которого необходимо внимательно следить и проверять, что все замечания были исправлены. Тут уже помощь специальных средств ощутима
Архитекторам (или техническим лидерам) уже предоставляется больше интересной для них информации. Они, естественно, уже в курсе деталей проекта (архитектуры, установленных правил). Sonar с легкостью покажет проблемные местах в проекте (содержащих большое количество замечаний), подозрительные зависимости, недостаток комментариев, недостаток покрытия кода тестами, дублирование кода. Вся эта информация им необходима для отслеживания того, что архитектура проекта развивается в правильном направлении и соблюдаются установленные стандарты кодирования.
Даже если код не ваш, то наличие в нем замечаний с приоритетом critical очень тревожный звоночек. Дальше можно обратить внимание на зависимости — присутствие в них циклов обычно говорит о проблемах в архитектуре. Отсутствие комментариев грозит тем, что на исправление багов или добавление функционала вы будете тратить больше времени, чем при их наличии.
codereviewdesignreview для дизайнеров надо устраиватьRestAdapter.Builder().setServer(..).setClient(new ApacheClient(client))Пример клиента для Apache Http можно посмотреть тут: github.com/square/retrofit/blob/master/retrofit/src/main/java/retrofit/client/ApacheClient.java
cafbit.com/entry/testing_multicast_support_on_android
jmdns использует мультикаст, но не все андроид устройства его поддерживают.
Пытались также использовать WiFi-direct, но он нормально так и не заработал у нас. Обнаружение устройств работало отлично. А вот если происходило несколько коннектов/дисконнектов то устройства в итоге переставали подключаться друг другу. В итоге перешли на использование jmdns
2. ну и оно у вас вообще компилируется?? В имени класса выпишете, через «с», а в конструкторе через «s»:
public class Caсhe<K, V> {
…
public Cashe(long default_timeout) throws Exception {
3. Странный у вас hashCode(). В чем смысл того, что вы прибавляете «43*7» к hashCode() ключа?
public int hashCode() {
int hash = 7;
hash = 43 * hash + (this.key != null? this.key.hashCode(): 0);
return hash;
}