Helpex - Trao đổi & giúp đỡ Đăng nhập

Đánh giá sách: Kiến trúc sạch của Robert C. Martin

Chú Bob đã trở lại! Cuốn sách mới nhất của anh ấy, Clean Architecture , đã được phát hành cách đây khoảng một tháng và nó có nghĩa là sẽ nâng các kỹ năng kỹ thuật phần mềm của bạn lên một tầm cao hơn nữa. Bỏ xa tất cả các chi tiết cấp thấp, cuốn sách mới nhất tập trung tối đa vào nghệ thuật kiến ​​trúc phần mềm và cố gắng đưa ra các nguyên tắc để tạo ra các dự án thành công, lâu dài trong bất kỳ loại môi trường nào, tại bất kỳ thời điểm nào (yep , có thật không!).

Giới thiệu

Cuốn sách bắt đầu bằng một lời giới thiệu nhẹ nhàng về chủ đề kiến ​​trúc. Thay vì cơn bão thông thường xuất hiện trong các văn bản kiến ​​trúc phần mềm, Uncle Bob đưa ra một mục tiêu thực dụng, không quá gợi cảm:

“Mục tiêu của kiến ​​trúc phần mềm là giảm thiểu nguồn nhân lực cần thiết để xây dựng và duy trì hệ thống cần thiết.”

Nếu bạn đã đọc một số văn bản trước đây của Martin, bạn sẽ không ngạc nhiên rằng cách để đạt được mục tiêu là giữ cho cơ sở mã sạch, chỉ lần này, chúng ta đang nói về kiến ​​trúc phần mềm.

Điều này, rõ ràng, có thể khiến chúng tôi gặp khó khăn với những người muốn phần mềm kiếm tiền “ngay tại đây, ngay bây giờ”. Đây là thực tế của việc trở thành một kiến ​​trúc sư phần mềm: Đó là một cuộc đấu tranh!

Bắt đầu với những viên gạch

Phần tiếp theo của cuốn sách đề cập đến chủ đề về các mô hình lập trình và sự tiến hóa được cho là của chúng. Rốt cuộc, làm thế nào chúng ta có thể nói về bất kỳ loại quy tắc hoặc nguyên tắc cấp cao nào trong một ngành phát triển nhanh như kỹ thuật phần mềm?

Quan điểm mà Uncle Bob trình bày là lĩnh vực kỹ thuật phần mềm đã không phát triển nhiều trong suốt 70 năm qua. Đúng, chúng tôi có máy tính nhanh hơn, nhiều công cụ hơn, ngôn ngữ mới, v.v., nhưng những ý tưởng cốt lõi vẫn như cũ. Bất kỳ sự “tiến hóa” lớn nào ở cấp độ mô hình đều có thể được trình bày như một hạn chế áp đặt cho mô hình trước đó, vì vậy chúng tôi thực sự đang đối phó với ít gánh nặng hơn so với những người tiền nhiệm.

“Phần mềm - thứ của các chương trình máy tính - bao gồm trình tự, lựa chọn, lặp lại và chuyển hướng. Chỉ có bấy nhiêu thôi. Không hơn không kém. ”

Nguyên tắc thiết kế

Trong phần thứ ba của cuốn sách, Martin mời chúng ta tìm hiểu sâu hơn về các nguyên tắc RẮN. Thay vì coi chúng như một loạt các mẹo thiết kế cấp độ lớp, anh ấy tiếp tục khai thác những kiến ​​thức chung mà chúng mang theo và giải thích cách áp dụng nó vào kiến ​​trúc phần mềm.

Nguyên tắc trách nhiệm duy nhất yêu cầu chúng ta xem xét trục thay đổi khác nhau trong cơ sở mã để một đoạn mã duy nhất có trách nhiệm đáp ứng nhu cầu của một tác nhân duy nhất.

Nguyên tắc Mở / Đóng giúp chúng tôi tạo ra một hệ thống phân cấp các thành phần trong đó các thành phần cấp thấp hơn trở thành phần bổ trợ cho các chính sách cấp cao.

Nguyên tắc thay thế của Liskov một lần nữa cảnh báo chúng ta về hậu quả của khả năng thay thế một phần mô-đun.

