회고
A project I've been working on for about 6 months has come to an end. I'd like to do a wrap-up to summarize what we did during this time. I'd also like to summarize how I've grown as a backend engineer and as a team member, and highlight some things to consider for the next project.
This project was an in-house side project. Despite being called a "side project" (there was actually a main product), it wasn't a very small project. The project was more or less driven by the client's requirements, and the requirements were very detailed.
I'll briefly describe the project with the following specifications
Developed server logic for the ### project
I designed the overall API design, service DB design, and discussed with data engineers and front-end developers as needed. I also thought about how to refine the data that came in in bulk into logic to display it on the screen. We had a lot of discussions with the planners about the data that would be too slow.
We tried to overcome various issues that arose from using external platforms as much as possible, especially when it came to using Kubernetes, and we communicated directly with the people in charge rather than through intermediaries. In particular, to avoid any ambiguity, I organized the things I tried/problems/desires in writing and pictures.
Writing test code would have made it easier to maintain, but I was so busy working on the product code that I missed a lot of it. This is something I regret a lot. The lack of test code meant that when we needed to do a big refactoring, we would miss bits and pieces.
As a workaround, I tried to get the front-end developer's code locally and run it myself to make sure that the data displayed on the screen didn't change before and after the refactoring. However, this was only user testing for a web project, and it was not enough to test on the actual server end.
As a backend engineer, I was working alone, so code reviews were rare. I asked my coworkers to review the code from time to time, but it was often difficult to confirm due to their busy schedules. Also, people who don't participate in the project don't know the business logic well, so even if they reviewed, they only reviewed the structural content, which was definitely a limitation.
It is rather difficult to develop ### alone.
I can't say that I was developing alone (there were data engineers, front-end developers, and front-end developers), but it was a project that I participated in alone as a backend engineer, so there are some regrets. This is because I can't really judge whether I'm making progress.
It's also quite realistic that I can't guarantee that I will have a coworker on every project, so in this case, I think I need to find a lot of ways to check whether my project direction is going well.
Sometimes the client's requirements are not directly addressable. It doesn't really matter what the reason is. In such cases, it's important to assess the current situation as best you can, diagnose if it's a solvable problem, estimate how long it will take to solve it, and communicate it.
We made good use of Kanban boards to organize the blocked items and make sure PMs were aware of them, and we tried to fit them into the schedule whenever possible.
Actually, I don't write test code because I just say it. I think that the act of writing test code itself is another arm. Therefore, the common things that can be left out when designing test code should be classified/modularized well. You can use existing packages or make your own.
You may be wondering, "Is it right for developers to organize their business logic? However, I think it's important to keep it as concise as time allows. The project is closed for now, but it could be reopened at a later date depending on what we decide. At that point, I may be reassigned to the project, or someone else may be hired. And, as I lamented above, I may need a guide to help my coworkers understand more about code reviews. I don't think it's unreasonable to aim to reduce the cost of communication at this point.
However, since we can't organize this business logic in a single chunk, we need to find a way to manage the documentation and link it to how the code is written.
I think I grow with every project I do. However, I think that 성장한다 needs to be crystallized, so that I can analyze myself and develop the intellectual muscle to decide what to keep and discard. I think the most important thing is to keep the things that have been beneficial and analyze the things that I feel have been a mistake and decide on the next action item.
I also realized that there are still a lot of things I don't know. From server structure, to DevOps (even if it's only part of it), to how to do things more efficiently, I still feel like I have a lot to learn and figure out. I'm going to write down action items as they come up and make a conscious effort to do them.
Still, I think this was a project with a lot of benefits. I hope that I can organize the things I learned and improve the things I didn't, so that I can approach the next project with more growth.