Андрей Седельников

Несмотря на сложившуюся практику в Андроиде сортировать классы по типам (Presenters в .presenters, Listeners в .listeners и так далее до умопомрачения) в реальном проекте с множеством классов такая схема не работает. Человеку проще воспринимать структуру построенную вокруг семантики приложения. То есть если в приложении есть главное меню а в нем переход в разделы Customers, Invoices то надо просто делать пакеты .menu, .customers, .invoices

Комментарии к коду не показательны. Насколько код и вся стуктура приложения будет понятна другому разработчику, и насколько легко можно будет приложение поддерживать и расширять, складывается из других факторов:

- Соответствие стандартам платформы (iOS, Android) - если имплементация сделана типичными для данной платформы методами, она будет понятна любому другому разработчику с данной платформы
- Зависимости между внутренними и с внешними компонентами - "перебор" с зависимостями говорит о неоптимальной архитектуре и последующей сложности расширения
- Насколько архитектура соответствует предметной области, то есть зная терминологию и специфику приложения, насколько будет понятно какие компоненты к чему относятся
- Оформление кода - громоздкие методы "длинной" больше одного экрана, неадекватные названия переменных, неоптимальная стуктура (вложенность) классов

В целом это НЕ нормально при смене подрядчик "делать все заново". Это значит к сожалению предыдущий подрядчик был ну очень непрофессионален.

Мы занимаемся разработкой приложений и можем делать аудит кода ориентировочно за 2-3 часа на приложение. Если еще есть потребность, обращайтесь на asedelnikov@appmagnetics.de

Сам себе ответил - "это не баг, это фича"

https://groups.google.com/forum/m/#!topic/adt-dev/...

Выбор Native/HTML5/Hybrid практически однозначно определяется смыслом проекта, то есть что собственно хотим построить.

Чем больше надо использовать железную часть устройства, чем больше различных сетевых коммуникаций и протоколов, чем быстрее надо чтобы все работало - тем больше смысла сразу брать натив.

И наоборот, чем больше обьем интерфейса и степень его единообразности по платформам, тем большее имеет смысл брать какой-либо кроссплатформенный фреймворк.