>> зачастую косвенно говорит. впрочем вот это "профилирование кода" как >> правило вообще не нужно никому.
> В этом сообществе, может, и не нужно. > Но тогда у меня для его участников есть печальная новость. я так думаю что столь важно не то с какой скоростью код может работать, сколь важно то с какой скорость код может быть изменен. основная проблема всех крупных проектов в том, что они приходят к такому состоянию, что они сами не могут внести исправления в собственный код. таких примеров масса. вот взять скажем ICQ. Могли в ICQ добавить аудио/видео разговоры, вменяемые никнеймы итп? могли. Что бы произошло в этом случае? ICQ бы выжил. однако он сдох[нет]. примеров подобного могу привести 100500. соответственно мне кажется что на сегодня наиболее рабочая парадигма - это не целиться в сторону максимально быстро работающего кода, а в сторону кода который пофиг быстро или нет работает, но который можно модифицировать. поэтому на собеседованиях/приеме на работу мне более интересны вопросы: что там с тестами? пишем/нет? как часто как много? что там с парадигмами? вот такую задачу КАК решать будем? итп. > Нет. > Я себе плохо представляю тестовое задание (точнее, плохо себе представляю > такой > код), по которому видно, как человек, его сделавший владеет процессом > разработки. а ты сформулируй этот самый "процесс разработки". и тогда ты сможешь написать тест. >> если тебя интересует именно профилирование кода, то в тестовом задании >> должно быть что-то, что потребует этого самого профилирования. > Не могу пока придумать такое задание. чего проще. просишь человека написать скажем интерактивное приложение, которое написать чтобы не безбожно тупило без профайлера - сложно. хз в какой области вы пишете, но если например веб, то пусть сделает страничку с табличкой которая на ходу будет пересчитываться. условие интерактивности положи как базовое в задачу. Сама задача должна быть несложной, но важно чтобы повозился с скоростью работы. как-то так. кстати что там у вас за задачи, которые непременно требуют профайлинга? профайлинг показывает узкие места. как правило решение лежит не в области переписывания узких мест, а в области смены чего-то в архитектуре -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
