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

UN>На январь 2010 соотношение вакансий к резюме для программиство 5:1 (по данным hh.ru и superjob.ru)

Благодарю. Будет повод на работе понаглее быть

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


UN>>На январь 2010 соотношение вакансий к резюме для программиство 5:1 (по данным hh.ru и superjob.ru)
_Д_>Благодарю. Будет повод на работе понаглее быть
... через неделю соотношение изменилось 5:2

Здравствуйте, erslgoeirjh, Вы писали:
E>А то сейчас все про кризис говорят, вот я и хотел бы узнать, как обстоят дела в связи с ним на рынке труда.

Побегал неделю по собеседованиям по своей специализации (С++/Win32), прошел почти все. При этом у меня достаточно высокая планка по З.П.
Честно скажу, насколько я хороший программист никто даже не пробовал проверять. Везде были одинаковые вопросы, которые 90% покрываются Маерсом, Саттером и Рихтером. При этом 50% вопросов пересекались, я даже улыбнулся когда отвечал на один вопрос подряд в двух разных компаниях.

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

Я сам проводил собеседования на прошлом месте работы и всегда после общего теста по С++ просил написать какой-нибудь код и покрыть его юнит тестами. Обычно на написание кода отводилось 30-40 мин, затем была короткая беседа по удобству его использования и в конце я просил внести в него новую ф-ть.
Прошу прощения за слово, но "гавнокодеры" определялись сразу. А ведь именно такие люди мешают жить менеджерам проекта и остальным программистам.

Итого, совет: освежите (прочитайте) 3 книжки Маерса, 2 Саттера, 1 Рихтера и спокойно ходите по собеседованиям. Без работы не останетесь.

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

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

UN>>На январь 2010 соотношение вакансий к резюме для программиство 5:1 (по данным hh.ru и superjob.ru)

_Д_>Благодарю. Будет повод на работе понаглее быть

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

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

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

TDD конечно же панацея Но это уже не модно, сейчас настоящие пацаны пишут на Agile или BDD. В Agile — главное провозгласить какую нибудь методологию единственно верной, как учение Маркса, выбрать Гуру, повесить его портрет на стенку и молится перед каждой итерацией. Больгинство Agile компаний которые видел почему-то походили на секты. Но есть и еще одна новомодная ветвь Agile — BDD:

"BDD is a second-generation, outside-in, pull- based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters."

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

Не напоминает рекламу стирального порошка Tide? Это определение дал один из идеологов ВDD Dan North. По мне так за методологии начали выдавать любую ахинею в последнее время.

IL_>Я сам проводил собеседования на прошлом месте работы и всегда после общего теста по С++ просил написать какой-нибудь код и покрыть его юнит тестами. Обычно на написание кода отводилось 30-40 мин, затем была короткая беседа по удобству его использования и в конце я просил внести в него новую ф-ть.
IL_>Прошу прощения за слово, но "гавнокодеры" определялись сразу. А ведь именно такие люди мешают жить менеджерам проекта и остальным программистам.

"И тут выхожу я весь в белом...".

IL_>Итого, совет: освежите (прочитайте) 3 книжки Маерса, 2 Саттера, 1 Рихтера и спокойно ходите по собеседованиям. Без работы не останетесь.

Это смотря какую религию хотите принять. Почему не прочитать три тома "Исскуство программирования" Кнута, "Шаблоны проектирования" банды четырех и неувядаемый труд Била Гейтса "Бизнес со Скроростью Мысли"?

Скажете ахинея? Не меньшая чем упомянутые выше авторы. Вот Рихтер например знаменит книгами по Win32 и Net, и чем же они необходимы для становления программиста? Я читал Рихтера по Win32. Да, книжка описывает интересные вещи о windows и Win32, но честно говоря никакого божественного смысла я в ней не обнаружил. Хорошая книжка про проприетарную технологию.

E>А то тут была байка про жилье, что спрос упал и рынок арендатора превратился в рынок арендодателя,который может диктовать условия.
E> Но вот почему-то как позвонишь арендатору, так по-прежнему и 100% комиссию хотят, и цены нифига не упали, и разговаривают все так же, будто к ним очереди строятся, а ты так, хрен с горы, отрываешь его от важных дел.

по ходу ты перепутал белых и красных^W^W^W арендодателей и арендаторов.

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

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

H>TDD конечно же панацея Но это уже не модно, сейчас настоящие пацаны пишут на Agile или BDD. В Agile — главное провозгласить какую нибудь методологию единственно верной
Agile — это метод управления проектом, а TDD — собственно написание кода. Эти методы лежат в разных плоскостях и друг-другу не противоречат.

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

