Здравствуйте, ilya_ny, Вы писали:

_>Здравствуйте, DaBro, Вы писали:

_>... "откуда столько криворуких?", "перцы", "персонажи", "мне с таким мучатся до конца проекта" (попробуй "мучиться"), ... "я говорю твердое нет"
_>ты что хотел этим сообщением донести? какой ты способный архитектор и понимаешь "основы ооп" ?

_>от твоего снобизма просто воротим. вот поэтому и не идут к тебе

DB>>Те же кто подходит для наших нужд в подавляющем большинстве не приходят работать.


_>видят, наверное, люди что за "перец" с ними беседует, чувствуют что "будут мучиться с таким до конца проекта" и поэтому говорят ему "тведое нет"


Извините, а Вы пробовали собеседовать людей? Я вот пробовал. И зп мы им обещали ВЫШЕ среднего. Только 80% кандидатов полностью неадекватны. Так что честно говоря я не понимаю почему все набросились на автора поста.

Здравствуйте, Геннадий Васильев, Вы писали:

P>>>Скорее, взялся возглавить сапожное производство — там от него избавиться намного сложнее.
E>>Т.е. бывший программист, взявшийся возглавить процесс разработки, это плохо?
ГВ>Обобщать нельзя, но зачастую ситуация напоминает "потеряли хорошего программиста и получили паршивого менеджера".

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

Здравствуйте, Дарней, Вы писали:

ГВ>>Обобщать нельзя, но зачастую ситуация напоминает "потеряли хорошего программиста и получили паршивого менеджера".
Д>Но еще хуже, когда хороший менеджер превращается в никудышного тим лида или например архитектора.

Такое случается крайне редко, практически не случается никогда.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Александр Каширин очень точно подметил особенность простого кода. Вы никогда не сталкивались с проектами на десяток мегабайт очень-очень простого кода, где зависимости проявляются в самых неожиданных местах?

Встречался. Но обьем кода совсем не мешал. Мой любимый метод навигации по коду — полнотекстовый поиск нужных идентификаторов по каталогу с сорсами. Часто приходится использовать и более точные инструменты поиска и навигации, но это уже по результатам полнотекстового поска, иногда с использованием резулярных выражений и только по частям идентификаторов.

ГВ>Да я тоже как-то не ратую за красоты ради красот. Просто наперёд трудно знать, что именно потребуется из механизмов C++. Потому мне и кажется глупостью превентивный запрет на что-то, мотивированный борьбой с "красотами ради красот". То есть механизм языка здесь неправомерно приравнивается к "красивостям", только и всего.

Ситуация: есть код, есть опыт доработки этого кода, известно время, необходимое для каждого дополнительного улучшения; известно, что это время в данном проекте незначительно по сравнению со временем проработки планируемого обьема фич и внешних взаимодействий. Ситуация практически идеальна. Вопрос, зачем разрешать дополнительные фичи, если ни одного серьезного показателя это не улучит (поскольку они и так на максимуме), а ухудшить может вполне ?

ГВ>>>А то мы так докатимся, что "лучше, проще и яснее" писать malloc/free и lock/unlock чем пользоваться деструкторами. Ясен пень, тут же мануалы читать надо. За шаблоны вообще лучше промолчу.

K>>Простота и доступность каждой фичи оценивается исходя из практики, а не берется с потолка. Деструкторы — проще, чем malloc/free, особенно если запретить невиртуальные деструкторы.

ГВ>Даже в сугубо инлайновых классах тоже нужно запрещать невиртуальные деструкторы? Это чтобы у любого класса была VMT или ещё зачем-то?

Это затем, чтобы не забыли сделать virtual destructor тогда, когда надо. В библиотечных классах можно сделать исключение. "Сугубо инлайновые классы" туда вполне просятся. Фактически, отказ от виртуального деструктора — это предварительная оптимизация, а она уместна по большей части именно в библиотеках. На редкие исключения можно и комментариев нагородить с более плотным ревью.

K>>А без шаблонов в основном коде жить вполне можно, оставив их только в библиотеках. Хотя любителям монолитных приложений этого не понять.

ГВ>Да ну? А RAII-обёртки как же?

