Tại sao tôi nên đọc cái này?

Để hiểu rõ hơn về cái giá thực tế và chết người của sự phức tạp. Bằng cách chú ý đến nhận thức thiên vị của chúng ta về cả sự đơn giản và phức tạp. Và cũng bằng cách lập mô hình phức tạp để khám phá một số đặc điểm của nó. Chủ yếu đó là bản chất theo cấp số nhân.

quy tắc đơn giản

Theo tôi, đơn giản là nguyên tắc quan trọng nhất của phát triển phần mềm. Đây, tôi đã nói rồi. Nó đơn giản mà :)

Bạn có nghĩ như vậy? Hãy để tôi nói cho bạn biết tại sao tôi tin điều đó.

Hai mặt của một đồng xu

Sự đơn giản bị đánh giá thấp

Chúng ta thường không nhìn thấy vẻ đẹp tiềm ẩn của sự đơn giản. Như thể chúng ta coi đó là điều hiển nhiên. Rất dễ bỏ lỡ sự khéo léo mà nó giới thiệu. Điều này là do một giải pháp đơn giản là rõ ràng để giải thích và hiểu nhưng thường không khám phá ra. Thật khó để tự hào về một cái gì đó mà một khi giải thích, có vẻ tầm thường. Ngay cả khi nó có thể đòi hỏi một nỗ lực to lớn để khám phá. Rốt cuộc, mọi người thường đánh giá kết quả chứ không phải cách để đạt được chúng. Nhưng để hiểu rõ hơn về giá trị của sự đơn giản, chúng ta cần nhìn nó theo cách khác. Xin chào, sự phức tạp.

Chi phí thực của sự phức tạp

Tôi tranh luận rằng sự phức tạp là một căn bệnh. Một căn bệnh chết người. Nó đã được thêm vào với liều lượng nhỏ bởi mỗi quyết định của chúng tôi. Chậm nhưng chắc chắn những thứ này có tác động tích lũy lên cơ thể mà chúng xâm nhập. Tốc độ thay đổi chậm lại như thể những trọng lượng vô hình đang được đặt thêm vào chân của người chạy. Cuối cùng, nó thậm chí có thể đạt đến sự đình trệ hoàn toàn. Trong những trường hợp xấu nhất, một sự can thiệp đau đớn (chẳng hạn như viết lại) là cách duy nhất để tiến lên phía trước.

Sự phức tạp được ngưỡng mộ

Tại sao kịch bản này rất phổ biến? Để trả lời câu hỏi này, chúng ta cần hiểu rằng chúng ta thiên về sự phức tạp. Điều này là do chúng ta được dạy để đánh giá cao sự phức tạp. Lấy Đại kim tự tháp Giza làm ví dụ điển hình. Nó được coi là thành viên đứng cuối cùng trong Bảy kỳ quan của thế giới cổ đại. Một tòa nhà đáng chú ý và ấn tượng. Nhưng nói thẳng ra, đó chỉ là một ngôi mộ. Pharaoh chỉ đơn giản là cần một nơi để được chôn cất. Giả sử rằng đây là ý định của anh ấy từ tòa nhà (bỏ qua động cơ tôn giáo hoặc chính trị). Sau đó, một ngôi mộ đơn giản sẽ là đủ. Một cái gì đó tương tự như những gì nguyên thủ quốc gia nhận được những ngày này. Tuy nhiên, chúng tôi ngưỡng mộ tòa nhà và sự phức tạp của nó. Chúng tôi không coi đó là sự lãng phí tài nguyên lẽ ra có thể được đầu tư vào nơi khác.

Và đây là một sự trớ trêu lớn:

Chúng ta ngưỡng mộ sự phức tạp và tránh sự đơn giản, trong khi chúng ta nên ngưỡng mộ sự đơn giản và tránh sự phức tạp.

Độ phức tạp của mô hình

Bạn có thể ước tính tác động của sự phức tạp? Nó làm gì với hệ thống hoặc tổ chức của bạn? Có lẽ nó cảm thấy rằng nó quá trừu tượng để tiếp cận chủ đề này. Hãy xem liệu chúng ta có thể cùng nhau phân tích chi phí tiềm ẩn của sự phức tạp và cách chống lại nó hay không.

Chúng ta cần xây dựng cho mình một mô hình tinh thần sẽ định hình kẻ thù khó nắm bắt này. Điều này sẽ đóng vai trò là nền tảng trong cách tiếp cận của chúng tôi đối với sự phức tạp.

chuỗi phức tạp

Bất kỳ chuỗi nào được xây dựng bằng cách kết nối các liên kết. Hãy lấy ví dụ về một hệ thống ngẫu nhiên của công ty phần mềm và cố gắng mô tả nó bằng các chuỗi. Các liên kết sẽ là các thành phần hệ thống (ví dụ: microservices). Một chuỗi sẽ bao gồm các thành phần hệ thống được ghép nối trong bất kỳ mối quan hệ có ý nghĩa nào (ví dụ: các dịch vụ siêu nhỏ giao tiếp với nhau). Sau đó, hệ thống có thể được biểu diễn dưới dạng một tập hợp các chuỗi. Đó là nó, đủ với các định nghĩa.

Hãy xem một ví dụ cụ thể. Giả sử chúng ta có hai dịch vụ siêu nhỏ giao tiếp với nhau. Họ là cả hai liên kết trong chuỗi của chúng tôi. Ngoài ra, chúng chạy trên một nhà cung cấp đám mây. Nhà cung cấp đám mây là một liên kết khác. Và cuối cùng, các dịch vụ được triển khai bằng cách sử dụng một số cơ sở hạ tầng CI/CD đơn lẻ. Tuy nhiên, một liên kết khác. Bây giờ chúng tôi đã mô tả một chuỗi gồm bốn mắt xích. Càng xa càng tốt.

