Как минимум я видел перевод статьи от одного из работников Google, который рассказывал про карьерный рост менеджеров в компании через внедрение новых фичей. Если ты будешь просто оптимизировать сервис, ты повышение не получишь. Отсюда периодические переделки интерфейса, появление новых фичей и т.д. - и проблемы с тормозами приложения, которые в последствие могут еще и усиливаться.
Статья говорит о проблеме фокусируясь в основном только на одной из причин - некомпетентности разработчика. Тогда как половина причин, а может и больше это хотелки бизнеса или внутренняя парадигма организации. Разработчик может и хочет что-то там ускорить, но всегда ли ему дадут это сделать?
На рынке конкуренция и надо выпустить MVP быстрее конкурентов? - Нафиг оптимизацию, делаем рабочий прототип на %известный фреймворк% и в продакшн. Оптимизируем потом с ростом нагрузки.
Клиенты жалуются на тормоза приложения? - Подтяните основные метрики. Если надо добавим ресурсов.
70% запросов жрет аналитика? - Ну простите уж, нам надо собирать много, много данных.
Надо провести рефакторинг и пересмотр архитектуры чтобы через пару лет все не навернулось? - Вы о чем вообще? Как я своему менеджеру прокину лишние расходы которые не принесут прибыль в текущем квартале? У нас вообще-то план есть!
А потом в Gmail тормозит интерфейс так, словно они майнят на клиенте крипту. Не думаю что в Google работают отбитые вчерашние ученики курсов, которые не могут посмотреть вне абстракции.
Хотя, причем тут ученики курсов. Тут затрагиваются архитектурные вопросы, к которым у джунов по идее не должно быть доступа. Джун не должен проектировать структуру БД. Это задача сеньора, который потом должен бить по рукам тех, кто пишет херовый код или запросы.
Желательно: поднимите публичный узел, если у вас есть сервер или белый IP. Каждый новый узел в России - это ещё одна точка, которую сложнее вырубить одним решением.
То есть, я правильно понимаю, что если это сделать, то данные этого публичного узла (сервер, собственный белый IP) будут доступны тем, кто будет заинтересован в отслеживании участников сети? А так же факт использования Yggdrasil будет известен DPI по фигнерпринту и самому провайдеру интернета, если не завернуть трафик в прокси?
А чтобы завернуть трафик в прокси, надо иметь свой сервер, в России или за пределами РФ. Если в РФ - то этот сервер можно будет связать с конкретной личностью, а если за пределами РФ - то просто заблокировать.
Как минимум я видел перевод статьи от одного из работников Google, который рассказывал про карьерный рост менеджеров в компании через внедрение новых фичей. Если ты будешь просто оптимизировать сервис, ты повышение не получишь. Отсюда периодические переделки интерфейса, появление новых фичей и т.д. - и проблемы с тормозами приложения, которые в последствие могут еще и усиливаться.
Статья говорит о проблеме фокусируясь в основном только на одной из причин - некомпетентности разработчика. Тогда как половина причин, а может и больше это хотелки бизнеса или внутренняя парадигма организации. Разработчик может и хочет что-то там ускорить, но всегда ли ему дадут это сделать?
На рынке конкуренция и надо выпустить MVP быстрее конкурентов? - Нафиг оптимизацию, делаем рабочий прототип на %известный фреймворк% и в продакшн. Оптимизируем потом с ростом нагрузки.
Клиенты жалуются на тормоза приложения? - Подтяните основные метрики. Если надо добавим ресурсов.
70% запросов жрет аналитика? - Ну простите уж, нам надо собирать много, много данных.
Надо провести рефакторинг и пересмотр архитектуры чтобы через пару лет все не навернулось? - Вы о чем вообще? Как я своему менеджеру прокину лишние расходы которые не принесут прибыль в текущем квартале? У нас вообще-то план есть!
А потом в Gmail тормозит интерфейс так, словно они майнят на клиенте крипту.
Не думаю что в Google работают отбитые вчерашние ученики курсов, которые не могут посмотреть вне абстракции.
Хотя, причем тут ученики курсов.
Тут затрагиваются архитектурные вопросы, к которым у джунов по идее не должно быть доступа. Джун не должен проектировать структуру БД. Это задача сеньора, который потом должен бить по рукам тех, кто пишет херовый код или запросы.
То есть, я правильно понимаю, что если это сделать, то данные этого публичного узла (сервер, собственный белый IP) будут доступны тем, кто будет заинтересован в отслеживании участников сети?
А так же факт использования Yggdrasil будет известен DPI по фигнерпринту и самому провайдеру интернета, если не завернуть трафик в прокси?
А чтобы завернуть трафик в прокси, надо иметь свой сервер, в России или за пределами РФ.
Если в РФ - то этот сервер можно будет связать с конкретной личностью, а если за пределами РФ - то просто заблокировать.
Или я что-то не так понял?