По DDD лучше всего читать собственно Эванса (первую книжку). Ну и Хорикова (но там больше статьи). Но книжки по DDD не помогут нарезать домены, тут лучше что-нибудь базовое по теории систем (хоть вузовский учебник, хоть Акоффа).
Какие еще языки для корпоративной разработки вы пробовали? В каких у вас есть серьезные компетенции? Без разнообразного опыта сложно говорить про "хороший" или "плохой" язык. А вот те, у кого есть достаточно разнообразный опыт - обычно относятся к Python с большим сомнением, тем более при использовании динамической типизации.
По МСА совсем уж хороших книг как не было, так и нет. Есть база типа Клеппмана, есть неплохие идеи в разных книжках у Ньюмана и Ричардса, но любые советы и рекомендации нужно читать осторожно и сверять с реальностями вашего проекта и потенциальными проблемами. Часто рекомендации не очень соответствуют реальности. Кстати, вместо Building Microservices лучше бы почитать Software Architecture: The Hard Parts тех же авторов.
А вот про выбор подхода - нет каких-то четких условий. В среднем, если домены хорошо нарезаны, то необходимости ходить в чужую БД вообще нет. Но иногда все-таки нужные чужие данные и тут Shared DB надежнее (не нужна синхронизация, реконсиляция и так далее), но хуже масштабируемо и требует аккуратного арх.контроля. Если команда не слишком опытная, инфраструктура хорошая и много денег - то можно смело идти в Databse-per-service. В реальности, конечно же, приходится думать над конкретным проектом и выбирать подходящее решение.
Так у AI вообще плохо с арифметикой. А статью, судя по всему, сгенерила LLMка (и вряд ли это был платный ChatGPT, скорее что-то бесплатное и поднятое на ноутбуке, судя по результату). Судя по всему, в МТС примерно так и относятся к своим разработчикам, не видя разницы между тимлидами и устаревшими LLMками.
Ну, студенты вряд ли лучше пишут, чем профессионалы (причем в конкретном языке). Но я про то, что дизайн исследования изначально такой, что даже за курсовую не засчитать, не говоря уж за публикацию.
Хм, а может это МТС тестирует просто AI-агента по написанию статей и ответам на комментарии? Но лучше бы взяли модель посовременнее, да и температуру лучше понизить.
Похоже, что вы недостаточно компетентны для понимания того, что написано в исследованиях. Возможно, вам стоит попробовать проанализировать дизайн исследований, их ограничения, актуальность - и делать выводы уже на этой базе. В текущем изложении эти исследования не доказали ничего )
Спасибо, я забыл про researchgate. Прекрасно. Там на Java/C/C++ код писали студенты старших курсов в 1997(!) году. А на Python - волонтеры из профессиональной тусовки. Дальше, по идее, можно уже и не читать, никакой ценности статья не имела даже в момент публикации )
Так Python - не язык более высокого уровня, нежели Java. Вот на чистом C писать чуть дольше, да. А все остальные современные языки примерно одинаковые по уровню.
Ни одно из этих утверждений, увы, не соответствует истине. Ну, сахара в питоне много, но в Котлине и современной java не меньше. Остальное - просто набор заблуждений )
Приведите дизайн исследований, где анализируется именно совокупное время на разработку реальных задач. Пока ни одна из приведенных статей никаких данных по скорости разработки не содержит. Более того, мой опыт говорит, что разработка продукта средней сложности на java занимает много меньше времени, чем на Python (больше библиотек, лучше инструменты, лучше контроль качества кода для крупных систем).
У меня вопросы и к компетентности и к объективности. И, на месте МТС, я бы не стал публиковать статьи настолько низкого уровня, а то можно решить, что вся разработка в компании примерного такого же качества...
А вы эти исследования вообще читали? 1. Прехельт - безнадежно устарел, сама статья под paywall, в абстракте ни слова про скорость разработки, статических данных мало для каких-либо выводов (80 программистов на 7 языков - не серьезно), ничего нет про данные по тестам. 2. Байхаши. Тоже под paywall, в абстракте выводы прямо противоречащие указанным. 3. Биссьяди. Тоже paywall, в абстратке ничего про функциональное точки нет, в метод выявления функциональных точек по коду в 2013м году не верю, время в opensource проектах вообще не понятно, как именно считать. 4. Нанци. Тоже paywall, в абстракте нет ни слова про время разработки, но при этом упоминается о меньшей надежности решений на динамических языках. Используемая база не позволяет сделать вывод о скорости разработки.
Итак, ни одна из статей никак не подтверждает тезис о большей скорости разработки на Python. Ну и ссылки на статьи под paywall в ненаучной среде вызывает много вопросов.
Хм, для меня "загрузка на 80%" - это 8 ядер из 10 загружены (ну или да, каждый 20% простаивает). Но если это свое железо, то в этом случае latency не увеличивается, так как ресурсов для планирования еще хватает и избытком (и даже гипертрейдинг не начинает сказываться, опять-таки из-за свободных ресурсов). Но это для своего железа, где никто другой за ресурсы не борется и когда процессор простаивает - он просто простаивает, никакой очереди.
А в облаке - там скорее по числу экземпляров скалируешься, благо их дешево поставить. И там у тебя меняется не загрузка сервера, а число контейнеров.
Хм, почему это при 70-80% система будет заметно тормозить? В облаках там все чуть по другому, там проще уметь просто быстро подключать новые узлы. Ну и если в пиках 60, то в среднем обычно меньше 10, а то и около одного процента (но зависит от конкретного бизнеса, не всюду бывают всплески в два порядка от среднего. У топикстартера - бывают...)
По DDD лучше всего читать собственно Эванса (первую книжку). Ну и Хорикова (но там больше статьи).
Но книжки по DDD не помогут нарезать домены, тут лучше что-нибудь базовое по теории систем (хоть вузовский учебник, хоть Акоффа).
Какие еще языки для корпоративной разработки вы пробовали? В каких у вас есть серьезные компетенции?
Без разнообразного опыта сложно говорить про "хороший" или "плохой" язык. А вот те, у кого есть достаточно разнообразный опыт - обычно относятся к Python с большим сомнением, тем более при использовании динамической типизации.
А у автора есть реальный опыт проектирования и защиты сайзинга для сколь-нибудь сложных систем? А то тут что не пункт - то ошибка проектирования (
Хм, из этих статей можно сделать только один выводы - их автор не умеет читать и не умеет в бенчмарки. Что-то еще есть?
И откуда такой вывод? И качество библиотек при этом учитывалось или в расчет принимались любые работы джунов?
По МСА совсем уж хороших книг как не было, так и нет. Есть база типа Клеппмана, есть неплохие идеи в разных книжках у Ньюмана и Ричардса, но любые советы и рекомендации нужно читать осторожно и сверять с реальностями вашего проекта и потенциальными проблемами. Часто рекомендации не очень соответствуют реальности. Кстати, вместо Building Microservices лучше бы почитать Software Architecture: The Hard Parts тех же авторов.
А вот про выбор подхода - нет каких-то четких условий. В среднем, если домены хорошо нарезаны, то необходимости ходить в чужую БД вообще нет. Но иногда все-таки нужные чужие данные и тут Shared DB надежнее (не нужна синхронизация, реконсиляция и так далее), но хуже масштабируемо и требует аккуратного арх.контроля. Если команда не слишком опытная, инфраструктура хорошая и много денег - то можно смело идти в Databse-per-service.
В реальности, конечно же, приходится думать над конкретным проектом и выбирать подходящее решение.
Для высоконагруженных - Rust, Java,
Go - скорее для очень простых и не слишком нагруженных микросервисов.
Ну или для средненагруженных системных утилит, тут он вообще идеален (так как для этого и проектировался).
Так у AI вообще плохо с арифметикой. А статью, судя по всему, сгенерила LLMка (и вряд ли это был платный ChatGPT, скорее что-то бесплатное и поднятое на ноутбуке, судя по результату).
Судя по всему, в МТС примерно так и относятся к своим разработчикам, не видя разницы между тимлидами и устаревшими LLMками.
Ну, студенты вряд ли лучше пишут, чем профессионалы (причем в конкретном языке).
Но я про то, что дизайн исследования изначально такой, что даже за курсовую не засчитать, не говоря уж за публикацию.
Хм, а может это МТС тестирует просто AI-агента по написанию статей и ответам на комментарии? Но лучше бы взяли модель посовременнее, да и температуру лучше понизить.
Похоже, что вы недостаточно компетентны для понимания того, что написано в исследованиях. Возможно, вам стоит попробовать проанализировать дизайн исследований, их ограничения, актуальность - и делать выводы уже на этой базе.
В текущем изложении эти исследования не доказали ничего )
Спасибо, я забыл про researchgate.
Прекрасно. Там на Java/C/C++ код писали студенты старших курсов в 1997(!) году. А на Python - волонтеры из профессиональной тусовки. Дальше, по идее, можно уже и не читать, никакой ценности статья не имела даже в момент публикации )
Так Python - не язык более высокого уровня, нежели Java.
Вот на чистом C писать чуть дольше, да. А все остальные современные языки примерно одинаковые по уровню.
Ни одно из этих утверждений, увы, не соответствует истине. Ну, сахара в питоне много, но в Котлине и современной java не меньше. Остальное - просто набор заблуждений )
Ну или это нормальный уровень для компании и там все такое.
Приведите дизайн исследований, где анализируется именно совокупное время на разработку реальных задач. Пока ни одна из приведенных статей никаких данных по скорости разработки не содержит.
Более того, мой опыт говорит, что разработка продукта средней сложности на java занимает много меньше времени, чем на Python (больше библиотек, лучше инструменты, лучше контроль качества кода для крупных систем).
У меня вопросы и к компетентности и к объективности.
И, на месте МТС, я бы не стал публиковать статьи настолько низкого уровня, а то можно решить, что вся разработка в компании примерного такого же качества...
А вы эти исследования вообще читали?
1. Прехельт - безнадежно устарел, сама статья под paywall, в абстракте ни слова про скорость разработки, статических данных мало для каких-либо выводов (80 программистов на 7 языков - не серьезно), ничего нет про данные по тестам.
2. Байхаши. Тоже под paywall, в абстракте выводы прямо противоречащие указанным.
3. Биссьяди. Тоже paywall, в абстратке ничего про функциональное точки нет, в метод выявления функциональных точек по коду в 2013м году не верю, время в opensource проектах вообще не понятно, как именно считать.
4. Нанци. Тоже paywall, в абстракте нет ни слова про время разработки, но при этом упоминается о меньшей надежности решений на динамических языках. Используемая база не позволяет сделать вывод о скорости разработки.
Итак, ни одна из статей никак не подтверждает тезис о большей скорости разработки на Python. Ну и ссылки на статьи под paywall в ненаучной среде вызывает много вопросов.
Хм, для меня "загрузка на 80%" - это 8 ядер из 10 загружены (ну или да, каждый 20% простаивает). Но если это свое железо, то в этом случае latency не увеличивается, так как ресурсов для планирования еще хватает и избытком (и даже гипертрейдинг не начинает сказываться, опять-таки из-за свободных ресурсов).
Но это для своего железа, где никто другой за ресурсы не борется и когда процессор простаивает - он просто простаивает, никакой очереди.
А в облаке - там скорее по числу экземпляров скалируешься, благо их дешево поставить. И там у тебя меняется не загрузка сервера, а число контейнеров.
Хм, почему это при 70-80% система будет заметно тормозить? В облаках там все чуть по другому, там проще уметь просто быстро подключать новые узлы.
Ну и если в пиках 60, то в среднем обычно меньше 10, а то и около одного процента (но зависит от конкретного бизнеса, не всюду бывают всплески в два порядка от среднего. У топикстартера - бывают...)