Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on How should I structure a growing Python project?
Parent
How should I structure a growing Python project?
I’m working on a Python project that’s starting to grow, and the code is becoming harder to manage as different responsibilities are mixed together. Are there any recommended ways to organize modules or patterns to improve maintainability and scalability?
Post
It's not really related to Python at all. For any language, you will use an object-oriented design for the sole reason that it scales well with larger projects. If every part of the program is written with lots of OO discipline, then the size of it won't matter since every module just ought to take care of it's own designated task and not worry about the outside world. This means that maintenance turns localized and bugs don't as easily escalate all over the program.
Similarly, if not enough care about design was taken from the start, then all design problems will escalate, "tight coupling" between unrelated parts will increase etc etc. It is good practice to always write production quality code from day 1 and not starting by hacking together some quick & dirty "debug release" code with the intention to clean it up later. "Just coding away" is the root of all evil.
The process of re-designing bad code is often called "refactoring", which is a snobby way of saying "I didn't consider requirements and/or design enough when I first wrote this bad code". Those who claim that "refactoring" is some sort of natural, mandatory part of the development process are probably not very experienced. With experience you'll learn that spending some extra week on requirements and design will save far more time later down the road. Because rewriting everything at a later stage takes lots of time and nobody wants to pay you for doing the work twice either.
If the code was originally well-designed but "scope creep", extra features or quick & dirty patches challenge that design, then that's known as code rot and it happens when you continuously maintain something over time. Particularly when abandoning discipline or when rolling out changes under time pressure. You might have to rewrite parts of the program from scratch to get rid of that. Ideally you should not abandon discipline when making a new extra feature and you should probably test it much more carefully than you tested the original code. A significant part of all bugs out there happen during maintenance.
In addition to paying extra attention to requirements and design, which are by far the most important parts, you also need:
- A coding style guide for how you should write code.
- Coding rules for which language/library features to avoid or treat with care.
- A documented procedure for how, when & where you do commits to the version control system.
- A documented procedure for how you publish/deploy programs.
- Peer code review and/or static/dynamic analyzers are great ways to reduce bugs.
0 comment threads