Страница 1 из 1

небольшой спор по архитектуре приложения

Добавлено: 2016.10.29, 17:55
Leviathan
Возник спор с программистом, тут он под ником godzie,

есть 2 мобильных приложений под ios и android

приложения посылают запрос к апи и получают набор векторов на бесконечной 2d плоскости которые образуют схему помещения.

далее пользователь выбирает точку куда он хочет придти и апи возвращает ему маршрут из набора векторов.
передается точка старта и точка куда надо попасть.

так вот апи реализованное godzie в случае если пользователь нажимает точку за пределами помещения(2D плоскость не имеет границ) выдает набор векторов с маршрутом прям через стены во вне.

на просьбу исправить и сделать так что бы если точка находится за пределами помещения, маршрут не выдавался godzie предложил встроить проверки того, где нажата точка, внутри помещения или во вне, в мобильные приложения, и не делать вызов к апи. типа это сэкономит трафик пользователю. правда для того что бы телефон мог обсчитать контур помещения, godzie предлагает дополнительно передавать при запросе схемы на каждый телефон периметр помещения(он предварительно рассчитывается на сервере при сохранении схемы).

я считаю что данное решение не правильное:

1. не понятно качество алгоритма построения маршрута раз он ведет сквозь стены
2. для экономии запроса из 2 координат который ошибочно будет делать 1 из 10 пользователей, которые нажмут за пределами помещения, мы будем каждому, каждый раз передавать дополнительные метаданные от 50 и больше точек(экономия сомнительная)
3. придется утраивать код, так как по мимо расчета маршрута в апи и проверки там(что логично) мы еще будем его перепроверять на телефонах.
4. усложняется поиск ошибок в коде и потенциальное количество мест где они могут возникнуть.
5. тяжелые расчеты перекладываем с сервера на телефоны пользователей с разными вычислительными мощностями.

аргументы godzie:

меньше запросов к серверу, + это логично со стороны клиент серверной архитектуры. Если вы вводите буквы в маску телефона это обрабатывается на клиенте в первую очередь. Тоесть ва целом я считаю что проверять надо и там и там тогда уж.

можно с картой присылать периметр этажа и тогда расчеты детские будут, ну это будет точек 50-100 даже для больших помещений


Так как мы не смогли решить, кто из нас прав, хотим спросить форум.

Re: небольшой спор по архитектуре приложения

Добавлено: 2016.10.29, 18:03
ElisDN
Leviathan писал(а):так вот апи в случае если пользователь нажимает точку за пределами помещения (2D плоскость не имеет границ) выдает набор векторов с маршрутом прям через стены во вне.
Это косяк алгоритма и API. Добавлять клиентсткую проверку на символы телефона и на помещения или нет - это по желанию, а API должен идеально работать всегда. Оправдания и переводы стрелок здесь неуместны.

Re: небольшой спор по архитектуре приложения

Добавлено: 2016.10.31, 14:14
maleks
godzie, знакомьтесь:
книга "Чистый код. Создание, анализ и рефакторинг", автор - Роберт Мартин, глава 17 - Запахи и эвристические правила. Запах G3 (Некорректное граничное поведение):
Код должен работать правильно — вроде бы очевидное утверждение. Беда в том,
что мы редко понимаем, насколько сложным бывает правильное поведение. Раз-
работчики часто пишут функции, которые в их представлении работают, а затем
доверяются своей интуиции вместо того, чтобы тщательно проверить работоспо-
собность своего кода во всех граничных и особых ситуациях.
Усердие и терпение ничем не заменить. Каждая граничная ситуация, каждый
необычный и особый случай способны нарушить работу элегантного и интуитив-
ного алгоритма. Не полагайтесь на свою интуицию. Найдите каждое граничное
условие и напишите для него тест.

Re: небольшой спор по архитектуре приложения

