Уровни C++ разработчика

Нет YAGNI на 9-м уровне.

Не, ну если знание сетевых протоколов рассматривать как что-то специфическое, то конечно.

В моем понимании знания устройства ОС и сетевых протоколов есть необходимое условие для того, чтобы человек мог называться программистом.

Я сам сменил три или четыре области разработчи: embedded C++, Android, AOSP, backend. Успел пописать на 5 (или около того) разных языках.

И мой личный вывод: нормальный программист будет выдвавть нормальный код. Всегда. Потратит какое-то время, чтобы «въехать» в специфику проекта, конечно, но даже при сохранении всех-всех технологий ему пришлось бы это делать.

RTFM ;-)

Так ничего общего, или никаких проблем с переходом?

знание области - никаких проблем, потому что «перехода» не было. а вот в программировании, естественно, ничего общего. но программирование и API разных систем - это мелочи по сравнению с областью применения.

ну, в пять утра я уже несколько хотела спать :) иногда пальцы печатают что-то на автомате.

вопрос в глубине этих знаний. и именно это отличает опытного программиста от студента. всякие стандарты С++ - это мелочи жизни. а вот опыт разработки в конкретной области - это куда более ценный навык. человек без опыта вообще не может ничего проектировать. а программирование может быть и простым выполнением чётко заданного задания. в этом плане вообще одного опытного программиста и кучи нубов будет достаточно для номинального написания простого проекта. но не более. когда вопрос касается более сложных задач, где нужно понимание области применения, там уже нубы никак не канают. поэтому крупные компании набирают студентов «на обучение» и обучение может длиться лет пять. это не до опытного сотрудника, а только до состояния, когда студента можно допустить писать рабочий код :)

всякие стандарты С++ - это мелочи жизни.

Тем более, что их вообще, кроме Скотта Мейерса, никто и не знает.

а вот опыт разработки в конкретной области - это куда более ценный навык

Да ну, фигня. Программирование — оно везде программирование. Разные парадигмы — это да, важный навык; в некоторых областях есть весьма хитрые алгоритмы; но это, скорее, исключение.

поэтому крупные компании набирают студентов «на обучение» и обучение может длиться лет пять.

Это какие-то легенды. Я занимался обучением студентов, на полгода, раз в неделю — и больше там делать уж точно нечего.

а только до состояния, когда студента можно допустить писать рабочий код

С нормальным кодревью можно допускать кого угодно, правда практический выхлоп будет небольшой.

* Количество людей, работающих в одной большой компании 5+ лет, принебрежительно мало.
* «опыт разработки в конкретной области» легко заменить на «опыт разработки». Разобраться на должном уровне в конкретной области хороший программист может за 2-3 месяца (примерно столько же времени нужно чтобы «войти» в новый проект даже в знакомой области). Если область слишком глубокая, то тогда выгоднее держать отдельно эксперта в области и отдельно программиста. Элементарно потому, что заменить эксперта/программиста по отдельности намного проще.

ну, просто ты не сталкивался с большими проектами, видимо. но такие проекты есть. и порог вхождения - несколько лет. потому и берут студентов, чтобы вырастить специалистов под свои разработки. и программист не может не понимать, что он делает. поэтому нельзя разделить технологию и программирование.

пример такой разработки - мы в своё время разрабатывали банковское оборудование. очень долго надо было натаскивать студентов, чтобы они смогли хоть что-то сделать полезное. ещё у нас в городе есть производители сетевого оборудования и у них своя ось. насколько я понимаю, они взяли куски от кернела и слепили что-то совершенно своё. и они набирают специалистов под обучение под свою ось и свой софт. он ни с чем не совместим. такую же сильно модифицированную ось я видела у разработчиков для ЖД и электрооборудования для всякого городского транспорта. там кернел древний, вроде 2.6, но настолько сильно модифицирован, что от него уже почти ничего не осталось. тоже сильная специфика. есть контора, которая работает с мэйнфреймами IBM, пишут всё с нуля, на специфическом ассемблере. тоже специфика. и таких компаний немало.

