Ну, студенты вряд ли лучше пишут, чем профессионалы (причем в конкретном языке). Но я про то, что дизайн исследования изначально такой, что даже за курсовую не засчитать, не говоря уж за публикацию.
Хм, а может это МТС тестирует просто 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, а то и около одного процента (но зависит от конкретного бизнеса, не всюду бывают всплески в два порядка от среднего. У топикстартера - бывают...)
Мне вот тоже кажется, что основной вывод из статьи - никогда не использовать стек JS+MongoDB. Ну или искать тех, кто умеет им пользоваться. Такого железа хватит на нагруженный сервер на несколько миллионов DAU...
Как-то из статьи все равно не понятно, а какое отношение SP имеют хоть к чему-нибудь. Для оценки сложности - лучше майки, оценки трудозатрат бессмысленны на уровне небольших задач, никакой capacity, выражаемой скаляром у команды нет и не может быть чисто теоретически. И вроде бы все это автор написал, но почему-то до очевидного следствия "выкиньте, наконец, SP на помойку" так и не дошел. Нет ни одного способа использовать SP хоть как-то (и да, накидывать задачи в спринт по их трудозатратам - тоже бесполезная деятельность, не поддерживаемая даже скрам-гайдом).
Единственная польза от SP - позволяют сразу определить команды с плохими процессами и отсутствием рефлексии. Но для этого и других косвенных признаков хватает.
Подведение коммуникаций, планирование финансирования - это все часть как раз планирования работ, которое, как ты сам показываешь, даже для серийного строительства одинаковых многоэтажек идет с отставанием в половине случаев. Т.е. даже шаблонное строительство - не может быть нормально спланировано.
В крупных IT бизнесах обычно очень, очень фиговые процессы, так как бизнес от качества процессов не зависит, а найти компетентных менеджеров в достаточных количествах не получается. Статья прекрасная, по ней можно проводить обучение по списку плохих подходов к разработке, собрали чуть ли не полный джекпот.
Ага, особенно явно это относится к строительству АЭС, где и с деньгами все нормально и задержки по срокам от плана в два-три раза никого не удивляют. Это шаблонные многоэтажки из готовых блоков строят более-менее по плану и в срок, хотя и там задержки на четверть срока не редки. Все остальное, от ремонта квартиры и до АЭС - в сроки укладывается довольно редко и, скорее, случайно.
В PG - не все, но это особенности реализации решения на PG и никак не связано с необходимостью всегда делать "БД на сервис". Скорее уж "если для нас существенна изоляция исполнений по сервисам и мы взяли PG - то нужно делать много разных баз". Кстати, даже в этом случае скорее имеет смысл выделить два СУБД - для "основного функционала" и для "необязательного функционала", создавать по БД на сервис все равно не нужно.
Ну, студенты вряд ли лучше пишут, чем профессионалы (причем в конкретном языке).
Но я про то, что дизайн исследования изначально такой, что даже за курсовую не засчитать, не говоря уж за публикацию.
Хм, а может это МТС тестирует просто 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, а то и около одного процента (но зависит от конкретного бизнеса, не всюду бывают всплески в два порядка от среднего. У топикстартера - бывают...)
Если в пиках, то там речь скорее о 70-80%. 20% в пиках (т.е. меньше процента в среднем) - это про совсем неэффективное использование ресурсов.
Т.е. вы поставили железа примерно в пять раз больше, чем планировали?
Тогда о чем статья-то? О том, что надо нанимать опытных разработчиков?
Да и получить 800rps на 16 CPU и 1200rps на 24 CPU - это очень грустно. Там же не платежи за каждым rps-ом прячутся, а что-то более простое...
Мне вот тоже кажется, что основной вывод из статьи - никогда не использовать стек JS+MongoDB. Ну или искать тех, кто умеет им пользоваться. Такого железа хватит на нагруженный сервер на несколько миллионов DAU...
Как-то из статьи все равно не понятно, а какое отношение SP имеют хоть к чему-нибудь.
Для оценки сложности - лучше майки, оценки трудозатрат бессмысленны на уровне небольших задач, никакой capacity, выражаемой скаляром у команды нет и не может быть чисто теоретически. И вроде бы все это автор написал, но почему-то до очевидного следствия "выкиньте, наконец, SP на помойку" так и не дошел. Нет ни одного способа использовать SP хоть как-то (и да, накидывать задачи в спринт по их трудозатратам - тоже бесполезная деятельность, не поддерживаемая даже скрам-гайдом).
Единственная польза от SP - позволяют сразу определить команды с плохими процессами и отсутствием рефлексии. Но для этого и других косвенных признаков хватает.
Ты какие-то странные цитаты привел про АЭС. Почитай про https://ru.wikipedia.org/wiki/АЭС_«Олкилуото», например.
Подведение коммуникаций, планирование финансирования - это все часть как раз планирования работ, которое, как ты сам показываешь, даже для серийного строительства одинаковых многоэтажек идет с отставанием в половине случаев.
Т.е. даже шаблонное строительство - не может быть нормально спланировано.
В крупных IT бизнесах обычно очень, очень фиговые процессы, так как бизнес от качества процессов не зависит, а найти компетентных менеджеров в достаточных количествах не получается.
Статья прекрасная, по ней можно проводить обучение по списку плохих подходов к разработке, собрали чуть ли не полный джекпот.
Ага, особенно явно это относится к строительству АЭС, где и с деньгами все нормально и задержки по срокам от плана в два-три раза никого не удивляют.
Это шаблонные многоэтажки из готовых блоков строят более-менее по плану и в срок, хотя и там задержки на четверть срока не редки. Все остальное, от ремонта квартиры и до АЭС - в сроки укладывается довольно редко и, скорее, случайно.
В PG - не все, но это особенности реализации решения на PG и никак не связано с необходимостью всегда делать "БД на сервис". Скорее уж "если для нас существенна изоляция исполнений по сервисам и мы взяли PG - то нужно делать много разных баз".
Кстати, даже в этом случае скорее имеет смысл выделить два СУБД - для "основного функционала" и для "необязательного функционала", создавать по БД на сервис все равно не нужно.