Мегасрач у belnetmon
На 500+ комментариев:
http://belnetmon.livejournal.com/1024560.html
Для непрограммистов объясняю суть: при собеседовании на работу программиста человеку предлагается пройти тест: написать реальную простенькую программу и посмотреть, получится ли у него.
Казалось бы, что в этом требовании такого странного? Реакция, однако, забавная. В тему набежало некоторое количество мутных личностей, которые стали писать о том, что предлагаемые задачи недостаточно простые или недостаточно стандартные.
Мне кажется, что суть проблемы такова: некоторые мои коллеги учатся не столько программировать, сколько красиво гнуть пальцы. Человек помнит огромное количество всяких продуктов, языков и систем. Но знания кандидата по каждому пункту укладываются в 1-2 абзаца. Это значит, что на собеседовании он легко может поддержать беседу о данной системе, но вот написать что-то реальное - фиг.
Я называю этот типаж "эрудитом".
Если попросить эрудита написать программу типа описанной в тесте, то он будет
- Два дня читать документацию
- Два дня гуглить
- Два дня шариться по форумам
- К началу следующей недели он найдет-таки на каком-то форуме подходящую программу, скопипастит ее, и она заработает.
При этом эрудит будет страшно горд теми фактами, что:
1. Он не изобрел велосипед (ибо изобретать велосипед неправославно).
2. Он использовал проверенный, работающий код - ибо все, что опубликовано в инете, в понимании эрудита работает идеально. В отличие от сделанного руками (см п.1)
3. Он сэкономил работодателю кучу бабок, так как см. пункт 1.
Особо продвинутый эрудит способен обернуть найденную копипасту в "паттерн". Как правило, результат от этого потеряет в качестве. Но эрудит будет убежден, что результат, напротив, приобретет дополнительные магические свойства типа "расширяемость +5". Просто потому как в книжках про "паттерны" много говорится про такие вещи. Поэтому всякий паттерн - это сразу большой плюс, а любой код, в котором эрудит сходу не увидит один из 20-30 знакомых паттернов, есть неправославный велосипед и должен вместе с афтаром гореть в аду.
Например, преобразование int в строку - это не паттерн...
http://belnetmon.livejournal.com/1024560.html
Для непрограммистов объясняю суть: при собеседовании на работу программиста человеку предлагается пройти тест: написать реальную простенькую программу и посмотреть, получится ли у него.
Казалось бы, что в этом требовании такого странного? Реакция, однако, забавная. В тему набежало некоторое количество мутных личностей, которые стали писать о том, что предлагаемые задачи недостаточно простые или недостаточно стандартные.
Мне кажется, что суть проблемы такова: некоторые мои коллеги учатся не столько программировать, сколько красиво гнуть пальцы. Человек помнит огромное количество всяких продуктов, языков и систем. Но знания кандидата по каждому пункту укладываются в 1-2 абзаца. Это значит, что на собеседовании он легко может поддержать беседу о данной системе, но вот написать что-то реальное - фиг.
Я называю этот типаж "эрудитом".
Если попросить эрудита написать программу типа описанной в тесте, то он будет
- Два дня читать документацию
- Два дня гуглить
- Два дня шариться по форумам
- К началу следующей недели он найдет-таки на каком-то форуме подходящую программу, скопипастит ее, и она заработает.
При этом эрудит будет страшно горд теми фактами, что:
1. Он не изобрел велосипед (ибо изобретать велосипед неправославно).
2. Он использовал проверенный, работающий код - ибо все, что опубликовано в инете, в понимании эрудита работает идеально. В отличие от сделанного руками (см п.1)
3. Он сэкономил работодателю кучу бабок, так как см. пункт 1.
Особо продвинутый эрудит способен обернуть найденную копипасту в "паттерн". Как правило, результат от этого потеряет в качестве. Но эрудит будет убежден, что результат, напротив, приобретет дополнительные магические свойства типа "расширяемость +5". Просто потому как в книжках про "паттерны" много говорится про такие вещи. Поэтому всякий паттерн - это сразу большой плюс, а любой код, в котором эрудит сходу не увидит один из 20-30 знакомых паттернов, есть неправославный велосипед и должен вместе с афтаром гореть в аду.
Например, преобразование int в строку - это не паттерн...
Re: int в строку
Re: int в строку
(x + 3)*(x + 3)*(x + 3) + (y*y*y + z)*(y*y*y +z)*(y*y*y +z) + ...
согласись, так:
kub(x + 3) + kub(y*y*y + z) + ...
- будет выгоднее, т.к. не надо заводить временных переменных, которые сразу же и выбросишь, и не надо трижды вычислять y*y*y + z.
А темплейт тут нужен, чтобы не писать версии kub отдельно для int, double, float...
Re: int в строку
Re: int в строку
Пример - моя (и не только моя) программа обработки звука. 16 бит достаточно для воспроизведения в отличном качестве, но при редактировании возникает эффект накопления погрешностей. Поэтому надо 32 бита. А 64 (double) бита - уже жирно, поскольку звуковые файлы и без того огромны (пока их не сжали).
Темплейты охватывают до хрена реальных задач. Пример из той же оперы. Некий модуль программы меняет pitch (высоту) звукозаписи. Хочется, чтобы он мог работать и с 32-битным звуком, ибо удобен, и с 16-битным, ибо стандарт. Алгоритм непростой (учитывая буферизацию и интерполяцию). И накуя, спрашиваетяс, я буду писать три версии этого алгоритма (под short, int, float)? Естественно, я и не пишу, у меня это оформлено как template.
Re: int в строку
no subject
no subject
no subject
ну ты понял :)
no subject
Обычно мне так или иначе приходится создавать класс с деструктором. Поэтому нет проблем с удалением массива внутри класса. Ну а массив обычных доблов удаляю перед каждым ретурн. Проблема то нулевая.