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 ý.
THẢO LUẬN
Anh có một câu hỏi, vậy nguyên nhân căn bản của tất cả issues trên là gì ? tức là root cause của database bottleneck là gì ?
đúng r bác
Cảm ơn bạn, bạn thấy website này thế nào ạ http://phuongtanthanh.gov.vn/kien-thuc-ky-nang/top-16-cong-ty-thiet-ke-website-cho-doanh-nghiep-264.html
Cảm ơn bạn vì bài chia sẻ chi tiết này
Cái này làm sao để điều khiển phím tổ hợp crtl c vầy mn
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 ý.