Building Robust JS Software

Thanks to Kim Jeong-hwan's lecture, I was able to get a feel for what it means to write good code. I am a non-major and a student who has only been learning programming for a few months. I only heard people talk about good code and clean code, but I didn't really get a feel for what they were. Then, my mentor always recommended that I try coding with TDD. He said that it would help me make it a habit to track my work in very small units. So I looked for Kim Jeong-hwan's lecture. In addition to thinking in small units, I think I got a feel for what DRY code, which I had only heard about all the time, was like. Not only this lecture, but also the Node TDD development and the articles you wrote on your blog are really good. Thank you for providing such great lecture materials.

It's fun. It's simple, but it contains a lot of content. From TDD to things to watch out for when developing JavaScript. And even the object concept... The instructor seems to apply those things naturally, but I'm not at that level yet. I'm learning a lot.

It's neat

You explained TDD very easily. I enjoyed watching it because you explained the concept of TDD very easily. Your source code style seems similar to React or Vue. I have a question. In a project that cannot use ES6 yet, you will need to convert it to ES5 and distribute it. Can you guarantee that the code tested in ES6 will pass the test even after converting it to ES5? Thank you for the great lecture. I will watch other lectures as well!

- It's an old but still working test course. - You can experience the following in a short time of about an hour. 1. You can learn the TDD pattern of Red-Green-Refactor. 2. You can experience separating the spaghetti code into view, data, and business logic. - In the course, you directly manage the view and data with js. - Modern libraries update the view if you only care about data (state). 3. You can feel the taste of object orientation.

Writing test code usually seems like something very difficult for beginners, but when I look at the section for an hour, I think it's simply one of the procedures to improve the quality of the code and increase the level of modularity. I think they're working with the library to get someone to verify whether I'm splitting it well or injecting dependencies well. In the end, isn't it an act to approach clean code? But I think there might be something like that. In a project where time is limited and the plan changes frequently, if I sit down and write test code and waste time, I think it would be tiring for my colleagues. I also think it would be better to return exception cases early and create features quickly. Of course, if it's the off-season or if I have a lot of time, I can write test code and apply it, but that's also impossible at my company. And do Korean IT companies give me time to do that? I don't think so. Maybe not. And I think there are quite a few colleagues who write test code and then just let it go because the green light comes on, saying it's not a problem for them. That might cause conflict. However, I think that the practical training that is conducted in the lecture is really helpful and important. Even in a large-scale project, test code must be written for the part that is in charge of very important logic. Considering the remarks of famous people who say that test code should not be used religiously, some developers may think that if they create it, everything will be solved.

It was a great lecture that made difficult things easy to understand! I used to pass on it because I thought it was annoying and I didn't have time, but now I'm motivated to get used to the test-driven development method.

It's hard ㅠㅠ I have to study the module pattern first And then I'll come back and look!