H>Не напоминает рекламу стирального порошка Tide? Это определение дал один из идеологов ВDD Dan North. По мне так за методологии начали выдавать любую ахинею в последнее время.

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

IL_>>Итого, совет: освежите (прочитайте) 3 книжки Маерса, 2 Саттера, 1 Рихтера и спокойно ходите по собеседованиям. Без работы не останетесь.

H>Это смотря какую религию хотите принять. Почему не прочитать три тома "Исскуство программирования" Кнута, "Шаблоны проектирования" банды четырех и неувядаемый труд Била Гейтса "Бизнес со Скроростью Мысли"?

H>Скажете ахинея? Не меньшая чем упомянутые выше авторы. Вот Рихтер например знаменит книгами по Win32 и Net, и чем же они необходимы для становления программиста? Я читал Рихтера по Win32. Да, книжка описывает интересные вещи о windows и Win32, но честно говоря никакого божественного смысла я в ней не обнаружил. Хорошая книжка про проприетарную технологию.

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

IL_>Я лишь хотел сказать, что писать код по методике TDD совсем не просто, этому тоже надо учиться. Ну и плюс к этому не все программисты хотят их писать.
IL_>Поэтому умение писать юнит тесты тоже нужно проверять на собеседовании.

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

IL_>Я посоветовал прочитать эти книги, т.к. в них в точности описываются вопросы которые задают на собеседованиях. Список книг можно расширить, но для успешного прохождения 80% собеседований этого набора будет достаточно.

Вообщето я хотел спроектировать дом для семейства жирафов (C) собеседование в микрософт. Список книг очень неудачен, например в конторе где я работаю ни Win32 ни .Net не используются в проектах. Теперь объясните чем чтение Рихтера поможет пройти собеседование например спецам со следующими специализациями:
— высоконагруженные системы на Linux/xBSD/Unix
— программирование на Perl/PHP
— С++ Qt
...

С чего собственно взяли что всем нужен Win32 / .Net? Первый собственно устаревающий низкоуровневый API, второй является проприетарной технологией для некоторой ниши бизнес и кастомных приложений. Обе эти вещи находятся очень далеко за пределами интересов очень большого количества программеров.

H>>TDD конечно же панацея Но это уже не модно, сейчас настоящие пацаны пишут на Agile или BDD. В Agile — главное провозгласить какую нибудь методологию единственно верной
S>Agile — это метод управления проектом, а TDD — собственно написание кода. Эти методы лежат в разных плоскостях и друг-другу не противоречат.

А про противопоказания TDD слышали?

Criticisms

1. Test-driven development is difficult to use in situations where full functional tests are required to determine success or failure. Examples of these are user interfaces, programs that work with databases, and some that depend on specific network configurations. TDD encourages developers to put the minimum amount of code into such modules and to maximise the logic that is in testable library code, using fakes and mocks to represent the outside world.
2. Management support is essential. Without the entire organization believing that test-driven development is going to improve the product, management will feel that time spent writing tests is wasted.[11]
3. The tests themselves become part of the maintenance overhead of a project. Badly written tests, for example ones that include hard-coded error strings or which are themselves prone to failure, are expensive to maintain. There is a risk that tests that regularly generate false failures will be ignored, so that when a real failure occurs it may not be detected. It is possible to write tests for low and easy maintenance, for example by the reuse of error strings, and this should be a goal during the 'Refactor' phase described above.
4. The level of coverage and testing detail achieved during repeated TDD cycles cannot easily be re-created at a later date. Therefore these original tests become increasingly precious as time goes by. If a poor architecture, a poor design or a poor testing strategy leads to a late change that makes dozens of existing tests fail, it is important that they are individually fixed. Merely deleting, disabling or rashly altering them can lead to un-detectable holes in the test coverage.
5. Unexpected gaps in test coverage may exist or occur for a number of reasons. Perhaps one or more developers in a team was not so committed to the TDD strategy and did not write tests properly, perhaps some sets of tests have been invalidated, deleted or disabled accidentally or on purpose during later work. If this happens, the confidence that a large set of TDD tests lend to further fixes and refactorings will actually be misplaced. Alterations may be made that result in no test failures when in fact bugs are being introduced and remaining undetected.
6. Unit tests created in a test-driven development environment are typically created by the developer who will also write the code that is being tested. The tests may therefore share the same blind spots with the code: If, for example, a developer does not realize that certain input parameters must be checked, most likely neither the test nor the code will verify these input parameters. If the developer misinterprets the requirements specification for the module being developed, both the tests and the code will be wrong.
7. The high number of passing unit tests may bring a false sense of security, resulting in less additional QA activities, such as integration testing and compliance testing.

