Здравствуйте, GUID, Вы писали:
GUI>Здравствуйте, Аноним, Вы писали:
GUI>У меня нет, к сожалению, рецензии именно Вашего тестового задания (речь идет о этом задании), но, для иллюстрации, я приведу два примера (успешный и не успешный) рецензий тестовых заданий месячной давности, чтобы показать, что во-первых, задания анализируются, во-вторых, что одного только факта исполнения кандидатом тестового задания недостаточно — еще важно КАК он его сделал:
GUI>Пример 1 (отрицательный).
GUI>Плюсы:
GUI>
GUI>- юный возраст
GUI>- использование компонентов .NET (такое тестовое задание данному рецензенту попалось впервые);
GUI>
GUI>Минусы:
GUI>
GUI> — предыдущий опыт работы был связан скорее с администрированием, нежели с кодированием;
GUI> — "знаком с языком VC" — этого может оказаться недостаточно;
GUI> — задание выполнено как "отписка", без цели показать "все, на что способен", а с целью сделать "чтобы отстали"
GUI> — совершенно неудобный UI (пользователь должен знать имена сервисов и имена машин, чтобы запустить или остановить сервис);
GUI> — многократное создание одних и тех же объектов (в VB при каждом нажатии на кнопку создается COM-объект MyServControl; в VC тоже самое происходит с объектом ServiceController);
GUI> — catch(...) — за это у нас "расстреливают";
GUI> — глобальные директивы using — это, по крайней мере, плохой стиль программирования. Кроме того, раз уж написал
GUI>GUI>using namespace System::ServiceProcess;
GUI>
то зачем тогда дальше писать
GUI>GUI>System::ServiceProcess::ServiceController *SC;
GUI>
?
GUI>
GUI>В общем, решили не приглашать.
GUI>Пример 2 (положительный)
GUI>Плюсы
GUI>
GUI>- человек явно стремится показать свои знания (проект выглядит крупнее и "продвинутее" среднестатистического тестового задания);
GUI> — не часто встречается в заданиях запуск и останов зависимых сервисов;
GUI> — использование обертки для SC_HANDLE;
GUI> — использование WNetAddConnection (очень редко встречается в заданиях);
GUI> — использование коллекций VB.
GUI>
GUI>Минусы:
GUI>
GUI> — в коде не выбрасывается ни одно исключение, но встречается огромное количество конструкций
GUI>GUI> try {}
GUI> catch(...) {}
GUI>
GUI> — обработка ошибок сделана на возвращаемых значениях (в качестве типа ошибки используется свой собственный enum);
GUI> — использование таких конструкций как
GUI> using CConnectionImpl::OpenConnection; (см. класс CManagerImpl) конечно говорит о том, что человек знает о их существовании, но на практике означает просчеты в проектировании (в проекте такого масштаба они явно не уместны!);
GUI> — встречаются "сишные" функции; используется CString вместо std::basic_string<> (стоит ли прикручивать целый MFC ради этого?);
GUI> — доступ к внутреннему представлению вектора (см., например, ServiceCtrl::QueryServiceConfig());
GUI> — std::vector<LPCTSTR> a_Array(a_Size); — выглядит пугающе (это отмечает в комментариях и сам автор);
GUI> — функция CManagerImpl::WaitForServiceState() содержит конструкцию
GUI>GUI>for(;;)
GUI> {
GUI> ...
GUI> Sleep(a_Wait);
GUI> }
GUI>
GUI>и вызывается в основном потоке (фактически, прямо в обработчике сообщений от UI); как следствие, приложение "зависает", пока не запустится (не остановится) соответствующий сервис (может, это как-то реализовано в VB?).
GUI>
GUI>Мнение рецензента: "Не знаю как на ведущего, а на простого "программиста второго уровня" вполне тянет".
GUI>Кандидата пригласили на собеседование.
Пожалуйста, уберите из Вашего задания "Оттестированность программы не имеет значения, главное — продемонстрировать ее функциональные возможности". Т.к. первого кандидата Вы завалили именно на этом. Программа функционирует, по Вашему заявлению Вам это и надо.
А почему расстриливать за Catch()? По-моему, если человек ловит исключения — это хорошо...
По поводу неудобства UI: это ведь тестовое задание, не коммерческая программа. Я бы лучше расстрелял за Sleep(a_Wait); А если сервис "подвиснет" во время остановки? Такое с AVP случается. Что тогда? По-моему, в этом второй кандидат продемонстрировал вопиющее незнание мультитредингово программирования.
По поводу MFC: глупо не использовать стандартные библиотеки, которые идут с языком. Особенно в тестовом задании. Откуда кандидату знать, используете Вы MFC в проектах или нет?
Аноним, если тебя одна контора послала — не расстраивайся. Проверка тестового задания — процесс, на который сильно влияет человеческий фактор. Набирай квалификацию на удаленных проектах. Что тут плохого? По-моему — одно: при иммиграции за границу как Skilled Professional надо подтвердить стаж. а при удаленных проектах это может быть затруднительно.
