Global refactoring

Our department owns a dozen external and internal sites, some are almost 10 years old. We will describe the tasks that arise in the process of support and development of such resources, solutions, and talk about new chips. For example, how not to share the link to the Christmas garland in early May;)



Of course, one of the main tasks is to help users fill out our magic credit questionnaires with Iron Man, but there are also quite earthly tasks.



The priority of the task to refactor a global javascript file to> 3000 lines of code has recently increased. You need to understand what kind of code is still in demand in most sections of the site.



First of all, we start the search for duplicate code, and we don’t find anything worthwhile, that is, of course, we find a lot of interesting things, but not exactly what we are looking for: it’s impossible to understand whether the functionality is currently used or not, because there are files in the project, folders on the server are, but if the user has access to the section, or if the link to some hidden section is used, do not automatically check. It happens, and Peter meets in the calculator for miles , I would not want to turn it off :)

')

The second point was to ping the server from the common ajax functions with queries, but neither our favorite users nor our server could handle this bullying, and we called Yandex.Metrica for help. There is already a counter on the site, it remains to call the replenishment of statistics for a specific counter into each function, and after the page loads, send this data to the server. Of course, after loading the page, the functions are sent using ajax , but there are not many active sections, and testing is started in low-load hours. With a large load would add n second queue.

 function setYaParam(functionName) { if (window['yaCounterXxx']) { var param = {}; param[functionName] = { n: 1 ,url: window.location.href || '' }; yaCounterXxx.params(param); } else { yaParams[functionName] = yaParams[functionName] ? yaParams[functionName] + 1 : 1; } } 

Inside Ya.Metriki, in the section "Content" / "Parameters of visits" we see the names themselves, sorting by frequency of use of everything, the sum of calls for the period of statistics and, in the last column, the average number of calls per page.







After an hour of work, we collect statistics on the use of 95% of the most visited pages and functions and remove their tracking in order to shift the Refactor and Analysis to the shelf, and after the month of statistics we distribute the rest of the low-query functionality into the required subsections.