Приведите пример обертки, которую нельзя загнать в библиотеку, и для которой нужны темплейты. Еще, взоможно, я неточно выразился — имелось в виду определение новых шаблонов, а не применение уже имеющихся.

K>>Значит займетесь чем-то другим, а засабмиченный вами код может оказаться откачен. [...]

ГВ>А с чего вы взяли, что я пойду работать в такую компанию, а если и пойду, то буду нарушать установленные в ней правила?

Про первую часть — потому что это все мелочи и едва ли играли бы роль при выборе работы. Про вторую ничего сказать не могу.

Mikhail

Здравствуйте, Александр Каширин, Вы писали:

K>>В результате обьем работы по изменениям, несмотря на меньший исходный код, оказывается больше. В частности, регулярно приходилось разламывать компактные if-ы с множеством условий в одном месте, изничтожать многочисленные return и оставлять один, и тому подобное, иногда даже добавлять буленовые флаги, как в приводившемся тут примере. Если же условия были бы разбиты на вложенные if-ы изначально, анализировать и разбирать пришлось бы меньше.

АК>Мне как раз показалось наоборот: в приведенном примере с булевскими флагами код значительно сложнее для анализа и хуже структурирован.

Там — да, не вопрос. Но в реальном коде бывает. Дело в большом размере if-а, большом числе и глубине вложенных if-ов с наличием логики на множестве разных веток, и в конечном счете в большом числе мест, где оказывается идентичный код, который можно выполнить сразу перед выходом из главного if-а. Такой код можно вынести и выполнять по boolean-у. Обычно выглядит логично.

K>>Есть ситуации, когда вывод о работоспособности кода делается после запуска тестов, а есть ситуации, когда это недостаточно убедительно и надо проследить всю логику обработки конкретного типа запроса, включая альтернативные ветки. В последнем случае чем проще код, тем лучше.

АК>Насколько мне известно, тестирование как раз и придумано потому, что человек не в состоянии безошибочно проанализировать поведение программы на основании code review — он все равно чего-то не заметит. Так "может в консерватории что-то подправить"? (с) М.Жванецкий Я имею в виду, может тест-кейсы переработать и дополнить?

Эти две вещи друг друга взаимно дополняют. Тесткейсы — средство для нормальной реализации, в которой могут быть ошибки. Начиная с какого-то момента приходится временно отложить тесткейсы в сторону и лезть разгребать нечто странное, во что превратился код после кучи срочных багфиксов, накопившихся за несколько лет. Ручной анализ — средство для ремонта изрядно "проржавевшей" реализации, текущее применение которой не соответствует условиям, для которых дизайнился первоначальный вариант, и которая из-за многочисленных прикрученых хаков и частичных доработок начинает выдавать странные трудноповторимые баги.

Здравствуйте, Eurispheus, Вы писали:

E>Такое случается крайне редко, практически не случается никогда.

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

Здравствуйте, kittown, Вы писали:

K> Ручной анализ — средство для ремонта изрядно "проржавевшей" реализации, текущее применение которой не соответствует условиям, для которых дизайнился первоначальный вариант, и которая из-за многочисленных прикрученых хаков и частичных доработок начинает выдавать странные трудноповторимые баги.

Блин, столько такого кода уже "восстановил" (по той же аналогии с химией — ржавчина тоже восстанавливается). Уже и опыт немалый в этом есть — кривой код приводить в состояние рабочего. Без документации. Без связи с разработчиками. Без ТЗ. Интересно, мне пригодится этот опыт в нормальных конторах? Впрочем, каюсь, скрипя сердце, писал и костыли к коду, когда время не позволяло поставить все на ноги другимим средствами...
ПЫСЫ А хочется-то все равно писать нормально, с нуля, чистенько. Эх, вот отпуск отгуляю — меняю место жительства и работу...

Здравствуйте, kittown, Вы писали:

