You might need to talk to your manager to get their support to do it during working hours, otherwise, you'd have to sacrifice your spare time.

I've been in a similar situation. My manager supported me a lot in the effort, but in the end, the best solution was to quit the company. May you be luckier!

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

Yes, I'll try to write some common scripts into modules and demonstrate the benefits. :)

But it is very unlikely since some old developers are too used to scripting approach with 100+lines of subroutines.

choroba's advice about proof of concept is good in any case. Show your managers (and/or your Senior colleagues) how building a library of modular, reusable routines can help. If you then still want to further OO, you can build upon how it supports modularity.

yes, you are right. OO is just one way of achieving modularity. Reading data, processing, outputting/formatting are in a single script...for all existing scripts. :(

That's your starting Point: compare the variants of those functions that you want to centralize by your module to find out how you should parametrize them. Then, instead of copying and modifying, set a good example by copying and creating a module (and, of course, eventually using that).

This will take more time, so you might have to do it alongside, but once it is usable, you can use it to convince your colleagues (I don't think your management mandates copy-paste-programming) to take this road.

Of course, further adaptations/modifications of the new "central" module can break those scripts that already rely on it, so it's important to include at least rudimentary tests, lest it will be turned into an argument against modularization…

modifying/refactoring existing code is a lot of efforts . That may be true, but do you have to? Propose this as a way forward. Like choroba mentioned Re: Convincing management for OO having a good set of modules makes future tasks easier. You may be able to just start doing it Find the common parts of a whole bunch of prior art and make some real good reusable modules. Use them in the next project. Then projects after that too. If prior art needs to fixed refactor/rewrite then.

Why Moose? Data munging is one of the places OO is probably least likely to help and Moose has a pretty big startup cost and a fairly big object inflation overhead.

You already got good advice about it. I’m strongly with soonix here. You want modularization. OO? Maybe, maybe not but there are plenty of options there besides Moose and I don’t know your needs but data munging tends to be an area where performance matters.

Senior developer insists that modifying/refactoring existing code is a lot of efforts

You can win them over by showing that these efforts are a "one-time high", and that they pay off (within a reasonable future, which you should also take into account).