Worked on an application used for points-based rewards system for agents in a company.
Also involved in a team working on a Customer Relationship Management app for an online store. The CRM generates reports, allows searching for nearby clients, viewing quotes of clients, viewing products and number of stocks available, etc.
Technologies used: ASP.NET MVC, ASP.NET Web API, AngularJS, Entity Framework, Dapper
The first app I worked on has two ways for data access: one uses a database-first model of Entity Framework and the other one uses a code-first model of Entity Framework. This sometimes gets in the way when I'm searching for the model to use when adding features in the app. So I refactored the app so that it will only use the code-first model. Then, when the refactorings was finished, I was able to delete all of the the database-first models.
It was just a small app and not very complex, so it was doable within a short period of time. I do not advise doing that in medium sized or big apps.
I was the only one working on my first project in the company so it seemed to me that I was free to do whatever I wanted with the codebase.
There was a test module in the project, but it was empty. I thought to myself, "Maybe the original developer wanted to create tests but did not have time to create it; let me try". The codebase was not structured to be testable, so I decided to re-structure things...
... to make the code testable.
I was able to setup the tests, and then managed to create some unit tests and some acceptance tests, but I later abandoned them for some reasons...
The major reason why the tests were abandoned was this: When I started working on the project, I have this kind of mindset which says something like "I have all the time in the world to work for this project, and so I will be able to write all the tests needed". Well, I later learned that the client does not have all the time in the world to give to me. Worse, I needed to work somewhere else so I have to resign from the job.
Because of the restructuring that I did, the project now has two different structures: the original one, and the other one which makes the code easier to test. Poor guy who inherited the codebase. I hope he can be able to find which code uses which structure.
... More than a year later, when I am already working in another company, I came across these words from the book "The Mythical Man-Month" by Frederick P. Brooks:
I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.
... I will certainly not contend that only the architects will have good architectural ideas. Often the fresh concept does come from an implementer or from a user. However, all my own experience convinces me, and I have tried to show, that the conceptual integrity of a system determines its ease of use. Good features and ideas that do not integrate with a system's basic concepts are best left out. If there appear many such important but incompatible ideas, one scraps the whole system and starts again on an integrated system with different basic concepts.
I think the lesson to be learned in that is that if one decides to restructure a codebase, because he finds it hard to work with that codebase if he will not do so, he must choose a structure that is not too different from the existing one, but still makes the codebase easier to work with.
I think that changing it to a completely different structure is acceptable only if the original restructur-er will be involved in the project for a long time or until the restructuring is completed.