Сейчас TDD уже не в моде

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


H>С чего собственно взяли что всем нужен Win32 / .Net? Первый собственно устаревающий низкоуровневый API, второй является проприетарной технологией для некоторой ниши бизнес и кастомных приложений.

Почем устаревающий? Винды разве кто-то отменил? Пока что, более 90% персоналок работают под этой "проприетарной технологией".

H>Обе эти вещи находятся очень далеко за пределами интересов очень большого количества программеров.

И это хорошо, нам больше достанется!

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

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

Мне кажется мы разговариваем на разные темы. Я вроде в прошлых своих постах не навязывал эту технологию, а лишь сказал что нужно уметь писать тесты ЕСЛИ TDD используется в компании. По поводу пользы тестов в этой теме спорить не буду, уже сто раз обсуждалось.

H>Вообщето я хотел спроектировать дом для семейства жирафов (C) собеседование в микрософт. Список книг очень неудачен, например в конторе где я работаю ни Win32 ни .Net не используются в проектах. Теперь объясните чем чтение Рихтера поможет пройти собеседование например спецам со следующими специализациями:
H>- высоконагруженные системы на Linux/xBSD/Unix
H>- программирование на Perl/PHP
H>- С++ Qt
H>...

Перечитайте первый мой пост, я писал про C++/Win32 специализацию. Если вы хотите устроится программировать на Net у вас будет другой список книг.
Знание систем и ДОПОЛНИТЕЛЬНЫХ языков программирования обычно является плюсом и не препятствует успешному прохождению собеседования. А такие библиотеки как Qt вообще изучаются по ходу написания кода.

H>С чего собственно взяли что всем нужен Win32 / .Net? Первый собственно устаревающий низкоуровневый API, второй является проприетарной технологией для некоторой ниши бизнес и кастомных приложений. Обе эти вещи находятся очень далеко за пределами интересов очень большого количества программеров.

Посмеялся

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

H>>>TDD конечно же панацея Но это уже не модно, сейчас настоящие пацаны пишут на Agile или BDD. В Agile — главное провозгласить какую нибудь методологию единственно верной
S>>Agile — это метод управления проектом, а TDD — собственно написание кода. Эти методы лежат в разных плоскостях и друг-другу не противоречат.

H>А про противопоказания TDD слышали?

H>Criticisms

Я этот набор отговорок слышу постоянно. Все сводится к банальному "тесты писать занудно, а мы тут все ТВОРЦЫ, нам ТВОРИТЬ надо".
Вот и творят, твари

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

S>>Agile — это метод управления проектом, а TDD — собственно написание кода. Эти методы лежат в разных плоскостях и друг-другу не противоречат.

H>А про противопоказания TDD слышали?

Конечно, TDD сложен когда идет сильная итеграция в OS. C другой стороны, всегда можно изолировать фрагменты кода их независимо тестировать как Unittest.
Это полезно для качества, когда код был тестанут независимо от большой инфрастуктуры, и когда к этим тестам можно всегда вернуться.

H>Сейчас TDD уже не в моде

Насчет вопросов моды это вы к Ксении Собчак или к Звереву обращайтесь: технология и мода вещи не совместимые.

L>Я этот набор отговорок слышу постоянно. Все сводится к банальному "тесты писать занудно, а мы тут все ТВОРЦЫ, нам ТВОРИТЬ надо".
L>Вот и творят, твари

Это Википедия — как правило весьма сбалансированный источник информации.
http://en.wikipedia.org/wiki/Test-driven_development

TDD возводит в абсолют юнит тесты как правило за счет других видов тестирования. Вот если я делаю высоконагруженную систему, в которой интерфейс — практически дергание URL, каким боком мне нужно TDD? Вот стрессовое тестирование для меня гораздо интереснее, как и интеграционное.

Интеграционные и стрессовые тесты очень часто намного интереснее. Тестирование со стороны "юзера" дает больше бенефитов, оно показывает как система ведет себя со стороны клинта. Клиенту глубоко пофиг что в системе есть класс LedManager, на него написано 120 тестов и он безупречен. Ему нужна система которая just works

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


