Những ý tưởng hệ thống gần như không hoạt động

Những ý tưởng hệ thống gần như không hoạt động

• "Hãy làm cho nó có thể mở rộng bằng plugin"

  • Ý tưởng là khi một cách triển khai nào đó không hoạt động, các nhà phát triển có thể dễ dàng thêm một cách triển khai mới. Tuy nhiên, trong hầu hết trường hợp, tính năng do API cung cấp không hoạt động dễ dàng như mong đợi. Để có khả năng plugin thực sự, cách triển khai thứ hai cần được thiết kế cùng từ đầu.

• "Hãy thêm API"

  • Khi xây dựng nền tảng và thu hút nhà phát triển, người ta thường thêm API. Nhưng cung cấp API đòi hỏi nỗ lực liên tục để đảm bảo tương thích và khả năng tương tác, và việc cung cấp API không có nghĩa là chắc chắn sẽ có người dùng. Việc xây nền tảng là một công việc kinh doanh nghiêm túc, và chỉ cung cấp API thì khó có thể tạo ra cơ sở kinh tế.

• "Hãy trừu tượng hóa thêm một lần nữa"

  • Có câu nói rằng vấn đề trong khoa học máy tính có thể giải quyết bằng mức độ gián tiếp hóa khác. Nhưng trừu tượng hóa quá sớm có thể gây khó khăn cho bảo trì, bảo mật và tối ưu hiệu năng. Một cấp trừu tượng được thêm vào khi chưa có kế hoạch sẽ làm bảo trì mã trở nên khó khăn.

• "Hãy bất đồng bộ hóa"

  • Bất đồng bộ hóa đã là chủ đề nghiên cứu lâu dài trong khoa học máy tính. Các web framework đã trừu tượng hóa tốt phần này, nhưng khi cố gắng quản lý bất đồng bộ trực tiếp bên ngoài framework, khả năng phát sinh lỗi khó dự đoán sẽ cao hơn.

• "Hãy làm kiểm soát truy cập sau"

  • Bảo mật hệ thống phải được xem xét từ đầu, nhưng thường bị đẩy sang sau vì áp lực đẩy nhanh tốc độ ra mắt sản phẩm. Nếu không nghĩ đến kiểm soát truy cập từ đầu với góc nhìn của cả khách hàng và kẻ tấn công, khả năng phải thiết kế lại sản phẩm sau này là rất cao.

• "Hãy đồng bộ dữ liệu"

  • Đồng bộ dữ liệu là một vấn đề rất khó với nhiều thách thức phải giải quyết thông qua kinh nghiệm. Xây dựng giải pháp dựa trên đồng bộ dữ liệu gần như không phải phương án tốt.

• "Hãy làm đa nền tảng"

  • Phát triển đa nền tảng giống như xây dựng hệ điều hành, nhà cung cấp đám mây hoặc trình duyệt. Việc này có thể hoạt động khi nền tảng còn mới hoặc ứng dụng còn đơn giản, nhưng theo thời gian nó sẽ ngày càng khó hơn.

• "Hãy cho phép thoát ra native"

  • Khi đa nền tảng có giới hạn, việc cho phép thoát ra các tính năng native thường là cần thiết. Nhưng cách này có thể xung đột với trạng thái mà framework đang duy trì, nên 9 trong 10 trường hợp sẽ thất bại.

• Kết luận

  • Những cách tiếp cận này không phải lúc nào cũng thất bại, nhưng trong đa số trường hợp thì có lựa chọn tốt hơn. Việc giải quyết vấn đề theo nguyên tắc nền tảng và tránh những mẫu phần mềm có xác suất thất bại cao là rất quan trọng.

[ndrgrd]

Trong trường hợp Plug, việc thiết kế interface bằng cách lọc ra tối đa các hành vi bắt buộc là quan trọng nhất.
Nếu xây dựng interface chỉ bằng cách bê nguyên cấu trúc từ code hiện tại thì tất nhiên nó sẽ trở thành một interface không cần thiết và bị ràng buộc bởi implementation đó, nhưng tình huống này thực sự xảy ra rất nhiều...

[GN⁺]

Ý kiến Hacker News

• DSL và API thường hoạt động hiệu quả. Các công cụ suy luận như TensorFlow cũng có thể được coi là một DSL hoặc API bao bọc DSL

  • SQL, ngôn ngữ Shader, BPF... cũng là các ví dụ tương tự
  • Cách tiếp cận "chỉ cần thêm API" có thể không thành công. Cần tiếp cận cẩn trọng và kỹ lưỡng như khi xây dựng UI

• DSLs đôi khi hoạt động rất tốt. Có thể tham khảo jOOQ.org

• Elastic Load Balancer là một vòng lặp điều khiển phản hồi tải. Đây là một loại sản phẩm

• Việc thiếu tài nguyên phổ biến ở hầu hết các ngành. Có thể tham khảo erikbern.com và "Goal: Process of Ongoing Improvement"

• Phát hiện bất thường không phải là vấn đề của hệ thống phân tán, nhưng những người từng gặp vấn đề có thể cho rằng nó là cần thiết

  • Thuật toán Isolation Forest đôi khi có tác dụng kỳ diệu. Năm 2018, họ đã đạt kết quả tốt khi sử dụng embedding dựa trên CNN cho văn bản

• Từ "gần như" không hiệu quả trong bối cảnh này. Nó chỉ là sự bi quan và châm biếm

• Nhiều người cố gắng tìm một hàm quyết định tinh vi cho trường hợp ngoại lệ, nhưng thực tế rất đơn giản: khi tôi làm thì ổn, khi người trước đó làm thì không ổn

• "Domain Driven Design" là thiết kế ứng dụng theo cấu trúc nghiệp vụ, đây là công thức cho thảm họa

  • Trong doanh nghiệp nhỏ có thể không có vấn đề, nhưng với doanh nghiệp thành công hoặc đang tăng trưởng sẽ nhanh chóng hối hận
  • Thay vào đó hãy thiết kế theo tầng chức năng, giữ logic nghiệp vụ, các hàng cơ sở dữ liệu và luồng công việc của người dùng càng nhiều càng tốt

• Vòng lặp điều khiển phản hồi tải là một thành phần cơ bản và thiết yếu. Nó được dùng trong nhiều hệ thống

• Đã làm việc trên nhiều dự án dùng nhiều DSL, cache P2P, và song song lai; hầu hết đều thành công

  • Cache P2P không cần thiết và do đó không tạo ra kết quả lớn
  • Nó phức tạp, nhưng độ phức tạp đó mang lại các tính năng khó đạt được theo cách khác

• Cách tiếp cận "chỉ cần đồng bộ hóa dữ liệu" có thể gây ra vấn đề

  • Nhiều hệ thống được thiết kế để đạt "quy mô Internet", nhưng thực tế nhỏ hơn rất nhiều
  • Những nhóm như vậy có thể ngây thơ, hoặc tệ hơn là dùng tiền để giải quyết vấn đề bằng cách huy động các quản lý không phải kỹ thuật

• Đã thành công trong việc triển khai nhiều ý tưởng. Vì vậy nghe có vẻ hơi lạ