Today's software engineering word is «farpotshket.» This is a Yiddish word meaning, «broken, because someone tried to fix it.»
(с) Andr Zerozero
Схлеснулись мы тут на днях на работе по вопросу «А хорошо бы закешировать регулярку», в совершенно банальной функции
uncached = function(data_in) {
return /_(\d)+(?:#(\d)+)?$/.exec(data_in);
};
сделав как-то так
cached = (function() {
var pattern = /_(\d)+(?:#(\d)+)?$/;
return function(data_in) {
return pattern.exec(data_in);
};
})();
Идея популярная, но многие ли задумывались о реальном профите и накладных расходах?
Результаты сравнительных тестов производительности получились странные — противоречащие моим ожиданиям, да еще и разница оказалась в пределах погрешности измерения:
uncached 13,268 cached 13,070
Хотя может быть на какой-то связке платформа-браузер цифры и будут валидными, но во что это обходится?
Берем complexity-report и смотрим на показатели наших функций, соответственно:
Function: uncached
Physical SLOC: 3
Logical SLOC: 1
Parameter count: 1
Cyclomatic complexity: 1
Halstead difficulty: 2
Halstead volume: 18.094737505048094
Halstead effort: 36.18947501009619
Function: cached
Physical SLOC: 8
Logical SLOC: 3
Parameter count: 0
Cyclomatic complexity: 1
Halstead difficulty: 2.6666666666666665
Halstead volume: 22.458839376460833
Halstead effort: 59.89023833722889
Абсолютные цифры невелики, но все же обратим внимание на показатели кода по Halstead — 30% рост difficulty и 65% рост effort при близком к нулю профите — хороший намек о том, что что-то пошло не так.
Да, есть хорошие практики и отличные советы, но пользоваться ими надо с умом, критически оценивая и не выдергивая их из контекста.
И не занимайтесь предварительной оптимизацией — сначала профайлинг и только потом улучшения.
Короче — не делайте фигни.