Я на собеседованиях задаю вопрос: «Какая на Ваш взгляд самая крутая фича, введённая в 11м стандарте?»

Потому, что его нужность зависит от проекта.

Там же их слишком дохрена. Лямбды, вывод типов, foreach, rvalue-ссылки, поддержка многопоточности? Что из этого главным считать?

«Source code is a liability, not an asset» - Eric Lee. Не особо известная цитата малоизвестного программиста, но сказано хорошо. Вовремя сказать «You ain't gonna need it» очень полезно в любом проекте.

Когда знакомишься с девушками, ты задаешь вопрос: «Где находится нофелет?»

чтобы правильно делать KISS, надо, натурально, быть сениором

Ну или хотя бы сеньоритой:)

Судя по википедии, надо быть моряком.

Тем более, что их вообще, кроме Скотта Мейерса, никто и не знает.

Майерс «ушêл на пенсию» и больше не следит за новинками С++. Остался Херб Саттер.

просто ты не сталкивался с большими проектами

Определение «большого» в студию.

и порог вхождения - несколько лет

За эти несколько лет нормальный разраб уйдёт куда-нибудь ещё.

А Бьярна куда дели? Да и как бы еще есть просветленные комитетчики, пусть и нераскрученные.

Мне больше понравилось, что есть ОС (Linux/Windows), но нет VCS, есть только GIT.

То есть раньше масса народу подразумевала, что ОС - это Windows, а СУБД - это MS SQL Server. А теперь подразумевают, что VCS — это git. Других не знают.

Справедливости ради, git - это и есть винда, ибо >95% рынка на нём.

Ну гит все равно надо знать, даже если организация ведет разработку в другой vcs, так как в наше время неизбежно приходится как-то взаимодействовать с опенсорсными проектами, а они в большинстве своем используют гит

А в тех случаях, когда где-то используется hg, то либо есть автоматическое гит-зеркало, либо можно взаимодействовать с ним непосредственно с помощью git-клиента

Мне лично трудно прдеставить что-то более важное, чем override. Остальное - просто плюшки

Всё суета. Главное что стало можно >> нормально в шаблонах писать.

Он настолько полезный? final ещё понятно, а вот суть override от меня ускользает.

Ну Бьярн само собой присутствует и пропозалы тоже пишет.

ну, я следила за комитетом по стандартизации и за бустом раньше. когда они С++11 планировали. даже писала туда разные предложения. но сейчас я в основном работаю с чистым C и то, что они сейчас тащат в стандарт, мне совсем не нравится. стандарт превращают в помойку, имхо. поэтому я как-то потеряла интерес к этому вопросу. C++ хорош тем, что можно не использовать хипстерские ненужные навороты. но само направление его развития - а-ля бешеный принтер стандартов - это не есть гут.

С нормальным кодревью можно допускать кого угодно, правда практический выхлоп будет небольшой.

нет. если студент не понимает задачу, даже код-ревью не поможет. а в сложных проектах задачу ставит сам программист, естественно. никто ему пошагово всё разжёвывать не будет. потому что написать код проще и быстрее, чем написать подробную инструкцию к тому, как писать этот код. потому студенты и учатся долго. пока они начнут понимать, как всё работает, пока вникнут в сложные протоколы и всякие там патентованные алгоритмы, проходит очень много времени. а до этого они практически бесполезны.

ну, большой проект - проект, который разрабатывали много разработчиков, более 10-20 лет, например. привязанный к конкретному железу, которое не используется в публичном пространстве. или к каким-то осям, которые не используются нигде, кроме конкретной компании. или с повышенными требованиями к безопасности, надёжности. когда от работы кода зависит жизнь людей, или работа сложного и дорогого оборудования. студентов к таким проектам не подпускают за километр. такими проектами занимаются не сопляки и не стартаперы, они могут себе позволить выращивать специалистов и обеспечить, чтобы специалисты не разбежались.