ГВ>>Александр Каширин очень точно подметил особенность простого кода. Вы никогда не сталкивались с проектами на десяток мегабайт очень-очень простого кода, где зависимости проявляются в самых неожиданных местах?
K>Встречался. Но обьем кода совсем не мешал. Мой любимый метод навигации по коду — полнотекстовый поиск нужных идентификаторов по каталогу с сорсами. Часто приходится использовать и более точные инструменты поиска и навигации, но это уже по результатам полнотекстового поска, иногда с использованием резулярных выражений и только по частям идентификаторов.

Вопрос в том, сколько времени уйдёт на эту самую навигацию.

ГВ>>Да я тоже как-то не ратую за красоты ради красот. Просто наперёд трудно знать, что именно потребуется из механизмов C++. [...]

K>Ситуация: есть код, есть опыт доработки этого кода, известно время, необходимое для каждого дополнительного улучшения; известно, что это время в данном проекте незначительно по сравнению со временем проработки планируемого обьема фич и внешних взаимодействий. Ситуация практически идеальна. Вопрос, зачем разрешать дополнительные фичи, если ни одного серьезного показателя это не улучит (поскольку они и так на максимуме), а ухудшить может вполне ?

Вагон неправильных рассуждений.

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

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

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

ГВ>>>>А то мы так докатимся, что "лучше, проще и яснее" писать malloc/free и lock/unlock чем пользоваться деструкторами. Ясен пень, тут же мануалы читать надо. За шаблоны вообще лучше промолчу.
K>>>Простота и доступность каждой фичи оценивается исходя из практики, а не берется с потолка. Деструкторы — проще, чем malloc/free, особенно если запретить невиртуальные деструкторы.
ГВ>>Даже в сугубо инлайновых классах тоже нужно запрещать невиртуальные деструкторы? Это чтобы у любого класса была VMT или ещё зачем-то?
K>Это затем, чтобы не забыли сделать virtual destructor тогда, когда надо. В библиотечных классах можно сделать исключение. "Сугубо инлайновые классы" туда вполне просятся. Фактически, отказ от виртуального деструктора — это предварительная оптимизация, а она уместна по большей части именно в библиотеках. На редкие исключения можно и комментариев нагородить с более плотным ревью.

Мотивация понятна: "чтобы не забыли сделать virtual destructor тогда, когда надо". Иными словами: "на всякий случай". Кстати, некогда я слышал о таком же "на всякий случай", но звучало это примерно так: "всё наследование должно быть виртуальным, все методы должны быть виртуальными". Не находите забавным?

K>Приведите пример обертки, которую нельзя загнать в библиотеку, и для которой нужны темплейты.

Хорошо, с этим согласен пока, обёртки имеет смысл отгонять в библиотеки.

K>Еще, взоможно, я неточно выразился — имелось в виду определение новых шаблонов, а не применение уже имеющихся.

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

Здравствуйте, Eugeny__, Вы писали:


E__>Блин, столько такого кода уже "восстановил" (по той же аналогии с химией — ржавчина тоже восстанавливается). Уже и опыт немалый в этом есть — кривой код приводить в состояние рабочего. Без документации. Без связи с разработчиками. Без ТЗ.

А мне нравится "восстанавливать" — почти детективное расследование иногда получается.

Здравствуйте, Александр Каширин, Вы писали:

АК>Если на просьбу написать, хоть и простое, но надежное, масштабируемое, расширяемое и поддерживаемое приложение, человек отвечает, что кучу решений этого задания можно найти в интернете, то я уже начинаю сомневаться в том, что он выполнит мою просьбу (причем по всем четырем критериям сразу). А это значит, что он просто не представляет себе, что от него требуется.

А я вообще считаю, что интервью — это не только способ оценить кандидата, но и оценить работодателя. Если интервьюер задает вопросы, основываясь на случайной выборке из справочной литературы, вопросы неинтересны и не претендуют на то, чтобы бросить вызов моему интеллекту (желательно именно интеллекту, а не памяти, причем той его части, которая, все-таки связана с разработкой ПО), это означает, что что он несерьезно подошел к вопросу подбора персонала (или, по крайней мере, его взгляды на этот процесс существенно отличаются от моих) и его команда наверняка состоит из случайных людей (или людей, который не разделяют моих принципов). В таком окружении я, вероятно, не смогу полноценно развиваться профессионально, а это приведет к потере уважения к себе, времени, энтузиазма, не говоря уже о деньгах (когда придет время менять работу). Несколько сотен баксов в месяц не стоят того.

