Я думаю, что главная задача, решаемая микросервисами - масштабирование части приложения при возрастании нагрузки на него. Ответственность вторична. То есть, например, если есть онлайн магазин с черной пятницей, то микросервисы дают возможность масштабировать не весь магазин с соответствующими затратами ресурсов, а только те его части, которые подвержены наибольшей нагрузке. В черную пятницу нет смысла сильно раздувать read-only каталог, зато возможно стоит апскейлить корзину и скидочный сервис. Экономия.
А описываемые автором проблемы с размазанными транзакциями - пример плохого разбиения на сервисы.
Выскажу непопулярное мнение. Мне не нравится Зен в BM. В первой HL это было отчужденное, выжженное индустриальное пространство, в котором уже действительно не осталось ресурсов, и вторжение Нихиланта на Землю ощущалось логичным. Он ощущался тем самым пограничным миром, в котором невозможно было оставаться надолго. В BM же Зен - цветущий, насыщенный, явно способный прокормить всех желающих. Красиво, конечно, захватывающе и интересно, но абсолютно, на мой взгляд, противоречит внутренней логике и сюжету.
Я не очень понимаю, каким именно образом аналитики из оригинальной статьи превратились в менеджеров. Аналитики - такие же работники, как и программисты, находятся примерно на том же уровне пищевой пирамиды. Не вижу ничего крамольного в выделении аналитиков в отдельную подкоманду при условии плотного взаимодействия с разработчиками. Лично я читаю слово «методолог» как «эксперт», эксперт в том, что программист не знает. Когда вы пишете бухгалтерский софт, вам нужен эксперт области, методолог, аналитик - как угодно. Иначе программисту придется изучать бухгалтерию. Если это отчеты - нужен методолог, который знает как это отчеты читаются в первую очередь, а не как строятся.
Также не очень понимаю, почему у автора бомбит от дачи сроков заказчику. Подписание любого контракта подразумевает подписание его на определенный срок, в течение которого работа должна быть выполнена. Нормальный адекватный процесс при этом подразумевает возможность их изменения, но в любом случае все начинается со сбора требований, их грануляризации и оценки.
Отдельным пунктом идет идея о том, что заказчику необходимо знать сроки. А деньги вам платят тоже за сроки?
В любом случае заказчику необходимо понимать, когда он это получит, чтобы подстроить свои процессы. Обеспечить железо, подготовить работников - это все не появляется ниоткуда, а требует расчета бюджета, амортизации, подготовки. Не только исполнитель делает работу, но и заказчик со своей стороны тоже.
Ну и главный мой вопрос - а как надо? Я, например, так и не понял.
Хорошая точка зрения. В принципе, да, чистый код расширяется легко и хорошо. Но все же, при написании библиотек и фреймворков лучше такие моменты закладывать изначально.
Вы категорически правы! Я в начале своей карьеры работал в телеком галере (широко известной в узких кругах), их продукт - фреймворк с безграничной возможностью конфигурации через дб модель и интерфейс модулей (и немного можно дописать джаву). Оттуда вышли десятки Senior Developer с опытом 10+, которые писали код от силы 20% этого стажа, а все остальное время занимались накликиванием конфигураций. Мой друг до сих пор там работает сениором, потому что его даже миддлом не берут, и уж тем более на зп, которую он хочет.
Парой комментариев выше написал, но повторюсь: я не утверждаю, что все интервью должно состоять лишь из этих вопросов. И уж тем более эти вопросы имеют смысл лишь для программиста с опытом и неплохим уровнем. Я с удовольствием побеседую и об опыте, и попишу на лайв-код сессии. Тем не менее, интервью, состоящее лишь из базовых вопросов, не дает хорошего представления о реальном скиле человека уровня Middle+
Не знаю, я не пользуюсь им интенсивно. Только для генерации сложных конфигураций спринга, и то потом адаптирую. Но мне кажется, многие и не задаются этим вопросом.
В целом, вы правы. Но, во-первых, я выступаю не с точки зрения интервьюера, а с точки зрения соискателя. После 10 лет разработки мне надоело одинаково отвечать на одинаковые вопросы, и на такие интервью я обычно даю отказ. Эти вопросы показывают как хорошо я подготовился, а не как хорошо я решаю боевые задачи и обеспечиваю высокий SLA при проблемах и создаю качественный код. Во-вторых, ставя себя на место интервьюера, для меня важно, что человек, с которым мне предстоит работать, вообще осознает такие концепции, как тестируемость, диагностируемость, продуктивное ревью. Он может их осознавать не совсем так, как хотелось бы мне, но гораздо хуже полное отсутствие. Здесь еще играет роль фактор собственной боли. Мне приходилось (и не единожды) работать в команде «сениоров», которые могут себе позволить класс на 3000 строк без единого теста. Лишь пару раз так напоровшись, я уже начал сам задавать вопросы «а как у вас в команде с тестами и CI/CD?». Но как соискателю, мне бы хотелось, чтобы об этом спрашивали меня.
К тому же, я не утверждаю, что все интервью должно состоять лишь из этих вопросов. Отличное дополнение для тех частей, где «просто побеседовать».
Я вообще никого не указываю в качестве виновника, вы странным образом трактуете мои слова. Равно как и про стек я не говорил в контексте компании (ей вообще по барабану), а в контексте команды, которая ей эту прибыль и делает. И тут, извините, придется знать как логирование делается в С++, а как в Java.
А касаемо ответственности, о том же и речь, что сначала тимлид и архитектор НЕ спрашивают на собеседовании "а ты тесты-то писать умеешь?", а потом начинается подсчет денег, утекших на хот-фикс. Об этом и есть статья. Требовать это надо еще при приеме на работу, тогда все всё обговорили и понимают как будут работать. И вот уже тогда можно искать "виновника", который эти договоренности (желательно еще и зафиксированные как Corporate code style) нарушил.
UPD: а еще вы совершенно неверно поняли контекст статьи. Это не вопросы, которые я бы задал кому-то, чтобы понять, нравится он мне или нет. Это вопросы, которые я бы хотел услышать. Чтобы их задавали мне.
Не совсем с вами согласен. Тестируемость и диагностируемость кода - вполне конкретные критерии. Подходы могут быть разными, и уж тем более они зависят от стека. И как раз эти подходы уже обсуждаемы и могут быть приятны/неприятны (чаще всего я все-таки ориентируюсь на командную культуру, а не личные предпочтения).
Кандидат может классно знать все виды сортировки, но когда продакшн завалится из-за того, что он перепутал плюс и минус в вычислении (банальная человеческая ошибка), то проблема тут как раз в том, что 1) он не сделал диагностируемый сервис 2) он недостаточно обеспечил его тестируемость. Компания потратит сотни денег на воспроизведение и фикс. И с точки зрения компании, этого можно было избежать, если бы эти вопросы были обсуждаемы на интервью.
Так и тема в целом философская и дискуссионная. Я практически в начале оговариваюсь, что стараюсь не писать свои четкие ответы. Впрочем, почти к каждому вопросу я даю рекомендацию, о чем может говорить ответ.
Например, если говорить об организации каталогов, лично я предпочитаю доменную, но в моей нынешней команде принята организация по назначению. Что из этого правильно? Правильно то, что принято в команде, но важно обсудить причину, плюсы и минусы.
Вы попробуйте для себя лично ответить на каждый вопрос. Можете сформулировать конкретное мнение (конктретную методику) и обосновать его выбор?
Для меня оказалось, что когда на собеседовании вообще не спрашивают про тестабилити кода, то в компании "не принято" писать юнит тесты. И если мы не говорим про диагностику, то в логах просто свалка. И наоборот, если мы в процессе хотя бы поверхностно затрагиваем эти темы, то культура кода в компании находится на довольно приятном для меня уровне.
Мне кажется, что если инженер и забыл что-то, то он должен быть в состоянии разобраться и выдать годное решение. Есть декомпиляторы на худой конец, примеры "в интернете" и т.д., а разобраться в применимости -- тут придётся использовать навык разработчика, какой вариант хороший, а какой плохой и почему, и людям без этого навыка в разработке не место. Это они думают что память бесконечная, процессор тоже и создавать по 100к объектов на один запрос это нормально, GC соберёт если что.
Золотые слова! Именно это и отличает хорошего инженера от того же ChatGPT. И, к теме статьи, мало просто это написать, нужно это качественно покрыть тестами и обеспечить хорошую диагностируемость. Чтобы даже в случае проблем с GC и 100к объектов иметь возможность быстро продиагностировать и как минимум выдать рекомендации что с этим добром делать прямо сейчас когда задержки посыпались.
Обычно я использую структуры из стандартной библиотеки, заворачивая их в свои классы. В крайнем случае - ищу подходящую в сторонних, исходя из критериев использования. Самому писать связные списки и прочие деревья мне еще ни разу не приходилось.
Я тоже такую тенденцию замечаю (на собесе лично я точно не сделаю, домашкой - в зависимости от критериев приемлемости, наверное, справлюсь), но тут вечный вопрос - а насколько часто вы в бою пишете структуры данных? Если в вашей сфере это рядовая задача - вопросов нет. Я вот очень давно учил структуры и алгоритмы, практически все забыл по причине неиспользования в моей сфере.
UPD: собственно, об этом я и написал. Такие данные я отношу к справочным. Но вот если ваши кандидаты даже справочником пользоваться не умеют, это большая проблема.
Да, долго. Да, шумно. Но главное, что не я! Владею Mijia 1C, и это спаситель от кошачьей шерсти на каждый день. Даже по сравнению с тем, что его надо чистить, я лучше потрачу 15 мин на чистку каждое второе воскресенье + раз в месяц генеральная влажная, чем буду через день батрачить в трешке вручную. Вариант клининга рассматривал - в долгосрочной несравнимо дороже.
Я думаю, что главная задача, решаемая микросервисами - масштабирование части приложения при возрастании нагрузки на него. Ответственность вторична. То есть, например, если есть онлайн магазин с черной пятницей, то микросервисы дают возможность масштабировать не весь магазин с соответствующими затратами ресурсов, а только те его части, которые подвержены наибольшей нагрузке. В черную пятницу нет смысла сильно раздувать read-only каталог, зато возможно стоит апскейлить корзину и скидочный сервис. Экономия.
А описываемые автором проблемы с размазанными транзакциями - пример плохого разбиения на сервисы.
Не думай о белой обезьяне…
Hidden text
У вас там в скриншоте мелькнул Karavan Food - люто рекомендую попробовать у них плов 🙂 лучший узбекский плов в Праге на мой вкус.
А вообще да, все так. Датовку только мне лениво заводить… в остальном точно не жалуюсь.
Выскажу непопулярное мнение. Мне не нравится Зен в BM. В первой HL это было отчужденное, выжженное индустриальное пространство, в котором уже действительно не осталось ресурсов, и вторжение Нихиланта на Землю ощущалось логичным. Он ощущался тем самым пограничным миром, в котором невозможно было оставаться надолго. В BM же Зен - цветущий, насыщенный, явно способный прокормить всех желающих. Красиво, конечно, захватывающе и интересно, но абсолютно, на мой взгляд, противоречит внутренней логике и сюжету.
Я не очень понимаю, каким именно образом аналитики из оригинальной статьи превратились в менеджеров. Аналитики - такие же работники, как и программисты, находятся примерно на том же уровне пищевой пирамиды. Не вижу ничего крамольного в выделении аналитиков в отдельную подкоманду при условии плотного взаимодействия с разработчиками. Лично я читаю слово «методолог» как «эксперт», эксперт в том, что программист не знает. Когда вы пишете бухгалтерский софт, вам нужен эксперт области, методолог, аналитик - как угодно. Иначе программисту придется изучать бухгалтерию. Если это отчеты - нужен методолог, который знает как это отчеты читаются в первую очередь, а не как строятся.
Также не очень понимаю, почему у автора бомбит от дачи сроков заказчику. Подписание любого контракта подразумевает подписание его на определенный срок, в течение которого работа должна быть выполнена. Нормальный адекватный процесс при этом подразумевает возможность их изменения, но в любом случае все начинается со сбора требований, их грануляризации и оценки.
В любом случае заказчику необходимо понимать, когда он это получит, чтобы подстроить свои процессы. Обеспечить железо, подготовить работников - это все не появляется ниоткуда, а требует расчета бюджета, амортизации, подготовки. Не только исполнитель делает работу, но и заказчик со своей стороны тоже.
Ну и главный мой вопрос - а как надо? Я, например, так и не понял.
Хорошая точка зрения. В принципе, да, чистый код расширяется легко и хорошо. Но все же, при написании библиотек и фреймворков лучше такие моменты закладывать изначально.
Вы категорически правы! Я в начале своей карьеры работал в телеком галере (широко известной в узких кругах), их продукт - фреймворк с безграничной возможностью конфигурации через дб модель и интерфейс модулей (и немного можно дописать джаву). Оттуда вышли десятки Senior Developer с опытом 10+, которые писали код от силы 20% этого стажа, а все остальное время занимались накликиванием конфигураций. Мой друг до сих пор там работает сениором, потому что его даже миддлом не берут, и уж тем более на зп, которую он хочет.
Парой комментариев выше написал, но повторюсь: я не утверждаю, что все интервью должно состоять лишь из этих вопросов. И уж тем более эти вопросы имеют смысл лишь для программиста с опытом и неплохим уровнем. Я с удовольствием побеседую и об опыте, и попишу на лайв-код сессии. Тем не менее, интервью, состоящее лишь из базовых вопросов, не дает хорошего представления о реальном скиле человека уровня Middle+
Не знаю, я не пользуюсь им интенсивно. Только для генерации сложных конфигураций спринга, и то потом адаптирую. Но мне кажется, многие и не задаются этим вопросом.
В целом, вы правы. Но, во-первых, я выступаю не с точки зрения интервьюера, а с точки зрения соискателя. После 10 лет разработки мне надоело одинаково отвечать на одинаковые вопросы, и на такие интервью я обычно даю отказ. Эти вопросы показывают как хорошо я подготовился, а не как хорошо я решаю боевые задачи и обеспечиваю высокий SLA при проблемах и создаю качественный код. Во-вторых, ставя себя на место интервьюера, для меня важно, что человек, с которым мне предстоит работать, вообще осознает такие концепции, как тестируемость, диагностируемость, продуктивное ревью. Он может их осознавать не совсем так, как хотелось бы мне, но гораздо хуже полное отсутствие. Здесь еще играет роль фактор собственной боли. Мне приходилось (и не единожды) работать в команде «сениоров», которые могут себе позволить класс на 3000 строк без единого теста. Лишь пару раз так напоровшись, я уже начал сам задавать вопросы «а как у вас в команде с тестами и CI/CD?». Но как соискателю, мне бы хотелось, чтобы об этом спрашивали меня.
К тому же, я не утверждаю, что все интервью должно состоять лишь из этих вопросов. Отличное дополнение для тех частей, где «просто побеседовать».
Я вообще никого не указываю в качестве виновника, вы странным образом трактуете мои слова. Равно как и про стек я не говорил в контексте компании (ей вообще по барабану), а в контексте команды, которая ей эту прибыль и делает. И тут, извините, придется знать как логирование делается в С++, а как в Java.
А касаемо ответственности, о том же и речь, что сначала тимлид и архитектор НЕ спрашивают на собеседовании "а ты тесты-то писать умеешь?", а потом начинается подсчет денег, утекших на хот-фикс. Об этом и есть статья. Требовать это надо еще при приеме на работу, тогда все всё обговорили и понимают как будут работать. И вот уже тогда можно искать "виновника", который эти договоренности (желательно еще и зафиксированные как Corporate code style) нарушил.
UPD: а еще вы совершенно неверно поняли контекст статьи. Это не вопросы, которые я бы задал кому-то, чтобы понять, нравится он мне или нет. Это вопросы, которые я бы хотел услышать. Чтобы их задавали мне.
Не совсем с вами согласен. Тестируемость и диагностируемость кода - вполне конкретные критерии. Подходы могут быть разными, и уж тем более они зависят от стека. И как раз эти подходы уже обсуждаемы и могут быть приятны/неприятны (чаще всего я все-таки ориентируюсь на командную культуру, а не личные предпочтения).
Кандидат может классно знать все виды сортировки, но когда продакшн завалится из-за того, что он перепутал плюс и минус в вычислении (банальная человеческая ошибка), то проблема тут как раз в том, что 1) он не сделал диагностируемый сервис 2) он недостаточно обеспечил его тестируемость. Компания потратит сотни денег на воспроизведение и фикс. И с точки зрения компании, этого можно было избежать, если бы эти вопросы были обсуждаемы на интервью.
Так и тема в целом философская и дискуссионная. Я практически в начале оговариваюсь, что стараюсь не писать свои четкие ответы. Впрочем, почти к каждому вопросу я даю рекомендацию, о чем может говорить ответ.
Например, если говорить об организации каталогов, лично я предпочитаю доменную, но в моей нынешней команде принята организация по назначению. Что из этого правильно? Правильно то, что принято в команде, но важно обсудить причину, плюсы и минусы.
Вы попробуйте для себя лично ответить на каждый вопрос. Можете сформулировать конкретное мнение (конктретную методику) и обосновать его выбор?
Для меня оказалось, что когда на собеседовании вообще не спрашивают про тестабилити кода, то в компании "не принято" писать юнит тесты. И если мы не говорим про диагностику, то в логах просто свалка. И наоборот, если мы в процессе хотя бы поверхностно затрагиваем эти темы, то культура кода в компании находится на довольно приятном для меня уровне.
Золотые слова! Именно это и отличает хорошего инженера от того же ChatGPT. И, к теме статьи, мало просто это написать, нужно это качественно покрыть тестами и обеспечить хорошую диагностируемость. Чтобы даже в случае проблем с GC и 100к объектов иметь возможность быстро продиагностировать и как минимум выдать рекомендации что с этим добром делать прямо сейчас когда задержки посыпались.
Обычно я использую структуры из стандартной библиотеки, заворачивая их в свои классы. В крайнем случае - ищу подходящую в сторонних, исходя из критериев использования. Самому писать связные списки и прочие деревья мне еще ни разу не приходилось.
Я тоже такую тенденцию замечаю (на собесе лично я точно не сделаю, домашкой - в зависимости от критериев приемлемости, наверное, справлюсь), но тут вечный вопрос - а насколько часто вы в бою пишете структуры данных? Если в вашей сфере это рядовая задача - вопросов нет. Я вот очень давно учил структуры и алгоритмы, практически все забыл по причине неиспользования в моей сфере.
UPD: собственно, об этом я и написал. Такие данные я отношу к справочным. Но вот если ваши кандидаты даже справочником пользоваться не умеют, это большая проблема.
И где-то здесь мы подходим к концепциям юзабилити и управления продуктом
А это наверное зависит от того, до каких структур хотите добраться. Префронтальная кора с носа поближе будет наверное
Да, долго. Да, шумно. Но главное, что не я! Владею Mijia 1C, и это спаситель от кошачьей шерсти на каждый день. Даже по сравнению с тем, что его надо чистить, я лучше потрачу 15 мин на чистку каждое второе воскресенье + раз в месяц генеральная влажная, чем буду через день батрачить в трешке вручную. Вариант клининга рассматривал - в долгосрочной несравнимо дороже.
Да, пожалуй. Пересчитал свою зп за 2020, вышло 31%. В любом случае считал треть грубо обычно.