Nguyên tắc Phân tách Giao diện biến thành một quy tắc không phụ thuộc vào những thứ mà chúng ta không sử dụng, không chỉ ở cấp độ “giao diện” của mã.

Và cuối cùng, nguyên tắc đảo ngược phụ thuộc trở thành quy tắc phụ thuộc , là xương sống của toàn bộ khái niệm Kiến trúc sạch.

Nguyên tắc thành phần

Sau khi rời xa các nguyên tắc và thiết kế cấp lớp, chúng ta cần một khối xây dựng phù hợp hơn cho nhu cầu của kiến ​​trúc phần mềm. Để chống lại xu hướng hiện tại của vi-container-phân phối tự động, Uncle Bob gọi những thành phần này chỉ đơn giản là các thành phần , được định nghĩa đơn giản là "đơn vị triển khai".

Phần quan trọng của các thành phần trở thành đơn vị triển khai hiệu quả là chúng ta cần phải cẩn thận hơn khi quyết định điều gì làm được và điều gì không đi vào bên trong một đơn vị. Sự gắn kết và kết hợp không còn là “làm một việc” hay “trộn mọi thứ với nhau”. Có một sự căng thẳng giữa các loại lợi ích khác nhau đạt được bằng các loại tách biệt khác nhau.

Mức độ chi tiết của các bản phát hành, khả năng tái sử dụng mã, tính ổn định của mã và tính trừu tượng và những chủ đề khác là chủ đề chính của phần này, cùng với các quy tắc giúp chúng tôi tận dụng tối đa: Nguyên tắc liên kết thành phần và nguyên tắc ghép nối.

Ngành kiến ​​trúc

Khoảng nửa cuốn sách, cuối cùng chúng ta cũng đến phần kiến ​​trúc-kiến trúc. Từ thời điểm này cho đến cuối cuốn sách, hầu như tất cả đều xoay quanh hai chủ đề bổ sung: chính sách cấp cao so với chi tiết cấp thấp và ranh giới bản vẽ.

Nếu bạn đã đọc bất cứ điều gì về Clean Architecture trước đây, sẽ không có bất kỳ điều gì ngạc nhiên ở đây. Các quy tắc kinh doanh của doanh nghiệp không nên phụ thuộc vào các trường hợp sử dụng của người dùng. Các trường hợp sử dụng không được phụ thuộc vào giao diện người dùng, cơ sở dữ liệu, v.v. Dù bạn làm gì, hãy tuân theo quy tắc phụ thuộc bằng cách giới thiệu ranh giới giữa các loại khối xây dựng khác nhau.

Bên cạnh khái niệm Kiến trúc sạch, phần này còn bao gồm chi tiết nhiều chủ đề khác nhau: cách vẽ ranh giới, các cách khác nhau để tách và thực thi ranh giới, mối quan hệ giữa các lớp, ranh giới, kiểm tra, v.v.

Theo ý kiến ​​của tôi, đây là phần "nóng nhất" và thú vị nhất của cuốn sách, vì vậy tôi sẽ không đưa ra thêm những điều hư hỏng ở đây. Hãy đọc cuốn sách, nếu bạn quan tâm!

Chi tiết

Phần cuối trông giống như một sự pha trộn của nhiều thứ không phù hợp với các phần trước của cuốn sách. Và do đó, chúng tôi nhận được một vài chương nữa về cơ sở dữ liệu, web và khuôn khổ là chi tiết cấp thấp (nếu bạn chưa chuyển đổi vào thời điểm đó), một nghiên cứu điển hình rất ngắn và một chương khách mời của Simon Brown.

Quan điểm của tôi

Cho đến nay, tôi đã cố gắng hết sức để cung cấp cho bạn một mô tả khách quan về những gì được đề cập trong cuốn sách và những hướng suy nghĩ nào được thực hiện ở đây và ở đó. Điều này nhằm khơi gợi sự quan tâm của bạn và nâng cao kỳ vọng của bạn nếu bạn chưa đọc cuốn sách. Bây giờ tôi sẽ cung cấp cho bạn một loạt các suy nghĩ hoàn toàn chủ quan, mà bạn hoàn toàn có thể bỏ qua hoặc không đồng ý.