При выборе работодателя применимы те же подходы, что и при выборе работника (луче упустить хорошего, чем получить плохого; благо, рыночная коньюктура позволяет так рассуждать). Это даже более важно из-за эксклюзивного характера отношений. С другой стороны, этого добиться проще: работодателей не так много и можно найти какую-то информацию. И в процессе сбора информации интервью занимает непоследнее место.

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

АК>Значит максимум, что с ним можно сделать после принятия на работу — это начинать его учить на позиции Junior. Однако из его амбиций следует, что студентом он быть не намерен.

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

Но в примере с этим гипотетическим кандидатом, описываемое поведение вовсе не является примером проявления амбиций. Это, скорее, проявление гордыни. Если бы кандидат сказал, что он готов расшибиться в лепешку, чтобы через полгода посредством самосовершенствования стать senior, вот это настоящие амбиции, которые можно только приветствовать.

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Здравствуйте, Александр Каширин, Вы писали:

АК>>С тех пор я согласен с Биллом Гейтсом: лучше не взять на работу 10 отличных специалистов, чем взять на работу 1 плохого.

AWW>А говорят, что Шаляпина тоже в хор не брали... А Энштейн был троешником...

AWW>Да что там они, сколько раз меня, по молодости на работу не брали... Говорили, что я чего-то там не умею... Я правда один раз потом тоже их на работу не взял... Но уже чисто по злобе....

AWW>А вообще, что-бы кто не говорил, практика критерий истины — если у человека, есть реализованные проекты, значит и у вас будут, а если он знает что такое виртуальные функции (вот ведь умора, что там можно не знать) но пректов у него нет... Значит и у вас будет занайка безрукий...

У кандидатов чаще всего есть реалиованные проекты (очевидное ислючение — кандидаты на позицию junior). Но часто бывает, что когда начинаешь копать поглубже, выясняется, что не дай Бог нам такую реализацию...

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

А на счет "знаек безруких" — то мне как-то не попадалось. Зазубренные знания, не подкрепленные достаточной практикой, в голове не задерживаются. А вот обратное случается гогаздо чаще. Человек нашел таки способ сделать что-то и решил конкретную задачу, но ему невдомек что можно было решить гораздо проще, если бы он разбирался в предмете (чаще всего достаточно иметь хорошее общее представление и помнить несколько ключевых слов чтобы быстро найти документацию). Вот пример: один кандидат рассказывал, что разработал собственный класс-контейнер (и использовал его в коммерческом проекте), любое изменение размера которого приводило к realloc (не говоря уже о других недостатках по сравнению с std::vector, таких как использование конструктора копирования при перемещении объектов в памяти, возможность применения библиотеки алгоритмов и т.д.).

AWW>А вообще по моему, все эти вопросы, и такое острое восприятие ЗНАЕТ-НЕЗНАЕТ , это скорее всего говорит, о том что тестер недавно институт закончил... Или изучает с++ до сих пор... Вот мне как проффесионалу, вообще по**** на каком языке програмировать... Надо будет на каком-то новом, выучи за пару недель....

Джоел писал, что имеються некоторые "априорные формы", которые некоторые люди понять не могут (во всяком случае это дается очень тяжело). К ним он отнес концепцию указателей. Из за этого миграция с VB в C++, например, может быть делеко не так проста. В большинстве же остальных случаев нашей отрасли смена технологий является совершенно обычным явлением. Найти кандидата, который подходил бы по всем параметрам сразу обычно слишком сложно и дорого. И это все равно не гарантирует, что вскоре его не придется переобучать всвязи с развитием технологий.

AWW>Да кстати, мне вот понравился один ответ на вопрос — "а почему вы меня по языку не спрашивали"... "Вы же профессионал — надо будет выучите..." был ответ...

