Currently, classes are sorted by type (adapters, fragments, etc). I am also wondering if the package structure in AntennaPod should be changed generally. Using gradle modules ensures that the graph stays acyclic because you simply can’t access other gradle modules without thinking about it explicitly. I hope that this procedure then avoids completely breaking git bisect, which I use pretty much during bug fixing.
#Gpodder antennapod code
the model) is completely free of dependencies, the files can be moved to a new gradle module (without code changes). So I think it would be best to start gradually and try to break some of the cycles. I don’t like the type of commits that touch everything at once because it creates conflicts in PRs and clutters the git history. And I would probably have to spend less time doing bug fixes if the code had more tests.Ī long-term goal would be to be able to separate the code base into multiple gradle modules (model, feed parser, media file parser, etc). I’m definitely not happy about the code structure, though. If there is still time left, I maybe do some code cleanup. There hardly is any package that is not inside a cycle.Īre you almost happy with the (unit and integration) tests we have so far and spend the time mainly on new features? Thanks for generating the dependency graph. Over the past 3 years, I have reworked quite a few monsterous classes but it is still far from being a good code structure. Even model objects like the “FeedItem” class perform database queries. AntennaPod’s code base has historically grown. The package structure should be acyclic, coupling between packages should be as low as possible.ġ00% agree. (only shows packages starting with de.danoeh.antennapod, same color = same package depth) Screenshots / Drawings / Technical details:ĪntennaPod currently has about 54 kLOC in more than 480 Java classes. Is it a desirable goal to improve testability as it might require a lot of effort, or are you almost happy with the (unit and integration) tests we have so far and spend the time mainly on new features?.Do you think it is realistic to do refactoring step by step to make the code more testable via unit tests?.To improve testability the code would need some refactoring: The package structure should be acyclic, coupling between packages should be as low as possible. While investigating in #4569 to provide more unit tests I realized that the source code is very hard to unit test because it heavily uses static fields, static methods, and the package dependencies are very cyclic, see chart below. Problem you may be having, or feature you want: I will describe the problem with as much detail as possible.Īpp source: not relevant Feature description.I will only create one feature request per issue.I have used the search function to see if someone else has already submitted the same feature request.
0 kommentar(er)
