В больших проектах скрам скорее мешает, чем помогает. У себя в команде мы реализовали очень важное улучшение по скраму - уволили скрам-мастера и отменили ретро (но таки иногда собираемся по необходимости с пивом). И работа стала намного эффективнее.
Читать незнакомый код - это не только код-ревью и это очень важный навык. Если человек не может прокомментировать небольшой, но сложный код, потом он точно также будет тупить и в реальной жизни и долго разбираться с багами. Пять строк кода распознать можно за пару минут, я не даю простыню целую читать.
Никаких замеров скорости тоже никто не делает, но хорошего специалиста сразу видно по тому как он пишет код.
В других компаниях на техсобес приходят лиды команд или сеньорные разработчики. Так как это отвлекает их от прямых обязанностей, они чаще всего относятся к кандидатам не очень‑то благосклонно, а вопросы формируют как будто из желания кандидата завалить на экзамене — максимально далекие от практики и глубокие по сути.
являюсь "сеньорным разработчиком", проводящим собеседования для с++ разработчиков. Собеседования для меня - это такие же прямые обязанности как и написание кода, код-ревью и т.п.. Что значит "отвлекает", не понимаю. Я заинтересован работать с профессионалами, в этом вся мотивация. Отношусь ко всем кандидатам одинаково лояльно и всегда объясняю почему меня интересует именно то, что я спрашиваю (написать балансировку КЧ дерева не прошу. Хорошо, если человек это знает. Не знает - тоже хорошо, т.к. это не нужно знать в реальной разработке 99.9% разработчикам). Чтобы не тратить свое и чужое время, обсудил и научил своих hr уточнять у кандидатов используемый ими стек разработки и субъективный уровень владения ЯП-ами и инструментами. Мне важно насколько быстро человек может читать чужой сложный код, на лету проектировать несложные структуры, быстро писать код, не пропуская и не забывая различные const, std::move и т.п., разбирается где и какой контейнер использовать. Кому сразу говорю нет - например, джун не может рассказать, что такое итератор - до свидания через полгода. Не знает как устроены внутри простые string, vector, list - тоже до новых встреч. К кандидатам-сеньорам требования другие, конечно, но тоже их проверить можно за полчаса на простых примерах кода.
Как известно, есть множество вещей, которые намного проще и быстрее можно написать на C#, Python и прочих, чем на С/С++. Как меряют продуктивность команд тоже известно. Можно даже, наверное, в том же гугле найти две С++ команды с дикой разницей по продуктивности. Поэтому пока эти утверждения неубедительно выглядят.
Здесь явно не хватает информации о том, при каких условиях компилятор неявно добавляет специальные функции-члены. Популярно об этом разжевал в свое время Ховард Хинант, чей знаменитый доклад можно посмотреть здесь:https://www.youtube.com/watch?v=vLinb2fgkHk&t=2742s. А вот умные указатели тут вообще лишние, IMHO.
Все скрам-мастера, которых я лично знаю и которых наблюдал в реальной работе - это люди, которые не годятся даже в джуны-разработчики/тестеры. Это такие лютые дилетанты, которые пытаются управлять процессами. Понятно, что среди профессионалов они не пользуются авторитетом, а зачастую и уважения. Мне кажется в этом главная проблема скрам-мастеров.
Ожидал увидеть что-нибудь про SDLC, SAST... про что-нибудь, что призвано противостоять проблемам. Проблемы, кстати, толком тоже не раскрыты. Статья, как минимум, требует доработки.
Чисто из своего опыта. В своей команде мы избавились от скрам-мастера и ретро. Это реально не нужно конкретно нам. Как минимум, теперь нет раздражающих факторов. Производительность ни разу не упала при этом. Как показывает мой 20+ летний опыт в IT, сокращение количества "эффективных менеджеров", как правило, приводит к более здоровой обстановке в коллективе и, как следствие, более эффективной работе.
Очень часто скрам продают руководству как идеальное решение всех проблем. На деле появляются дополнительные эффективные менеджеры и всякие левые бизнес тренеры и консультанты, компетентность которых вызывает массу вопросов. И таки да, немного порядка скрам добавляет. Главная беда - это огромное время, затрачиваемое сотрудниками на церемонии и ритуалы скрама. Особенно когда особых проблем нет, но на ретро надо обязательно высосать из пальца улучшения и в следующем спринте потратить время на решение этих якобы проблем. Короче говоря, если в компании нет активных борцов с этим злом, то тут грусть и печаль.
Мой опыт показывает, что когда человек говорит, что знает C++, на деле оказывается, что даже половины языка он ничерта не знает, не говоря уж об STL. Смотрит на лямбду, к примеру, и спрашивает, это точно С++? Но это не сильно мешает ему писать вполне грамотный код, быстрый и безопасный.
Если взять и уволить всех этих "ключевых" сотрудников, то Сбер ничего не потеряет. Более того, уверен, даже выиграет. Такое количество эффективных менеджеров на одного работника походу только в этой организации.
Как говорится, работать удаленно не только приятно, но и круглосуточно. Есть компании, где менеджеры считают вполне нормальным привлечь сотрудника в 10 вечера якобы для решения срочного вопроса, ибо ты же все равно на удаленке. И есть даже такие, которых устраивает такое положение дел, типа я днем тогда могу своими делами заниматься, раз такое творится.
Очепятка "ОС 6-DOS у Seattle Computer Products"
ОС 86-DOS ...
Как хорошо, что по C++ нет чит-шита. Иначе бы он был на 1000 страниц
Upd. а нет, таки есть (
https://cheatsheets.zip/cpp
В больших проектах скрам скорее мешает, чем помогает. У себя в команде мы реализовали очень важное улучшение по скраму - уволили скрам-мастера и отменили ретро (но таки иногда собираемся по необходимости с пивом). И работа стала намного эффективнее.
Читать незнакомый код - это не только код-ревью и это очень важный навык. Если человек не может прокомментировать небольшой, но сложный код, потом он точно также будет тупить и в реальной жизни и долго разбираться с багами. Пять строк кода распознать можно за пару минут, я не даю простыню целую читать.
Никаких замеров скорости тоже никто не делает, но хорошего специалиста сразу видно по тому как он пишет код.
являюсь "сеньорным разработчиком", проводящим собеседования для с++ разработчиков. Собеседования для меня - это такие же прямые обязанности как и написание кода, код-ревью и т.п.. Что значит "отвлекает", не понимаю. Я заинтересован работать с профессионалами, в этом вся мотивация. Отношусь ко всем кандидатам одинаково лояльно и всегда объясняю почему меня интересует именно то, что я спрашиваю (написать балансировку КЧ дерева не прошу. Хорошо, если человек это знает. Не знает - тоже хорошо, т.к. это не нужно знать в реальной разработке 99.9% разработчикам). Чтобы не тратить свое и чужое время, обсудил и научил своих hr уточнять у кандидатов используемый ими стек разработки и субъективный уровень владения ЯП-ами и инструментами.
Мне важно насколько быстро человек может читать чужой сложный код, на лету проектировать несложные структуры, быстро писать код, не пропуская и не забывая различные const, std::move и т.п., разбирается где и какой контейнер использовать.
Кому сразу говорю нет - например, джун не может рассказать, что такое итератор - до свидания через полгода. Не знает как устроены внутри простые string, vector, list - тоже до новых встреч. К кандидатам-сеньорам требования другие, конечно, но тоже их проверить можно за полчаса на простых примерах кода.
Как известно, есть множество вещей, которые намного проще и быстрее можно написать на C#, Python и прочих, чем на С/С++. Как меряют продуктивность команд тоже известно. Можно даже, наверное, в том же гугле найти две С++ команды с дикой разницей по продуктивности. Поэтому пока эти утверждения неубедительно выглядят.
Иначе невозможно участвовать в тендерах на поставку российских операционных систем. Вас разве не смущают тысячи отечественных устройств?
Компиляция на этапе выполнения в С++??? Впервые вижу такой термин в плюсах ))) Есть стойкое ощущение, что статья требует серьезной доработки.
Здесь явно не хватает информации о том, при каких условиях компилятор неявно добавляет специальные функции-члены. Популярно об этом разжевал в свое время Ховард Хинант, чей знаменитый доклад можно посмотреть здесь:https://www.youtube.com/watch?v=vLinb2fgkHk&t=2742s.
А вот умные указатели тут вообще лишние, IMHO.
Все скрам-мастера, которых я лично знаю и которых наблюдал в реальной работе - это люди, которые не годятся даже в джуны-разработчики/тестеры. Это такие лютые дилетанты, которые пытаются управлять процессами. Понятно, что среди профессионалов они не пользуются авторитетом, а зачастую и уважения. Мне кажется в этом главная проблема скрам-мастеров.
Ожидал увидеть что-нибудь про SDLC, SAST... про что-нибудь, что призвано противостоять проблемам. Проблемы, кстати, толком тоже не раскрыты. Статья, как минимум, требует доработки.
Чисто из своего опыта. В своей команде мы избавились от скрам-мастера и ретро. Это реально не нужно конкретно нам. Как минимум, теперь нет раздражающих факторов. Производительность ни разу не упала при этом. Как показывает мой 20+ летний опыт в IT, сокращение количества "эффективных менеджеров", как правило, приводит к более здоровой обстановке в коллективе и, как следствие, более эффективной работе.
Поясните, что значит "виртуальные вызовы невозможно оптимизировать"? Девиртуализация, существующая в современных компиляторах, получается блеф?
мне кажется, Страуструп юмор оценил бы
Было бы неплохо добавить, что зачастую первый принцип противоречит второму, и как решается эта проблема.
Очень часто скрам продают руководству как идеальное решение всех проблем. На деле появляются дополнительные эффективные менеджеры и всякие левые бизнес тренеры и консультанты, компетентность которых вызывает массу вопросов. И таки да, немного порядка скрам добавляет. Главная беда - это огромное время, затрачиваемое сотрудниками на церемонии и ритуалы скрама. Особенно когда особых проблем нет, но на ретро надо обязательно высосать из пальца улучшения и в следующем спринте потратить время на решение этих якобы проблем. Короче говоря, если в компании нет активных борцов с этим злом, то тут грусть и печаль.
Мой опыт показывает, что когда человек говорит, что знает C++, на деле оказывается, что даже половины языка он ничерта не знает, не говоря уж об STL. Смотрит на лямбду, к примеру, и спрашивает, это точно С++? Но это не сильно мешает ему писать вполне грамотный код, быстрый и безопасный.
Скорее std::array
Если взять и уволить всех этих "ключевых" сотрудников, то Сбер ничего не потеряет. Более того, уверен, даже выиграет. Такое количество эффективных менеджеров на одного работника походу только в этой организации.
Как говорится, работать удаленно не только приятно, но и круглосуточно. Есть компании, где менеджеры считают вполне нормальным привлечь сотрудника в 10 вечера якобы для решения срочного вопроса, ибо ты же все равно на удаленке. И есть даже такие, которых устраивает такое положение дел, типа я днем тогда могу своими делами заниматься, раз такое творится.