Cảm ơn bạn. Sắp tới mình sẽ cố gắng hoàn thành series để tổng hợp đầy đủ nội dung của cuốn sách. Mong bạn đón đọc.

Đúng vậy bạn

Bác này làm cả clip youtube quảng cáo trên voz phải không nhỉ?

Bạn có thể post ảnh log lỗi lên đây được không nhỉ, chứ miêu tả như hiện tại cũng khó tưởng tượng quá (^^;)

làm sao để lấy được số báo danh ạ

Cảm ơn bạn đã chia sẻ!

Có vẻ hay đó bạn

Thank bạn, bài viết hay quá.

@khoaha2 em note lại các bài cần hint ra đây anh check thử nhé

Thanks

nó có test được scope không ạ ?

@vietnguyen148 Vâng, cảm ơn bạn đã bổ sung thiếu sót cho mình.

Bạn inbox email. Wilidn2021@gmail.com . mình có việc cần thuê bạn làm cái này tí.

Mình đồng ý với bạn rằng thiết kế đẹp ngay từ đầu là một điều không tưởng, bởi chúng ta đều biết mô hình thác nước không áp dụng được với các dự án phức tạp bây giờ. Tương tự, sự phức tạp trong một hệ thống cũng không thể tránh khỏi, nhưng cần hết sức giảm thiểu nó. Theo mình, 2 nguyên nhân đầu và nguyên nhân phụ bạn đưa ra thuộc dạng tư duy chiến thuật như đã nói ở phần 1. Mục tiêu quan trọng nhất của tác giả John Ousterhout là thay đổi cách tư duy của lập trình viên khi phát triển hệ thống. Còn về nguyên nhân thứ 3. Việc quản lý hệ thống không chỉ phụ thuộc vào cách chúng ta tổ chức code, mà còn có liên quan chặt chẽ đến cách quản lý đội ngũ lập trình viên. Hiện tại có thể kể đến mô hình microservices, các services được đảm bảo "loosely coupled" theo Data driven design, mỗi service được phụ trách bởi một team nhỏ. Ở các bài viết sau sẽ trình bày các kỹ thuật để tạo ra deep modules, giảm thiểu classitis. Bạn theo dõi tiếp nhé.

Cảm ơn góp ý từ bạn. Nội dung bài viết rất trừu tượng, bởi lẽ tựa đề của cuốn sách mà mình dựa theo là Triết lý của phát triển phần mềm. Ở bài viết sau mình sẽ trình bày về các kỹ thuật cụ thể hơn, tuy nhiên vẫn không thể cụ thể như cuốn Clean code được. Cá nhân mình thấy việc trừu tượng có cái hay, vì nó có thể áp dụng được nhiều công nghệ, nhiều ngôn ngữ lập trình khác nhau. Cuối series này chắc chắn sẽ có tổng kết các lời khuyên và các red flag. Mong bạn tiếp tục theo dõi và góp ý.

Noiceeeeee

Hóng phần 2, hay quá bác ơi🙆

Anh @vigov5 ơi anh xem xét thêm hint 1 số bài lâu không có thêm bạn giải đi ạ , bí quá .

Hội chứng classitis theo mình là điều không thể tránh khỏi. Nó đến từ 3 nguyên nhân:

• Thiết kế rất trong trẻo, nhưng thực tế code phải cụ thể hóa hơn rất nhiều. Hay nói cách khác, là thiết kế quá nông.
• Trong quá trình phát triển thì cực kì thiếu con người có khả năng review và update lại thiết kế. Code thì chỉ biết tuân theo thiết kế, có gì phát sinh là đẻ ra thêm class mới, function mới, easy mà chẳng đụng chạm đến ai. Mà thiết kế thì họ ko kiểm soát được việc code nảy nở ra thêm như thế nào.
• Dự án có thể chia cho nhiều người, hoặc cắt nhỏ thành nhiều team. Mỗi team sẽ viết thêm code để phục vụ mục đích cho bên mình mà ko cần thảo luận với bên kia. Do đó chắc chắn sẽ gặp rất nhiều code thừa, code lặp, hoặc ý tưởng thì giống nhau nhưng code của mỗi team lại thêm mắm thêm muối, ko dùng chung của nhau được.
• (cái này là phụ thôi, nhưng cũng khá nghiêm trọng) Tâm lí con người luôn muốn tránh đụng chạm và bản thân mình hay team mình về đích trước. Cha chung ko ai khóc mà. Thiết kế mà đẹp ngay từ đầu thật là một điều không tưởng.

Phải chăng tác giả đang chê triết lí thiết kế của Oracle Đúng vậy, lúc mình bắt đầu học sâu hơn về Java thì thực sự rối trí bởi nó có quá nhiều lớp, chả biết dùng như thế nào là chuẩn mực. Nếu chỉ dùng Java code web api thôi thì ít đụng chạm đến vấn đề này hơn. Chứ để làm app desktop hay làm game mà ko biết vận dụng các lớp nâng cao của Java thì chương trình rất kém về hiệu suất. Thực ra mình ko chuyên backend nên nếu nói có gì sai, anh em vặn lại giùm ạ