Dù sự đơn giản có nhiều lợi thế, đáng tiếc là thực tế sự phức tạp lại dễ bán hơn (2022)
(eugeneyan.com)- Đằng sau việc các phương pháp đơn giản bị đánh giá thấp trong phản biện bài báo hay xét thăng chức là thiên kiến phức tạp, vì sản phẩm phức tạp trông như chứa đựng nhiều nỗ lực, kỹ năng và đổi mới hơn
- Các hệ thống có nhiều lựa chọn và thành phần trông có vẻ linh hoạt, nhưng trong vận hành thực tế, việc giải thích, kiểm thử và khắc phục sự cố trở nên khó hơn, đồng thời sai sót và kém hiệu quả có thể tăng lên
- Ý tưởng và hệ thống đơn giản dễ hiểu, dễ dùng, dễ nhận phản hồi và dễ mở rộng; khi được mua lại năm 2012, Instagram phục vụ hàng chục triệu người dùng với đội ngũ 13 người, đồng thời vẫn duy trì các công nghệ đã được kiểm chứng như PostgreSQL và Redis
- Trong machine learning, kỹ thuật phức tạp không phải lúc nào cũng vượt trội; trên 45 bộ dữ liệu dạng bảng quy mô trung bình, mô hình dựa trên cây tốt hơn mạng nơ-ron sâu, và trong gợi ý/tìm kiếm có trường hợp tích vô hướng (dot product) tốt hơn neural collaborative filtering
- Nếu thưởng cho bản thân sự phức tạp, ta sẽ nuôi dưỡng xu hướng làm phức tạp không cần thiết và khuynh hướng not invented here; vì vậy, với vấn đề càng phức tạp, trước hết càng phải cân nhắc liệu có giải pháp đơn giản hay không và chi phí của sự phức tạp có xứng đáng không
Vì sao sự phức tạp trông hấp dẫn hơn
- Sự phức tạp dễ được xem là tín hiệu của nỗ lực
- Những bài báo có nhiều ý tưởng khó và chi tiết kỹ thuật thường trông như đã tiêu tốn nhiều thời gian và công sức
- Hệ thống có nhiều thành phần và tính năng dễ được đánh giá là sản phẩm được đầu tư công phu hơn các hệ thống nhỏ hơn
- Ấn tượng rằng thứ gì đó khó làm ra sẽ vận hành như một tín hiệu về giá trị và chất lượng
- Nó cũng được diễn giải là tín hiệu của kỹ năng
- Một hệ thống có nhiều bộ phận chuyển động tạo ấn tượng rằng người thiết kế có năng lực hiểu và tích hợp từng phần
- Bài báo có nhiều thuật ngữ chuyên môn và chứng minh tuy khó tiếp cận, nhưng lại trông như thể thể hiện chuyên môn sâu về chủ đề
- Thực hành hỏi trong phỏng vấn các thuật toán và cấu trúc dữ liệu hầu như không dùng trong công việc thực tế cũng liên quan đến tín hiệu kiểu này
- Cũng có nhận thức rằng đó là tín hiệu của đổi mới
- Bài báo tạo ra một kiến trúc mô hình hoàn toàn mới dễ được đánh giá là mới mẻ hơn bài báo chỉ sửa đổi mạng hiện có
- Hệ thống có nhiều thành phần được xây từ đầu trông độc đáo hơn hệ thống tái sử dụng các bộ phận sẵn có
- Nhận xét “chỉ thay đổi một thứ, còn lại giống nghiên cứu trước” có thể làm giảm giá trị của một ý tưởng đơn giản
- Càng nhiều tính năng, càng dễ tạo ảo giác rằng nó bao quát hơn
- Một hệ thống hỗ trợ cả kho dữ liệu SQL lẫn NoSQL, hoặc cho phép cả pipeline batch lẫn streaming, trông như thể xử lý được mọi trường hợp
- Người ta cho rằng càng nhiều khối Lego thì càng có thể ứng phó tốt hơn với thay đổi
- Những phán đoán như vậy dẫn đến complexity bias, tức thiên vị quá mức cho thứ phức tạp so với ý tưởng và hệ thống đơn giản
Những điểm mà sự đơn giản trở thành lợi thế thực sự
- Ý tưởng và tính năng đơn giản dễ hiểu và dễ sử dụng
- Khả năng được chấp nhận và tác động thực tế tăng lên
- Cũng dễ truyền đạt và nhận phản hồi hơn
- Hệ thống phức tạp khó giải thích và quản lý, khiến người dùng khó nắm được phải làm gì và làm như thế nào
- Nếu có quá nhiều mục cần điều chỉnh, sai sót sẽ tăng; nếu có quá nhiều bước, sự kém hiệu quả sẽ xuất hiện
- Hệ thống đơn giản dễ xây dựng và mở rộng
- Ít thành phần hơn giúp việc triển khai dễ hơn
- Dùng công nghệ chuẩn hóa, có sẵn giúp dễ tìm người triển khai và bảo trì
- Mã nguồn và tương tác nội bộ giảm, nên gánh nặng hiểu và kiểm thử cũng thấp hơn
- Hệ thống phức tạp không cần thiết khiến việc xây dựng tốn nhiều thời gian và tài nguyên hơn, tạo ra lãng phí
- Trường hợp Instagram cho thấy lợi thế của lựa chọn công nghệ đơn giản
- Khi được mua lại năm 2012, Instagram phục vụ hàng chục triệu người dùng với đội ngũ 13 người
- Thay vì công nghệ mới theo trào lưu, họ duy trì công nghệ đã được kiểm chứng để giảm gánh nặng vận hành trên mỗi kỹ sư
- Khi các startup khác đưa vào các kho dữ liệu NoSQL đang thịnh hành rồi gặp khó khăn, Instagram dùng PostgreSQL và Redis dễ hiểu
Chi phí vận hành và khả năng bảo trì
- Triển khai hệ thống không phải là điểm kết thúc mà là điểm bắt đầu
- Phần lớn nỗ lực phát sinh sau khi đưa vào production
- Việc vận hành nhiều khả năng sẽ do người khác, không phải đội ban đầu tạo ra hệ thống, đảm nhận
- Hệ thống đơn giản có thể giảm chi phí bảo trì và kéo dài tuổi thọ
- Càng ít bộ phận chuyển động, hệ thống càng đáng tin cậy và dễ sửa
- Số phần có thể hỏng giảm xuống
- Ít tương tác nội bộ hơn nên dễ nâng cấp hoặc thay thế từng thành phần riêng lẻ
- Hệ thống phức tạp có nhiều thành phần mà một đội giới hạn phải hiểu, nên chi phí bảo trì tăng
- Khi có nhiều phần phụ thuộc lẫn nhau, việc khắc phục sự cố cũng khó hơn
- Thomas Paine từng viết trong 『Common Sense』 rằng “bất cứ thứ gì càng đơn giản thì càng ít khả năng bị rối loạn, và khi đã rối loạn thì càng dễ sửa”
Những ví dụ trong machine learning cho thấy kỹ thuật đơn giản không hề lép vế
- Kỹ thuật tinh vi hơn không phải lúc nào cũng cho hiệu năng tốt hơn
- Tree-based models > deep neural networks: trên 45 bộ dữ liệu dạng bảng quy mô trung bình, mô hình dựa trên cây tốt hơn mạng nơ-ron sâu
- Greedy algorithms > graph neural networks: trong các bài toán đồ thị tổ hợp, thuật toán greedy tốt hơn graph neural network
- Simple averaging ≥ complex optimizers: trong bài toán học đa nhiệm, phép lấy trung bình đơn giản không kém các bộ tối ưu phức tạp
- Simple methods > complex methods: xét độ chính xác dự báo trên 32 bài báo, phương pháp đơn giản tốt hơn phương pháp phức tạp
- Dot product > neural collaborative filtering: trong gợi ý và tìm kiếm item, tích vô hướng tốt hơn neural collaborative filtering
Vấn đề phát sinh khi thưởng cho sự phức tạp
- Nếu thưởng cho sự phức tạp, mọi người sẽ có động cơ tạo ra những thứ phức tạp không cần thiết
- Phương pháp hoặc hệ thống đơn giản có thể bị đánh giá là kém giá trị hơn chỉ vì trông có vẻ dễ
- Khi làm hệ thống phức tạp để nhận phần thưởng, giải pháp đơn giản nhất không còn là lựa chọn hiển nhiên nữa
- Sự phức tạp sinh ra nhiều phức tạp hơn, cuối cùng có thể dẫn đến mức không thể làm việc được
- Khuynh hướng not invented here cũng được củng cố
- Dù tái sử dụng các thành phần hiện có có thể tiết kiệm thời gian và công sức, vẫn nảy sinh xu hướng muốn xây từ đầu
- Điều này có thể lãng phí thời gian và tài nguyên, đồng thời dẫn đến kết quả tệ hơn
- Trong quy trình thăng chức và phản biện bài báo machine learning, sự phức tạp cũng có thể bị nhấn mạnh quá mức
- Bryan Liles chỉ ra rằng giải pháp đơn giản dễ triển khai và mở rộng hơn giải pháp phức tạp, nhưng việc thăng chức thường được trao cho người tạo ra giải pháp phức tạp
- Micah Goldblum nói rằng trong phản biện ML, việc phương pháp quá đơn giản hoặc được cấu thành từ các bộ phận có sẵn là nhận xét thường gặp, nhưng sự đơn giản là điểm mạnh chứ không phải điểm yếu
- Những đổi mới như Kalman Filters, PageRank, SVM, LSTM, Word2Vec, Dropout cũng từng bị từ chối
Cách tốt hơn để xử lý sự phức tạp
- Mục tiêu là giải vấn đề phức tạp bằng giải pháp đơn giản nhất có thể
- Cần tập trung vào độ phức tạp của vấn đề, không phải độ phức tạp của giải pháp
- Giải pháp đơn giản cho thấy hiểu biết sâu về vấn đề và năng lực tránh các giải pháp rối rắm hơn, tốn kém hơn
- Điều này liên quan đến câu nói của Albert Einstein: “Mọi thứ nên đơn giản hết mức có thể, nhưng không đơn giản hơn thế”
- Có thể cân nhắc nhiều giải pháp có trọng tâm thay vì một giải pháp phức tạp bao quát mọi thứ
- Giải pháp vạn năng (one-size-fits-all) có thể kém linh hoạt và kém tái sử dụng hơn kỳ vọng
- Khi hỗ trợ đồng thời nhiều use case và bên liên quan, hệ thống trở nên liên kết chặt, cần nhiều phối hợp hơn cho lập kế hoạch và migration
- Hệ thống một mục đích dễ vận hành và cũng dễ loại bỏ khi cần
- Có thể áp dụng Occam’s razor như một cách giảm thiên kiến phức tạp
- Đây là nguyên tắc cho rằng giải pháp hoặc lời giải thích đơn giản nhất thường là đúng
- Không nên bác bỏ ý tưởng đơn giản quá sớm, hoặc thêm sự phức tạp không cần thiết để biện minh cho giá trị
- Cần xét chi phí của sự phức tạp và hỏi “nó có đáng không”
Thiên kiến ngược lại: tái sử dụng sự phức tạp quen thuộc
- Ở phía đối lập với “not invented here” cũng có thiên kiến tự động ưu tiên các thành phần hiện có
- Vì chúng đã quen thuộc, dễ hơn theo kinh nghiệm cá nhân, và có thể giảm thời gian, công sức của bản thân
- Nhưng nếu bản thân thành phần hiện có rất phức tạp, nó có thể lãng phí thời gian và tài nguyên hơn, đồng thời tạo kết quả tệ hơn so với việc tạo một thứ mới đơn giản hơn
- Khi không có lựa chọn đơn giản, việc xây mới có thể là cần thiết
- Cũng có trường hợp thứ mới được tạo ra thực ra không đơn giản hơn mà trở thành một thứ khác phức tạp ngang thứ cũ
- Một số vấn đề vốn dĩ phức tạp và có essential complexity không thể loại bỏ trong thực tế
- ORM được xem là một ví dụ xấu
- ORM liên tục được tạo mới và ban đầu bắt đầu đơn giản, nhưng cuối cùng độ phức tạp bùng nổ
- object/relational impedance mismatch là vấn đề đã được biết rõ, và bản thân ý tưởng ORM vốn dĩ phức tạp
- Thứ trông như vẫn giữ được sự đơn giản nhiều khả năng không phải ORM mà là query builder hoặc data mapper
- PSR cache API là ví dụ về sự phức tạp có thể loại bỏ
- Sau cache API PSR-6 đã xuất hiện cache API PSR-16 đơn giản hơn
- PSR-16 giảm độ phức tạp và số lượng khái niệm, khiến API nhỏ hơn và ít áp đặt quan điểm hơn
- Việc có thể tạo adapter PSR-6 để triển khai PSR-16 và adapter theo hướng ngược lại cho thấy phần phức tạp bị loại bỏ trong PSR-16 không phải là bản chất
- Một số thư viện và framework có thể phình to vượt quá độ phức tạp bản chất dưới danh nghĩa trải nghiệm nhà phát triển
- Sự đơn giản thực tế có tính chất đo lường được bằng các chỉ số như số dòng mã, số public method, mức độ kết hợp
- Có trường hợp thư viện trong vài năm phình to gấp 10 lần kích thước ban đầu và cứ 6–12 tháng lại có breaking change lớn
- Động cơ xem một thư viện không tăng trưởng là “đã chết” và chuyển sang gói “tích cực” hơn cũng có thể là triệu chứng của thiên kiến phức tạp
- Để tránh sự phức tạp lan rộng, đôi khi cần lựa chọn xây mới
- Nếu có thể cố định yêu cầu và tránh tăng trưởng lan rộng về phạm vi, một triển khai mới có thể là lựa chọn đơn giản hơn
- Cần cẩn trọng để không củng cố thiên kiến ở bất kỳ phía nào
1 bình luận
Các ý kiến trên Hacker News
Tôi từng làm ở một công ty thuộc FAANG vào thời điểm họ lấy việc giải quyết vấn đề phức tạp làm tiêu chí thăng tiến; càng giải được vấn đề phức tạp hơn thì cấp bậc, đãi ngộ và địa vị càng tăng.
Tự nhiên mọi người bắt đầu đi tìm những vấn đề phức tạp đáng để giải, và khi các công ty khác sao chép ý tưởng của công ty đó, có vẻ ngay cả những công ty nhỏ không cần các giải pháp phức tạp cũng có stack công nghệ tương tự.
Gần đây, khi nhìn vào UI ô tô, đặc biệt là UI phức tạp và khó dùng của xe điện, tôi cũng nghĩ tương tự; đến mức nó khiến tôi không mua được chiếc xe mà mình cần.
Kết luận là người tiêu dùng tinh tế và người tiêu dùng mang tính ngưỡng vọng rất khác nhau, và nhóm ngưỡng vọng đông hơn nhiều.
Vì vậy, việc hy sinh người tiêu dùng tinh tế để phục vụ người tiêu dùng ngưỡng vọng là hợp lý về mặt kinh tế.
Người tiêu dùng ngưỡng vọng chấp nhận lỗi và những trò đánh lừa như thể đó là biểu tượng của thành tựu tiêu dùng.
Nói thẳng ra, họ quá thích việc lái một chiếc xe “sang” đến mức không thấy đống rác đi kèm; còn với tư cách người đã mua xe sang suốt nhiều thập kỷ, tôi chỉ muốn cần số dễ nhận biết là được.
Các mục chạm trở nên quá nhỏ mà không có lý do, và có vẻ các nhà phát triển đã thiết kế, kiểm thử UI trên màn hình đặt cố định trên bàn hoặc trong một chiếc xe đứng yên.
Trong một chiếc xe đang chạy, mọi thứ đều hỏng.
Các xe đời mới không có cần số, đèn xi-nhan, cần gạt mưa, cần đèn là một mớ hỗn độn.
Khi ngồi ghế lái, bạn phải chọc trúng những mục tiêu nhỏ trên một màn hình không có chỗ đặt tay, nên thao tác gián tiếp, sự rối rắm, thiếu chính xác và phân tán chú ý đều khiến mọi người lái xe kém hơn.
Nó tự động hóa những việc phiền phức như khóa/mở khóa, đóng cửa sổ, sưởi/làm mát trước, tự đặt điều hướng đến công ty vào buổi sáng và về nhà vào buổi tối, điều chỉnh ghế và thiết lập tùy theo khóa điện thoại nào được dùng.
Nhờ kết nối miễn phí, điều hướng cũng hoạt động tử tế, còn mọi hệ thống GPS trong xe tôi từng dùng trước đây đều vô dụng.
Màn hình chọn và phát nhạc cũng tốt, lệnh thoại cũng hoạt động khá ổn cho việc chọn nhạc.
Nó không hoàn hảo, nhưng tôi thấy tốt hơn mọi xe động cơ đốt trong mà tôi từng lái.
Buổi sáng đi làm chỉ cần hai bước: mở cửa, vào chế độ lái.
Với xe động cơ đốt trong vào mùa đông thì phải hơn 10 bước: tìm chìa khóa, mở khóa xe, mở cửa, chỉnh ghế sau khi vợ lái, bấm nút khởi động, khử sương kính trước, bật sấy kính sau, cạo băng kính trước, chọn công ty trên GPS, nhả phanh đỗ, đạp côn, vào số.
Những người không trực tiếp sở hữu cứ than thở mãi trên mạng về màn hình cảm ứng, nhưng chủ Tesla thì vẫn ở lại với thương hiệu vì xe tốt hơn các xe khác, bất kể có màn hình cảm ứng hay không.
Technology Connections gần đây nói trong một video rằng để đổi cần gạt mưa, anh ấy phải giữ một cái cần gạt kiểu thập niên 90 xấu xí trong 4 giây, và phải đọc sách hướng dẫn mới biết được điều đó.
Những thao tác rác rưởi kiểu này rất phổ biến ở những chiếc xe được tạo nên từ các bộ phận gắn rời rạc.
Ngược lại, xe của tôi gửi thông báo video giám sát thời gian thực về điện thoại, lái giúp tôi trên đường đi làm, và chuyện vào số thường chỉ ở mức thắt dây an toàn, đạp phanh là xe tự chọn hướng.
Các chức năng quan trọng có thể được truy cập theo ngữ cảnh bằng nút trên vô lăng, chứ không phải 50 cái nút.
Nó đơn giản mà mạnh mẽ, và vấn đề nằm ở chỗ cách triển khai của những chiếc xe sang nói trên quá tệ.
Thỉnh thoảng tôi xem một YouTuber tên Theo Browne; anh ấy chủ yếu là lập trình viên frontend
Khi nghe anh ấy giải thích giải pháp, tôi có cảm giác như bị gậy bóng chày đập vào đầu, và số lượng thành phần đưa vào demo nhiều đến mức muốn khóc
Tôi cũng ngạc nhiên trước số lượng thuật ngữ khó hiểu liên quan đến React được nhắc tới trong một video
Không phải tôi muốn chỉ đích danh ai đó để chỉ trích, nhưng tôi lo rằng chính sự phức tạp đó lại giúp anh ấy duy trì độ nổi tiếng
Ngược lại, Pieter Levels đưa PHP thuần thẳng vào production mà không nói đến những thứ như Suspense, server-side rendering hay Hydration
Cả hai cuối cùng đều đạt tới cùng một mục tiêu, nhưng tôi nghĩ Pieter Levels sẽ kiếm được nhiều tiền hơn hẳn, và khoảng cách về độ phức tạp là rất lớn
Thực tế, tôi cho rằng những thứ như Nomad List còn giàu tính năng hơn nhiều so với những gì thấy ở Theo
Sau đó tôi thấy một người khác nhận ra anh ấy, rồi họ có một cuộc tranh luận lớn tiếng nhưng thân thiện về một chủ đề mà Theo từng nói rất mạnh trên kênh
Tính cách của anh ấy có vẻ hoàn toàn phù hợp với việc tối đa hóa mức độ tham gia của truyền thông thông qua sự phức tạp không cần thiết
Càng phức tạp thì càng có nhiều thứ để tranh cãi, và với những người không quen các lựa chọn khó hiểu, bạn có thể trông thông minh hơn
Lượng thư viện và code dùng cho những ví dụ như đồ chơi còn lớn hơn nhiều so với những gì tôi thấy trong production, mà tôi cũng từng thấy vài hệ thống khá quái vật
Không biết chuyện này sẽ kéo dài được bao lâu
Nó đi kèm cả đống thứ linh tinh bạn sẽ không dùng, và lại cản trở đúng phần bạn cần dùng
Khi có vấn đề, giờ bạn không chỉ phải hiểu ngôn ngữ lập trình và code của mình, mà còn phải hiểu cả code trong framework trên đường đi mà luồng của bạn chạy qua
Đường đó rất dễ đi sâu 10–20 hàm, và cực hiếm khi những gì xảy ra trong các trường hợp biên khác nhau được tài liệu hóa đủ cụ thể
Lượng công cụ dùng để làm những thứ tương đối đơn giản là khổng lồ, và tôi có cảm giác chuyện tương tự cũng đang xảy ra trong DevOps
Vấn đề này có vẻ do các “frontend developer” trong doanh nghiệp tạo ra
Có lẽ một kiểu mặc cảm tự ti trước “kỹ nghệ thực sự” mà full-stack hay backend developer làm đã khiến frontend cũng muốn tạo ra những vấn đề “kỹ nghệ thực sự”
Sau nhiều thập kỷ phát triển các hệ thống legacy, đôi khi theo thiết kế của công ty chúng tôi, đôi khi theo hợp đồng cho khách hàng, tôi đã thấy rất nhiều việc khiến tôi tin rằng một số khách hàng nhất định thích phần mềm phức tạp và nhiều lỗi
Lý do là họ có thể núp sau nó
Kiểu như “phần mềm có lỗi nên tôi không hoàn thành đúng hạn”, “phần mềm không hỗ trợ Y nên tôi không làm được X”, “con chó ăn mất bài tập của tôi”
Trong nhiều trường hợp, lẽ ra có thể thiết kế một giải pháp đơn giản, dễ dùng và ít lỗi hơn nhiều, nhưng khi đó người dùng sẽ khó che giấu rằng một thất bại cụ thể có thể không phải do phần mềm mà do sự kém năng lực của chính họ
Vì vậy, đặc biệt ở những công ty chịu nhiều áp lực từ cấp trên, các quản lý thực sự thích làm việc với phần mềm mà họ không hoàn toàn hiểu và vốn nổi tiếng là có lỗi, có vấn đề
Năm 27 tuổi, khi chuyển khỏi công việc đầu tiên sau 5 năm làm ở đó, tôi đã thay một chương trình GUI siêu phức tạp bằng một GUI nhỏ bọc quanh hai chương trình CLI
Nó chạy được mọi lần ngay cả khi đầu vào sai, và trong những lần hiếm hoi thất bại thì cũng đưa ra thông báo lỗi hữu ích
Ba người phụ nữ dùng nó thật sự ghét tôi
Khoảng một năm sau khi rời công ty tôi mới hiểu lý do, và khi đó tôi cũng không thông minh cho lắm
Theo thời gian, tôi bắt đầu nghĩ rằng người ta muốn những thứ như Microsoft Teams, vì khi cần họ có thể dùng nó để che chắn cho mình
Với UI vật lý, nhóm chúng tôi gọi chuyện này là vấn đề lò vi sóng
20 nút phụ trên lò vi sóng thì không ai dùng và hầu hết chỉ dùng một hai nút, nhưng lò vi sóng ít nút thì lại chẳng ai mua
Tôi vẫn thích chiếc Samsung ME82V của mình suốt 10 năm qua, chỉ cần hai núm xoay là xong
Vì vậy ăn vụng lúc 2 giờ sáng lại thành chuyện phải đứng canh lò vi sóng như năm 1999
Thứ tôi muốn chỉ là núm chỉnh tốc độ, công tắc nhồi tức thời và công tắc nguồn, và ai cũng muốn như thế, nhưng không hiểu vì sao mỗi thế hệ mới lại gắn thêm cả đống tính năng chẳng ai dùng
Không phải lúc nào cũng chỉ dùng đúng hai nút giống nhau, nên tôi thích quyền lựa chọn có thể dùng các nút khác
Và khá nhiều khi nhiều nút hơn cũng đi kèm thông số tốt hơn
Ít thao tác hơn, ít tính năng hơn, nhưng trải nghiệm người dùng rất tuyệt
Tôi nhớ sự gọn gàng của iPod khi so với các sản phẩm cạnh tranh quá nhiều tính năng và phức tạp
Những lời than thở kiểu này gây khó chịu vì đầy những châm ngôn sáo rỗng
Trích Einstein và Dijkstra thì rất dễ tỏ ra thông minh, và cũng dễ khái quát hóa rồi chỉ trích các giải pháp phức tạp khi có lợi thế của việc nhìn lại sau sự việc và thiếu hiểu biết về yêu cầu thực tế
“Đơn giản nhất có thể, nhưng không đơn giản hơn” lúc nào cũng đúng
Nếu giải pháp lộn xộn thì lẽ ra phải làm nó đơn giản hơn, còn nếu giải pháp thô sơ gây ra vấn đề thì lẽ ra không nên làm nó quá đơn giản
Kiểu như hỏi tại sao không nghĩ đến việc làm cho nó hoàn hảo ngay từ đầu
Trong thực tế, khi một giải pháp có nhiều đánh đổi, ngay cả việc thống nhất thế nào là đơn giản cũng rất khó
Duy trì một cơ sở dữ liệu phức tạp có thể dễ hơn việc có ba cơ sở dữ liệu “đơn giản”, phải làm gấp ba lần công việc quản trị rồi cuối cùng lại phải triển khai đồng bộ hóa hoặc giao dịch phân tán
Thứ dễ triển khai lúc này có thể tạo ra vấn đề phức tạp về sau, còn một giải pháp có sẵn không giải quyết trọn vẹn vấn đề sẽ sinh ra các workaround phức tạp cho những trường hợp nó không hỗ trợ, rồi cuối cùng còn thêm cả độ phức tạp của việc chuyển sang thứ phù hợp hơn
Lời khuyên “cứ làm đơn giản thôi” thường không nhận ra rằng những giải pháp như vậy không phải thuốc chữa bách bệnh, và trong thực tế hiếm khi có lựa chọn rõ ràng giữa phức tạp và đơn giản
Dự án có các ràng buộc như hệ thống cũ lộn xộn, yêu cầu pháp lý không nhất quán, nhu cầu kinh doanh thay đổi, và cũng có thể ưu tiên tốc độ ra mắt hoặc năng lực có thể tuyển được
Bài toán kinh tế cũng lạnh lùng: dù việc xuất báo cáo thường niên trông như một cỗ máy Rube Goldberg, nó chỉ được dùng mỗi năm một lần, và nếu viết lại thì có thể cũng không hoàn vốn trong vòng 50 năm
Các cuộc bàn luận về độ phức tạp hiếm khi thừa nhận rằng dự án và yêu cầu sẽ phát triển
Thứ hiện tại hoàn toàn đơn giản về sau có thể trở nên phức tạp theo một cách hoàn toàn hợp lý, chứ không phải do bất tài hay ác ý
Ban đầu lưu dữ liệu trong file văn bản thuần là đơn giản một cách đẹp đẽ, nhưng về sau có thể trở thành một cơ sở dữ liệu NIH tệ hại
Nhưng ngay từ đầu dùng cơ sở dữ liệu chỉ cho 3 dòng dữ liệu thì cũng là thiết kế quá tay
Refactoring có chi phí, nên việc luôn dùng giải pháp lý tưởng cũng không hề đơn giản như vậy
Ít thứ thực sự hiển nhiên hơn ta tưởng rất nhiều
Diễn giải “đơn giản nhất có thể, nhưng không đơn giản hơn” thành yêu cầu phải hoàn hảo là không hợp logic
Trong thực tế làm việc, ta biết rằng lặp lại thắng kế hoạch
Nếu khó thống nhất thế nào là đơn giản, thì đừng xin phép, hãy xin tha thứ
Đó là quy luật đúng trong ngành này, và có lẽ cả nhiều ngành khác
Chắc chắn có một kiểu độ phức tạp ngẫu nhiên đặc thù thường thấy ở những kẻ mộng mơ và lập trình viên frontend
Độ phức tạp là phức tạp
Hệ thống phức tạp hơn còn có hiệu ứng thứ cấp là tạo ra nhiều tài liệu xung quanh như tutorial, video
Ngoài ra, với những người đã học nó, họ trở thành người có kỹ năng và trách nhiệm mà công ty cần, nên đem lại sự ổn định việc làm hơn so với một thứ cứ chạy tốt đến mức không cần những người như vậy
Trong IT có quá nhiều công việc vốn đã không tồn tại nếu phần mềm được làm đơn giản và cứ thế chạy được
Trong trường hợp đơn giản thì nó “cứ chạy”, miễn là bạn không nhìn vào bên trong hoặc cố làm việc gì không tầm thường
Ẩn dụ đó có lẽ khá đúng
Nếu đang nói về phản biện bài báo khoa học, thì với tư cách người phản biện, thứ tôi tìm trong bài không phải là sự đơn giản, cũng không phải độ phức tạp, và cũng không phải “tính mới”
Thứ tôi tìm là một phân tích thực nghiệm thấu đáo và gợi suy nghĩ về vấn đề
Trong các bài gửi đến có nhiều bài thuộc kiểu 1) đề xuất một hệ thống như quái vật Frankenstein khâu từ cả chục ý tưởng sẵn có, không phân tích sâu các kiểu thất bại của từng phần mà huy động tối đa những món đồ chơi mới nhất có trong tay để đạt được “những con số lớn”, 2) chỉ sửa nhẹ một phương pháp cũ rồi tình cờ hiệu năng tốt hơn, nhưng không có biện minh thực nghiệm hoặc lý thuyết phù hợp về vì sao nó hữu ích
Kiểu thứ hai có thể có chút giá trị rất nhỏ cho cộng đồng hoặc độc giả, nhưng phần lớn tôi xem là vô dụng
Điều có giá trị với độc giả là khi một nghiên cứu sinh tiến sĩ nhìn vấn đề đủ lâu để nối trực giác của mình với sự xác nhận định lượng, có thể kiểm chứng, và thu được một quan sát có thể tái lập với sức dự đoán
Chẳng hạn như “bài này đã kiểm chứng bằng thực nghiệm trong mọi trường hợp rằng X ảnh hưởng đến Y thông qua cơ chế Z được mô tả trong bài, nhờ đó cải thiện chỉ số A thêm B%, và điều này phù hợp với Z”
Bất kể độ phức tạp, kiểu “làm X thì A tăng B%” là chưa đủ
Đáng tiếc là không phải phản biện nào cũng đồng ý
Giáo viên lịch sử thời trung học của tôi ra bài tập viết một bài luận về các sự kiện dẫn đến Thế chiến II
Câu hỏi đầu tiên là bài nên dài bao nhiêu, và thầy trả lời rằng nếu có thể xử lý chủ đề phức tạp này trong một trang A4 thì thầy sẽ cho điểm tối đa, nhưng thầy thật lòng nghi ngờ liệu một bài ngắn như vậy có thể làm được không
Tất cả đều bị sốc trước lập luận đó
Chưa ai từng nghe thầy nói như vậy, và nó cho thấy từ nhỏ ta được dạy rằng nhiều hơn luôn tốt hơn
Một lời giải thích luôn có thể dài hoặc ngắn tùy mức trừu tượng được chọn, và người ta thường chọn mức đó theo bối cảnh và quy ước xã hội
Ví dụ, “một lần nhấn phím dẫn đến chữ trên màn hình như thế nào” có thể được giải thích bằng một câu, hoặc nếu đi vào firmware, stack phần mềm, điện tử học, khoa học vật liệu, quy trình sản xuất thì có thể thành nhiều cuốn sách dày
Thế chiến II cũng có thể nói là bắt đầu khi Hitler xâm lược Poland và France, cũng có thể đi vào Hiệp ước Versailles, hoặc thậm chí nói đến cả quá trình tiến hóa của sự sống trên Trái Đất
Cách cuối cùng thì ra vẻ thông thái quá mức, nhưng về mặt kỹ thuật đúng là một sự kiện dẫn đến Thế chiến II
Rất khuyến nghị bài nói Simple Made Easy của Rich Hickey
Độ phức tạp hoàn toàn không dễ bán, nhưng thứ dễ dùng thì bán được
Nếu công ty có thể tuyển nhiều người biết dùng ‘foo’ và ngành vẫn tiếp tục nói về ‘foo’, họ sẽ chọn foo dù nó là một mớ hỗn độn hoàn toàn
Cứ nhìn lambda architecture, phần lớn các dự án Apache, container, v.v. là thấy