Sự phức tạp sẽ ảnh hưởng nặng nề đến bạn khi các liên kết bắt đầu có nhiều hơn một trạng thái. Ví dụ: giả sử một trong các vi dịch vụ đang được di chuyển sang phiên bản chính mới (ví dụ: có các thay đổi đột phá trong API). Trong quá trình di chuyển, liên kết đó sẽ đồng thời có hai trạng thái. Như thể chuỗi của chúng tôi chia thành hai “ chuỗi ma ”. Hơn nữa, nếu chúng tôi hỗ trợ kiến ​​trúc nhiều đám mây và có 2 nhà cung cấp đám mây khác nhau thì một liên kết khác có nhiều hơn một trạng thái. Nhưng bây giờ chuỗi ban đầu của chúng tôi đã được chuyển đổi thành 4 chuỗi ảo. Đồng thời, nhóm cơ sở hạ tầng bắt đầu thử nghiệm A/B cơ sở hạ tầng CI/CD. 4 nhân đôi thành 8. Con số này tăng theo cấp số nhân.

Giờ đây, trường hợp cạnh dẫn đến lỗi hệ thống chỉ có thể được kích hoạt ở một trong các chuỗi ảo. Ví dụ: một lỗi được kích hoạt bởi một lệnh gọi API tới vi dịch vụ mới được di chuyển. Nhưng chỉ khi nó được triển khai bằng cơ sở hạ tầng mới trên đám mây đầu tiên. Các sân khấu được thiết lập. Và đoán xem, nó xảy ra vào khoảng 2 giờ sáng, đánh thức kỹ sư trực. Dẫn đến một khám nghiệm tử thi khác .

Bạn càng có nhiều chuỗi và chúng càng dài thì nguy cơ bùng nổ chuỗi ma theo cấp số nhân càng tăng.

Hãy chú ý một số hành vi thú vị phát sinh từ mô hình này:

1. Tác động phức tạp - Việc thêm cùng một mức độ phức tạp vào một hệ thống phức tạp sẽ mang lại tác động cao hơn so với một hệ thống đơn giản. Điều này là do yếu tố phức tạp theo cấp số nhân.
2. Nghịch lý về độ phức tạp - Nỗ lực giảm độ phức tạp về lâu dài có thể sẽ làm tăng độ phức tạp trong thời gian ngắn. Điều này là do việc thực hiện các thay đổi liên quan đến việc di chuyển sẽ thêm nhiều trạng thái hơn vào các liên kết của chuỗi hiện có (hiển thị trong ví dụ trên). Điều này có thể tạo ra cảm giác giữa mọi người rằng những nỗ lực của chúng tôi nhằm giảm bớt sự phức tạp đang thất bại trong khi thực tế không phải như vậy.

Trong bài đăng này, tôi đã đề cập đến một loại phức tạp. Tuy nhiên, sự phức tạp có thể có nhiều hình dạng và hình thức khác nhau. Liệt kê một số:

1. Độ phức tạp của hệ thống - Như chúng tôi đã mô tả ở trên. Sự phức tạp của các thành phần hệ thống và tương tác của chúng.
2. Độ phức tạp của sản phẩm - Từ sản phẩm đến dịch vụ. Chia nhỏ nó thành các tính năng, UX, luồng và tương tác của chúng.
3. Sự phức tạp của tổ chức - Từ cơ cấu tổ chức đến các quy trình và quản trị của nó.
4. Độ phức tạp của mã - Không chỉ là các định nghĩa về thời gian và bộ nhớ cổ điển của khoa học máy tính. Nhưng cũng có những khía cạnh khác như mã sạch.

Cái gì tiếp theo?

Trong bài đăng tiếp theo của tôi, chúng tôi thảo luận về một số đặc điểm phức tạp bổ sung:

Nhảy xuống hố thỏ phức tạp

Phần kết luận

Tóm lược

Sự phức tạp thường được mọi người ngưỡng mộ. Tuy nhiên, chúng ta thường bỏ lỡ rằng nó cũng có một mặt chết người. Chúng ta thường không nhìn thấy chi phí của nó cho đến khi quá muộn, chủ yếu vì nó là một khái niệm trừu tượng và khó nắm bắt. Sự phức tạp của mô hình hóa và tính chất cấp số nhân của nó cho phép chúng ta nhận thức được những mối nguy hiểm phía trước. Nhấn mạnh tầm quan trọng cốt yếu của sự đơn giản.

Bớt tư tưởng

Một lưu ý phụ về mô hình tinh thần của các chuỗi phức tạp: Một mô hình tốt hơn có thể sẽ là một biểu đồ (mô hình khoa học máy tính cổ điển). Trong đó mỗi thành phần hệ thống là một nút/đỉnh. Một cạnh giữa các nút đánh dấu rằng các thành phần hệ thống đó được kết nối trong một số mối quan hệ. Sau đó, các chuỗi của chúng tôi từ ví dụ trước sẽ là các cụm trong biểu đồ. Nhưng điều này chỉ là quá phức tạp. Ý tưởng chính của tôi trong bài đăng này là thuyết giảng về sự đơn giản, không xây dựng một mô hình chính xác cho sự phức tạp. Nó đúng cho các hệ thống cũng như cho các bài đăng trên blog. Hy vọng rằng một mô hình đơn giản nhưng không chính xác sẽ giúp củng cố thông điệp rút ra. Độ phức tạp có tính chất cấp số nhân. Hãy nhận biết sự nguy hiểm mà nó gây ra.

Sự nhìn nhận

Rất cám ơn Pol Miro Omella , Yanai Ron , Nimrod Shai và Roy Green vì những đánh giá và nhận xét sâu sắc của họ.