Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, DaBro, Вы писали:
Д>хотел бы я знать, что ты понимаешь под "основами ООП"
Д>PS у меня есть один знакомый, который не понимает толком разницы между виртуальными и невиртуальными функциями. Точнее, раньше не понимал Но при этом он пишет вполне качественный код — во всяком случае, намного лучше многих других наших коллег
Д>PPS А знаешь, что меня удивляет больше всего? Это работодатели, которые разводят неимоверные понты на собеседованиях и спрашивают целую кучу вещей, которые в реальной работе на этой позиции никогда не понадобятся.
Очень согласен с тобой. Опять разгорелся флейм "тупые кандидаты" vs "умные работодатели". Если вы такие умные, то почему такие бедные ? Ну не хотите — не берите тупое быдло, которое почему-то не знает в совершенстве ООП и не хочет работать у вас за 300 баксов (утрирую но предполагаю что ситуация из этого расклада)
Меня всегда умиляли собеседователи, делающие акцент на строгую теорию. Итак, начнем
Вот сейчас специально запустил поиск по проекту слова "virtual". Не поверишь — сие слово найдено только в комментариях, в проекте нет ни одной виртуальной функции. Как по-твоему живет и существует наш крупный заграничный проект, за котороый заказчик платит неплохие деньги ? всей команде надо убить себя об стену.
Да, мало того — из разговоров коллег выясняю, что многие не знают джаваскрипта и успешно пишут приложения, многие толком не знают что такое постбэк и тоже успешно пишут, многие веб-разработчики (!) вообще понятия не имеют как виртуальный каталог на ИИСе настроить. И все пишут и надо скзаать успешно. И я бы вовсе не назвал этих людей глупыми — они пишут вполне грамотный код (я если честно сам удивляюсь иногда как)
Ведь в реальности вся эта лабуда, типа изысков ООП, виртуальных деструкторов и паттернов, и даже виртуальных функций, почти не используется в реальных проектах. ах да, я забыл — вы такие проекты называете "убогими формочками", но тем не менее за эти формочки заказчик платит деньги, и немалые.
Кстати, об ООП. Вот сейчас работаю над проектом, который проектирвался явно товарищами, помешанными на ООП (несмотря на то что даже вирт. функций ни одной нету). Строгое отделение бизнес-логики от гуи, все сущности вынесены в классы, классов такое количество, что в них запутаешься, все обращение к БД через кучу провайдеров-адаптеров. Казалось бы все грамотно и правильно — однако малейшее изменение кода в рамках данной архитектуры — перематеришься пока сделаешь — чрезмерная "объектно-ориентированность" тоже ведет к путанице кода не хуже чем "гоу ту". А уж косяков по производительности (многократное повторное считывание одних и тех же данных) — так их вообще дофига.
Так что все хорошо в меру, в том числе и использование ООП.
Теперь о руководстве. С чего Вы взяли, что руководитель должен быть прилежным кодописателем ? Разумеется, понятие о кодописании он должен иметь, но по долгу службы руководителю больше приходится решать политические вопросы и общатсья с заказчиком, нежели писать код (я в бытность свою руководителем иногда по полтора месяца не писал ни строчки кода). А теория, пусть люди ее и учили, очень быстро выветривается.
Поэтому глуп тот работодатель который начинает дрючить по теории — все мы учили и высшую математику, и ТАУ, но это же не значит что все мы может сейчас сдать с ходу экзамен ? Мне больше импонируют работодатели, которые спрашивают те вещи, которые реально пригодятся в проектах, не зацикливаясь на деталях — а по рассказу кандидата о предыдущих проектах можно понять не меньше, чем по бумажному тесту на написание сортировки массива.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, creatman, Вы писали:
C>>Как можно писать высококачественный плюсовый код не различая виртуальных и невиртуальных функций. И ктомуже умения писать код это еще половина проблемы, другая половина это читать существующий код, понимать его и модифицировать.
Д>оказывается — можно. Код многих других, которые прекрасно знают, что такое виртуальная фнукция, намного хуже. Зачастую — на порядки.
Да, согласен, смотрите subj. Но причем тут виртуальные функции? Виртуальные функции это реализация полиморфизма в Си++, вы не используете полиморфизм???? Вы не используете ООП??? тогда о чем тут речь? Писать на чистом Си это одно, а говорить, что использовать виртуальные функции в Си++ необязательно это уже совсем грубая ошибка.
C>> А есть ведь еще такие вещи как виртуальное наследование
Д>Ну во первых, с виртуальными функциями у него общее только одно — это название. Д>А во вторых, кстати, в ABBYY виртуальное наследование запрещено к применению специальной инструкцией.
Это их проблемы, я думаю кривых рук хватает и в ABBYY
C>> И правильно. Потому что ромбы в иерархиях — это результат кривых рук архитектора.
Каких иерархиях? Пожалуйста приведите мне хоть одну иерархию без виртуальных функций (очень интересно)?
Здравствуйте, creatman, Вы писали:
C>>>Хм... C>>>Если человек не знает, что такое шаблон, интерфейс, виртуальное наследование, виртуальные функции (собственно человек не зает Си++ но кодирает на нем) как он может выбирать вариант реализации? Он будет делать такую реализацию, которая соответствует его уровню заний и опыту, а если и то и другое в небольших количествах, упасите боже.
xog>>Заменит это все невиртуальными реализациями, хуже если человек все это знает (по книжкам) и пытается слепить все вместе, вот тогда точно кранты. Самое главное — опыт.
C>МДаааа... No Comments
Каждый суслик в поле агроном ... (с)
Здравствуйте, creatman, Вы писали:
C>Здравствуйте, xog, Вы писали:
AS>>>Есть и такое. Мало где пригождается. Как говорится простота залог успеха
xog>>Абсолютно согласен
C>Абсолютно не согласен. Работаю в большой компании, над большой и серьезной системой, виртуального наследования тут хватает и оно тут к месту. И вопрос тут не в том пригождается оно или нет, а в том знает ли человек проектирующий систему и выбирающий вариант реализации о том, что виртуальное наследование есть вобще, и знает ли он, что если он его забудет использовать, то в определенных (в полне обычных случаях) его система рухнет как карточный домик! Если он не знает этого то просто у него нет опыта и он мало наступал на грабли, по которым прошли многие специалисты.
Сделать из сложного простое задача нетривиальная и виртуальное наследование этому никак не способствует
Здравствуйте, creatman, Вы писали:
C>МДаааа... No Comments
правильно пишет. Самый худший код, который я видел в своей работе — это написанный такими вот "мега-гуру", которые на ровном месте наворотили кучу ненужных фенечек. Так что в результате получилась "архитектура", которая расширяется во всех мыслимых направлениях, кроме тех, которые нужны реально. Кода я этот мусор переписал, объем кода уменьшился в разы. Это при том, что я еще новый функционал добавил.
Здравствуйте, dr.Chaos, Вы писали:
DC>Например, я мес назад устроился в крупную ИТ компанию. Собеседовали меня — жуть DC> только проекту около 20 лет и много унаследованного Сишного кода
Здравствуйте, creatman, Вы писали:
C>Да, согласен, смотрите subj. Но причем тут виртуальные функции? Виртуальные функции это реализация полиморфизма в Си++, вы не используете полиморфизм???? Вы не используете ООП??? тогда о чем тут речь? Писать на чистом Си это одно, а говорить, что использовать виртуальные функции в Си++ необязательно это уже совсем грубая ошибка.
полиморфизм разный бывает, и виртуальные функции далеко не единственное решение. И далеко не всегда лучшее.
C>Это их проблемы, я думаю кривых рук хватает и в ABBYY
удивительно только, почему это одна из немногих российских компаний, которые продают свой продукт по всему миру.
C>Каких иерархиях? Пожалуйста приведите мне хоть одну иерархию без виртуальных функций (очень интересно)?
какое вообще отношение имеют виртуальные функции к виртуальному наследованию?
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, _Obelisk_, Вы писали:
L>>>Ой, не факт... L>>>Особенно если тест на бумаге класса "напишите на С++ функцию сотрировки массива". _O_>>Многие, кстати, не способны написать сортировку. L>Я сам, кстати, тоже. Не смогу написать на С++ функцию сортировки на бумажке. Мне убицца апстену?
Убиваться апстену не нужно. Но придется признать, что, если Вы не понимаете, как работают и как могут быть оптимизированы такие простые алгоритмы, как сортировка массива, то вряд ли следует ожидать от Вас качественной разработки более сложного кода.
A>Хорошие спецы стараются поработать в иностранной конторе.
Хорошие спецы стараются поработать в успешной конторе. Вот странность, почему-то она со временем становится иностранной...
A>Оттуда, как результат, знание инглиша. А дальше куда? Правильно, попробовать за границей.
ИМХО, пробовать за границей нужно как можно раньше. Пока нет детей и еще здоровы родители.
A>Найти хорошего спеца с инглишом — вообще трудно.
Нет, найти хорошего спеца с качественным инглишом — очень дорого.
Здравствуйте, Александр Каширин, Вы писали:
АК>Здравствуйте, landerhigh, Вы писали:
L>>Здравствуйте, _Obelisk_, Вы писали:
L>>>>Ой, не факт... L>>>>Особенно если тест на бумаге класса "напишите на С++ функцию сотрировки массива". _O_>>>Многие, кстати, не способны написать сортировку. L>>Я сам, кстати, тоже. Не смогу написать на С++ функцию сортировки на бумажке. Мне убицца апстену?
АК>Убиваться апстену не нужно. Но придется признать, что, если Вы не понимаете, как работают и как могут быть оптимизированы такие простые алгоритмы, как сортировка массива, то вряд ли следует ожидать от Вас качественной разработки более сложного кода.
А часто вы оптимизируете сортировки в своих проектах ? Я лично не разу, хотя проектов хватало... Всегда использовали стандартные ф-ции и все работало нормально. Более того, сейчас провел опрос своих знакомых на предмет написания сортировок, но ни кто из них правильно на бумаге сразу написать не смог. При этом все без исключения смогли обяснить чем сортировки отличаются друг от друга и где какую надо применять.
Компания вроде бы не маленькая — человек 200, на рынке с 90-х годов. При этом на собеседовании ни когда не слышал (и сам не задавал если просили собеседование провести) вопросы по языку или по алгоритмам. Если человек смог сделать охрененный проект который работает уже пару лет и при этом не может написать сортировку — и хрен с этим ! Научим за пару месяцев, самое главное чтобы он у нас такой проект повторить смог !
Здравствуйте, landerhigh, Вы писали:
_O_>>Многие, кстати, не способны написать сортировку. L>Я сам, кстати, тоже. Не смогу написать на С++ функцию сортировки на бумажке. Мне убицца апстену?
Грустно. Гордиться тут нечем. Совсем примитивная сортировка пузыркем занимает несколько строчек. Чего там писать-то ?
Здравствуйте, ihatelogins2, Вы писали:
I>Здравствуйте, DaBro, Вы писали:
DB>>Последнее время приходится собеседовать много людей. И это меня повергает в уныние. DB>>Обычный кандидат не знает самых основ ООП но зато уже готов быть архитектором, получать больше чем самые квалифицированные разработчики из числа моих знакомых и уже успел поуправлять командой программистов (что же это за команда то была?). И это при том что ко мне такие перцы попадают из рук архитектора проекта и если я скажу да то мне потом с таким персонажем мучатся до конца проекта. Поэтому я естественно говорю твердое нет. Те же кто подходит для наших нужд в подавляющем большинстве не приходят работать. И я даже не знаю почему — мне об этом не говорят. Может нашего работодателя жаба душит? И вроде далеко не последняя софтверная контора... DB>>Чегож так мало хороших программистов то у нас.
I>За 130 тыров чистыми в месяц готов приятно удивить Вашу компанию уровнем профессионализма.
На сколько дней/недель? А то ведь вдруг потом кто-то 150 предложит %)
Здравствуйте, egaron, Вы писали:
E>Вот сейчас специально запустил поиск по проекту слова "virtual". Не поверишь — сие слово найдено только в комментариях, в проекте нет ни одной виртуальной функции. Как по-твоему живет и существует наш крупный заграничный проект, за котороый заказчик платит неплохие деньги ?
Я работал на крупном заграничном проекте на чистом Си без всяких плюсов, который берет начало в 80-х годах прошлого века. Так вот, как ни странно, уже тогда, когда не существовало такого понятия как ООП, разработчики уже мыслили этими понятиями! Я очень удивился, когда обнаружил в коде передачу кучи параметров через структуры, а некоторые вызовы сопровождались указателями на функции, которые нужно изнутри вызывать. Я вижу два основных признака ООП: инкапсуляция и полиморфизм. Даже несмотря на отсутствие тогда соответствующих средств разработки.
E>Ведь в реальности вся эта лабуда, типа изысков ООП, виртуальных деструкторов и паттернов, и даже виртуальных функций, почти не используется в реальных проектах.
Смелое заявление. Особенно насчет виртуальных деструкторов. Если класс хоть от чего-то наследован, то не применять виртуальный деструктор — это высшая степень безграмотности. (Прошу не рассказывать мне о случаях, когда внутри класса нет ни одной виртуальной функции, а данные состоят только из элементарных типов: даже если это так, то я смотрю на будущее и допускаю появление таких элементов внутри класса при расширении функциональности программного продукта).
E>Кстати, об ООП. Вот сейчас работаю над проектом, который проектирвался явно товарищами, помешанными на ООП (несмотря на то что даже вирт. функций ни одной нету). Строгое отделение бизнес-логики от гуи, все сущности вынесены в классы, классов такое количество, что в них запутаешься, все обращение к БД через кучу провайдеров-адаптеров. Казалось бы все грамотно и правильно — однако малейшее изменение кода в рамках данной архитектуры — перематеришься пока сделаешь — чрезмерная "объектно-ориентированность" тоже ведет к путанице кода не хуже чем "гоу ту". А уж косяков по производительности (многократное повторное считывание одних и тех же данных) — так их вообще дофига.
Несостоятельность архитектора, проектировавшего систему, вовсе не свидетельствует о несостоятельности ООП. Я, например, не понимаю, как вы реализуете кучу провайдеров-адаптеров, если у вас нет ни одной виртуальной функции? Как реализуется подстановка схожей функциональности на другом движке (скажем, смена БД)? Шаблонами с частичной специализацией? Или вообще полным переписыванием провайдера? А как же повторное использование кода? Что-то у вас с архитектурой явно не то...
E>А теория, пусть люди ее и учили, очень быстро выветривается.
Зависит от степени "выученности". Если человек зазубрил, чтобы сдать зачет — да, быстро забывается. А если он понимает процесс — в любой момент времени эти знания легко выуживаются из глубин мозга.
E>Поэтому глуп тот работодатель который начинает дрючить по теории...
Согласен. Именно поэтому практические тесты типа "решите, пожалуйста, вот эту задачу" мне тоже кажутся значительно более показательными. Я с некоторых пор являюсь ярым приверженцем выдачи тестового задания еще до технического собеседования (т.е. после вступительного собеседования, когда примерно понятно, что человек заинтересован у нас работать). При этом от человека в явном виде требуется разработка масштабируемого, расширяемого, надежного, поддерживаемого кода. Сложность задания оценивается примерно в 2-3 часа на фукнционал и еще 2-3 часа на красивое оформление. Мы давали на его реализацию неделю. Т.е. если человек хочет прийти к нам работать, то за неделю он наверняка сможет найти немножко свободного времени для того, чтобы показать себя. Это же, кстати, впоследствии позволит сэкономить время на техническом собеседовании (а не так как в фирме Materialise в Киеве: собеседование расчитано на полный день до вечера).
Так вот, любопытнейшие результаты, я вам скажу Примерно 80% решений удается "завалить" парой-тройкой тестовых примеров. Больше половины оставшихся написаны методом "copy-paste" (это если обобщенно). А один кадр, получив задание, вообще замолк, и через его знакомых до нас дошла информация, что он на нас обиделся: "Они там что, студентом меня считают что ли? Дают задание, на которое в интернете можно найти кучу решений. Да пошли они куда подальше, я им не студент, мой уровень не настолько низок, чтобы вот так меня тестировать". Тут тоже понятно: завышенная самооценка и немеренные амбиции, от чего потом огребем по полной программе (я готов обосновать, в моей практике есть парочка примеров).
E>Мне больше импонируют работодатели, которые спрашивают те вещи, которые реально пригодятся в проектах, не зацикливаясь на деталях — а по рассказу кандидата о предыдущих проектах можно понять не меньше, чем по бумажному тесту на написание сортировки массива.
Как проверить, что кандидат наговорил про "свои проекты" всю правду и только правду и ничего кроме правды?
DC>Собеседовали меня — жуть. Сначала большой группой, потом поменьше, потом мой нынешний тим лидер. Много спрашивали про ООП и особенно про паттерны. Приняли.
Вы не поняли, им просто очень хотелось узнать про паттерны от знающего человека.
Здравствуйте, Дарней, Вы писали:
Д>PPS А знаешь, что меня удивляет больше всего? Это работодатели, которые разводят неимоверные понты на собеседованиях и спрашивают целую кучу вещей, которые в реальной работе на этой позиции никогда не понадобятся.
У меня такое ощущение, что эти вопросы задаются исключительно с целью занизить предлагаемую зарплату на собеседовании Чтобы всегда можно было задать "сложный" вопрос типа "а какой GUID у IXMLDomDocument" (для программеров), или "серийный ключ Винды" (для сисадминов), или "IP-адрес сайта Майкрософт" (для web-девелоперов) а затем со знанием собственного превосходства сказать "ну на такую зарплату вы явно не подходите, можем предложить в 2 раза ниже"
Здравствуйте, memorilik, Вы писали:
M>Здравствуйте, Александр Каширин, Вы писали:
АК>>Убиваться апстену не нужно. Но придется признать, что, если Вы не понимаете, как работают и как могут быть оптимизированы такие простые алгоритмы, как сортировка массива, то вряд ли следует ожидать от Вас качественной разработки более сложного кода.
M>А часто вы оптимизируете сортировки в своих проектах ?
Сортировку приходилось оптимизировать только один раз — примерно в начале 90-х годов. Потому что Quick Sort в тех условиях давал средний результат больше n*log(n). А вот другие алгоритмы (в смысле, не сортировку) доводилось оптимизировать неоднократно, начиная от задач реального времени и заканчивая проектами, в которых итерационная расчетная часть в неоптимизированном варианте выполнялась десятками минут вместо нескольких секунд.
M>Если человек смог сделать охрененный проект который работает уже пару лет и при этом не может написать сортировку — и хрен с этим ! Научим за пару месяцев...
Ух... пара месяцев на алгоритм сортировки... мечта Мне обычно на исследование подобного объема новой информации давалось два дня, причем самообучения (потому как новая технология, по которой специалистов под рукой нет)
