Комментарии 93
Не указан самый главный навык С/С++. Умение работать с core dump полученный с боевой системы в условиях стресса и криков "все пропало! все стоит! когда же будет почиииняно!?".
P.S. Как мне хорошо, что я перешел давно на Java и как мило разбирать стек ошибок Java в логе.
Нет проблем сделать свой обработчик исключений и генерить красиые коредампы. И это будет опциональной фичей, что повышает скрытость года.
скрытость года
Отличная опечатка
Я 15 лет писал на С++ для разных "железных" устройств (типа Verifone терминалов/PINPAD), unix систем (демоны и пр.) и сервисы/прикладные программы Windows.
Так что, не теоретически знаком с этим.
90% проблем (core dump) это последствие порчи стека/памяти иногда за несколько минут до фактического возникновения exception. И не надо мне говорить про безопасные vector и прочее. В не учебных и сложных программах всегда найдется место где что то будет не учтено не смотря на все авто ptr, вектора, обработчики исключений и прочие обкладки.
А когда в стрессовых условиях начинаешь разбираться почему упало и как это исправить - это запоминается надолго.
Работает на одной платформе (sparc, например) и нерегулярно (пару раз в неделю) падает на другой (x86) - типичный пример таких разборок.
Так что, у меня есть с чем сравнивать. На Java (последние лет 7 на Java и С++ с плавным смещение в строну кроссплатформенных программ на Java) мне гораздо комфортнее. И время поиска проблем гораздо меньше.
А спорить с фанатиками С++, которые ничего другое и не пробовали (да и на С++ максимум год) - дурное дело. Их лучше обходить большим кругом.
Я работаю программистом 33 года. За это время поработал на куче платформ. И как ты понимаешь, начал программировать ещё до появления плюсов. Сейчас пишу для PowerPC. Java особенно мила, когда начинает собирать мусор под нагрузкой и перестает реагировать на запросы. Если руки не из жопы, то и на С/С++ не проблем с памятью.
Какой "тонкий" и "закамуфлированный" наезд. Про руки из жопы.
Не делает вам чести.
Скорее говорит о вашей склонности к склочности и пр.
Не надо это воспринимать лично. Писать можно на всем, все может вызвать проблемы. Но есть подходы к организации разработки, тестировании, архитектуры которые позволяют эти проблемы уменьшить. Для того же С есть MISRA. А на многих платформах кроссплатформенная Java не работает и/или использовать нельзя. Типичный пример - микроконтроллеры или настоящий хайлоад в телекоме.
Коллеги из отдела разработки ПО для платежных терминалов постепенно переходят на Java (android). Все современные терминалы идут в основном уже "не голый C++/C" без OS, а под Android.
Я помню, сколько стоило перетащить ПО с одной платформы (POS терминалы) на другую (другой проц) с особенностями адресации и сегментации.
Конечно для какого ни будь контроллера c ядром Cortex-M3 иногда даже на C/C++ места впритык.
Но я все равно не хотел бы для пром. комплексов (unix/linux) где нет жестких ограничений по ресурсам писать на С++. Просто могу сравнить сколько на разработку развитие и поддержку одних и тех же по функционалу программ уходит, если писать на С++ и на Java.
Зачастую проще переписать старую программу сделанную на С++ под Java, чем продолжать развитие этой старой программы на С++.
Собственно, это часто приходится делать в последние годы. Дешевле переписать и внести новый функционал уже в переписанное, чем развивать старое.
И зачастую это ПО я сам лет 10 назад писал. Т.е. проблема не в том, что бы вникнуть как это старое работает. А просто активно не хочется продолжать его развивать на С++.
Займет больше времени и передать некому (найти С++ разработчика с опытом - проблема)
Так что, для общих задач (перекладывания байтиков в протоколах типа json и работа с БД) пусть мазохисты используют С++. У меня есть возможность сравнить и для меня выбор очевиден.
Если уж пошли обиды, то тут уже я чувствую презрение к этим "перекладывателям байтов" на с++.
Я последние лет 5 пишу исключительно "перекладыватели байтов из одного протокола в другой и в БД". В общем то все задачи процессинга платежей и переводы денег к этому и сводятся.
Отдушина - хоббийные программки. Хотя.. то же укладывние видеопотока в TCP/IP - это то же перекладывание байтиков/битиков.
Но перекладывать байтики и битики, для типичных моих задач на работе, не изобретая велосипед проще на Java (+python +js)
Попробуй найди нормальную библиотеку реализации HTTP сервера, или обработки Json, которая "широко известна и используется в широких кругах", а не "широко известна в узких кругах С++". А Postgre/Oracle клиент (полный как jdbc, а не OCI драйвер) под C++? а клиент kafka под C++?
Все это очень круто. Но есть одна проблема - все это ужасно медленное. Там где скорость не критична, можно писать хоть на визуал бейсике. Если гуй - С#, если json попарсить - питон, если посчитать носки на складе - Ява подойдёт. А вот если нужна скорость - с/с++.
Переписанный обработчик с C++ под java.
TCP/IP listener (не http), TCP/IP клиент и коннект к БД. XML поверх TCP/IP
Фактически навороченный маршрутизатор.
на бою работают обе версии (на разных комплексах, но на одной физически машинке).
Так вот.. в быстродействии разницы нет. Что там что там в районе 20..30 ms на обработку через БД и маршрутизацию.
Да. ресурсов C++ вариант потребляет меньше. но не принципиально. где то на 70-80% (процент большой большие, но от общей памяти сервера разница не значительная).
Но насколько удобнее и проще:
вносить изменения и новый функционал.
Не надо выпускать много дистрибутивов под каждые аппаратные платформы (и тестировать их)
Не надо ставить драйвер БД, поскольку Jdbc это thin драйвер. 4.логирование апачевским log4j2 в централизированое хранилище (не находил для C++ точного аналога)
Понадобился асихронный канал для маршрутизации - нет проблем. Вот клиент для kafka (java). А для С++ куда ни сунешься - попробуй найди библиотеку.
Простите, не совсем понятно:
Да. ресурсов C++ вариант потребляет меньше. но не принципиально. где то на 70-80% (процент большой большие, но от общей памяти сервера разница не значительная).
С++ версия потребляет на 70-80% процентов меньше памяти? CPU?
памяти.
IO Операции (сетевые) что в Java что в С++ потребляют фактически одинаково CPU. Что С++, что Java это обертка над системными вызовами IO операций. Сравнивать производительность имеет смысл вообще только для каких то нагруженных вычислений. А когда 99% работы - это IO операции (вызовы OS), то выгоды в C++ нет.
А SAX парсер java или xerces C++ для 10Кб XML это неуловимая разница (даже если она есть).
памяти
Понятно, спасибо.
Из того, что вы рассказываете возникает вопрос: а зачем версия на С++ вообще была нужна?
10 лет назад на десктопном комьютере время отклика укладывалось в 2ms с обращениями к базе данных. И 20к запросов в секунду.
так то если порассуждать - весь софт это "rep movsd"
Настоящий хайлоад в HFT-несколько миллионов RPS для инфры арбитража датафидов вполне обычное явление. И да-успешно справляется код на C#, правда написанный так, чтобы GC не пришлось работать.
Система, которая управляет доступом пользователей к мобильной сети в Йота - это hello world? Другой пример - ReGet.
Хехе, вы ответили автору этой программы ) Воистину, тесен мир.
Я уже сейчас не помню в подробностях, как там было что написано, но ощущение было, что все довольно аккуратно (кастомная реализация HTTP и FTP над сокетами в Windows). Когда мне тоже пришлось реализовывать подмножество HTTP на уровне сокетов (потому что все "промышленные" и "стандартные" библиотеки так и не удалось заставить работать нормально, хотя мы всей командой два месяца пытались), то те знания всплыли и пригодились.
Либо у вас хороший CI который позволяет все отловить до того как ушло в прод.
У нас такой CI прям сейчас. А в чем проблема видится? Весь код проверятся статическими анализаторами. Код имеет как минимум 80% покрытие юнит тестами. Так же имеется масса интеграционных тестов и симуляций. Все юнит тесты запускаются в нескольких вариантах: релизная сборка, и разные комбинации санитайзеров. Если хоть какая-то из стадий тестирования проваливается, мердж в мастер будет заблокирован.
В результате проблем с памятью реально нет. Проблемы логики есть, но никакой язык от них не защищает.
Проблема в том, что рантайм-проверки не покрывают всё возможное пространство [классов эквивалентности] состояний. И я что-то думаю, что ваши 80% — это по строкам, а не по бранчам и, тем более, не по пространству состояний.
Юнит-тесты должны быть одним из как минимум 3-х уровней тестирования. Имея все уровни тестирования на своих местах количество ошибок памяти практически сводится к нулю.
Чем в языке строже система типов, тем от большего количества логических ошибок он защищает. В пределе — от любых.
Адепт секты святого Хаскеля детектед. Хаскель может и защитит от изрядного числа ошибок, но от банальной ошибки некорректного описания типа с дальнейшим некорректным использованием - нет.
boost::stacktrace? давно уже есть, а из нового вроде в новый стандарт должны добавить
Базовые требования - Хороший технический английский. Для чего? Читать документацию?
Да, и кроме того куча блогов, статей, полезных материалов - на английском.
Но это не "хороший технически английский", а умение читать технический текст на английском и это, на мой взгляд, большая разница.
Сколько у вас коллег соответвует всем этим требованиям? :)
Почитал - расстроился. Единственный блок, в котором я вроде как чувствую себя "уверенно" - это "умение писать код". Всё остальное - чисто "по верхам", имею самое общее представление, сказать, что "знаю" не могу.
Пичалька.
Какая в такая "дорожная карта"? Сверните ее трубочкой и засуньте ее себе в ухо! В русском языке есть слово "план". Если непонятно, то можно "план действий". А дорожным картам место в атласе автомобильных дорог.
Какой еще план - когда это латинское слово? Чего это такой маститый языковед как вы поганите русский язык всякой латинщиной?
"дорожным картам место в атласе автомобильных дорог."
карта - заимствование из французского
атлас - древнегреческий
автомоби́ль - древнегреческий + латинский
место - заимствование польского
Да как вы только смеете поганить великий и могучий русский язык таким количеством инстранщины?! Общаться надо исключительно на языке образца "Не лѣпо ли ны бяшетъ, братіе, начяти старыми словесы трудныхъ повѣстій о пълку Игоревѣ" и никак иначе
Еще лет 20 назад термин "roadmap" перевели бы в данном контексте как "путь развития", "сценарий развития" или "план развития". И никого бы не интересовало откуда были позаимствованы слова "план" и "сценарий". Да и само слово "родмап" в профессиональном арго использовалось наряду с "битмапом" и особых проблем не вызывало (именно когда использовалось в профессиональном арго). Но почему-то стало модно применять "дорожная карта", видимо в переводах с английского в среде, где "родмап" употреблять было не принято. А то, что "дорожная карта" выглядит весьма дико на фоне десятилетиями употреблявшихся "план действий"/"план развития", употребителей этой самой "дорожной карты" не волнует. А зря.
Правильно!
Любой язык, если только он не мертвый, развивается, меняется и т.д. При этом стандарты определения "дико" и т.п. - делаются исключительно через "я так считаю, потому что мне не нравится". Почему, например, для вас дико именно это, а не весь русский язык после реформы 1918 года? С чего вы решили, что именно ваша версия русского языка является эталоном?
Дабы быть правильно понятым. Нет, я не сторонник старой орфографии и т.п. Это к тому, что определить, в какой момент именно язык должен быть "зафиксирован" в своем развитии, невозможно. Он всегда будет меняться, пока его используют.
С чего вы решили, что именно ваша версия русского языка является эталоном?
Во-первых, я высказываю свое мнение и оценка "дико" -- это моя личная оценка. Какие лично мне делать оценки -- это, простите, мое дело. С чего захочу, с того и решу.
Например, воспользуюсь "бритвой Оккама": не следует множить сущности без необходимости.
Во-вторых, я не лингвист, мне сложно судить об объективных законах изменения естественных языков. Но предполагаю, что языки меняются под влиянием прогресса (технического, социального и т.д.) или глобальных изменений/потрясений (вроде стихийных бедствий, изменения климата, военных конфликтов мирового масштаба). Что и обуславливает появление в языке новых слов и понятий (вроде "автомобиль", "электронно-лучевая трубка", "компьютер", "сотовый телефон" и т.д.), а так же исчезновение старых (вроде "иноходь" или "зело").
В случае с "дорожной картой" не видно каким бы прогрессом или какими бы изменениями надобность в таком синониме для "план развития" была бы обусловлена. Ну, за исключением, постепенной дебилизации значительной части населения.
Во-первых, я высказываю свое мнение и оценка "дико" -- это моя личная оценка. Какие лично мне делать оценки -- это, простите, мое дело. С чего захочу, с того и решу.
Вот! О чем и речь. Высказывать и иметь, разумеется, можете, но, судя по оценке стартового поста, такое мнение большинство считает, мягко говоря, не особо правильным, т.к. аргументация "мне не нравится", рядом с логикой даже рядом не лежала. С таким же успехом можно говорить; что современная версия русского языка - дикая, а дореформенная - прекрасна.
Но предполагаю, что языки меняются под влиянием прогресса (технического, социального и т.д.) или глобальных изменений/потрясений (вроде стихийных бедствий, изменения климата, военных конфликтов мирового масштаба)
А еще они меняются путем заимствования и проникновения друг в друга, что мы и наблюдаем на примере дорожной карты.
судя по оценке стартового поста, такое мнение большинство считает, мягко говоря, не особо правильным
Кто вам сказал, что текущая оценка отражает мнение большинства?
Кроме того, Habr для меня лично неприятно известен тем, что здесь запросто уводят в глубокие минуса более чем здравые комментарии. Вероятно, из-за этой особенности многие Habr-ом просто брезгуют.
т.к. аргументация "мне не нравится", рядом с логикой даже рядом не лежала
Покажите аргументацию "мне не нравится" в моих комментариях, пожалуйста.
А еще они меняются путем заимствования и проникновения друг в друга
Если вы дадите себе труд подумать, то увидите, что "заимствования и проникновение" являются прямым следствием прогресса и общемировых изменений. Так что это не "а еще", это все тоже самое.
мы и наблюдаем на примере дорожной карты
Я не знаю кто такие "мы" и что наблюдаете лично вы.
Мои наблюдение за проникновением "дорожной карты" в обиход наводит меня на следующий сценарий развития событий:
где-то в дипломатических кругах происходило согласование документа, который в своем англоязычном названии включал слово "roadmap";
результаты этих согласований нужно было объявить на русскоязычную аудиторию;
использовать транслитерацию "родмап" не позволял уровень, т.к. здесь нельзя было употреблять термины из профессионального арго;
перевести как это было принято раньше, а именно "план действий", было нельзя, т.к. "roadmap" в подобных договоренностях означает не столько строгий план, сколько общий набор шагов в определенной последовательности. Тогда как в русском языке "план" -- это именно что четкий план, за невыполнение которого можно ответить по всей строгости (не отвлекаемся сейчас на другие смыслы слова "план", особенно связанные с запрещенными веществами). Так что переведешь как "план действий" и нарвешься на неприятности. Поэтому нужно было придумать что-то другое. Вероятно, "дорожная карта" оказалась наиболее нейтральным вариантом. Плюс и не очень четким и понятным большинству, что так же размывало зону ответственности;
ну а после того как выражением "дорожная карта" стали пользоваться высокопоставленные лица (которые были вынуждены так делать "по протоколу") эта гадость стала распространяться и в другие области.
Возможно, все было еще прозаичнее: на каком-то этапе кто-то просто прогнал английский текст через автоматический переводчик и получил "дорожную карту" вместо "пути движения" (или "последовательность шагов") и понеслось.
Покажите аргументацию "мне не нравится" в моих комментариях, пожалуйста.
Вот. Кому-то точно также может казаться, что весь послереформенный русский язык выглядит дико.
А то, что "дорожная карта" выглядит весьма дико на фоне десятилетиями употреблявшихся "план действий"/"план развития", употребителей этой самой "дорожной карты" не волнует.
Кому-то точно также может казаться, что весь послереформенный русский язык выглядит дико. Не нравится человеку и все тут. Разница только в том, что требований употреблять дореформенную грамматику особо не встречается, а требования не употреблять современные изменения как у автора стартового комментария с его "Сверните ее трубочкой и засуньте ее себе в ухо!" встречаются.
Все, действительно, прозаичнее. Языки проникают друг в друга обыкновенной калькой. Как вам, например, "Autobahn news"? И никакой технический прогресс (если только не считать возможность общаться с кем угодно откуда угодно, что ускоряет смешивание языков) для этого не требуется.
Вот.
Вот что? Я вас попросил привести пример аргументации вида "мне не нравится" в моих комментариях. Приведите, пожалуйста. Не нужно растекаться мыслею о том что кому-то что-то. Цитату, пожалуйста.
Кому-то точно также может казаться, что весь послереформенный русский язык выглядит дико.
У этого "казаться" могут быть вполне себе логичные объяснения. Когда я написал ""дорожная карта" выглядит весьма дико на фоне десятилетиями употреблявшихся "план действий"/"план развития"", то озвучил лишь вывод, опустив мотивацию.
Я привел его в цитате. Вот цитата еще раз. Вам не нравится и кажется диким. Вопрос, почему вам кажется диким именно это, а не, например, весь русский язык после реформы 1918 года, вы упорно игнорируете.
Мыслию по древу я не растекаюсь, а всего лишь комментирую ваши то, что написали вы. Если бы вы не начали писать про то, почему меняется язык, я бы не начал комментировать ваши мысли эту тему.
А то, что "дорожная карта" выглядит весьма дико на фоне десятилетиями употреблявшихся "план действий"/"план развития", употребителей этой самой "дорожной карты" не волнует.
Я привел его в цитате.
Там нет аргументации, там есть констатация факта.
Чтобы было лучше понятно. Представьте, что вы приходите на выставку авангардной живописи, где представлены картины Малевича, Кандинского и Шагала. И среди них висит одна картина Рафаеля или Тициана. Если вы скажете, что картина Рафаэля выглядит дико на фоне остальных, будет ли это означать "мне не нравится"? Или это скорее "очень странное соседство"?
Вам не нравится и кажется диким.
Мне кажется диким, но не потому, что мне это не нравится.
Вопрос, почему вам кажется диким именно это, а не, например, весь русский язык после реформы 1918 года, вы упорно игнорируете.
Простите, вопроса почему мне не нравится именно "дорожная карта" я не видел. Могу объяснить что мне представляется диким, если желаете.
А вот обобщение того, что я нахожу странным (и неправильным) использование "дорожной карты" вместо "пути развития", на столь глобальные изменения языка, как это было в 1920-х годах прошлого века, выглядит для меня демагогией с вашей стороны.
Судя по статье, знать надо больше чем всё, но всё же как наглядная схема развития - неплохо.
как внутри устроены стандартные контейнеры std::vector, std::string, std::list, std::map;
как работают исключения, какие у них есть преимущества и недостатки;
современные стандарты C++ — 17 и 20. Необходимо не только знать их, но и уметь обоснованно применять на практике нововведения языка. То есть там, где это действительно необходимо и помогает сделать код лучше;
разницу между design-, compile- и runtime — а также не боится шаблонов.
А вы классический си не используете, только си++? Используя си могли бы расширить окно поиска кандидатов на программистов встроенного программного обеспечения, там знания архитектуры и многопотосности у людей довольно приличное.
Используем, просто статья про плюсы. А так - вот сишная вакансия: https://careers.kaspersky.ru/vacancy/19366
Почему не Rust - Касперский же! А на Rust - как анти/вирусы писать, если всё безопасно?!
Для этого есть Небезопасный Rust 👿
Мне стыдно что я не добавляю ничего по теме, я просто зашёл в комментарии почитать последние новости про Rust. Они обычно все в комментариях к статьям по C++. :)
На самом деле хорошо описано.
В умение писать код я бы добавил навык написания юнит тестов. Во-первых, этот навык позволяет писать "unitable" код, что делает его более масшатабируемым и надежным. А во-вторых, написанные тесты, являются отражением того, на сколько разработчик "осознаёт" написанный код - проверка базовых сценариев, сложных сценариев, сценариев с пограничными условиями, итд.
Также в статье ничего не указано о работе с CMake и пакетных менеджерах. Считаю что эти навыки необходимы для того, чтобы создавать библиотеки, которые могут быть легко интегрированы в другие проекты.
Bazel, скорее уж и без пакетных менеджеров. Я не думаю что в ЛК вообще есть CMake, так как они должны быть на монорепо при их масштабе проектов.
Да вы нас на сквозь видите - как раз мигрируем с cmake на базель.
На мой взгляд, монорепа в большом количестве масштабных проектов, это во-первых архитектурно неправильно, а во-вторых, это отложенное лечение мигрени в будущем.
Это совершенно ошибочное мнение приблизительно соответствующее "DDL-hell это прекрасно и позволяет лечить все проблемы вовремя". При наличии достаточно большого продукта монорепозиторий с trunk-based подходом к разработке вообще единственный возможный вариант собрать продукт во-время.
Несовсем понимаю вашу аргументы в пользу монорепы. Как разделение проектов по репозиториям влияет на врямя соборки?
Допустим есть продукт A и продукт B. A зависит от библиотеки CC, B также зависит от CC. И при этом A имеет еще одну библиотечную зависимость - DD.
Какой смысл держать A и B в одном репозитории если это разные продукты? Также зачем это делать для библиотеки вместе если они являются разными "сущностями" и подключаются под разные цели?
Когда библиотеки и продукты разделены по репозиториям, это грубо говоря добавляет "предохранитель" не сделать из кода трудно-интегриуемую мешанину.
Также, если у одного из продуктов есть зависимоть от конкретной версии библиотеки, то это можно легко сделать через пакетный менеджер, чтобы не билдить её каждый раз, что уменьшит время сборки.
Ещё, на мой взгляд странно, что когда сотрудник приходит условно в отдел по разработке антивируса, а ему надо тянуть гигабайты кода из репы и он сразу получает доступ ко всем остальным проектам.
Как разделение проектов по репозиториям влияет на врямя соборки?
На время сборки вообще никак, кэши и там и сям решат проблему приблизительно одинаково. А вот на саму возможность что-то собрать еще как влияет путем сведения к нулю политики и человеческого фактора.
Допустим есть продукт A и продукт B. A зависит от библиотеки CC, B также зависит от CC. И при этом A имеет еще одну библиотечную зависимость - DD.
Если А и Б находятся в одном репозитории, они оба зависят от: одного и того же сборочного тулчейна, одной и той же версии сторонних библиотек и внутренних компонентов. Если это убрать то рано или поздно проекты оказываеются в ситуации когда А зависит от ССв1, Б зависит от ССв2, ССв1 зависит от ... и так далее по цепоче. В определенный момент, когда компонентов много, обхем зависимостей просто перестает быть поддерживаемым.
Если учесть, что ССвХ разрабатывается командой в самой компании, то возникаю еще и политические моменты. Если проект А более влиятельный чем проект Б, он может принудить команду СС поддерживать говно мамонта потому что им удобно и мешать продуктам Б, В и Г вообще что-либо делать. И что характерно обычно так и бывает.
Ещё, на мой взгляд странно, что когда сотрудник приходит условно в отдел по разработке антивируса, а ему надо тянуть гигабайты кода из репы и он сразу получает доступ ко всем остальным проектам.
Что странного в сквозной видимости вносимых изменений? Если инженеру из команды А надо внести какие-то изменения в СС, он просто вносит их попутно внося точечные изменения в Б и В. Ему больше не надо ждать когда Б смилостивится для того что бы поднять версию СС у себя. В то же время владельцы СС знаю какие проекты могут пострадать от их внутренних изменений и либо заранее договориться с владельцами зависимых проектов об обновлении либо внести их своими силами.
Все это может не иметь особого смысла для мелких компаний где над проектами работает сотня другая инженеров (хотя я бы предпочел монорепо даже для стартапа из 3-4 инженеров), но когда речь начинает идти на тысячи инженеров, все просто кардинально меняется.
софт-скиллы. Тут достаточно просто «взрослого» подхода к работе: предупреждать заранее, если что-то не получается сделать в оговорённый срок, не замалчивать личные и рабочие проблемы и т. п
Вот конкретно этот пункт я бы крайне советовал пересмотреть в пользу полноценной проверки софт скилов. Так как лично наблюдал как у вас народ по телефону (да, да, тому самому что на каждом столе у всех стоит) друг друга буями кроют.
Учитывая сверхзавышенные требования и невозможность устройства на работу в такие конторы специалистов со средними навыками, очень странно что постоянно просачивается информация о подобных ситуациях на рабочем месте. Профессионалы ведь не могут так себя вести? Или могут? А если так, то нет ни смысла ни мотивации стремиться устроиться в подобные шарашкины конторы типа Касперского и Яндекса. Тем более что по зарплатному фонду они предлагают очень средненькую оплату труда за "отличное знание C++".
В ЛК никогда не было сверх завышенных требований и была весьма и весьма приличная оплата. В Я требования были в соответствии с количеством желающих у них работать, денег было по максимуму на рынке РФ, пока стоки не забанили. Не знаю как сейчас, давно из РФ уехал.
Стремится или нет выбор каждого, но в РФ на сегодня почти не осталось компаний в которых стоило бы работать, и ЛК да Я одни из немногих уцелевших.
В ЛК никогда не было сверх завышенных требований
Но статья, которую мы обсуждаем, говорит об обратном.
В статье есть два требования, если по группам разделить. Одно общее для всех групп - знание C++, второе знание ОС с которой надо работать Windows/Linux/macOS. Если это завышенные требования я затрудняюсь представить как будут выглядеть адекватные. И этих знаний реально хватает, хватало как минимум, что бы пройти туда собеседования.
Согласен что Я и ЛК это компании, которые являются предметом гордости и проф развития для тех специалистов.
Профессионалы ведь не могут так себя вести?
Только профессионалы и могут позволить себе так себя вести. На Маска посмотрите )
Так как лично наблюдал как у вас народ по телефону (...) друг друга буями кроют.
Так это не плюсовики, а гошники были. А с них, как и везде, спрос меньше.
применяйте тот инструмент, который ближе к задаче и которым может пользоваться команда.
а так, годная статья, но есть (если не ошибаюсь на хабре) нормальный такой роадмап c++ разработчика - отлично прорисованное дерево.
добавлю ссылку на роадмап https://miro.com/app/board/o9J_lpap34Q=/
и статью хабр https://habr.com/ru/articles/593503/
C++ — низкоуровневый язык
Помню времена, когда C++ был высокоуровневым языком )
Дорожная карта навыков разработчика на C++
Джеймс Гослинг как-то сказал, что Java — это C++, из которого убрали все пистолеты, ножи и дубинки, однако практика показывает, что «ножи и дубинки» становятся классным инструментом в руках опытных разработчиков. В общем, немалая часть проклятий в адрес C++ объясняется элементарным «вы просто не умеете его готовить». Мы в «Лаборатории Касперского» умеем готовить «плюсы» и поэтому любим их. C++ — низкоуровневый язык, который позволяет работать с железом и писать быстрый код и при этом содержит массу возможностей. В экосистеме «плюсов» куча проработанных паттернов, best practices и готовых библиотек под разные задачи. Язык динамично развивается — но сохраняет обратную совместимость.
В этом посте мы с помощью карты покажем, какие навыки и знания нужны разработчику на C++. Естественно, разбирать путь развития «плюсистов» будем на собственном примере — тем более что у нас в «Лаборатории Касперского» много очень разных проектов с отличающимися задачами. Однако наша карта по большей части универсальна и будет полезна всем, кто хочет развиваться в С++-разработке.