Refactoring in a large code base
Thomas Mellman
tmellman at web.de
Fri Jan 22 07:27:10 EST 2016
On Fri, 22 Jan 2016 04:04:44 -0800, Rustom Mody wrote:
> These are just specific examples that I am familiar with Chris' general
> point still stands, viz take the large and complex program that is
> cpython and clean up these messinesses: You will still have a large and
> complex program
I'm not really sure what the point is we're working on... let me
propose these:
- unix principle is good: keep things simple, limited in scope.
Then leverage that.
- there will always be complexity, but if the complexity is
modularized, it's controlled.
In particular, the complexity of a program should represent the
complexity of the problem. I call that "structural complexity".
To be avoided, corrected, is "superficial complexity",
where the complexity of a system is squished into a single (or
reduced number of) planes. Like vomiting a program onto a desk.
- "Advice" that the program needs to be refracted is generally not helpful.
More information about the Python-list
mailing list