Добавлено: 2016.10.31, 15:06
zelenin
maleks писал(а):книга "Чистый код. Создание, анализ и рефакторинг", автор - Роберт Мартин, глава 17 - Запахи и эвристические правила. Запах G3 (Некорректное граничное поведение):
вопрос в том, кто определяет правильное поведение. Очевидно, заказчик в ТЗ не описал правильное поведение, исполнитель понял по свОему, теперь заказчик спохватился, а исполнитель не хочет шевелиться.

Мне очевидно, что оба правы и не правы. Апи должно быть доработано, чтобы не выдавать невалидные маршруты. Приложения должны быть доработаны, чтобы производить клиентскую валидацию на тычок вне помещения. Но апи - это алгоритм, а клиентская валидация - ux. Фикс алгоритма в приоритете.

Ну а для экономии бюджета по договоренности можно что-то одно пофиксить.

Re: небольшой спор по архитектуре приложения

Добавлено: 2016.10.31, 22:39
Leviathan
zelenin писал(а):
maleks писал(а):книга "Чистый код. Создание, анализ и рефакторинг", автор - Роберт Мартин, глава 17 - Запахи и эвристические правила. Запах G3 (Некорректное граничное поведение):
вопрос в том, кто определяет правильное поведение. Очевидно, заказчик в ТЗ не описал правильное поведение, исполнитель понял по свОему, теперь заказчик спохватился, а исполнитель не хочет шевелиться.

Мне очевидно, что оба правы и не правы. Апи должно быть доработано, чтобы не выдавать невалидные маршруты. Приложения должны быть доработаны, чтобы производить клиентскую валидацию на тычок вне помещения. Но апи - это алгоритм, а клиентская валидация - ux. Фикс алгоритма в приоритете.

Ну а для экономии бюджета по договоренности можно что-то одно пофиксить.

По вашему в ТЗ надо писать, что маршрут не должен идти сквозь стены? ))
Тогда это уже не маршрут - можно просто начальную и конечную точку соединить и все!

Так можно договорится, что в ТЗ надо сразу все исключения прописывать и правила их обработки.
А то программист когда пишет видимо не должен их обрабатывать если они в ТЗ не указаны.
Тогда проще самому сесть и написать, чем каждую запятую в ТЗ прописывать.

И где тут экономия бюджета? Один программист исправляет свой код, или 2 программиста(android ios) пишут проверку его кода?

Re: небольшой спор по архитектуре приложения

Добавлено: 2016.10.31, 22:46
zelenin
Leviathan писал(а):По вашему в ТЗ надо писать, что маршрут не должен идти сквозь стены? ))
необходимо. Необходимо описать результат, при котором алгоритм будет считаться валидным.
Leviathan писал(а):И где тут экономия бюджета? Один программист исправляет свой код, или 2 программиста(android ios) пишут проверку его кода?
экономия бюджета: апи или аппы фиксить по выбору или все оба.

Re: небольшой спор по архитектуре приложения

Добавлено: 2016.11.01, 00:30
Leviathan
даже не знаю, что ответь, что бы не обидеть, по моему вы просто флудите не по теме.
и в данном конкретном случае, говорить о том, что надо писать в ТЗ, что бы маршрут не проходил сквозь стены - это маразм.

большая просьба - не переносите свои личные обиды на заказчиков, которые вам плохо пишут ТЗ в эту тему.
не надо домысливать за нас, как было поставлено ТЗ и что в нем было прописано.

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

по экономии бюджета - она достигается только в одном случае - правится АПИ, правка приложений бюджет не экономит,
надеюсь вы хотя бы тут со мной согласитесь.

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

выводы о ваше квалификации пусть каждый делает сам, не буду комментировать.

в любом случае тема не про написание ТЗ и не про экономию бюджета.
поэтому просьба, если нечего сказать по существу - не флудите.

Re: небольшой спор по архитектуре приложения

