[Moscow.pm] гребаные тестовые задания

Михаил Шогин mshogin на gmail.com
Пн Дек 7 10:43:18 PST 2015


7 декабря 2015 г., 19:17 пользователь Alex Chistyakov <alexclear на gmail.com>
написал:

>
>
> 2015-12-07 18:56 GMT+03:00 Ivan Petrov <i.petro.77.00 на gmail.com>:
>
>> >> зачастую косвенно говорит. впрочем вот это "профилирование кода" как
>> >> правило вообще не нужно никому.
>>
>> > В этом сообществе, может, и не нужно.
>> > Но тогда у меня для его участников есть печальная новость.
>>
>> я так думаю что столь важно не то с какой скоростью код может работать,
>> сколь важно то с какой скорость код может быть изменен.
>>
>
> Обе вещи важны, должен быть баланс.
>
Это даже  не "тонкий" вопрос, а вопрос жизни и смерти, если ты не можешь
изменить код, то все, еще пару лет и код будет переписываться с 0.
Причем изменить ни что то там, а реально взять и отрефакторить то что уже
не удовлетворяет потребностям бизнеса, а у вас есть два варианта: хак или
все переписать.
При балансе, ответ очевиден - хак! Так что только loosely coupled design
and TDD!

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


-- 
С уважением
Михаил Шогин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20151207/c0f7fb2b/attachment-0001.html>


Подробная информация о списке рассылки Moscow-pm