Tôi không thích cuốn sách.

Tôi ghét phải nói ra, nhưng tôi thực sự thất vọng khi đọc xong. Đừng hiểu lầm tôi. Tôi đã rất hy vọng vào cuốn sách. Tôi đã đặt hàng trước nó ngay khi lần đầu tiên tôi thấy nó có sẵn trên Amazon và sau đó đọc nó trên Safari vì tôi không muốn đợi bản sao vật lý đến. Vì vậy, ý kiến ​​của tôi không xuất phát từ bất kỳ loại thành kiến ​​tiêu cực chung nào đối với Uncle Bob hoặc chủ đề Clean Architecture.

Vấn đề đầu tiên của tôi với cuốn sách là nó không chứa nhiều hơn những gì bạn có thể tìm thấy trong những lời dạy khác của Uncle Bob, như các bài báo hoặc video. Mặc dù hình thức một cuốn sách chắc chắn là một cách tốt để sắp xếp thông tin với nhau và trình bày nó như một tổng thể gắn kết, nhưng việc thiếu tính mới có phần gây thất vọng cho một người hâm mộ Uncle Bob lâu năm.

Vấn đề thứ hai, một chút liên quan đến vấn đề đầu tiên, là, theo ý kiến ​​của tôi, nó chứa rất nhiều tiếng ồn không cần thiết. Toàn bộ việc đi qua các mô hình và nhắc lại các nguyên tắc SOLID lần thứ một triệu có vẻ không phải là điều cần thiết đối với tôi. Nếu cuốn sách có số trang hạn chế, thì những chương này sẽ là thứ để tôi vứt bỏ.

Vấn đề thứ ba, và có lẽ là lớn nhất, mà tôi gặp phải là cuốn sách cảm thấy rất xa rời thực tế hàng ngày của một nhà phát triển phần mềm. Có, nó cho bạn biết rằng bạn nên giữ cơ sở dữ liệu, khuôn khổ và những thứ khác trong tầm tay. Có, nó cho bạn biết bạn có thể thấy những loại cấp độ nào trong mã của mình và cách thức hoạt động của quy tắc phụ thuộc giữa chúng. Nhưng hầu như không có thông tin nào về “cách thức” của ý tưởng đó. Và theo kinh nghiệm của tôi, cách thức của Kiến trúc sạch là phần khó đối với những lập trình viên sạch đầy tham vọng. Những gì chúng tôi nhận được ở đây là một nghiên cứu điển hình siêu nhỏ, rất cơ bản mà tôi thấy khó hiểu hơn là hữu ích.

Bằng cách nào đó, tiếp tục chủ đề về sự mất kết nối, cuốn sách cũng gần như không đề cập đến các ý tưởng thịnh hành khác trong phát triển phần mềm như DDD, tìm nguồn cung ứng sự kiện, microservices, v.v. Vâng, hai điều sau được đề cập trong một vài câu, nhưng điều đó không giúp ích được gì cho mọi người. để ánh xạ các ý tưởng cho nhau và giúp họ kết hợp hầu hết mọi thứ với nhau. Có vẻ như mọi thứ “quan trọng” là nội dung cuốn sách có ý nghĩa với nhau. Phần còn lại của thế giới không quan trọng.

Phần kết luận

Bây giờ, tôi đã trình bày những điều khách quan và chủ quan về cuốn sách, đến lượt bạn quyết định xem có nên đầu tư thời gian và đọc nó hay không. Đề nghị của tôi là những người chưa đọc hoặc xem nhiều Uncle Bob chắc chắn nên đọc nó. Bạn sẽ tìm thấy một cách tốt, gắn kết để suy nghĩ về phát triển phần mềm. Mặt khác, nếu bạn là một người hâm mộ Uncle Bob lâu năm (và bằng cách nào đó mà bây giờ vẫn chưa đọc?!), Bạn có thể thêm nó vào danh sách đọc của mình. Không có gì ở đó mà bạn phải đọc ngay tại đây, ngay bây giờ.

10 hữu ích 0 bình luận 16k xem chia sẻ

Có thể bạn quan tâm

loading