Здравствуйте, kosmik, Вы писали:
K>So?
А то, что как-то не вяжется то, что пишут на форумах, и то, что наблюдаю в реальной жизни. Да, на форумах все говорят, что никто не знает что такое виртуальный деструктор, а опыта по 10 лет в С++, что никто не знает что такое дерево, не различает никто связанный список и вектор. Ну не верю! Если профильное образование, и это читали, и сколько нибудь опыта есть — базу знать будут. Да, далеко не все знают, как внутри реализовано виртуальное наследование — в это поверю. Относительно дерева, что не все с ходу напишат балансировку дерева, 3 способа обхода дерева — да, поверю. То, что далеко не все скажут, что будет, если в Java переопределить equals, но не переопределить hashCode (и наоборот), и почему их надо переопределять вместе — в это тоже поверю (под сказать понимаю — с ходу привести пример). Что наизусть правила переопределения хеш кода тоже далеко не все помнят — да, это так. И то, что по памяти не все смогут специально дедлок сделать, поверю. Что не все сходу перечислят все типы полиморфизма в конкретном языке, да, это так. И много чего похожего, в это тоже поверю. Поверю потому, что далеко не все с таким сталкивается в работе, и, как результат, могут забыть.
Это я к тому, что говорите, что все козлы, ничего не знают, приводите примеры детских вопросов, но на деле вопросы были немножко другие наверняка, и ответ, уверен, подразумевался исчерпывающий, с перечислением всех возможных граблей — нет?
kosmik пишет: > > V>Т.е в одной компании, пусть и медлено, но человек и "классы дизайнил и > V>исключения понимал", а вот как к вам на собеседование сунулся сразу > V>перестал. > > Связаны эти высказывания довольно хорошо. Если в конторе достаточно > простые продукты, совсем длинные сроки etc, но на аналогичных позициях > она может позволить себе иметь менее квалифицированных сотрудников, > которые и классы дизайнить не умеют и не понимают как исключения > использовать.
"А у меня длинее" == "в конторе достаточно простые продукты". Думаю, не
имеет смscла обсуждать длину продуктов вашей и виртуальной контор. Ты
придумываешь высказывания некое и начинаешь его приписывать оппоненту. С
таким "в сад".
Ели контора делает продукт, а не пилит государево бабло, то содержать
неквалифицированных сотрудников она не может — от них одни убытки. Т.е.
такой сотрудник или родственник ББ, или будет уволен достаточно быстро
(3-6 месяцев), а если родственник, то он не будет менять теплое место.
>> Связаны эти высказывания довольно хорошо. Если в конторе достаточно >> простые продукты, совсем длинные сроки etc, но на аналогичных позициях >> она может позволить себе иметь менее квалифицированных сотрудников, >> которые и классы дизайнить не умеют и не понимают как исключения >> использовать. V>"А у меня длинее" == "в конторе достаточно простые продукты". Думаю, не V>имеет смscла обсуждать длину продуктов вашей и виртуальной контор. Ты V>придумываешь высказывания некое и начинаешь его приписывать оппоненту. С V>таким "в сад".
Скажем так, я описал то как я вижу ситуацию. Пока что разные требования к сотрудникам в разных компаниях (и как следствие, их квалификацию в-среднем) я могу объяснить тем что:
a) грубо говоря, то что обычно делает один человек там делают два
b) разная сложность продуктов
c) разная агрессивность в смысле сроков
V>Ели контора делает продукт, а не пилит государево бабло, то содержать V>неквалифицированных сотрудников она не может — от них одни убытки. Т.е. V>такой сотрудник или родственник ББ, или будет уволен достаточно быстро V>(3-6 месяцев), а если родственник, то он не будет менять теплое место.
От неквалицифированных сотрудников никакого _убытка_ обычно нет, есть просто меньший выхлоп.
BTW: пилить бабло можно не только государево, но и частное (некоторое время назад был очень смешной ролик про закрытие Адамант-Мультимедиа).
E>А то, что как-то не вяжется то, что пишут на форумах, и то, что наблюдаю в реальной жизни. Да, на форумах все говорят, что никто не знает что такое виртуальный деструктор, а опыта по 10 лет в С++, что никто не знает что такое дерево, не различает никто связанный список и вектор. Ну не верю! Если профильное образование, и это читали, и сколько нибудь опыта есть — базу знать будут. Да, далеко не все знают, как внутри реализовано виртуальное наследование — в это поверю. Относительно дерева, что не все с ходу напишат балансировку дерева, 3 способа обхода дерева — да, поверю. То, что далеко не все скажут, что будет, если в Java переопределить equals, но не переопределить hashCode (и наоборот), и почему их надо переопределять вместе — в это тоже поверю (под сказать понимаю — с ходу привести пример). Что наизусть правила переопределения хеш кода тоже далеко не все помнят — да, это так. И то, что по памяти не все смогут специально дедлок сделать, поверю. Что не все сходу перечислят все типы полиморфизма в конкретном языке, да, это так. И много чего похожего, в это тоже поверю. Поверю потому, что далеко не все с таким сталкивается в работе, и, как результат, могут забыть. E>Это я к тому, что говорите, что все козлы, ничего не знают, приводите примеры детских вопросов, но на деле вопросы были немножко другие наверняка, и ответ, уверен, подразумевался исчерпывающий, с перечислением всех возможных граблей — нет?
Сам я никогда вопросы типа перечислить типа полиморфизма, лично мне по барабану знает это человек теоретически или нет, мне интересно умеет это он использовать или нет. А проверяется это в дизайне классов какой-нибудь простой коллекции: тут же видно понимает ли человек что такое public а что такое private и как это нужно использовать. Не нужно спрашивать что такое инумератор или визитор — нужно посмотреть на то как человек вытащит наружу объекта какой-нибудь простой обход etc. Обход, заодно, и проверит как человек решит в коде простую задачку. Если у человека уже такие вещи вызывают проблемы, то чего ожидать от тех задач, с которыми придется сталкиваться на работе?
На моей памяти был не один случай когда в простейшую структурку тут же клали DbConnection и начинали объяснять каким образом будет устроена соответствующая таблица в базе.
Здравствуйте, kosmik, Вы писали:
K>Сам я никогда вопросы типа перечислить типа полиморфизма, лично мне по барабану знает это человек теоретически или нет, мне интересно умеет это он использовать или нет. А проверяется это в дизайне классов какой-нибудь простой коллекции: тут же видно понимает ли человек что такое public а что такое private и как это нужно использовать. Не нужно спрашивать что такое инумератор или визитор — нужно посмотреть на то как человек вытащит наружу объекта какой-нибудь простой обход etc. Обход, заодно, и проверит как человек решит в коде простую задачку. Если у человека уже такие вещи вызывают проблемы, то чего ожидать от тех задач, с которыми придется сталкиваться на работе?
Что могу сказать — очень похвально, побольше бы таких собеседующих.
kosmik пишет: > > Скажем так, я описал то как я вижу ситуацию. Пока что разные требования > к сотрудникам в разных компаниях (и как следствие, их квалификацию > в-среднем) я могу объяснить тем что: > a) грубо говоря, то что обычно делает один человек там делают два > b) разная сложность продуктов > c) разная агрессивность в смысле сроков
Но у кого длинее ты не знаешь, но выше утверждал, что у тебя.
> > От неквалицифированных сотрудников никакого _убытка_ обычно нет, есть > просто меньший выхлоп.
Как это? А что они зарплаты не получают? Или деньги у вас из тумбочки
берутся?
>> Скажем так, я описал то как я вижу ситуацию. Пока что разные требования >> к сотрудникам в разных компаниях (и как следствие, их квалификацию >> в-среднем) я могу объяснить тем что: >> a) грубо говоря, то что обычно делает один человек там делают два >> b) разная сложность продуктов >> c) разная агрессивность в смысле сроков V>Но у кого длинее ты не знаешь, но выше утверждал, что у тебя.
Одно из объяснений.
>> От неквалицифированных сотрудников никакого _убытка_ обычно нет, есть >> просто меньший выхлоп. V>Как это? А что они зарплаты не получают? Или деньги у вас из тумбочки V>берутся?
А вот так: нетто выхлоп для компании положительный.
kosmik пишет: > >> > От неквалицифированных сотрудников никакого _убытка_ обычно нет, есть >> > просто меньший выхлоп. > V>Как это? А что они зарплаты не получают? Или деньги у вас из тумбочки > V>берутся? > > А вот так: нетто выхлоп для компании положительный.
Можно к вам, я тоже работать не буду, а нетто выхлоп будет положительный.
K>На моей памяти был не один случай когда в простейшую структурку тут же клали DbConnection и начинали объяснять каким образом будет устроена соответствующая таблица в базе.
Философский вопрос. Это хорошо, или плохо, если с места — в карьер?
K>>На моей памяти был не один случай когда в простейшую структурку тут же клали DbConnection и начинали объяснять каким образом будет устроена соответствующая таблица в базе.
SD>Философский вопрос. Это хорошо, или плохо, если с места — в карьер?
А вот на мой — не все однозначно. Если это sample для KB — может, как раз так оно и нужно, безо всякой шелухи? На собеседовании других вариантов-то и не надо, проверяется-то сферический конь в вакууме. Вот пущай и проверяется.
Зато сразу видно, что человек помнит, как работать с БД. Вот, к примеру, я, позор на мою седую голову, не помню ничего из синтаксиса и прочих классов работы с БД. Хотя вроде бы не так уж и давно пилил JDBC драйвер для нетривиального DB provider'а...
SD>А вот на мой — не все однозначно. Если это sample для KB — может, как раз так оно и нужно, безо всякой шелухи? На собеседовании других вариантов-то и не надо, проверяется-то сферический конь в вакууме. Вот пущай и проверяется.
Лично меня настораживает подход "положу все в базу, потом буду думать что делать" в случае когда задается тривиальный контейнер.
SD>Зато сразу видно, что человек помнит, как работать с БД. Вот, к примеру, я, позор на мою седую голову, не помню ничего из синтаксиса и прочих классов работы с БД. Хотя вроде бы не так уж и давно пилил JDBC драйвер для нетривиального DB provider'а...
Может быть там где нужна работа с базой это и плюс, однако подход очень странный. Не будешь такому code review постоянный делать, потом обнаружишь что каждая ерунда делается в базе
K>Лично меня настораживает подход "положу все в базу, потом буду думать что делать" в случае когда задается тривиальный контейнер.
Если вспомнить принципы Agile и постоянный рефакторинг — честно говоря, проблем в таком подходе не вижу. Понадобится — переделаем. Premature optimization is the root of all evils. (С) сами знаете кто.
K>Может быть там где нужна работа с базой это и плюс, однако подход очень странный. Не будешь такому code review постоянный делать, потом обнаружишь что каждая ерунда делается в базе
IMHO (ну, не такое уж и H, скорее IMO), делать code review нужно всегда и всем. Даже гуристым гуру. Причем делать его лучше не шибко продвинутым сотрудникам.
Зачем?
Чтобы они, увидев непонятный или слишком сложный код, задали вопрос "а как это работает".
И гуру переписал бы оный код так, чтобы стало понятно. Или хотя бы расставил комментарии. Схему, на крайняк, нарисовал бы.
SD>Если вспомнить принципы Agile и постоянный рефакторинг — честно говоря, проблем в таком подходе не вижу. Понадобится — переделаем. Premature optimization is the root of all evils. (С) сами знаете кто.
Абсолютно лишняя итерация. Эквивалент тому что человек никогда не понимает с первого раза и не спрашивает. Это довольно дорого, особенно в ситуации когда сотрудника не майкроменеджат.
SD>IMHO (ну, не такое уж и H, скорее IMO), делать code review нужно всегда и всем. Даже гуристым гуру. Причем делать его лучше не шибко продвинутым сотрудникам. SD>Зачем? SD>Чтобы они, увидев непонятный или слишком сложный код, задали вопрос "а как это работает". SD>И гуру переписал бы оный код так, чтобы стало понятно. Или хотя бы расставил комментарии. Схему, на крайняк, нарисовал бы.
Может быть это и имеет смысл, хоть я придерживаюсь другого мнения. Фишка в том что когда появляется проблема с коммуникацией (а ситуация когда у человека первая итерация абсолютно неправильна) Вы предлагаете нейтрализовывать ее эффект через code review. На мой взгляд гораздо эффективнее решать саму проблему — если ход мыслей у человека таков что он выбирает плохие решения, не нужно его брать.
K>Абсолютно лишняя итерация. Эквивалент тому что человек никогда не понимает с первого раза и не спрашивает. Это довольно дорого, особенно в ситуации когда сотрудника не майкроменеджат.
Лишняя? А если этот код вообще потребуется выкинуть? Например, он был временным, для обхода какого-нибудь бага в тестовом фреймворке, или, что проще, чисто для демонстрации чего-либо на коротком собеседовании. В общем, если только вам не удастася доказать, что код потенциально опасен (к примеру, если это С++ и структура не noncopyable, а dbconnection при deep copy имеет проблемы — как, #$%^&, имеет проблемы любой вызов Carbon'а после fork() процесса без exec() в MacOS). И то, если заранее известно, как, где и зачем код будет применяться, — комментаний полечит проблему.
K>Может быть это и имеет смысл, хоть я придерживаюсь другого мнения. Фишка в том что когда появляется проблема с коммуникацией (а ситуация когда у человека первая итерация абсолютно неправильна) Вы предлагаете нейтрализовывать ее эффект через code review. На мой взгляд гораздо эффективнее решать саму проблему — если ход мыслей у человека таков что он выбирает плохие решения, не нужно его брать.
Видите ли, вы (может, подсознательно) приняли его решение как "плохое". Причем, я так понимаю, с этим бессмысленно спорить, т.к. ваше решение уже для вас аксиоматично. Соответственно, вы ищете не людей с хорошими решениями, а людей с _вашими_ решениями.
Скажу честно — это _очень правильный подход_ !!! Он позволяет создавать слаженные коллективы. Которые, возможно, делают и не самый гениальный софт. Но уж точно делают его последовательно, и, что еще важнее, предсказуемо.
SD>Лишняя? А если этот код вообще потребуется выкинуть? Например, он был временным, для обхода какого-нибудь бага в тестовом фреймворке, или, что проще, чисто для демонстрации чего-либо на коротком собеседовании. В общем, если только вам не удастася доказать, что код потенциально опасен (к примеру, если это С++ и структура не noncopyable, а dbconnection при deep copy имеет проблемы — как, #$%^&, имеет проблемы любой вызов Carbon'а после fork() процесса без exec() в MacOS). И то, если заранее известно, как, где и зачем код будет применяться, — комментаний полечит проблему.
Лишняя итерация — та, выхлоп которой в районе нуля. Даже если код выбрасывается целиком есть два случая:
a) мы поняли что какой-то способ, который считали хорошим на самом деле плох
b) мы изначально написали очевидный бред
А комментарии человек сам должен вытрясать. Или спрашиваешь или будь добр угадывать
Вариант (b) опасен. Это все равно что нанимать в дикторы заику, а в журналисты — человека, не владеющего письменной речью. Может быть с 10 попытки они что-то и родят, но смысл в такой потере времени?
SD>Видите ли, вы (может, подсознательно) приняли его решение как "плохое". Причем, я так понимаю, с этим бессмысленно спорить, т.к. ваше решение уже для вас аксиоматично. Соответственно, вы ищете не людей с хорошими решениями, а людей с _вашими_ решениями. SD>Скажу честно — это _очень правильный подход_ !!! Он позволяет создавать слаженные коллективы. Которые, возможно, делают и не самый гениальный софт. Но уж точно делают его последовательно, и, что еще важнее, предсказуемо.
SD>Так что —
Да нет, человек может объяснить почему его решение имеет право на жизнь. Только если объяснение состоит в том "я так привык думать" — в сад.