проблемы будут, но их станет меньше же — текущее решение еще хуже. ревизий много и они все от разных программистов, с разными ошибками. невозможно даже проверить — используем ли мы один тон общения везде на сайте. насчет внешних источников — эти тексты и так все публичные как правило, не должно быть проблемой
Вот это уже ближе ага, в Гугле не мог найти его
Немного уровень более низкий (репозитории, а не фреймворки), наверное, будет требоваться, чтобы тексты в отдельных файлах лежали, типа lang-файлов каких-то
Да — примерно в этом идея и заключается, мы запоминаем в какой вьюхе на каких строках текст использовался (контекст), а дальше уже дело других сотрудников (не программистов) решить, переиспользовать один текст/перевод или сделать новый
Вот-вот, про это и речь — проблема видна на многих сайтах. Требовать от программистов находить правильно ID текста существующего — не сильно лучше, чем требовать от них писать красивые тексты.
Slack — это переделанный mIRC. Переделывать что-то старое, используя новые технологии и более удобный интерфейс — это очень даже хорошо. Речь о том, что все существующее — очень устаревшее и неудобное. Медленно, дорого, неэффективно
Мне кажется это замедляет разработку — программисту каждый раз надо искать в существующих текстах — есть ли что-то подобное уже. Часто видел, как начинают плодится похожие сообщения, то есть система не работает — и замедляет программиста, и не приводит к систематизированный базе текстов.
Поправить текст — минутное дело для программиста, знающего где он находится
Проблема в том, что остальные сотрудники даже не знают о существовании нового текста, который программист добавил (и программист плохо владеет русским/английским/тд языками)
Сложно следить — значит легко получить беспорядок, что видно на большом количестве сайтов, к примеру.
Посмотрел ссылки — все-таки не то, неудобно. 1) Тексты хранятся вместе с кодом, просто в отдельных файлах. Чтобы редактировать — надо делать коммиты в код, хотя логика не изменилась. 2) Ломается flow программиста, нужно замедляться и искать правильные ID текстов вроде polyglot.t(«nav.sidebar.welcome») — сделал опечатку в «nav.sidebar.welcome» и получил некрасивую страницу
Я думаю, что даже без локализации вероятно было бы удобно. Я работаю в среднем проекте с одним языком, и регулярно бывает что 1) нетехнический сотрудник нашел ошибку и хочет поправить 2) кто-то где-то нашел опечатку или грамматическую ошибку 3) сотрудники, включая программистов, не «помнят», что мы говорим юзеру в ситуации X или Y, потому что сообщения часто меняли. То есть немного не хватает одного места, откуда можно контроллировать коммуникации с пользователями — когда и что мы говорим. Даже если это один язык, просто с несколькими важность еще выше.
Да — я только в играх и мобильных приложениях что-то подобное и видел. Не смог нагуглить ни одного варианта для backend/frontend разработчиков. Похоже, что все проекты от малого до среднего размера — для них нет никакого решения
Я нигде не писал, что микросервисы – это про чистоту кода ;-) Мой тезис, что цена плохого кода в микросервисах ниже. Причины Вы сами частично назвали только что.
Про спагетти, вероятно, неудачные картинки. В Интернете ходит популярная картинка, где микросервисы с равиоли сравнивают (спагетти — плохой код 90-ых, лазанья — слои в MVC/монолитах, равиоли — микросервисы)
Думаю, что основной минус (подводный камень) — это усложнение архитектуры. Архитектор приложения должен понимать основы devops & работы сетей, облачные технологии.
Самим командам работать станет проще — с их точки зрения достаточно написать небольшое приложение, удовлетворяющее спецификациям API.
В принципе, все паттерны разработки, все «крутые» фишки ООП или функционального программирования — это всегда улучшение эффективности разработки ценой усложнения системы.
Можно написать фронт-енд на jQuery в 1000 строк, можно на Angular в 50. Второе эффективнее и проще обновляется в будущем, но требует изучения фреймворка, понимания хороших практик программирования.
Для этого есть стандартные решения, но это, безусловно, усложнение
СОА может повысить производительность для проекта с очень несимметричной нагрузкой вроде YouTube, где сервисов по транскодингу надо в сотни раз больше, чем сервисов по, скажем, публикации комментариев.
Так как шлюз API может асинхронно выполнять запросы к разным сервисам — здесь тоже можно выиграть в производительности, в зависимости от проекта.
Да, дублируются. 10-15 лет назад это бы считалось минусом, а сегодня с текущими ценами на пространство и хостинг — всем уже без разницы. Поднимите пустой проект на React — у вас зависимостей на 500-700 мегабайт скачается (это не комплимент обществу Node :). Один дополнительный хелпер или утилита не сделают погоды вообще :)
У меня каждый микросервис экспортирует документацию в формате Swagger (как и у vearutop), а данные которые полезны более, чем одному сервису транслируются в топиках SNS в формате JSON. Нет никакой сериализации объектов, так как используются разные языки и фреймворки.
Как сделать контракт на эти JSON сообщения — наверное, можно документировать формат + покрыть тестами в сервисах, которые их публикуют. Можно, наверное, и обертку для каждого языка реализовать с поддержкой версий
«Что касается масштабирования, хороший монолит не слишком уступает тут сервис-ориентированной архитектуре. Как правило все упирается в централизованные хранилища и диспетчеры.»
Все-таки уступает по себестоимости и эффективности. Масштабируя монолит, ты масштабируешь _все_ элементы приложения, а масштабируя микросервисы — только те, которым сейчас нужно больше ресурсов. А раз мы поднимаем «машину» по-меньше — то снизятся расходы на облачный хостинг, да и будет очевиднее, что нуждается в оптимизации, а что нет.
Вы привели пример еще одного объективного преимущества :)
Я пользуюсь Docker Cloud, он очень много сам за меня делает «behind the scenes». Но мне немного повезло — я сетевой инженер в прошлом, поэтому нам не пришлось нанимать devops вообще.
Немного уровень более низкий (репозитории, а не фреймворки), наверное, будет требоваться, чтобы тексты в отдельных файлах лежали, типа lang-файлов каких-то
Проблема в том, что остальные сотрудники даже не знают о существовании нового текста, который программист добавил (и программист плохо владеет русским/английским/тд языками)
Сложно следить — значит легко получить беспорядок, что видно на большом количестве сайтов, к примеру.
Я думаю, что даже без локализации вероятно было бы удобно. Я работаю в среднем проекте с одним языком, и регулярно бывает что 1) нетехнический сотрудник нашел ошибку и хочет поправить 2) кто-то где-то нашел опечатку или грамматическую ошибку 3) сотрудники, включая программистов, не «помнят», что мы говорим юзеру в ситуации X или Y, потому что сообщения часто меняли. То есть немного не хватает одного места, откуда можно контроллировать коммуникации с пользователями — когда и что мы говорим. Даже если это один язык, просто с несколькими важность еще выше.
Про спагетти, вероятно, неудачные картинки. В Интернете ходит популярная картинка, где микросервисы с равиоли сравнивают (спагетти — плохой код 90-ых, лазанья — слои в MVC/монолитах, равиоли — микросервисы)
Привести практические примеры, в принципе, не проблема. Просто не подумал! :)
Самим командам работать станет проще — с их точки зрения достаточно написать небольшое приложение, удовлетворяющее спецификациям API.
В принципе, все паттерны разработки, все «крутые» фишки ООП или функционального программирования — это всегда улучшение эффективности разработки ценой усложнения системы.
Можно написать фронт-енд на jQuery в 1000 строк, можно на Angular в 50. Второе эффективнее и проще обновляется в будущем, но требует изучения фреймворка, понимания хороших практик программирования.
СОА может повысить производительность для проекта с очень несимметричной нагрузкой вроде YouTube, где сервисов по транскодингу надо в сотни раз больше, чем сервисов по, скажем, публикации комментариев.
Так как шлюз API может асинхронно выполнять запросы к разным сервисам — здесь тоже можно выиграть в производительности, в зависимости от проекта.
У меня каждый микросервис экспортирует документацию в формате Swagger (как и у vearutop), а данные которые полезны более, чем одному сервису транслируются в топиках SNS в формате JSON. Нет никакой сериализации объектов, так как используются разные языки и фреймворки.
Как сделать контракт на эти JSON сообщения — наверное, можно документировать формат + покрыть тестами в сервисах, которые их публикуют. Можно, наверное, и обертку для каждого языка реализовать с поддержкой версий
Все-таки уступает по себестоимости и эффективности. Масштабируя монолит, ты масштабируешь _все_ элементы приложения, а масштабируя микросервисы — только те, которым сейчас нужно больше ресурсов. А раз мы поднимаем «машину» по-меньше — то снизятся расходы на облачный хостинг, да и будет очевиднее, что нуждается в оптимизации, а что нет.
Я пользуюсь Docker Cloud, он очень много сам за меня делает «behind the scenes». Но мне немного повезло — я сетевой инженер в прошлом, поэтому нам не пришлось нанимать devops вообще.