Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Splitting program into modules

by Anonymous Monk
on Nov 12, 2018 at 07:05 UTC ( #1225609=note: print w/replies, xml ) Need Help??


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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1225609]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (8)
As of 2019-09-23 11:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    The room is dark, and your next move is ...












    Results (279 votes). Check out past polls.

    Notices?