Tạo phần mềm JS vững chắc

Nhờ bài giảng của Jeonghwan Kim, tôi đã có thể hiểu được ý nghĩa của việc viết mã tốt. Tôi là một người không chuyên, mới bắt đầu lập trình cách đây vài tháng. Tôi luôn nghe mọi người nói về mã tốt và mã sạch, nhưng tôi không biết chính xác điều đó có nghĩa là gì. Trong khi đó, người cố vấn của tôi luôn khuyên tôi nên thử viết mã bằng TDD. Nói như vậy, nó giúp tạo thói quen theo dõi các nhiệm vụ theo từng phần rất nhỏ. Vì vậy, tôi đã tìm bài giảng của Kim Jeong-hwan và nghe nó. Ngoài việc suy nghĩ theo các đơn vị nhỏ, tôi nghĩ tôi đã hiểu được một chút về mã khô mà tôi luôn nghe nói đến là gì. Tôi nghĩ không chỉ bài giảng này mà cả việc phát triển Node TDD và các bài viết bạn viết trên blog của mình đều thực sự tốt. Cảm ơn bạn đã cung cấp tài liệu giảng dạy tốt.

Thật là vui. Nó đơn giản nhưng chứa rất nhiều thông tin. Những điều cần lưu ý khi phát triển JavaScript bắt đầu từ TDD. Và thậm chí cả khái niệm đối tượng... Người hướng dẫn dường như áp dụng những điều đó một cách tự nhiên, nhưng tôi vẫn chưa đạt được điều đó. Tôi đang học hỏi rất nhiều.

Nó gọn gàng

Bạn giải thích TDD rất dễ dàng. Tôi rất thích nó vì bạn đã giải thích khái niệm TDD rất dễ dàng. Có vẻ như kiểu nguồn bạn đang tạo tương tự như React hoặc Vue. Tôi có một câu hỏi. Các dự án chưa sử dụng được ES6 sẽ cần chuyển đổi sang ES5 và triển khai. Mã được kiểm tra trong ES6 có thể được đảm bảo vượt qua tất cả các bài kiểm tra sau khi chuyển đổi sang ES5 không? Cảm ơn bạn vì bài giảng tuyệt vời. Các bài giảng khác cũng sẽ hữu ích!

- Đây là bài giảng thử nghiệm cũ nhưng vẫn còn hiệu quả. - Bạn có thể trải nghiệm những điều sau đây trong khoảng một giờ. 1. Bạn có thể tìm hiểu mẫu TDD của Red-Green-Refactor. 2. Bạn có thể trải nghiệm việc tách mã spaghetti thành dạng xem, dữ liệu và logic nghiệp vụ. - Trong bài giảng, view và dữ liệu được quản lý trực tiếp bằng js. - Các thư viện hiện đại cập nhật chế độ xem bằng cách chỉ quan tâm đến dữ liệu (trạng thái). 3. Bạn có thể cảm nhận được mùi hướng đối tượng.

Thông thường, những người mới bắt đầu có thể nghĩ rằng viết mã kiểm tra là một việc rất khó khăn, nhưng điều tôi nghĩ khi xem phần này trong một giờ là nó chỉ đơn giản là một trong những quy trình để cải thiện chất lượng mã và tăng mức độ mô đun hóa . Tôi nghĩ rằng tôi đang làm việc với thư viện để nhờ ai đó xác minh xem tôi đang phân tách tốt hay thực hiện tốt việc chèn phần phụ thuộc. Cuối cùng, đây không phải là một hành động để tiếp cận mã sạch sao? Nhưng tôi nghĩ có một cái gì đó như thế. Đó là một dự án mà bạn không có nhiều thời gian và kế hoạch thay đổi thường xuyên, nhưng bạn có nghĩ rằng với tư cách là một đồng nghiệp, sẽ rất mệt mỏi nếu tôi ngồi viết mã kiểm tra không? Đúng hơn, tôi nghĩ sẽ tốt hơn nếu trả lại sớm các trường hợp ngoại lệ và tạo các tính năng một cách nhanh chóng. Tất nhiên, nếu là trái vụ hoặc có nhiều thời gian, tôi sẽ viết và áp dụng mã kiểm tra, nhưng điều đó dường như cũng không thể thực hiện được ở công ty của tôi. Ngoài ra, các công ty CNTT Hàn Quốc có cho bạn thời gian để làm việc đó không? Tôi nghĩ là không. Có lẽ không. Và tôi nghĩ mình đã thấy khá nhiều đồng nghiệp viết code test và không nghĩ có vấn đề gì chỉ vì đèn xanh xuất hiện. Tôi nghĩ sẽ có xung đột vì điều đó. Tuy nhiên, tôi nghĩ phần đào tạo thực tế được cung cấp trong bài giảng thực sự hữu ích và quan trọng. Ngay cả khi đó là một dự án quy mô lớn, mã kiểm tra phải được viết cho các phần chịu trách nhiệm về logic rất quan trọng. Xem xét nhận xét của những người nổi tiếng khuyên mọi người đừng viết mã kiểm tra một cách tôn giáo, một số nhà phát triển có thể nghĩ rằng mọi thứ sẽ được giải quyết nếu họ viết nó.

Đó là một bài giảng tuyệt vời đã khiến những điều khó hiểu trở nên dễ hiểu! Có một thời gian mình đã pass vì thấy khó chịu và không có thời gian nhưng giờ mình đã có động lực để làm quen với phương pháp phát triển do test-led.

Khó quá ㅠㅠ Tôi cần nghiên cứu mẫu mô-đun trước. Và hãy quay lại và gặp chúng tôi!