эффект второго порядка в программировании
May. 10th, 2010 02:24 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avva(эта запись будет интересна в основном программистам)
В предыдущей записи я мельком упомянул историю о том, как в одной компании программистам стали давать премии за количество строчек кода, и они в результате стали это число раздувать посредством всяких ухищрений.
Несмотря на то, что история звучит апокрифичненько, на самом деле я о ней прочитал всего пару дней назад во внутренней рассылке на работе, и в ней были указаны конкретная компания, конкретный отдел, продукт и итд. Я попросил у автора разрешение пересказать ее у себя в журнале, и мы договорились, что названия я уберу, а все остальное перескажу. Строго говоря, история приходит к вам из третьих рук: ее непосредственным действующим лицом была жена моего коллеги.
Итак, много лет назад ЖМК (жена моего коллеги) работала в очень большой компании, имя которой вам знакомо. Она получила неожиданное задание: разработать способ аккуратного подсчета строк кода, чтобы менеджеры первого и второго звена могли с помощью этих чисел измерять продуктивность разработчиков. Все это происходило в огромном отделе данной компании, включавшем в себя более 2000 (!) разработчиков.
ЖМК должна была использовать машинный анализ исходного кода, а не просто количество "физических" строк в файлах. Иными словами, это скорее был подсчет отдельных инструкций (statements) в языке, хотя назывался он "количество строк кода". Одним из ключевых вопросов, которые понадобилось прояснить с менеджерами, оказался вопрос if-statements, которые на данном языке часто писали в одну строку: считать их за одну строку или каждый branch считать отдельно? Менеджеры решили, что каждый branch следует считать отдельно.
Внимание, эффект второго порядка!
Вскоре после введения нового режима измерения продуктивности ВСЕ if-then statements в исходном коде данного проекта стали выглядеть так:
if CONDITION then ACTION else ;
Т.е. программисты обнаружили, что если добавить "else" перед точкой с запятой, то их продуктивность удваивается.
ЖМК также обнаружила большое количество блоков следующего вида:
if (v > 0) then x = 3 else ;
if (v > 0) then y = sqrt(v) else ;
if (v > 0) then print(y) else ;
там где обычно программист написал бы
if (v > 0) then begin x = 3; y = sqrt(v); print(y) end ;
Дело в том, что "обычный" способ считался за 3 строчки кода (или 4, если добавить пустой else в конце), а "новый" за 6.
и так далее.
Кому-то может показаться странным, что программисты могли так извратить светлый дух науки Тьюринга и Кнута, и породить такое уродство. Но для многих из них разница в оценке продуктивности означала разницу между "Фиатом" и "Феррари", и - что поделать - людям это было важно.
В предыдущей записи я мельком упомянул историю о том, как в одной компании программистам стали давать премии за количество строчек кода, и они в результате стали это число раздувать посредством всяких ухищрений.
Несмотря на то, что история звучит апокрифичненько, на самом деле я о ней прочитал всего пару дней назад во внутренней рассылке на работе, и в ней были указаны конкретная компания, конкретный отдел, продукт и итд. Я попросил у автора разрешение пересказать ее у себя в журнале, и мы договорились, что названия я уберу, а все остальное перескажу. Строго говоря, история приходит к вам из третьих рук: ее непосредственным действующим лицом была жена моего коллеги.
Итак, много лет назад ЖМК (жена моего коллеги) работала в очень большой компании, имя которой вам знакомо. Она получила неожиданное задание: разработать способ аккуратного подсчета строк кода, чтобы менеджеры первого и второго звена могли с помощью этих чисел измерять продуктивность разработчиков. Все это происходило в огромном отделе данной компании, включавшем в себя более 2000 (!) разработчиков.
ЖМК должна была использовать машинный анализ исходного кода, а не просто количество "физических" строк в файлах. Иными словами, это скорее был подсчет отдельных инструкций (statements) в языке, хотя назывался он "количество строк кода". Одним из ключевых вопросов, которые понадобилось прояснить с менеджерами, оказался вопрос if-statements, которые на данном языке часто писали в одну строку: считать их за одну строку или каждый branch считать отдельно? Менеджеры решили, что каждый branch следует считать отдельно.
Внимание, эффект второго порядка!
Вскоре после введения нового режима измерения продуктивности ВСЕ if-then statements в исходном коде данного проекта стали выглядеть так:
if CONDITION then ACTION else ;
Т.е. программисты обнаружили, что если добавить "else" перед точкой с запятой, то их продуктивность удваивается.
ЖМК также обнаружила большое количество блоков следующего вида:
if (v > 0) then x = 3 else ;
if (v > 0) then y = sqrt(v) else ;
if (v > 0) then print(y) else ;
там где обычно программист написал бы
if (v > 0) then begin x = 3; y = sqrt(v); print(y) end ;
Дело в том, что "обычный" способ считался за 3 строчки кода (или 4, если добавить пустой else в конце), а "новый" за 6.
и так далее.
Кому-то может показаться странным, что программисты могли так извратить светлый дух науки Тьюринга и Кнута, и породить такое уродство. Но для многих из них разница в оценке продуктивности означала разницу между "Фиатом" и "Феррари", и - что поделать - людям это было важно.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-05-10 12:20 pm (UTC)А я б на месте ЖМК извратился и подсчитывал количество реальных машинных инструкций в объектном коде после комиляции с максимальной оптимизацией.
no subject
Date: 2010-05-10 12:25 pm (UTC)no subject
Date: 2010-05-10 12:27 pm (UTC)Тогда бы писали:
if (v > 0) then x = 0 else ;
if (v > 0) then x++ else ;
if (v > 0) then x++ else ;
if (v > 0) then x++ else ;
no subject
Date: 2010-05-10 12:49 pm (UTC)Понятно, что можно кучу мусора написать или даже автоматически генерировать, но цимес программистского сопротивления заключается в увеличении производительности по строкам кода с минимально вредным влиянием на конечный продукт. Иначе не интересно :).
no subject
Date: 2010-05-10 01:06 pm (UTC)Даже если программист не будет выдумывать откровенной чуши, сама идея бонусов за каждую машинную операцию начисто отобьет желание как-то оптимизировать код. Можно конечно выдавать премии за наименьшее кол-во строчек, но тогда рутинная работа превратится в чемпионат по програмированию и о читабельности кода можно будет забыть :)
no subject
Date: 2010-05-11 03:13 am (UTC)Вроде разворачивание циклов приводит к увеличению быстродействия программы, таким образом можно боротся за скорость работы программы путем учеличения своей зарплаты. Т.е. разворачивать все циклы в которых количество итераций меньше 16(64) и.т.д.