Refactoring can be frustrating.

As I read through code I often rewrite it as I go, I find this helps me to understand it better. A bit like how doodling has been shown to help people remember stuff. I also take notes as extra comments as I go. Often after having gone through a bag of code I find that some of the edits I have made improve it. Ideally I could just create a new branch, merge request, go through the process and eventually get that code merged.

One issue that comes up, and comes up particularly often on large refactor work is conflicts and conflict management.

Now pycharm has a great ability to resolve a lot of conflicts but if the refactor is large enough to be moving whole collections of modules to a new architecture then simple side by side comparison of the changes doesn’t work. It can sometimes be hard to see how to integrate the new work.

Alongside this is the fact that for large architecture sized refactor projects the process to get merge approval can take a long time, and in a way rightly so. Such large changes need to be comprehensively understood and tested before anyone should think about clicking a merge button. Unfortunately this time element along with the challenge in integrating some of the conflicts means that it can be useful to get a heads up that a change is going to be merged into the main branch before it happens. It might even be the case that it would be beneficial for the other work to be based on top of the new refactor work but that the author of the change doesn’t know about the refactor project.

Luckily gitlab and github provide API access to the information on projects. That allows us to be able to write scripts that can gather the information we need and alert us to potential issues before we are notified a merge conflict has arisen.

I’ve been using an adaptation of the following script on some of the projects I’ve been working on in order to get such a heads up about potential conflicts:

This script is very limited in what it does, simply checking a particular file in which I have done a large amount of refactor work and notifying me, after running the program, that there are other people working in the area.

What it would be nice to do is have a script which runs in the background and sends me an email when any merge request is opened which has the potential to, if merged into the main branch before my changes, cause a conflict.

I could also go further, albeit with some difficulty. I could try to enforce a larger influence on the codebase in the direction of a style I prefer. I could have the ability to protect modules I have worked on from being added to in a way that might reduce the coherence of the module.

No one has the time to read through all the merge requests going into a large project, particularly large open source projects. As an individual developer it might sometimes be hard to influence the rules which go to defining how a codebase expands and changes.

Having an overarching eye to check of a list of things you would like the codebase to adhere to but which might not have made it to the guidelines for a given project is a light touch way of influencing things for the better. At least by your definition of better.

There is a lot of potential in the APIs provided by gitlab and github, I know many projects that have lists that when updated can cause merge conflict issues, one cool project using the API might be to automatically resolve particularly repetitive merge conflict issues automatically.