Интересное решение, но возникает другая проблема. Мне нужно синхронизировать приложение между различными пользователями в реальном времени, ввиду чего предполагалось использовать RethinkDB, которая позволяет подписываться на изменения (не нашёл аналогичной возможности в CouchDB). Эта БД рассылает уведомления всем подписчикам, которых затронули изменения базы, но если подписаться позже, для обновления придётся заново выкачивать коллекцию целиком (всегда есть вероятность, что я чего-то не знаю). Кроме этого, насколько я понял, PouchDB синхронизирует всю базу целиком, хотя нужно синхронизировать только персональные данные.
Кирилл Тимофеев, разрабатываю корпоративные веб приложения. Стек технологий: Angular 4 + SCSS, Node.js + RethinkDB. Некоммерческий опыт с Ionic, Electron, React. Общее понимание различных языков, фреймворков и движков.
А что именно вам интересно обсудить?
Спасибо за информативный ответ, остался ещё вопрос: как рассчитывать оклад для продавца, если результат его деятельности напрямую зависит от подписанных чеков? Оплачивать попытки? Но что, если неудачные попытки были из-за низкого уровня навыков и это только уменьшает список лидов и, возможно, репутацию всей компании?
Saboteur, так я ведь не говорю, что это не важно, просто сейчас речь идёт о другом. Качество кода - это к вопросу о дальнейшей поддержки. Разделение задач - это о работоспособности продукта, когда отдельные его части соединяются между собой.
Вот почему вы приводите эти неподходящие сравнения? Я же не спрашиваю, как дизайнеры настраивают фотошоп или организуют иерархию слоёв. Какие ещё отступы? Да мне всё равно, у кого сколько пробелов, мне важна документация, по которой я смогу обращаться к api подсистемы.
Спасибо. Я бы обобщил это такими этапами:
1. разработка концепции, руководствуясь целями (вряд ли можно разделить)
2. прорисовка базовых компонентов на основе концепции (уже можно разделять)
3. создание сложных компонентов на основе базовых или готовых сложных
Филипп Грр, правильно ли я понимаю, что ПМ создаёт информационную архитектуру проекта? Или это следующий, более подробный этап планирования, которым занимается дизайнер?
* да, я пока что не силён в организационных вопросах
dimonchik2013, кто обычно проводит техническое интервью для составления ТЗ? По идее, ПМ лучше знает технические подробности, а СМ лучше умеет продать как можно больше услуг. Как быть?
Sasha Novik, речь ведь идёт не о сложной логике, которая конечно выносится в сервис, а о часто повторяющихся действиях между компонентами представления. Например, модальное окно можно показать и спрятать, внутрь положить контент и кнопки с возвращаемым результатом. Как бы такие окна не выглядели: в стиле материал, бутстрапа, чего-то оригинального - всё это разукрашивание не должно повлиять на логику взаимодействия с таким компонентом. Тогда я смогу строить составные компоненты, которые перерисовываются в нужном стиле, стоит лишь поменять оформление базовых компонентов.
vetsmen, именно. Чтобы лучше понять, как это работает, вам нужно изучить, как async/await устроены изнутри, т.е. как связаны с промисами. Или просто использовать готовые рецепты.
Спасибо, но я никогда не имел дела с сейлз-менеджерами, поэтому будет здорово прояснить этот момент подробнее.
1. Как взаимодействуют СМ и ПМ?
2. Как оплатить работу ПМ понятно, но как грамотно договариваться с СМ?
Потому, что он будет виден не только за пределами этого блока, но и всех восходящих. Поэтому да: правильнее объявлять переменные до блока или делать вычисления в отдельной функцией, чтобы присваивать результат в константу.