вот суть override от меня ускользает.

Не даёт накосячить при переопределении виртуальных функций.

final ещё понятно

а вот это почти не нужно.

Уровни на картинке - бред сивой кобылы. Возможно, авторы посмотрели на свой опыт и расположили все знакоме слова в каком-то порядке.

Не даёт накосячить при переопределении виртуальных функций.

Пример?

Делает не то, что подразумевается (без override):

calss Foo {
public:
    void do_something() {
        std::cout << "1" << std::endl;
    }
}

class Bar: public Foo {
public:
    virtual void do_something() {
        std::cout << "2" << std::endl;
    }
}

int main() {
    Foo *foo = new Foo;
    Foo *bar = new Bar;
    foo->do_something();
    bar->do_something();
}

Не компилируется (с override):

calss Foo {
public:
    void do_something() {
        std::cout << "1" << std::endl;
    }
}

class Bar: public Foo {
public:
    virtual void do_something() override {
        std::cout << "2" << std::endl;
    }
}

int main() {
    Foo *foo = new Foo;
    Foo *bar = new Bar;
    foo->do_something();
    bar->do_something();
}

Компилируется и делает то, что подразумевается (с override):

calss Foo {
public:
    virtual void do_something() {
        std::cout << "1" << std::endl;
    }
}

class Bar: public Foo {
public:
    virtual void do_something() override {
        std::cout << "2" << std::endl;
    }
}

int main() {
    Foo *foo = new Foo;
    Foo *bar = new Bar;
    foo->do_something();
    bar->do_something();
}

ну, просто ты не сталкивался с большими проектами

Вижу что вы предпочитаете преписать какие-то качества вашему оппоненту и потом использовать их в споре.

P.S. AOSP достаточно большой и специфичный проект, как вы считаете?

На практике интересно только в проектах с развесистой иерархией наследования, что не всегда надо.

Иерархии наследования с виртуальными функциями есть практически в любом практически важном проекте. Исключение составляют шаблонные библиотеки, и то не все

Развесистость не важна, важна частота изменений в виртуальных функциях помноженная на количество людей, поддерживающих производные классы.

final позволяет компилятору делать девиртуализацию вызова, если используется указатель на небазовый по отношению к финальному методу класс

Да, превращает ошибки рантайма в ошибки компиляции, чистое добро

Вот мне и интересно мнение кандидата, правильного ответа нет, мне интересно послушать рассуждение.

Нет, я спрашиваю: «Девушка, а у Вас есть штруй?»

Ах вот оно что. Ну я обычно с таким кодом не сталкиваюсь.

И как? Много симпатичных распугал? С кем сложились полноценные долгосрочные отношения? Есть систематизированная таблица?

Отказывался общаться с теми, кто давал положительный ответ.

А если девушка симпатичная, но у нее есть штруй?

А если девушка симпатичная, но у нее есть штруй?

У тебя есть знания (исследования) про корреляцию симпатичности и отклика на «штруй»?

Ну я симпатичная девушка, а штруй у меня 20 метров.

правильного ответа нет, мне интересно послушать рассуждение.
Ну я симпатичная девушка, а штруй у меня 20 метров.

Так бы сразу и сказал, что ты просто тренируешь речевой(слоховой) аппарат, как https://www.youtube.com/watch?v=CUAyeKZi_1E

ну, андроид я всегда считала кучей говнокода, если честно :) и он так и не вырос из этой стадии, похоже. изначально кривая архитектура и жуткие костыли преследовали его все эти годы. он только прирастал в объёме, но лучше качественно не становился. я так и не считаю его чем-то достойным.

он и не честный опенсорц, и не целиком коммерческая разработка. что-то посередине. как китайский квартал: куча каких-то нагромождений и пристроек, но в целом жуть и мрак.