http://www.perlmonks.org?node_id=1225609


in reply to Splitting program into modules

A contrarian view: 14000 lines of working code is no joke. Why bother refactoring? If you don't understand it, keep trying. To add new functionality simply write new subroutines that follow the conventions of the original code. Fragmenting the code may make it even harder to understand and maintain. Perl makes delicious and potent spaghetti, just add more sauce, and enjoy. K.I.S.S.

Replies are listed 'Best First'.
Re^2: Splitting program into modules
by eyepopslikeamosquito (Chancellor) on Nov 12, 2018 at 10:42 UTC

    A contrarian view: 14000 lines of working code is no joke. Why bother refactoring?

    Successful software tends to live a long time: bugs are fixed; new features added; new platforms supported; the software adapted to new markets. That is, successful software development is a long term activity. Planning for success means planning for your code to be maintained by a succession of many different programmers over a period of many years. Not planning for that is planning to fail. This is the primary reason for refactoring and continuously keeping the code clean, to make long term code maintenance sustainable.

    Put another way, it's the difference between Programming "Hey, I got it to work!" and Engineering "What happens when code lives a long time?". A quick one-off hack is fine if the code only needs to run a couple of times ... but not if it becomes a long-lived critical feature.

    Programming is easy, Engineering hard. You need to hire programmers with sound technical skills and domain knowledge, enthusiastic, motivated, get things done, keep the code clean, resilient, innovative, team players ... and then motivate them, train them, keep them happy so they don't want to leave, yet have effective handovers when they do ... a hard problem. Yet to be successful that's what you need to do.

    See also: Why Create Coding Standards and Perform Code Reviews?

Re^2: Splitting program into modules (Divide And Conquer)
by LanX (Archbishop) on Nov 12, 2018 at 14:01 UTC
    > 14000 lines of working code is no joke. Why bother refactoring?

    Such monster are mostly full of bugs because maintenance becomes impossible if you've lost the overview.

    Let's be generous and assume 100 lines of code and clutter per function in average. That'll mean 140 functions...

    ... divide this by 5 or 10 or 15 ...

    > K.I.S.S.

    D.A.C.D. °

    Splitting up into smaller units, included with do or require is pretty safe˛ ...

    and will add

    • far better overview already.
    • easier POD-Documentation
    • better control over global vars
    • granulated revision control by changing single files instead of a whole bundle
    • easier deployment
    • more efficient testing
    and I haven't even talked yet about the possibilities to improve this code further like described in my first post.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

    °) Divide and conquer, Dumbo!

    ˛) file scoped lexicals must be in the same file like the functions they access