Improve readability and testability of code
Issue
Having all the logic bundled within a single main method is difficult to understand and test, so I broke up the code as much as I could in a way that could address both these problems.
Changes
-
Code hygiene:
- Added wrapper class (
YoutubeClientAdapter) to interface functions from the youtube api client and implement helper methods for the main method- If this approach is accepted, we can mock the api client using mockito and start writing
YoutubeClientAdaptertests
- If this approach is accepted, we can mock the api client using mockito and start writing
- Added placeholders (
views,likes, etc..) to the statistics comment (stat_comment) to simplify generating new comment strings using theString.formatmethod (perhaps we should think about localizing this string in the future?)
- Added wrapper class (
-
Other improvements:
- Get video statistics in one batch fetch in
YoutubeClientAdapter#get_channel_videosrather than invoking a fetch operation for each video - Set
ratioto 0 in main method if there are 0 likes to avoid division by 0 error - Added new requirement
API_KEYfor the.envfile- Note: I was not able to get a successful response from the comment insert/update api operations without this
- Added
__pycache__,.vscodeto .gitignore
- Get video statistics in one batch fetch in
A lot of this is very helpful! I haven't gone through all of it, but I will. The only issue I see with it is that it's quite a bit different from the YouTube Data API doc code. That may be better, but it could cause some trouble in the future for others trying to understand the code. Let me think on this a bit longer.
A lot of this is very helpful! I haven't gone through all of it, but I will. The only issue I see with it is that it's quite a bit different from the YouTube Data API doc code. That may be better, but it could cause some trouble in the future for others trying to understand the code. Let me think on this a bit longer.
Good point. I can isolate some of the YouTube boilerplate code better and remove some of my changes to that specific part later. But, I think using an adapter for the api client helps to unbundle some complex logic in the main method and it will also offer some nice auto-completion hints from the ide (good for potential contributors) since we would have an interface for the api client in the codebase.