Jeremiah Flaga

This is where I was first exposed to this idea of Domain-Driven Design (DDD). I was excited with this because I have always been in search for the best way to structure software, and this DDD thing seems to offer ideas on how to do it.

Our employer made us read some articles about DDD because we will be using it in an in-house project. But I was not lucky to be involved in the in-house project because the employment of three junior developers, which included me, ended after six months due to a problem unbeknownst to me.

I just saw the initial structure of the project. I saw that there was a Core module, which I now understand to be the module which holds the business rules. There was also an Infrastructure module(s), which holds the data layer, the email service, and some other parts of the system. There was no presentation layer yet during the time that I saw the project. But it had unit tests.

1. I started to understand what Object-Oriented programming is.

   (When I applied for this job, I claimed to know OOP. But I later realized that I really did not know OOP. I only knew about what a class is, what an interface is, what an abstract class is, what polymorphism is, but I did not not yet have a full understanding about their purpose.)

   This is where I started to understand the Dependency Inversion Principle, the use of the Factory design pattern, and other things.

2. I learned that programmers at this level of their carreer needs lots of guidance/mentoring from their seniors, most especially when the project is in a complex state already, and if the seniors don't want the juniors to mess with the code.

   (When I become a senior developer someday, I intend to guide/mentor my teammates who are in the beginning years of their carreer... provided of course that they also share some of their knowledge with me. )

3. Also, I think it will be helpful to give from time-to-time some readings or lectures about the domain of the system being maintained by the programmers, so that it will not be very hard for them to understand the parts of the codebase where knowledge of the domain is needed.

4. This is the time where I, and my teammates, plunged into the Clean Code book because one of our team leads made us read one chapter of the book each week, and spend about an hour each week discussing that chapter.

   Unfortunately, for reasons unknown to me, our discussions stopped after a few meetings. We did not finish the book. We only discussed up to chapter five, if I remember it correctly. And I read up to chapter 8 only of the book.

   But I learned a lot from the chapters which I read.

5. This is where I experienced writing unit tests after-the-fact, that is, after the production code is already written. — It was hard.

   There were parts of the system that were somewhat easy to test. But there were parts that were hard to test. Those parts that were hard to tests? — those that used DateTime.Now, and static methods, and extension methods of C# (which basically are still static methods), those parts that use (what I now know as) Service Locator — I skipped testing them . Of course I first tried to look for ways on how to test those things...

   I think the time I spent writing those tests was a waste of time , partly because there were parts of the system that I skipped testing (because I did not know how to test them), and partly because I did not have the goal of using the tests to make the design of the system better at a later time, which is supposed to be one of the reasons for writing tests for an existing software. I did not know yet that sometimes it is necessary to change production code to make them testable — something I learned later on after reading books such as "Working Effectively with Legacy Code", and after learning more about TDD.

   Don't get me wrong here. I don't hate unit testing. During that time, I already have an appreciation on the benefits of having unit tests — it had been three years already since I first heard about unit testing and TDD during that time.

   I think I should have told my team leads about my opinion that writing those tests was just a waste of time. Had I told them about it, they might have explained to me why those tests should be written, and they might have helped me look for ways to write tests for the untestables that I encountered. But I was very timid during that time and was afraid to express my opinions.

   But despite that experience, I'm not against writing tests. I am even a TDD advocate today through the influence of Uncle Bob Martin. But writing tests after the production code is already written requires a somewhat different skillset than doing TDD. I was, and is still, not skillfull on writing tests after-the-fact. But I'm trying to be good at it also.

Nothing extraordinary. Just finished the tasks assigned to me.

But this time, because I already have a better understanding of polymorphism (and its use), and the SOLID principles, and other things related to software design, I tried to use these knowledge in my coding.

1. I learned how to work on a Java platform.

   Before this job, I only knew how to do real world apps using .NET.

   Doing Android made me more confident that I can also do work on other platforms. (Big thanks to my employer for giving me this job even though I had almost no experience with Android development.)

2. Even though we were using RxJava in our project, which others say makes dealing with threading much easier, there was a time where I had to deal with what they call a race condition with this threads thing while working on version 2 of the app.

   It was hard. The bug was intermittent. It was hard to find, [partly because that part of the project uses RxJava in a wrong way(?) After I few weeks/months working on the project I discovered that when using RxJava, methods must return Observables all the way up from the data source to the presentation layer, to avoid memory leaks and so that they can be easily composed.

   But I'm not 100% sure if the wrong way of using RxJava is truly the reason for that bug. Perhaps it was just my ignorance on how to deal with threads. Luckily, that feature was removed during the development of version 3 of the app. Yehey!

   I still have to learn more about this threads thing.

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 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.

Don’t try to clean up everything.

Avoid directly using 3rd party classes at the boundaries of your architecture.