У нас все правительство токсичное и детей ненавидит лютой ненавистью, один только ЕГЭ что стоит, ювенальный маразм и прочие фашистские законы, в том числе против семьи, детей и их развития. Поэтому и продолжает работать. и таких как правило не убирают.
И такой работой должны заниматься исключительно руководство, кадровики и штатные профессиональные психологи, которые в основном должны быть из отделов кадров.
Никакой автоматизации и тем более выигрыша в ресурсах, в том числе не обслуживание этого монстра в малых и средних компаниях эта новомодная фишка практически никогда не дает, за очень редким исключением. И сопровождать его крайне сложно и дорого, и сам он по себе во многом весьма непредсказуем в части стабильности. А уж когда рухнет-попробуй еще подними. Тот еще кардебалет с бубнами. В 90% случаем это как минимум сильно избыточное решение и даже очень спорное в плане необходимости использования, и еще во многом небезопасное, так как велосипед в виде боинга.
А еще это жесткая зависимость от вендора-гугла, который в один прекрасный момент его накроет медным тазом. Вон что было после того как он перестал поддерживать докер среды.
///Но что, если у вас есть устаревшие приложения, которые не могут работать в контейнерах?///
Что означает "устаревшие" приложения? Это не устаревшие приложения, а просто совершенно другая архитектура для совсем других целей. Глупая повальная мода на контейнеризированные приложения никак и нисколько не отменяет те же монолитные архитектуры. Кстати, сами api и приложения которые управляют контейнерными средами-это еще одна дополнительная прослойка в основной системе, увеличивающая собственные риски, в том числе увеличивая сложность(а значит и расходы на сопровождение), во многом уменьшая безопасность(с одной стороны) несмотря на расхожее мнение и далеко не всегда оправдано в плане архитектуры многих приложений. Контейнеризация хоть и дает с одной стороны некоторые преференции и плюсы, но в то же время в ней и много рисков, минусов, как и в случае с кубернетисами.
И вообще, инициатива(полезная разумеется) - строго наказуема. Во многих современных компаниях, чья работа выстроена на основе современных так называемых методологий управления, навязанных Западом и их спецслужбами. Хотя на первый взгляд им и удалось весь процесс выстроить таким образом, как будто бы то не так и все ровно да наоборот-)
Две основные общие проблемы скрам: его применяют не там где надо и его применяют не так как надо. А надо(или допустимо) его применять в не более 10% случаев. Скрам-это не панацея совершенно, а там где его пичкают по принципу басни Крылова Про мартышка и очки - часто даже вредит делу.
Начнем с того, что любой agile, который пичкают везде и всюду-это не про эффективность, а про дефективность и вредительство. В большинстве задач нужна четкие и понятные иерерхия и документированность всех бизнес процессов, инфраструктур и их организации, включая должностные обязанности каждого сотрудника.
Для того чтобы в любой организации не было такого бардака, где сотруднику кто попало и когда попало переназначает любую задачу, необходимы детально описанные бизнес процессы и их организация, работающая инфраструктура и ее управление, четко и детально прописанные в документации иерархия подчиненности с самого верху, должностные обязанности каждого сотрудника с обозначенными рамками, а так же назначены текущие и планируемые задачи, их приоритеты со сроками их старта и исполнения, хотя-бы примерными и ответственные за эти задачи. И, разумеется, прозрачные механизмы отчетности. И главное все это должно быть документировано всегда актуальной документацией. Чтобы потом концы не искать, как это часто случается в подобных шарагах с agile.
Далеко не везде все это нужно, а много где подобного рода автоматизация даже может навредить. И не стоит забывать о важном и во многих случаях незыблемом принципе-не трогай без необходимости то, что нормально работает. Автоматизация разработки бывает нужна только компаниям которые постоянно занимаются разработкой собственного ПО и только на одном из этапов разработки, но не продакшена, или же поиском багов в приложениях, и то, в тестовых средах, не в продакшене, или в продакшене, но на период тестирования на уязвимости и баги.
Безусловно кореллирует, но не пропорционально тем масштабам, которые уделяют этому они. Причем у них вообще вопросы зачастую сильно оторванные от прикладных областей.
самый криворукий говнокодерский контингент кстати-это как раз студенты на стажировках. все с вами понятно-) потому я Индексе такое УГ в плане качества сервисов.
Алгоритмы безусловно один из главных необходимых навыков, но далеко не достаточный, особенно когда он полностью оторван от прикладной области.
А собесы в Яндексе, по примерам очевидцев, создают впечатление, что с прикладной частью не сильно дружат. И для понимания и решения 90% прикладных задач среднего ИТ специалиста-программиста достаточно просто знания и понимания трех основных алгоритмов на пальцах. И основных структур данных. Что кстати не менее важно. И главное-их отображения и отработки системами. Остальное - доучивается в процессе работы и по мере необходимости, на опыте.
У нас все правительство токсичное и детей ненавидит лютой ненавистью, один только ЕГЭ что стоит, ювенальный маразм и прочие фашистские законы, в том числе против семьи, детей и их развития. Поэтому и продолжает работать. и таких как правило не убирают.
Яндекс кстати-это вовсе не показатель крутости в части состава программистов-)
И такой работой должны заниматься исключительно руководство, кадровики и штатные профессиональные психологи, которые в основном должны быть из отделов кадров.
Никакой автоматизации и тем более выигрыша в ресурсах, в том числе не обслуживание этого монстра в малых и средних компаниях эта новомодная фишка практически никогда не дает, за очень редким исключением. И сопровождать его крайне сложно и дорого, и сам он по себе во многом весьма непредсказуем в части стабильности. А уж когда рухнет-попробуй еще подними. Тот еще кардебалет с бубнами. В 90% случаем это как минимум сильно избыточное решение и даже очень спорное в плане необходимости использования, и еще во многом небезопасное, так как велосипед в виде боинга.
А еще это жесткая зависимость от вендора-гугла, который в один прекрасный момент его накроет медным тазом. Вон что было после того как он перестал поддерживать докер среды.
///Но что, если у вас есть устаревшие приложения, которые не могут работать в контейнерах?///
Что означает "устаревшие" приложения? Это не устаревшие приложения, а просто совершенно другая архитектура для совсем других целей. Глупая повальная мода на контейнеризированные приложения никак и нисколько не отменяет те же монолитные архитектуры. Кстати, сами api и приложения которые управляют контейнерными средами-это еще одна дополнительная прослойка в основной системе, увеличивающая собственные риски, в том числе увеличивая сложность(а значит и расходы на сопровождение), во многом уменьшая безопасность(с одной стороны) несмотря на расхожее мнение и далеко не всегда оправдано в плане архитектуры многих приложений. Контейнеризация хоть и дает с одной стороны некоторые преференции и плюсы, но в то же время в ней и много рисков, минусов, как и в случае с кубернетисами.
.
Не всегда конечно, но тем не менее - Браво!
На деле же это обыкновенное вредительство на основе сектантства, замаскированного под систему якобы повышения эффективности.
В 90% случает карьеру так и делают-по головам.
И вообще, инициатива(полезная разумеется) - строго наказуема. Во многих современных компаниях, чья работа выстроена на основе современных так называемых методологий управления, навязанных Западом и их спецслужбами. Хотя на первый взгляд им и удалось весь процесс выстроить таким образом, как будто бы то не так и все ровно да наоборот-)
Саму компанию и выстроенную в ней систему оценивать никому не дадут, а если дадут и попросят, то врядли кто-то либо мало кто скажет честно-)
Токсичнее самой технологии agile в контексте запихивания ее куда ни попадя - и не придумать-)
Две основные общие проблемы скрам: его применяют не там где надо и его применяют не так как надо. А надо(или допустимо) его применять в не более 10% случаев. Скрам-это не панацея совершенно, а там где его пичкают по принципу басни Крылова Про мартышка и очки - часто даже вредит делу.
Начнем с того, что любой agile, который пичкают везде и всюду-это не про эффективность, а про дефективность и вредительство. В большинстве задач нужна четкие и понятные иерерхия и документированность всех бизнес процессов, инфраструктур и их организации, включая должностные обязанности каждого сотрудника.
Для того чтобы в любой организации не было такого бардака, где сотруднику кто попало и когда попало переназначает любую задачу, необходимы детально описанные бизнес процессы и их организация, работающая инфраструктура и ее управление, четко и детально прописанные в документации иерархия подчиненности с самого верху, должностные обязанности каждого сотрудника с обозначенными рамками, а так же назначены текущие и планируемые задачи, их приоритеты со сроками их старта и исполнения, хотя-бы примерными и ответственные за эти задачи. И, разумеется, прозрачные механизмы отчетности. И главное все это должно быть документировано всегда актуальной документацией. Чтобы потом концы не искать, как это часто случается в подобных шарагах с agile.
в том числе поэтому все эти новомодные штучки в автоматизацией процесса разработки-всегда палка о двух концах-)
Далеко не везде все это нужно, а много где подобного рода автоматизация даже может навредить. И не стоит забывать о важном и во многих случаях незыблемом принципе-не трогай без необходимости то, что нормально работает. Автоматизация разработки бывает нужна только компаниям которые постоянно занимаются разработкой собственного ПО и только на одном из этапов разработки, но не продакшена, или же поиском багов в приложениях, и то, в тестовых средах, не в продакшене, или в продакшене, но на период тестирования на уязвимости и баги.
Не стоит особо заморачиваться. А тем кто повально и огульно все эту порнуху навнедрял везде где ни попадя - впору бошки с руками поотрывать.
Безусловно кореллирует, но не пропорционально тем масштабам, которые уделяют этому они. Причем у них вообще вопросы зачастую сильно оторванные от прикладных областей.
самый криворукий говнокодерский контингент кстати-это как раз студенты на стажировках. все с вами понятно-) потому я Индексе такое УГ в плане качества сервисов.
Алгоритмы безусловно один из главных необходимых навыков, но далеко не достаточный, особенно когда он полностью оторван от прикладной области.
А собесы в Яндексе, по примерам очевидцев, создают впечатление, что с прикладной частью не сильно дружат. И для понимания и решения 90% прикладных задач среднего ИТ специалиста-программиста достаточно просто знания и понимания трех основных алгоритмов на пальцах. И основных структур данных. Что кстати не менее важно. И главное-их отображения и отработки системами. Остальное - доучивается в процессе работы и по мере необходимости, на опыте.