Edited
๏ฝฅ
Reviews 42
๏ฝฅ
Average rating 5.0
Pros: - Can directly implement the basic domain of a bulletin board as MSA through live coding. - Can gain various experiences directly on the bulletin board, covering diverse topics like posts, comments, likes, views, and optimization. - Practicing is good because it's all done via live coding from 1 to 10, and there's little difference from the provided source code. Cons: - Since it's for intermediate learners, some explanations are lacking, and the process is dry, simply following the coding. - For intermediate learners, wouldn't it have been better to provide completed code for each section and explain why the design was done this way for each section and how the code works, rather than live coding...? - Testing is difficult without test data because each test code is dependent on each module, making local unit testing difficult. Suggestions for improvement: - It would be good if testing were conducted by distinguishing between unit tests and integration tests. - Having to run each module entirely repeatedly for testing is too cumbersome; it would have been better to utilize Docker containers. - Since the test code depends on the `articleId` that is generated, I have to copy the `articleId` from the logs for testing, which felt inconvenient because it's too data-dependent. - It would be even better if the parts you explain in between were left as comments. Even with 6 years of experience, there were parts that were difficult in between. I had to stop for a while due to work and came back to it after a long time. There were many parts I didn't understand... The lecture is long, so starting from the beginning felt like a burden. I generally understood by looking at the code and proceeded, It was a bit difficult when the tests failed because I accidentally deleted all the local data in the middle๐๐ Nevertheless, using the bulletin board project to easily explain system design that considers performance aspects such as query optimization and cache optimization was really good overall. Thank you~
Will Dunn, first of all, thank you for the good review and constructive feedback! > For intermediate learners, wouldn't it have been better to provide completed code per section and explain more about why the necessary design was done this way for each section and how this code works.... Honestly, personally, I find this method much easier when creating lectures, but I think it's difficult to meet everyone's requirements..! It seems most students tend to prefer live coding more. It seems quite a few people are curious about how code is actually written, and how to find and resolve errors during debugging. In some ways, it can be a tedious process, but many people also prefer the process itself. Considering the difficulty level, the target audience definitely includes current developers, but since there are also many job seekers and new developers, it seems many are curious about the code writing process itself..! So, the next lecture will likely proceed with live coding to meet most requirements..! We ask for your understanding on this matter ๐ญ Regarding the design, I thought I had mentioned it sufficiently with diagrams, but considering the difficulty, I fully understand that questions may not be completely resolved depending on the pace or individual differences in progress. I check the Q&A board constantly, so please feel free to ask questions about anything you feel is insufficient!! > Areas for improvement I also fully agree that testing is difficult. It's always hard to initialize large-scale data, and since you need to put in a lot of actual data for things to become visible during the practice process, we had to rely on pre-initialized real data. I also thought a lot about how to conduct tests while preparing the lecture.. To be more precise about the tests we build in the lecture, the integration tests, which are not unit tests, were simply meant for visual confirmation of execution. (Therefore, the tests are not idempotent, nor are they performed in an isolated environment.) Test containers were also considered, but when trying to consider everything, the amount of things to know becomes endless, so I think there were parts where we had to draw a line..! In fact, some content was reduced from the initial plan, and there were quite a few slides that were created and then deleted.. I will continue to think about the part regarding testing! > It would be better if you left the parts you explain in the middle as comments I fully agree. Thank you for the good suggestion!! > In the middle, I lost all local data, which caused test errors, so it was a bit tough ๐๐ I strongly relate to that; I've also had local data break or get lost a few times while preparing lectures, and re-initializing it was quite cumbersome.. ๐๐๐ You must have been very busy with work, so I'm very grateful and proud that you listened well despite that. The content is sufficient for current developers, but I thought they usually wouldn't listen much because they are busy with work, so I'm even more proud that there was someone who listened so well. Thank you for your hard work in completing the course, thank you for organizing and providing the feedback, and thank you for diligently taking the lecture!!