Ну, если Вы наглядно продемонстрировали, что увас есть успешный опыт обучаемости, то это совершенно нормально. Другое дело, что не все работодатели могут себе позволить втечение продолжительного времени обучать сотрудника или ждать пока он сам набереться опыта (все-таки оценка в 2 недели чрезывчайно оптимистична, особенно в случае с C++; тем более, что за языком потянется ворох смежных технологий): при этом не только падает производительность нового сотрудника, но и отнимается время у более опытных коллег.

А вообще здесь важен разумный баланс (и разумность его зависит от конкретного случая). Большинство организаций сочтет нерациональным учить ASP-програмиста писать драйверы для Linux.

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>А говорят, что Шаляпина тоже в хор не брали... А Энштейн был троешником...

AWW>Да что там они, сколько раз меня, по молодости на работу не брали... Говорили, что я чего-то там не умею... Я правда один раз потом тоже их на работу не взял... Но уже чисто по злобе....

Да, ну уж если Вас (!) не брали, то у Шаляпина с Энштейном тем более никаких шансов, конечно же, не было...

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, Александр Каширин, Вы писали:

АК>>О! Прекрасное заключение мысли! А разве мы рассматриваем варианты, когда ищем работу в фирме, в которой не очень-то и хотелось бы работать? Я такие предложения фильтрую еще на этапе первого звонка от HR или заменяющего его менеджера

Д>В пределах досягаемости нет ни одной компании, где "очень хотелось бы работать". А переезжать я пока не собрался

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

На самом деле разработческие фирмы очень сильно отличаються. Может быть Вы просто еще не понимаете, что именно вы хотели бы получить от смены работодателя? Если четко определить критерии поиска, то количество подходящих вариантов может радикально согратиться.

Поиск работы по принципу "где меньше напрягают на собеседовании" скорее всего приведет Вас не в лучшее место.

E>>Меня всегда умиляли собеседователи, делающие акцент на строгую теорию. Итак, начнем

