I want to do several experiments with automated refactoring or really refactoring based on a limited set of rules. The experiments are based on WordPress and I want to write out my ideas. I find it helps to write out an idea to see better understand it. It might amount to nothing, but that is the point of experiments.
Expanding is taking function calls within a library, framework or application and sticking replacing the call with the code in that function.
Collapsing is reducing code in a function or method to smaller functions or methods.
The point of expanding is to remove other refactoring that may have been done to functions already. To see the bigger picture so to speak to see whether a better pattern is witnessed. Sometimes, you need to see how code structured or restructured to see whether you could improve it.
The purpose of collapsing is to break larger functions into smaller functions that handle a single part of the larger function and used in the place of the code. The goal is to see whether the smaller functions can be reused in more places. To test a hypothesis that smaller functions could be reused in more places than larger functions. If the functions are used in one place or have limited usefulness, to slot the smaller functions body back into the functions that call it.
There is a larger goal with collapsing classes and taking the methods and reducing them to methods and executing the same process over these methods turned to functions. Refactoring the objects to either arrays or data classes with public properties. This process seems like it would be more involved and I will attempt it after the expansion and collapsing steps are completed. The collapsing process will be difficult enough to accomplish without rewriting classes.
Finally, the final part of this will be to generate tests for the collapsed functions. Really, the point of the entire exercise is to generate functions and eventually classes that can have unit tests generated. Generate the test objects and integration tests and integration test objects.
The expanding and collapsing process is meant to produce code that is unit testable. Then also generate the test cases, the test objects and expand on it to integration and system test cases. If this goal could be reached, then producing test cases would be a walk in the part. It should hopefully reduce the amount of test cases that have to be manually written.
The goal is to produce code that is of higher quality from existing code bases. Creating a tool that could be developed further to work on other projects.
The difficulty is telling the type of a variable and what data to place. Part of this will be manual, meaning most of the test cases, test objects, etc are generated with only the data and validation algorithm being needed to be completed. The point being that the person would go down each section and fill in the missing parts until all of the test cases run.
For WordPress, the goal is to separate filters and actions from the functions and methods that call the plugin api directly and move them to its own function. There isn't much point to this, other than to see at a glance how many filters and actions exist and where the calls are located.
I also want to move functions to namespaces and reference the new functions from the original.
I want to introduce inversion of control, where each function has an interface and default implementation that could be replaced. This will hopefully help with testing and creating tests. The smaller functions will hopefully have functional paradigm principles applied, where the input and output are idempotent.
I think I'm going to introduce a JSON or YAML file to handle the manual modifications that are needed and replaced when the script is run. Especially when namespaces start being applied.
I haven't decided how I'm going to do this. I might create a simple web service that takes the expanded functions and asks users to refactor the function and expanded classes. Saving the results and learning from the human refactoring. I want to see how well I can get the machine to refactor and write tests for existing code.
For now, I think I'm going to stick with the manual process. It is good enough and I have a lot more control and can tweak the results a bit more, for now, than I could the machine learning results.