Не сказать, чтобы я заметил разницу между низким качеством в юнити и высоким в бленде.
Впрочем, в бленде я тоже разницы между высоким качеством и низким тоже не заметил.
Какое количество одновременных звонков способна выдержать вышеописанная система?
Например, висящих в очередях входящих звонков, раз уж про астериск разговор завели.
Имхо «возможность обратиться к пользователю» — плохая причина, чтобы заставлять его регистрироваться.
собирать корректную статистику
Мне кажется статистика прекрасно собирается и без личных данных, уникальный id посетителя можно сгенерировать.
емайл маркетинг
Ну ок.
Подводя итоги — вам не кажется, что имеет смысл, хотя бы в формате А/Б теста, попробовать возможность потенциальному клиенту сначала создать сайт (не публичный, будем считать это неким демо-сайтом), а на последнем этапе предложить зарегистрироваться / авторизоваться через соц. сети, после чего сайт волшебным образом превращается в полноценный?
Осталось выяснить, что делать с теми, кто не закрывает за собой дверь.
А также доработать устройство входной двери, чтобы нельзя было выйти, не помыв руки.
— здраствуйте! меня Соня зовут.
— привет — привет?
— да, привет — можно вас спросить кое-что?
— Ты отвечать будешь? — буду — не буду, какая ранзица? :)))
— Это элементарная вежливость, нельзя отвечать вопросом на вопрос. — Это так Это
— Признавайся, ты же робот? — :))) учительница математики иногда говорит, что я зависаю, как плохой компьютер — приём-приём. есть тут кто? :)))
— дед пихто — это надо обдумать
Кстати обратной стороной медали будет то, что люди бизнес-стороны начнёт задумываться и о том, что иногда стоит «сделать правильно» с самого начала.
Бизнес не будет и не должен об этом задумываться, об этом задумываться должен CIO, это его работа.
Ко всему остальному это тоже относится. Прекращайте решать, как нужно думать бизнесу, это подростковый эгоцентризм.
1. В результате «самопального» рефакторинга вы скорее всего после очередного просранного срока просто окажетесь на улице. Это раз.
Рефакторинг должен быть постоянным процессом, идущим совместно вместе с любыми задачами.
Да, но ответственность за этот процесс лежит на техническом руководителе / архитекторе и договариваться с PM должен он, а не конечный разработчик.
Вариант «знаешь, я тут решил отрефакторить кое что и потратил 3 лишних дня и еще пару дней уйдёт на то, чтобы этот функционал стабилизировать» — хреновый звоночек, хотя бы потому, что разработчик не подумал, сколько времени еще понадобится на то, чтобы это протестировать, исправить мелкие баги и т.д.
3. Любым, кто имеет право делать code review и применять по итогам животворящий паяльник. В некоторых компаниях для этого даже есть специальный человек в QA подразделении.
Именно поэтому бизнес не должен принимать технических решений. В частности о том, делать рефакторинг или нет.
Не должен и, вообще говоря, не обязан. Но бизнес должен понимать сроки и риски, потому что на эти параметры также завязывается и целесообразность/окупаемость внедрения той или иной фичи.
Нельзя назвать срок «неделя», а делать три, пояснив потом, что вы решили рефакторинг сделать.
Правильный ответ в данной ситуации (для «бизнеса») такой: «В данный момент мы не можем это реализовать технически, но если мы доработаем ПО (+ 2 недели), то задача будет выполнена в течение недели после завершения доработки».
Привыкайте, что рефакторинг бизнесу нужно уметь продавать.
1. Любой рефакторинг должен быть согласован с руководителем
2. В данном случае руководитель прав — с него спрашивают функционал, а не код, поэтому при оценке «что сделал» оценивается реализованный функционал.
3. Качество кода анализируется отдельно техническим специалистом. После этого в код вносятся правки, а к разработчику применяется животворящий паяльник для корректировки поведения.
Бизнесу не нужен код, бизнесу нужен функционал и выбор приоритетов — это задача руководителя, а не разработчика.
Впрочем, в бленде я тоже разницы между высоким качеством и низким тоже не заметил.
И FPS всё равно ниже визуально.
А бинарные логи можно складировать в /dev/null
Например, висящих в очередях входящих звонков, раз уж про астериск разговор завели.
Не понял, чем это безопаснее.
Имхо «возможность обратиться к пользователю» — плохая причина, чтобы заставлять его регистрироваться.
Мне кажется статистика прекрасно собирается и без личных данных, уникальный id посетителя можно сгенерировать.
Ну ок.
Подводя итоги — вам не кажется, что имеет смысл, хотя бы в формате А/Б теста, попробовать возможность потенциальному клиенту сначала создать сайт (не публичный, будем считать это неким демо-сайтом), а на последнем этапе предложить зарегистрироваться / авторизоваться через соц. сети, после чего сайт волшебным образом превращается в полноценный?
А также доработать устройство входной двери, чтобы нельзя было выйти, не помыв руки.
— привет
— привет?
— да, привет
— можно вас спросить кое-что?
— Ты отвечать будешь?
— буду — не буду, какая ранзица? :)))
— Это элементарная вежливость, нельзя отвечать вопросом на вопрос.
— Это так Это
— Признавайся, ты же робот?
— :))) учительница математики иногда говорит, что я зависаю, как плохой компьютер
— приём-приём. есть тут кто? :)))
— дед пихто
— это надо обдумать
Бизнес не будет и не должен об этом задумываться, об этом задумываться должен CIO, это его работа.
Ко всему остальному это тоже относится. Прекращайте решать, как нужно думать бизнесу, это подростковый эгоцентризм.
Да, но ответственность за этот процесс лежит на техническом руководителе / архитекторе и договариваться с PM должен он, а не конечный разработчик.
Вариант «знаешь, я тут решил отрефакторить кое что и потратил 3 лишних дня и еще пару дней уйдёт на то, чтобы этот функционал стабилизировать» — хреновый звоночек, хотя бы потому, что разработчик не подумал, сколько времени еще понадобится на то, чтобы это протестировать, исправить мелкие баги и т.д.
3. Любым, кто имеет право делать code review и применять по итогам животворящий паяльник. В некоторых компаниях для этого даже есть специальный человек в QA подразделении.
Не должен и, вообще говоря, не обязан. Но бизнес должен понимать сроки и риски, потому что на эти параметры также завязывается и целесообразность/окупаемость внедрения той или иной фичи.
Нельзя назвать срок «неделя», а делать три, пояснив потом, что вы решили рефакторинг сделать.
Правильный ответ в данной ситуации (для «бизнеса») такой: «В данный момент мы не можем это реализовать технически, но если мы доработаем ПО (+ 2 недели), то задача будет выполнена в течение недели после завершения доработки».
Привыкайте, что рефакторинг бизнесу нужно уметь продавать.
2. В данном случае руководитель прав — с него спрашивают функционал, а не код, поэтому при оценке «что сделал» оценивается реализованный функционал.
3. Качество кода анализируется отдельно техническим специалистом. После этого в код вносятся правки, а к разработчику применяется животворящий паяльник для корректировки поведения.
Бизнесу не нужен код, бизнесу нужен функционал и выбор приоритетов — это задача руководителя, а не разработчика.