Engineering-In Quality
(This is targeted for the Design Summit, but LP isn't showing that very clearly)
As the number of active contributors to Nova grows, and as the amount of code grows to be too much for anyone to keep in their head, we need to get more help from our toolset.
Right now we have a lot of rules about code formatting, but almost no guidelines about code quality or defensive coding.
For example, by moving from Dicts to objects with defined properties, Python and PyLint will catch many mistakes that would otherwise be difficult-
Is there a book like "Effective Java" for Python?
(http://
Blueprint information
- Status:
- Complete
- Approver:
- Vish Ishaya
- Priority:
- Medium
- Drafter:
- justinsb
- Direction:
- Approved
- Assignee:
- Vish Ishaya
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
- Vish Ishaya
Whiteboard
Result of this discussion was towards moving to an object-model or keep dictionaries for everything. We are evaluating different approaches. I'm going to put together an alternate object proposal and we will vote on the mailing list. --vish
Jay Pipes wrote:
I disagree with this blueprint almost entirely. We don't need "help from our toolset". The source code of Nova or any other OpenStack project shouldn't be designed to work well with someone's favourite IDE or language.
Also, Python != Java, and thank goodness for that. We should use the paradigms of the programming language that OpenStack is written in and not try to bolt on the concepts from Java just because that might be the language you prefer.
The ways to improve code quality without trying to be a programming language that we don't use is to actually enforce the APIs that are in the code. The reason the image format stuff got so messy is because people decided to ignore the API that was in BaseImageService and thought that "their" API was the only one being used.
If the defined interface needs to be expanded, it should be discussed and expanded, like was the case with the "properties" discussion. The solution is not to go to using object.attribute notation versus object['attribute'] notation just because an IDE you work in happens to auto-complete on the former rather than the latter.
-------
Justin Santa Barbara wrote:
The fact remains that there are whole classes of mistakes we're making, that are easily caught by freely available tools (PyLint). If you would like to expand PyLint to be able to detect more classes of bugs, then by all means go ahead. Otherwise, I believe we should acknowledge that people make mistakes, and I think it's good engineering to write our code in such a way that bugs can be detected by the tools we have, rather than the tools we would like to have, where such compromises are reasonable.
This is just like having pep8, but for code quality, not just for formatting.
If you have a better way to scale the project and increase quality, then I'm all for that. The goal is not "use PyLint" or Pep8 or Eclipse or PyCharm or Emacs or Vim, the goal is to produce a quality OpenStack. I tried to keep the discussion topic unbiased, but it's difficult to do that while still explaining what it is you want to talk about.
Sounds like we're in for a great debate!
