Open Adirelle opened 9 years ago
@Adirelle First of all.. Thanks for the AWESOME analysis.
I agree with all points and I know this should be a big refactoring on all parts of PHPCI application, but i think it's required in order to make the application evolve and remove some technical debt accumulated on time.
I would also suggest:
If also other are agree I also like to help on this refactoring on my spare time, but IMHO we need to define a list of task and prioritize (to manage dependencies, ..) before start on it.
@Adirelle & @mavimo - Seconded, this is a great analysis.
I agree we need to define a plan first, and then I'd want to see the following:
@dancryer I agree.
I suggest to start with somethink simple like:
The 1 is WIP in #881 The 2 is "easy" and don't impact a lot on other parts
@dancryer, @mavimo I have several PR in progress, and I think I'll wait until they either get merged or rejected before working forwards on other points. Some of them impact the Builder and the plugins and I am almost sure they will cause conflicts.
About the Logger, I think we should define some guidelines beforehands:
@mavimo: I would like to see a global DIC to be created. In my opinion, this could be done in a few steps:
After hacking around PHPCI the last few days, I think we would have to do some cleanup prior to adding features/fixing certain bugs. The biggest issue is the dependency of several components, including all plugins, to the bloated Builder. I think trimming down the Builder should be a primary focus.
Moreover, it appears that the coding practices differ highly from a plugin to another one, depending on their author, which doesn't help refactoring them. It seems a lot of copy-pasta have been used, instead of using a common base class.
Another outstanding point is that there is no standard way to deal with plugin options, so every plugin author uses its own way. We should think about this.
So I've started to clean the plugins to eventually remove their dependency to Builder: https://github.com/Block8/PHPCI/compare/master...Adirelle:plugin-cleanup
I don't try to fix bugs nor completely remove the dependency to Builder, and I haven't introduced any breaking changes. However, I feel some things could be moved into the Plugin interface to lighten the constructor, like a setOptions method: this would allow to remove the $options from the constructor (and the associated Plugin Factory shenanigan). Something should be done about options: setting defaults and checking values is a common task. There already are libraries handling this in a neat way. For example, we could use Symfony's OptionResolver, though it would cause BC in some cases.
I'm also hesitating about the way to handle the plugins' build settings: I was thinking about adding a "BuildSettingsAware" interface. Another solution is to merge the plugin's build settings into every stage options. This wouldn't require another interface but it would be less clean.
At this point, I can start to clean Build's subclasses in the same way, but I would like some feedback on this points.
Since I started using and hacking PHPCI, several things in the source are tingling my OOP sense. I think most of these things come from legacy code and contributions of people with various backgrounds and experience in OOP. Though they work, I feel these parts should need some love to pay the technical debt. Here are a few points I noticed (and you have probably also noticed):
I can contribute to fix these points but I would like to know what you, PHPCI collaborators, think about this.
Thanks for reading.