Добавлено: 2016.11.01, 00:48
zelenin
Leviathan писал(а):даже не знаю, что ответь, что бы не обидеть, по моему вы просто флудите не по теме.
по-моему вы начали флудить не по теме, навязывая мне "правильный" для вас ответ на ваш же вопрос
Leviathan писал(а):и в данном конкретном случае, говорить о том, что надо писать в ТЗ, что бы маршрут не проходил сквозь стены - это маразм.
Leviathan писал(а):давайте для вашего душевного успокоения, я скажу, что требования не прокладывать маршрут сквозь стены было
ясно
Leviathan писал(а):большая просьба - не переносите свои личные обиды на заказчиков, которые вам плохо пишут ТЗ в эту тему.
без психологии пожалуйста. это же не ваш профиль?
Leviathan писал(а):не надо домысливать за нас, как было поставлено ТЗ и что в нем было прописано.
все что написано в ТЗ по факту обсуждать бессмысленно. Если обсуждаем, значит этого в ТЗ не было.
Я же написал: надо править и то и другое. Но для экономии бюджета можно исправить одно, и приоритет у апи. Еще перефразировать?
Leviathan писал(а):судя по вашей позиции с бюджетом, вы допускаете вариант - оставить апи как есть и исправить приложения.

выводы о ваше квалификации пусть каждый делает сам, не буду комментировать.
вы тут обиженку пришли из себя строить?

Re: небольшой спор по архитектуре приложения

Добавлено: 2016.11.01, 01:12
Leviathan
1. ничего я вам не навязываю - принял вашу позицию к сведению, о чем и написал.

2. психология не мой профиль, но и вы не экстрасенс. поэтому не надо за меня домысливать, что было в ТЗ, а чего не было.

3. что написано в ТЗ вы не знаете, но почему то продолжаете утверждать.
я всего лишь написал, что не надо в маразм с ТЗ впадать и теоретически рассуждать какой плохой очередной заказчик.
вы меня не знаете и со мной не работали, да и вопрос не про это.

вы явно переносите свой негативный опыт не к месту.

" Если обсуждаем, значит этого в ТЗ не было." - блестящая логика.

ваши цитаты:

"Ну а для экономии бюджета по договоренности можно что-то одно пофиксить."
"экономия бюджета: апи или аппы фиксить по выбору или все оба."

видимо да, надо перефразировать. не понятно.

4. что то не уловил в моих цитатах намека, что я обижен ))))) за уши не надо притягивать.
ну и в догонку:
"без психологии пожалуйста. это же не ваш профиль?"

Re: небольшой спор по архитектуре приложения

Добавлено: 2016.11.01, 01:18
Leviathan
zelenin писал(а): Я же написал: надо править и то и другое. Но для экономии бюджета можно исправить одно, и приоритет у апи. Еще перефразировать?
вообще конечно логика железная, в начале поста вы мне пишите, что я навязываю свое мнение, но если судить по этой цитате оно у нас совпадает.

тогда что я вам навязываю?

Re: небольшой спор по архитектуре приложения

Добавлено: 2016.11.01, 01:33
zelenin
Leviathan писал(а):ваши цитаты:

"Ну а для экономии бюджета по договоренности можно что-то одно пофиксить."
"экономия бюджета: апи или аппы фиксить по выбору или все оба."
эту еще приложите:
Фикс алгоритма в приоритете.
3. что написано в ТЗ вы не знаете, но почему то продолжаете утверждать.
я всего лишь написал, что не надо в маразм с ТЗ впадать и теоретически рассуждать какой плохой очередной заказчик.
вы меня не знаете и со мной не работали, да и вопрос не про это.

вы явно переносите свой негативный опыт не к месту.

" Если обсуждаем, значит этого в ТЗ не было." - блестящая логика.
ТЗ заказчика для меня не негативный опыт, а данность работы. Поэтому все что я высказываю про ТЗ это лишь логические предположения, основанные на опыте. Откуда ж я знаю что там в ТЗ было? Просто уместность обсуждения недоработки по ТЗ для меня сомнительна.
Да и фрилансить я бросил уже годы назад, поэтому на все это взираю с точки зрения холодного разума.
вообще конечно логика железная, в начале поста вы мне пишите, что я навязываю свое мнение, но если судить по этой цитате оно у нас совпадает.
именно. но вы этого сразу не поняли, и с места в карьер начали меня переубеждать)