Author: Wang Qi Le

The past week , I have been trying to make all the integration tests pass in the project .

20 weeks have passed since I’ve written my first blog .

Since day 1 , I have learned countless of new techniques to manage a project . Of course , the skills that I possessed today came with numerous embarrassing experiences . A few “highlights” I could think of is me committing my first commit message as “commit” , manually inserting 400-500 lines of required rows in SQL for not adding the latest migration , not to mention unique rows . Also , spending 6 hours a day trying to build the project because one number in the port was set incorrectly . I am sharing this because as embarrassing as it can be , even at its very peak , always remind ourselves mistakes are not something we should shy away from but to embrace and learn from it .

In all honesty , big thanks to my supervisor Peter who is persistent in putting me under this forceful environment at all times , as much as I hate it , I am also equally grateful for it . Accelerating my learning curve and more importantly , realizing results come from sheer hard work , not living in our own comfort zones to feel good about our own opinions .

Also , I would like to thank everyone else who ensured my time at Tong Hin was smooth and memorable .

Thank you once again .

Throughout my coding experience in Tong Hin’s module . I have applied most of the concepts in Object Oriented Programming (OOP) . OOP is a concept of using classes and objects . The classes in OOP are usually referred to as “blue prints” which means the structure of the program , we are able to use these classes to form objects which contains data . The 4 basics concepts of OOP are Encapsulation , Inheritance , Polymorphism and Abstraction .

Encapsulation controls the display and access of methods with public , private and protected modifiers , each with its own unique purpose . These access can also be control by a getter and setter method . A getter method is used to get the changes of a value of a property . A setter method is used to set or update a value of a property . I have used this concept a lot while creating new features with the wrapper pattern implementation .

Inheritance allows us to access methods from other classes with the : symbol . This concept has helped me a lot with achieving less messy and maintainable code with inheriting repository interfaces and database contexts when creating unit tests .

Polymorphism can be broke down into 2 types , static (method overloading) and dynamic (method overriding) . Method overloading allows us to use multiple methods with the same name , under the conditions of declaring different data types , changing the order or number of parameters . Method overriding allows us to use the virtual keyword within a base class method , I have used this a lot to with the creation/disposing of the test databases .

Abstraction is rarely used among the 4 concepts . However the purpose of an abstract class is to hide certain details and showing only essential information .

After getting the hang of these concepts , I could not imagine developing a project without the practice of OOP , while recognizing more and more new ways of problem solving and reducing code complexity .

The past week , I read about the practice of CI/CD (Continuous Integration , Continuous Delivery) in a developing project . For newer developers , the biggest fear is doing a pull request and recognizing the countless of red underlines in our code , while it’s already a mess to develop a single branch without causing breaking changes , we can’t imagine the stress having to pull requests from multiple branches .

Continuous Integration (CI)

A solution to this problem is a to practice CI . As the goal is to have multiple developers working simultaneously on different features . It is very likely to cause changes that breaks the application . Therefore , a successful CI involves creating well-designed unit and integration tests across all modules , so that code changes can be regularly tested , built and merged to a shared repository without breaking the application in the CD stage .

Continuous Delivery (CD)

A CD picks up where the CI ends , CD automates the release of that validated code to a repository. In order to have a successful CD process , it’s essential that CI is already built into your development pipeline . The goal of CD is to have a codebase that is ready to be delivered from a SandBox environment within minutes of creation to a production environment.

For the past week , I have read about applying the CQRS Pattern in a project . CQRS stands for Command and Query Responsibility Segregation . This design pattern is aimed to segregate the read and update operation in a project .

The CQRS pattern separates read and write into different models , using commands to update data , and queries to read data . The presentation layer for commands is typically separated into Validation , Command , Domain and Persistence . Queries is separated into a read-only layer to generate Data Transfer Objects .

The benefits of using the CQRS pattern is simply like the pattern named itself . The separation of command and query models , resulting in a more simplified design in a project .

However , this design pattern is more suitable for larger projects where the requirements for read and write operations that is more complex and challenging . For simple CRUD operations, we might not need to implement this pattern . 

The past week , I have been working on creating features in Tong Hin’s inventory module , and used many different types of collections interchangeably to retrieve data such as IEnumerable , ICollection , IList and IQueryable .

IEnumerable vs ICollection vs IList vs IQueryable

IEnumerable is the most basic type of list container to store data . It has no order and does not allow us to modify the set . An IEnumerable supports the where clause to filter elements , but it does not hold the count of elements as we need to iterate over the elements with “foreach” to get the count .

ICollection is a modifiable set and allows us to edit the elements in the collection with .Add , .Update and .Remove . Such as IEnumerable , ICollection also has no order and does not allow us to sort the data without changing it to a list with ToList() .

IList is an ordered set and provides an object indexer to allow the user to access the collection with square brackets like myList[x] . It is useful when we want to sort elements in the collection . I used it to sort dates to show the latest data in a table .

IQueryable is used when we want to run an Ad-hoc query , an Ad-hoc query is created to provide a specific record set from the database , usually defined to serve for a particular purpose . I used it to include different entities from other classes in one query .

In summary , each function has its own characteristics and is adaptable to different scenarios , and it is better for us not to memorize but understand how things work .

The past week , I have been doing more refactoring in the Tong Hin’s inventory module , to allow maintainable code in the project .

Writing maintainable code simply means code that is easy to modify, read or extend , not just to be understood by ourselves so the program “runs” but easy to be read by current/future users involved in a project . In other words , not causing an immense grief to other group members .

Aside from the classic practices for newer developers such as writing comments , giving meaningful variable names , writing testable code , clean coding etc . Trust me , it really ain’t enough .

Any software developer will get into these situations where we face an “endless loop” of errors when creating a feature . Fixing an error from one part and another pops up within this feature , while repeatedly adding more messy if-else null checking statements to avoid/fix each error , and “forcing” maintainable code while losing our sanity on top of it.

In these situations , we should realize that simplicity is part of the answer , that no user interaction is also the best user interaction . Ask ourselves if it needs to be done at all ? Because throwing away 30% of the problem for 70% of the solution may fix the problem .

With that said , maintainable coding is really easier said than done . It requires us to think out of the box , which cannot be taught to anyone . There are cases where we can avoid/fix the “endless loop” of errors by trying weird things , adding/removing a button , twisting and avoiding the root problem and out of nowhere get the answer .

Regarding last week’s blog in optimizing EF core performance , the cartesian explosion was optimized to a slight extent successfully using explicit loading and removing several repetitive code . The data of this performance is tracked with the help of performance profiling .

I optimized the problem by starting a timeline profiling session provided by visual studio , here are the following steps :-

Step 1 : In visual studio , go to Debug and click performance profiler

Step 2 : Select Application Timeline and Database (examine the SQL query to measure time)

Step 3 : Click start , navigate to the cause of the UI freeze and click “Stop Collection”

Following these steps we are able to analyze where is the memory traffic coming from , then improving the code and fixing the issue .

In summary , profiling helps a lot in detecting what causes performance issues , for less experienced developers we have to be careful in retrieving so called “list” or static data using database connection every time in a loop or repetitive process . After many trial and error , I manage to optimize the performance loading in the SandBoxApp .