Based on discussions with Mr. Peter, I focus on the Transfer API call functionality, which only interacts with Mongo on each create and update. I initially create the necessary files such as commands, as well as controllers, repositories, interfaces, tests, collections and services. After implementing these components, I directly create the sample data containing the required order details. I then update the controller to read the data to test whether the call function was successful. As I successfully retrieve the data, I continue the create command and keep improving the service. I also manually test this feature by calling the POST API to create a new order, and it worked just fine for the first try. This makes me feel very accomplish and I will continue to update the instructions tomorrow. Soon, Mr. Peter mention that any nullable data should not be seen in the Mongo express interface.
Moreover, I try to update controller tests to initialise data and set up the test environment correctly. After that, I continue on the create and update commands, constantly refining the logic and handling exceptions. At the same time, I also push my user and retail contexts for review. When Mr. Peter reviewed it, he pointed out a major problem with the controller design. The controller should only contain a Mediator constructor. I took his feedback seriously, I then add relevant queries in a timely manner and push an updated version. Mr. Peter also find that there were some unnecessary changes in my work, and require me to review and try to delete irrelevant code.
Other than that, I continue on refining the commands and services. The update command is particularly frustrating due to the complexity of handling multiple states. I found myself struggling to find the best process, I keep questioning myself and iterating on my logic. Meanwhile, I also push my works to Mr. Peter, he still flagged some unnecessary elements in the code base that made it cluttered and confusing. This was a difficult realisation because I had to face the fact that I was adding complexity instead of clarity. Mr. Peter suggested using SourceTree to compare commits line by line.
Additionally, since the deadline was getting closer, I spend the day reverting unnecessary changes as quickly as possible. During our discussion with Mr. Peter, we discovered a serious misunderstanding that I keep synchronising data incorrectly by creating or updating a local dataset instead of just focusing on MongoDB. I then modifying and refining the sync commands to be consistent with the correct context and ensure the API and tests were running as expected. When I successfully manual test the updated sync commands, I felt a sense of relief and renewed confidence. Later, I start to adjust the testing in retail and user contexts. However, there was an error on the user side that I couldn’t resolve in the end and will continue tomorrow.
Beyond that, after a lot of hard work, I finally find the solution and pass the test. I then review my work again until satisfy, then I commit and push to the repository. I then turn my attention back to completing the command and service. Soon, I found out the create command shouldn’t have any big issues. Later that day, Mr. Peter and I discussed about the item adjustments during the ordering process along with some additional requirements to be updated.
Conclusion
Looking back on this week, I experience all sorts of frustrations. I begin to realise the importance of clarity, communication and iteration in coding and collaboration. I keep refining and modifying the commands and the services in order to achieve better logic. While there is still much room for improvement, I will keep my encouragement to handle the challenges ahead.