Ну это в тему, что лишние тесты никогда не бывают лишними.
(это утверждение тоже не бесспорно, т.к. порой роль играет и время прогона тестов и трудозатраты на их поддержку).
А можно ли для этого подхода определить критерии достаточности? Достаточное количество итераций, например.
Просто без подобных критериев, данный метод напоминает тыканье пальцем в небо «авось упадет».
В случае с обычными тестами, хотя бы можно определить когда достигнуто 100% покрытие, т.е. все ветвления пройдены со всеми наборами значений.
А с данным подходом, когда и как Вы решаете, что код протестирован достаточно хорошо?
И правильно ли я понимаю, что Вы предлагаете использовать данный подход для тестирования системы в целом? Т.е. что то вроде интеграционных тестов черного ящика?
А давайте взглянем на ситуацию с другой стороны.
Сроки нарисуем исходя из того, что у нас средненькая по уровню команда, а гений нам поможет эти сроки сократить. Разве это плохо? Раньше закончили проект, раньше взяли другой — в единицу времени заработали больше денег. А если уж неразговорчивый гений нас неожиданно покинул, то просто сделали задачу в срок.
И обращу Ваше внимание, я сверху написал «не будет лишним в большой команде».
А насчет того что задачку никто не сможет поддерживать.
У нас было заведено (когда я работал в офисе) решения сложных задач описывать. Даже если этот гений с трудом поддерживает беседу на отвлеченные темы, в профессиональных терминах он решение объяснить сможет. Ну не видел я людей которые не умеют рассказать как они это сделали. Описывается это и в коде и в документации, а для особо интересных задач можно провести семинар, где докладчик расскажет что и как сделал — поднимет эрудицию всей команде.
Я понял Вашу мысль.
Идея плясать от сделанной работы и уже в этой канве выяснять уровень владения технологиями мне нравится. В общем то так и собеседуемому будет проще вспомнить чем он владеет.
Но для такого разговора нужно самому, что называется, быть в теме. А это не всегда возможно, например если если вы нанимаете узкого специалиста. Тут уже он может Вам лапши навешать сколько угодно. А вопросы на общую эрудицию помогут отсеять «балаболку», несложные задачи на соображалку покажут остроту и гибкость ума. Можно не делать их обязательными, дабы не утомлять кандидата, который Вам подходит по другим критериям, но если он согласится их взять и успешно решит — это дополнительный плюс.
А почему процесс должен быть завязан на гения? Он задачу решил, решение реализовал и задокументировал. Поддержка правильно решенной задачи должна требовать меньше ресурсов.
Неплохой способ проведения интервью. Но все же главная цель собеседования не провести непринужденную беседу с обоюдным пусканием пыли в глаза, а продать себя подороже и оценить, как можно точнее, сколько стоит оппонент.
Хотелось бы подетальнее узнать, как вы предлагаете выяснить уровень подкованности кандидата в тех или иных областях.
Прописные то они прописные. Но за каждодневной программистской рутиной и они могут забыться.
Думаю, любому программисту пойдет на пользу сделать на основе этих истин «чеклист», и проверять по нему результаты своей работы.
У меня на этом «малыше» крутится домашний сервер (да и не только у меня)
А это и торренты и файлохранилище и вебсервер и много чего еще.
Задачи прекрасно параллелятся хотя бы потому, что их много.
И при таком применении выйгрыш в производительности у двухядерного варианта вплотную приближается к 100%.
Согласен с тем, что домашний сервак не обязательно должен выглядеть красиво и стоять на виду.
Можно собрать в большой некрасивой коробке и спрятать.
Но будет заметно дешевле при меньших ограничениях на компоненты.
Мне кажется параметры формулы нужно немного поменять. =)
Скорее всего мастер дома будет держать небольшой запас материала (ну эдак на 3-4 изделия минимум), т.е. для закупки материалов нужен один рабочий день на 3-4 изделия (а если мастер востребованный то итого меньше + оптовые цены).
Кроме того опыт и знания позволят мастеру тратить меньше одного дня на одну вещь.
Так что реальный ценничек у востребованного мастера должен быть пониже.
ЗЫ
извиняюсь, если что
захотелось немного демагогии =)
Есть на Яндекс панорамах, значит пора метро строить =)
(это утверждение тоже не бесспорно, т.к. порой роль играет и время прогона тестов и трудозатраты на их поддержку).
А можно ли для этого подхода определить критерии достаточности? Достаточное количество итераций, например.
Просто без подобных критериев, данный метод напоминает тыканье пальцем в небо «авось упадет».
В случае с обычными тестами, хотя бы можно определить когда достигнуто 100% покрытие, т.е. все ветвления пройдены со всеми наборами значений.
А с данным подходом, когда и как Вы решаете, что код протестирован достаточно хорошо?
И правильно ли я понимаю, что Вы предлагаете использовать данный подход для тестирования системы в целом? Т.е. что то вроде интеграционных тестов черного ящика?
PS
В тексте есть опечатка — слово «длинны».
Я к тому, что собеседование нужно начать «как с умным человеком». А на вопросы про биты в байте скатываться уже позже.
Сроки нарисуем исходя из того, что у нас средненькая по уровню команда, а гений нам поможет эти сроки сократить. Разве это плохо? Раньше закончили проект, раньше взяли другой — в единицу времени заработали больше денег. А если уж неразговорчивый гений нас неожиданно покинул, то просто сделали задачу в срок.
И обращу Ваше внимание, я сверху написал «не будет лишним в большой команде».
А насчет того что задачку никто не сможет поддерживать.
У нас было заведено (когда я работал в офисе) решения сложных задач описывать. Даже если этот гений с трудом поддерживает беседу на отвлеченные темы, в профессиональных терминах он решение объяснить сможет. Ну не видел я людей которые не умеют рассказать как они это сделали. Описывается это и в коде и в документации, а для особо интересных задач можно провести семинар, где докладчик расскажет что и как сделал — поднимет эрудицию всей команде.
Идея плясать от сделанной работы и уже в этой канве выяснять уровень владения технологиями мне нравится. В общем то так и собеседуемому будет проще вспомнить чем он владеет.
Но для такого разговора нужно самому, что называется, быть в теме. А это не всегда возможно, например если если вы нанимаете узкого специалиста. Тут уже он может Вам лапши навешать сколько угодно. А вопросы на общую эрудицию помогут отсеять «балаболку», несложные задачи на соображалку покажут остроту и гибкость ума. Можно не делать их обязательными, дабы не утомлять кандидата, который Вам подходит по другим критериям, но если он согласится их взять и успешно решит — это дополнительный плюс.
просто нужно уметь выделять для него задачи
пусть себе сидит хмурый в углу и щелкает задачки, которые оказались непосильными для остальной общительной и юморной части команды
Хотелось бы подетальнее узнать, как вы предлагаете выяснить уровень подкованности кандидата в тех или иных областях.
Думаю, любому программисту пойдет на пользу сделать на основе этих истин «чеклист», и проверять по нему результаты своей работы.
А это и торренты и файлохранилище и вебсервер и много чего еще.
Задачи прекрасно параллелятся хотя бы потому, что их много.
И при таком применении выйгрыш в производительности у двухядерного варианта вплотную приближается к 100%.
Можно собрать в большой некрасивой коробке и спрятать.
Но будет заметно дешевле при меньших ограничениях на компоненты.
Сам то я, собирая подобный девайс дизайном не заморачивался. Запихнул все в старый ATX корпус и спрятал его в угол за шкафом.
Так там он и стоит — невидимый боец домашнесервачного фронта.
А ценник получился в 2 раза ниже.
Итого меньше 3000 за те же ТТХ.
Скорее всего мастер дома будет держать небольшой запас материала (ну эдак на 3-4 изделия минимум), т.е. для закупки материалов нужен один рабочий день на 3-4 изделия (а если мастер востребованный то итого меньше + оптовые цены).
Кроме того опыт и знания позволят мастеру тратить меньше одного дня на одну вещь.
Так что реальный ценничек у востребованного мастера должен быть пониже.
ЗЫ
извиняюсь, если что
захотелось немного демагогии =)