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?
| [reply] |
> 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.
°) Divide and conquer, Dumbo!
˛) file scoped lexicals must be in the same file like the functions they access | [reply] |