LVV>Меня вообще удивляет — зачем на собеседовании чего-то спрашивать по профессии... Гораздо правильнее оценить кандидата на предмет уживаемости в коллективе, оценить его лидерские или нелидерские качества... А по професси все сразу станет ясно, если взять его на испытательный срок — хотя б и на две недели всего...
LVV>Помнится, мне в первый день работы дали написать реальную прогу на коболе (ну контора на нем работала... , который я сдавал тока в институте... Я написал — начальник был в полном ауте... Он не мог поверить, что я с листа накатал реально работающую прогу на малознакомом языке...
LVV>Естественно, взяли на постоянку без всяких вопросов...

LVV>И в собеседовании — ну сразу видно, кидает кандидат понты или нормальный чел, который уживется в коллективе и реально поможет проекту...

Тезис о том, что кухарка может управлять государством не стоит распространять на работу в сфере разработки ПО. Кандидат должен продемонсрировать профессиональные навыки с учетом позиции, на которую он претендует (в нашем отделе, например, знание C++ является необязательным на позицию Junior, но, при этом, совершенно необходимо глубокое знание для кандидата на позицию Senior, хотя первый может достаточно быстро превратиться во второго). Давать ответственную позицию неопытному (в требуемой области; хотя в ряде случаев можно "зачесть" опыт в других областях) кандидату не только опасно (работодатель лишается рычага воздействия в случае возникновения проблем), но и подрывает мотивацию к саморазвитию.

Навык коллективной работы — это важный профессиональный (нетехнический) навых. Я согласен, что достаточно часто ошибочно игнорируются нетехнические навыки и качества кандидата (такие как умение найти общий язык с людьми, умение изложить свои идеи, умение понять чужие идеи, инициативность, целеустремленность и т.п.), но отказываться от оценки технических навыков также нерационально.

Здравствуйте, egaron, Вы писали:

E>Очень согласен с тобой. Опять разгорелся флейм "тупые кандидаты" vs "умные работодатели". Если вы такие умные, то почему такие бедные ? Ну не хотите — не берите тупое быдло, которое почему-то не знает в совершенстве ООП и не хочет работать у вас за 300 баксов (утрирую но предполагаю что ситуация из этого расклада)

Между прочим, ошибочные предположения — это один из неиссякаемых источников ошибок. Обычно лучше разобраться, является ли это предположение надежным (а еще лучше — фактом) прежде чем начинать кодировать.

E>Меня всегда умиляли собеседователи, делающие акцент на строгую теорию. Итак, начнем

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

E>Вот сейчас специально запустил поиск по проекту слова "virtual". Не поверишь — сие слово найдено только в комментариях, в проекте нет ни одной виртуальной функции. Как по-твоему живет и существует наш крупный заграничный проект, за котороый заказчик платит неплохие деньги ? всей команде надо убить себя об стену.

Можно пойти дальше и писать код исключительно для машины Тьюринга. Заказчика можно убедить тем, что на машине Тьюринга можно решить любую алгоритмическую задачу (и это математически доказанный факт). При этом можно радикально сократить затраты на рабочую силу, ведь с машиной тьюринга могут разобраться дети начиная с класса примерно 6-го. При этом можно не опасаться выхода Turing Framework очередной версии из-за которой сотрудников придется переучивать.

E>Да, мало того — из разговоров коллег выясняю, что многие не знают джаваскрипта и успешно пишут приложения, многие толком не знают что такое постбэк и тоже успешно пишут, многие веб-разработчики (!) вообще понятия не имеют как виртуальный каталог на ИИСе настроить. И все пишут и надо скзаать успешно. И я бы вовсе не назвал этих людей глупыми — они пишут вполне грамотный код (я если честно сам удивляюсь иногда как)

К сожалению (или к счастью), общепризнанных стандартов качества кода не существует. Для некоторых грамотный код это то, что компилируется. Другие пишут про это книги. Что русскому хорошо, то немцу — смерть

E>Ведь в реальности вся эта лабуда, типа изысков ООП, виртуальных деструкторов и паттернов, и даже виртуальных функций, почти не используется в реальных проектах. ах да, я забыл — вы такие проекты называете "убогими формочками", но тем не менее за эти формочки заказчик платит деньги, и немалые.

Ну конечно, реальным пацанам зачем паттерны? Главное лавэ срубить, да побольше!

Здравствуйте, Dair, Вы писали:

D>Здравствуйте, DaBro, Вы писали:

D>Для справки: я в своей жизни за 7 лет опыта использовал множественное наследование 2 (два) раза, когда так было просто удобнее. При этом ромбообразного наследования там не было и в помине.

Мне вот тоже как-то не доводилось использовать виртуальное наследование, а на одном из интервью у меня спросили, как я бы реализовал такую-то фишку, если бы был разработчиком компилятора. Стоит ли говорить, что в книжках про такое не пишут (я ни разу не видел), а серьезной разработкой компиляторов никогда я не занимался. Однако оказалось, что если хорошенько поработать головой и прикинуть, как решение может вписаться в имевшиеся у меня знания и опыт, то остаеться всего пара работоспособных вариантов...

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

D>Я встречал людей, которые прекрасно знали основы ООП. Но применять на практике боялись (именно так).

Это говорит, скорее, что основы-то они не знали, а просто ориентировались в терминологии.

D>Резюме: досконально знать принципы ООП надо учителю программирования, имхо. А разработчику надо уметь их правильно применять.

Я никогда не требовал от кандидатов подобных определений, но для себя лично считаю это важным хотя бы потому, что это позволяет лучше излагать свои мысли и избегать ошибочного понимания чужих. При наличии опытыта и понимания освоить терминологию несложно (обратное гораздо сложнее). Так почему бы это не сделать?

D>Давайте рабочий тест. Даже тем, кто не знает принципов ООП. Потом устройте code revision. Позовите коллег. Будет круто, точно говорю

А еще прикольно бывает протестировать коллег (возможно из другого отдела) на своих вопросах и тестах. Это позволяет адекватно оценить сложность заданий и не дает коллегам расслабиться У нас такое периодически практикуется (с наиболее головоломными задачками). В частности, я сам решал в свое время почти все задачи, которые сейчас даються на интервью в нашем отделе. К сожалению, новые интересные задачи появляються не так уж часто.

Здравствуйте, _DAle_, Вы писали:

_DA>Здравствуйте, Kisloid, Вы писали:

K>>Почитал ветку выборочно, у мня такое впечатление возникло, что россия это будущая индия. Мы превращаемся в индусов. Слежу за школьными и студенческими олимпиадами (тк сам все это прошел в свое время), уровень задач из года в год все ниже и ниже, на форуме самого сильного в россии по программированию сообщества РСДН "инженера" начали кричать, что не надо знать алгоритм сортировки, можно с инета "закопипастить". Что творится в университетах, это просто плакать хочется.

_DA>Не согласен с тем, что уровень задач на олимпиадах падает. Отдельные соревнования — не показатель. Просто, например, на NEERC, видимо, решили, что пусть лучшие команды решают по 10-12 задач, а не по 4-5, как это было когда-то, и задачи стали в среднем проще. А вообще жаловаться на низкий олимпиадный уровень в России в этом году уж точно нельзя: ACM ICPC выиграл Саратовский ГУ, TopCoder Open 2006 выиграл Петр Митричев, впереди IOI

Не говоря уж о том, что в финале из 12 финалистов 5 бы ли представители нашего региона. Такого, по моему, вообще никогда не было. И это при том, что другие регионы, в особенности китайцы, тоже здорово прогрессируют.

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

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

Здравствуйте, ilya_ny, Вы писали:

_>кстати, я только что вспомнил как и мне как-то сказали, что я ооп не знаю

_>

_>собеседование.. 3 мужика
_>1.
_>один нарисовал квадратик, другой взял у него бумажку, подумал немного, и рядом подрисовал прямоугольничек и спращивает : "что от чего порождено ? а нарисуй-ка нам классы!"
_>я говорю, что квадратик порожден от прямоугольничка, на что третий мужичек сразу и говорит : "а не фига вы, молодой человек, ооп не знаете"
_>после этого третий ничего не произнес до самого конца собеседования.

Сдается мне, что от Вас хотели добиться понимания LSP. Это достаточно важный принцип, но это далеко не критерий понимания ООП вообще. К тому же ему несложно научить. По моему личному мнению, это необязательное знание в начале испытательного срока и весьма желательное — в конце (сразу оговорюсь, что это применительно к нашей команде; у других может быть своя специфика). С другой стороны, это все же отрицательный фактор (или, по крайней мере, не положительный) и он может сыграть в совокупности с другими, вероятно, более серьезными факторами.

Здравствуйте, SeRya, Вы писали:

SR>Если Вы меняете работу не потому что осознаете, что вам это действительно нужно, а просто так, то это характеризует Вас с отрицательной стороны и сильно снижает шанс попасть в контору, где "очень хотелось бы работать" когда такая появиться.

Откуда такой странный вывод? Я то как раз стараюсь не менять работу без серьезных причин.

SR>На самом деле разработческие фирмы очень сильно отличаються. Может быть Вы просто еще не понимаете, что именно вы хотели бы получить от смены работодателя? Если четко определить критерии поиска, то количество подходящих вариантов может радикально согратиться.

Количество достойных вариантов в пределах нашего города и так сократилось почти до нуля, не вижу смысла сокращать его еще сильнее

SR>Поиск работы по принципу "где меньше напрягают на собеседовании" скорее всего приведет Вас не в лучшее место.

Нет, ты не понял. На собеседовании пусть напрягают, если по делу. Но делать "тестовые задания" на неделю объемом я не буду. Просто потому, что ценю свое время.

Здравствуйте, Eugeny__, Вы писали:

E__>Блин, столько такого кода уже "восстановил" (по той же аналогии с химией — ржавчина тоже восстанавливается). Уже и опыт немалый в этом есть — кривой код приводить в состояние рабочего. Без документации. Без связи с разработчиками. Без ТЗ. Интересно, мне пригодится этот опыт в нормальных конторах?

И да и нет. Скилл крайне полезный, в любой конторе периодически накалываешься на груду подобной ржавчины. Но на нем одном каши не сваришь, долго на такой позиции (больше года-дполутора) сидеть без смысла. Срок — субьективная оценка времени на предельное отточение скилла.

E__>ПЫСЫ А хочется-то все равно писать нормально, с нуля, чистенько. Эх, вот отпуск отгуляю — меняю место жительства и работу...

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