[placement][ptg] code refactoring constraints and goals
>From the etherpad 
* We got a lot of value out of the ovo-ectomy and de-list. We're now
at a stage where there is plenty more that could be done, but the
choices are more subject to personal preference.
* How (and should) we further split and shrink objects/resource_provider.py
We got a lot of value out of the big refactoring the removed OVO and
split objects/resource_provider.py into smaller files. It's also a
stated goal that we should continue refactoring and continuously
revisit existing code.
However, we started to stumble because we had some disagreements on
how to proceed. We should resolve those disagreements so we can
proceed (he said, obviously).
Questions that have come up (plus other ones I can think off the top
of my head):
* Is it worth reordering methods to some kind of arbitrary ordering?
* If a method or module is "long" (by some definition) does that
make it bad?
* Where is the balance between backport hurting churn and keeping
the mix fresh?
* Should there be a more cleanly defined boundary between the
methods that marshal data (the top-level methods in objects/*.py)
and those that talk to the persistence layer (also in
* Do we need to define (better) or document the layers/boundaries
in the system?
* How can we encourage a similar refactor/revisit-often attitude to
There are plenty of other refactoring related thoughts too. Have at.
Chris Dent Ù©â??Ì¯â??Û¶ https://anticdent.org/
freenode: cdent tw: @anticdent