Аудит разработки мобильного приложения?

Question

[seva1]

Привет

Есть подрядчик, который разработал мобильное приложение для IOS и ANDROID и сейчас выходит на сдачу проекта. У нас в штате есть люди, которые могут проверить только визуальную(Frontend) составляющую работы приложений. Но вот, что там в коде, задокументирован ли он - нет.

И тут возник вопрос, а как сделать аудит внутренностей? Может быть там такой blackbox, что сменив подрядчика - мы нифига не разберемся и заново все придется делать.

Спасибо

Answer 1

[Дмитрий Энтелис]

Imho единственный способ - нанять разработчика и поставить ему задачу изучить данный код.
Готовьтесь к оценке в 80-160 часов за это.

PS В 99% случаев сменив подрядчика придется делать заново, это нормально.
Более того, т.к 70-80% работы это сборка визуальной части, - при каждом крупном редизайне лучше делать целиком заново.

Answer 2

[Rockerman]

Если разработчику приходится документировать код, значит это говорит о плохом качестве кода (код должен быть самодокументируем), или о сложных и неочевидных алгоритмах. В последнем случае нормально оставлять комментарии если предметная область действительно сложная. В остальных случаях обилие комментариев - признак плохого когда.

Answer 3

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

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

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

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

Мы занимаемся разработкой приложений и можем делать аудит кода ориентировочно за 2-3 часа на приложение. Если еще есть потребность, обращайтесь на [e-mail]