H>TDD возводит в абсолют юнит тесты как правило за счет других видов тестирования. Вот если я делаю высоконагруженную систему, в которой интерфейс — практически дергание URL, каким боком мне нужно TDD? Вот стрессовое тестирование для меня гораздо интереснее, как и интеграционное.
Люди склонны путать TDD с тестированием. Так вот, TDD ничего общего не имеет с тестированием в его общепринятом смысле. Это способ разработки.
H>Интеграционные и стрессовые тесты очень часто намного интереснее. Тестирование со стороны "юзера" дает больше бенефитов, оно показывает как система ведет себя со стороны клинта. Клиенту глубоко пофиг что в системе есть класс LedManager, на него написано 120 тестов и он безупречен. Ему нужна система которая just works
Это способ разработки, который при правильном использовании позволяет построить именно это с минимальными накладными расходами. Потому что еще до того, как вы начнете функциональное тестирование, ваши тесты должны будут гарантировать, что ваша система для дергания URL не падает, когда в ответе встречается, скажем, фреймы или если ответ оказался обкусанным. Нет смысла тестировать дом, если фундамент недоделан, а в стенах дыры. Никто не строит самолет, не проведя комплексное тестирование каждого компонента в отдельности.

Ну и лично мой опыт — если юнит тестов нет, не говоря уже о TDD, то все остальные виды тестирования доставляют немало приятного овертайма для всех соучастников. Но мне есть с чем сравнить

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

H>>А про противопоказания TDD слышали?

S>Конечно, TDD сложен когда идет сильная итеграция в OS. C другой стороны, всегда можно изолировать фрагменты кода их независимо тестировать как Unittest.
S>Это полезно для качества, когда код был тестанут независимо от большой инфрастуктуры, и когда к этим тестам можно всегда вернуться.

+1. У меня как-то на одном проекте была задача ввести UT FW и покрыть код тестами. Это был тихий ужас, и я это дело благополучно слил! А все почему?
Потому что обычно код нормально не тестируем, потому что очень сильно зависит от сторонних эффектов. Т.е. он не пишется с расчетом на покрытие тестами, а "творится", как сказал landerhigh. Чтобы обойти это, придумываются всякие stub's, mock'и и прочие заглушки, имитирующие внешнюю среду, и все это превращает написание и поддержку тестов в девелоперский кошмар.
Для того, чтобы тесты было писать удобно и они были легко поддерживаемы, код лучше разделять на 2 составляющих:
1) Чистые (в терминах ФП) функции/методы.
2) Все остальное.

Тогда тестирование (1) хорошо автоматизируется, а (2) покрывается функциональным/интеграционным тестированием.
<troll mode>Если код уже гавно</troll mode>, то тесты будет очень сложно ввести и поддерживать.

L>Это способ разработки, который при правильном использовании позволяет построить именно это с минимальными накладными расходами. Потому что еще до того, как вы начнете функциональное тестирование, ваши тесты должны будут гарантировать, что ваша система для дергания URL не падает, когда в ответе встречается, скажем, фреймы или если ответ оказался обкусанным.

более половины багов вносятся на этапе интеграции.

L>Ну и лично мой опыт — если юнит тестов нет, не говоря уже о TDD, то все остальные виды тестирования доставляют немало приятного овертайма для всех соучастников. Но мне есть с чем сравнить

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

Я не против юнит тестов, я против провозглашения их панацеей

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

H>более половины багов вносятся на этапе интеграции.

Значит, как минимум меньшая половина багов вносится на этапе разработки модулей. И их предотвращение на этом этапе обходится гораздо дешевле их исправления потом

L>>Ну и лично мой опыт — если юнит тестов нет, не говоря уже о TDD, то все остальные виды тестирования доставляют немало приятного овертайма для всех соучастников. Но мне есть с чем сравнить

H>Были системы которые работали на удивление хорошо хотя в них не было ни одного юнит теста. Видел системы с тысячами юнит тестов которые были совершенно неработоспособны. Более того, неадекватные тысячи тестов сильно замедляют разработку — их приходится переделывать

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

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

S>>Это полезно для качества, когда код был тестанут независимо от большой инфрастуктуры, и когда к этим тестам можно всегда вернуться.

AD>+1. У меня как-то на одном проекте была задача ввести UT FW и покрыть код тестами. Это был тихий ужас, и я это дело благополучно слил! А все почему?

Хех. Уж на что я апологет тестирования, но когда пытаются поставить задачу покрыть имеющийся код тестами, я обычно говорю "Спасибо, см. рис. 1".