"Этот код выглядит ужасно. Потому что он ужасен. Но нам все равно нужно это сделать. У нас выбор: делать это на сервере или на клиенте. Я выбираю сервер." — глубокая фраза.)))
«это же само собой разумеющееся, мы думали, что ты это сделаешь, поэтому ты это должен сделать бесплатно» — есть ли шанс представить в этот момент что заказчик может быть прав и постараться найти причину в процессе почему так произошло?
Спасибо большое за ответ.
«строительство жилого дома на загородном участке по типовому проекту сотню раз» — я как раз для этого старался ввести ограничения к статье про ИТ решения и процесс их разработки. Возможно надо добавить слово Custom. Но, понимая что ваш пример синтетический, я с вами в целом соглашусь. При этом, хочу заметить что в современном мире, учитывая особенно текущую ситуацию, есть тенденция на то что «Проектов» как таковых становится меньше и компетенции к адаптации необходимы всё больше и больше. А это в свою очередь влияет на трудность воспроизведения своего опыта и повторения оценки.
В статье описан больше сценарий исследовательской разработки. Даже перед тем как вы сможете что-то повторить 100 раз, вам необходимо будет пройти первые фазы (Gartner Hype Cycle for Emerging Technologies тут как пример может выступать), когда вы будете вырабатывать решение. И тут в зависимости от индустрии, срока жизни и изменчивости среда будет в любом случае меняться
«А самое главное, люди, носители этого опыта, поменяются, кто то уйдет, кто то обленится» — Ну так поэтому я и старался писать так же и о деятельности распространения знаний. Словом «культура» тут можно многое описать, но если в этой «культуре» нет системной деятельности по распространению знаний, то и «культура» не поможет.
Конечно, спасибо за вопрос:
Как только интернет соединение появляется- ПО проверяет автоматом обновления. Если надо обновить, то пользователю поступает запрос с возможностью отложить обновление определённое кол-во раз. После того как пользователь соглашается, то происходит обновление по пакетам асинхронно.
При этом есть альтернативное решение, но более дорогое с точки зрения реализации. Не спрашивать у пользователя хочет ли он обновится, а просто обновлять пакетами в бекграунде, а потом уже говорить пользователю что всё обновлено и делать свап данных.
Atreides07, DmitriyTitov, MrAwesome, NickPasko спасибо еще раз за ваши комментарии. Решили к ним прислушаться и немного доработать статью, добавив и раскрыв более подробно «Что сделали мы», показав схему архитектуры самого приложения, а также привести примеры того, как внедрить такое разбиение у себя в проекте.
Вот тут уже интересно=). Хочу задать пару вопросов:
1)Почему для вас фраза «продумывать архитектуру» ассоциируется в первую очередь с блокчейном и микросервисами а не с бизнесом к примеру? =) Какую для вас ценность несёт термин «достаточная» проработка архитектуры?
2)Да, прототипирование, в том числе и rapid prototyping существуют и имеют вполне себе осмысленное право на существование. При этом, хочу обратить ваше внимание что так же существует Эволюционное прототипирование. Мы к примеру так же использовали на мой взгляд удачно быстрое прототипирование в кейсе https://koniglabs.ru/case_study/1-2stundeuben%e2%80%8c/. Но при этом я не скажу что это Minimum Viable Product. Может вопрос в целях использования прототипирования? =)
Как пример: Можно сделать UX прототипирование достаточно быстро и без строчки кода. При этом цель тут понятная- изучение пользовательского опыта. Но глупо ставить к примеру целью UX прототипирования: Понять концепцию решения сложной математической задачи.
Спасибо за ответ, обновим статью и допишем, но уходить в распутывание доменов и сложной логики не хочется специально. Тут хочется показать что данный подход на уровне приложения прост в использовании.
В данной статье просто не хотелось уходить в детали решения того как базово применять данные подходы. Таких статей на мой взгляд много. Хотелось сделать именно акцент на том что применять проектирование даже и особенно на этапе MVP нужно! Что нужно с точки зрения бизнеса не забывать об архитектуре даже в те моменты, когда хочется быстро «накалбасить» решение и зарелизить что бы проверить гипотезы.
Но прочитав комментарии соглашусь что надо добавить больше тех. информации с обоснованиями в содержание.
"Этот код выглядит ужасно. Потому что он ужасен. Но нам все равно нужно это сделать. У нас выбор: делать это на сервере или на клиенте. Я выбираю сервер." — глубокая фраза.)))
«строительство жилого дома на загородном участке по типовому проекту сотню раз» — я как раз для этого старался ввести ограничения к статье про ИТ решения и процесс их разработки. Возможно надо добавить слово Custom. Но, понимая что ваш пример синтетический, я с вами в целом соглашусь. При этом, хочу заметить что в современном мире, учитывая особенно текущую ситуацию, есть тенденция на то что «Проектов» как таковых становится меньше и компетенции к адаптации необходимы всё больше и больше. А это в свою очередь влияет на трудность воспроизведения своего опыта и повторения оценки.
В статье описан больше сценарий исследовательской разработки. Даже перед тем как вы сможете что-то повторить 100 раз, вам необходимо будет пройти первые фазы (Gartner Hype Cycle for Emerging Technologies тут как пример может выступать), когда вы будете вырабатывать решение. И тут в зависимости от индустрии, срока жизни и изменчивости среда будет в любом случае меняться
«А самое главное, люди, носители этого опыта, поменяются, кто то уйдет, кто то обленится» — Ну так поэтому я и старался писать так же и о деятельности распространения знаний. Словом «культура» тут можно многое описать, но если в этой «культуре» нет системной деятельности по распространению знаний, то и «культура» не поможет.
Как только интернет соединение появляется- ПО проверяет автоматом обновления. Если надо обновить, то пользователю поступает запрос с возможностью отложить обновление определённое кол-во раз. После того как пользователь соглашается, то происходит обновление по пакетам асинхронно.
При этом есть альтернативное решение, но более дорогое с точки зрения реализации. Не спрашивать у пользователя хочет ли он обновится, а просто обновлять пакетами в бекграунде, а потом уже говорить пользователю что всё обновлено и делать свап данных.
Ответил на вопрос?
Будем рады узнать ваше мнение :)
1)Почему для вас фраза «продумывать архитектуру» ассоциируется в первую очередь с блокчейном и микросервисами а не с бизнесом к примеру? =) Какую для вас ценность несёт термин «достаточная» проработка архитектуры?
2)Да, прототипирование, в том числе и rapid prototyping существуют и имеют вполне себе осмысленное право на существование. При этом, хочу обратить ваше внимание что так же существует Эволюционное прототипирование. Мы к примеру так же использовали на мой взгляд удачно быстрое прототипирование в кейсе https://koniglabs.ru/case_study/1-2stundeuben%e2%80%8c/. Но при этом я не скажу что это Minimum Viable Product. Может вопрос в целях использования прототипирования? =)
Как пример: Можно сделать UX прототипирование достаточно быстро и без строчки кода. При этом цель тут понятная- изучение пользовательского опыта. Но глупо ставить к примеру целью UX прототипирования: Понять концепцию решения сложной математической задачи.
Но прочитав комментарии соглашусь что надо добавить больше тех. информации с обоснованиями в содержание.