Когда стоит задача и клиент хочет, чтобы было уже вчера - тогда не до чистоты. Нужно радовать клиента.
Так и сегодня потребовалось оптимизировать скорость отчёта.
В старой версии отчёт опрашивал базу для каждого счётчика два раза. При малом количестве счетчиков работа отчёта была приемлема - порядка 10-20 секунд.
Но клиенты добавили более четырехсот счётчиков и стало трудно дождаться его выполнения. Пришлось пожертвовать памятью и кэшировать запрос "кучкой". Используя Ruby это было сделано за 5 часов работы (с отладкой) и после применения кэша в памяти скорость выполнения сократилась до 2 секунд.
Но какой ценой далось это? Пришлось писать новую версию процедур получения данных и обработки их. Таким образом старые отчёты (с малым количеством счётчиков) ещё работают со старым кодом обработки данных, а новый отчёт использует кэширующий алгоритм.
Произошло создание двух сущностей, выполняющих одну и ту же задачу. Это один из "запахов кода". Но задача была выполнена быстро, и клиент остался доволен.
Но вот код перестал быть чище и в следующий раз, когда придётся добавлять ещё какой-нибудь функционал к отчётам, можно забыть, что можно использовать более быстрый алгоритм и в других подобных отчётах. И это потребует рефакторинга.
Встаёт проблема: когда применять рефакторинг? Если его делать перед добавлением нового кода, то можно увлечься и целый день заниматься только рефакторингом.
Но клиент не будет доволен увеличением сроков сдачи задачи. Будет доволен лишь программист, ощущающий чистоту и красоту его системы. Получается как в работе плотника: поработал - убери за собой.
То есть после сдачи задачи, можно заняться рефакторингом. Но вот дилемма - после этого код может "поломаться". Поэтому нужно будет написать тесты, которые описывают изменяемые процедуры, чтобы их функционал проверять автоматически при пошаговом изменении кода.
Откуда взять это время на тестирование и сам рефакторинг, спросите вы? У программистов всегда есть задачи, но бывают дни, когда скорость работы мала, или просто "башка не варит".
Вот в эти дни и можно привести в чистоту кодовую базу. Также, если у вас есть время после задачи, то не спешите браться за новую. Немножко прибраться - потом самим же будет удобнее добавлять функционал.
Так и сегодня потребовалось оптимизировать скорость отчёта.
В старой версии отчёт опрашивал базу для каждого счётчика два раза. При малом количестве счетчиков работа отчёта была приемлема - порядка 10-20 секунд.
Но клиенты добавили более четырехсот счётчиков и стало трудно дождаться его выполнения. Пришлось пожертвовать памятью и кэшировать запрос "кучкой". Используя Ruby это было сделано за 5 часов работы (с отладкой) и после применения кэша в памяти скорость выполнения сократилась до 2 секунд.
Но какой ценой далось это? Пришлось писать новую версию процедур получения данных и обработки их. Таким образом старые отчёты (с малым количеством счётчиков) ещё работают со старым кодом обработки данных, а новый отчёт использует кэширующий алгоритм.
Произошло создание двух сущностей, выполняющих одну и ту же задачу. Это один из "запахов кода". Но задача была выполнена быстро, и клиент остался доволен.
Но вот код перестал быть чище и в следующий раз, когда придётся добавлять ещё какой-нибудь функционал к отчётам, можно забыть, что можно использовать более быстрый алгоритм и в других подобных отчётах. И это потребует рефакторинга.
Встаёт проблема: когда применять рефакторинг? Если его делать перед добавлением нового кода, то можно увлечься и целый день заниматься только рефакторингом.
Но клиент не будет доволен увеличением сроков сдачи задачи. Будет доволен лишь программист, ощущающий чистоту и красоту его системы. Получается как в работе плотника: поработал - убери за собой.
То есть после сдачи задачи, можно заняться рефакторингом. Но вот дилемма - после этого код может "поломаться". Поэтому нужно будет написать тесты, которые описывают изменяемые процедуры, чтобы их функционал проверять автоматически при пошаговом изменении кода.
Откуда взять это время на тестирование и сам рефакторинг, спросите вы? У программистов всегда есть задачи, но бывают дни, когда скорость работы мала, или просто "башка не варит".
Вот в эти дни и можно привести в чистоту кодовую базу. Также, если у вас есть время после задачи, то не спешите браться за новую. Немножко прибраться - потом самим же будет удобнее добавлять функционал.
Комментариев нет:
Отправить комментарий