While working on the new feature set for my markdown converter application TILvert, I started by refactoring the original mechanism I had in place for file processing. The reason I decided to refactor the procedure was to make it much easier for myself to update to the applications features without much of a hassle or trying to jump around code in strange locations.
The Refactor
The major changes that happened to the codebase were mostly structural and procedural changes. Previously, the application would process the files in a slightly complicated manner (honestly it was just spaghetti code) and required a decent amount of work to get it to be more generic and easily maintainable.
I made use of the strategy pattern from software design patterns. I implemented a file processor class which can be assigned a file processing strategy. Each strategy handles the file according to the coded procedure for that file, this can be changed by either supplying a different type of input file which the application will automatically attempt to detect the type of file. Or by changing the extension options to md or txt to switch between the 2 processing strategies.
The New Features
After creating 2 issues in my repository to update the new features I wanted add to the code; Adding Italic tag support and Adding Bold tag support, I began creating new branches for each of the features.
While creating the branches, I branched twice off the main branch and began to work separately on each feature in their respective branch. Once the features were completed, I merged the Italic tag commit without any issues. However, when it came time to merge the Bold tag commit, that resulted in a merge conflict (very common on large applications but rather rare when working alone on a particular branch) this to me was somewhat of a surprise as I expected it to not have any conflicts at all.
I realized later on that the content of the code that has updated rarely matter to git, but it does care about which lines you edited within a given context, giving the illusion that git is able to differentiate between different functions. This was an interesting discovery for myself and will definitely help me avoid future conflicts and be more aware of what I code and where.
Other Features
Since the refactoring of the code into multiple file processing strategies made it so much easier to maintain and update the code, I also decided to implement a few extra features into the markdown processor. The processor now also supports Code Blocks and Inline Code Blocks as well as horizontal rules, and customizable language support for the HTML document.
Top comments (0)