Bạn không phải Google (You Are Not Google)
(blog.bradfieldcs.com)Nhiều kỹ sư phần mềm không thật sự lý trí trong việc lựa chọn công nghệ. Khi chọn công nghệ mới, họ thường làm theo chỉ vì đó là công nghệ được các công ty Big Tech như Google hay Amazon sử dụng, thay vì dựa trên nhu cầu thực tế hoặc định nghĩa vấn đề rõ ràng. Ví dụ, MapReduce hay Hadoop được sinh ra để xử lý dữ liệu ở quy mô cực lớn, nhưng khi những công ty không có quy mô dữ liệu tương xứng vẫn triển khai chúng, họ lại phải gánh chi phí I/O không cần thiết và mất đi một số tính năng. Đây đơn thuần là hiện tượng "sùng bái công nghệ (cargo cult)".
Bài viết đưa ra một checklist tên là UNPHAT để tránh kiểu bắt chước thiếu phê phán này:
Understand – Hãy hiểu đầy đủ vấn đề.
eNumerate – Hãy liệt kê nhiều phương án khác nhau.
Paper – Hãy đọc bài báo hoặc white paper làm nền tảng cho công nghệ đó.
Historical context – Hãy xem xét bối cảnh lịch sử khi nó được phát triển.
Advantages – Hãy so sánh ưu và nhược điểm một cách cân bằng.
Think – Hãy tự suy nghĩ xem công nghệ này có thật sự phù hợp với vấn đề hay không.
Bài viết cũng nêu các ví dụ về những công nghệ như Cassandra, Kafka, hay SOA(Service-Oriented Architecture) bị áp dụng một cách thiếu phê phán trong những tình huống không phù hợp với ca sử dụng thực tế. Chẳng hạn, Kafka được tạo ra cho LinkedIn để xử lý hàng triệu thông điệp mỗi giây, nhưng lại có khi được dùng ở những công ty nhỏ chỉ có vài chục giao dịch mỗi ngày.
Tác giả cũng nhấn mạnh rằng ngay cả Google cũng đã ngừng dùng MapReduce khi họ nhận thấy nó không còn phù hợp nữa. Cuối cùng, điều quan trọng không phải là bản thân công nghệ, mà là bạn phải hiểu chính xác vấn đề mình đang muốn giải quyết và chọn công nghệ phù hợp với nó.
Cuối bài, tác giả nhắc rằng Pólya, Hamming, Rich Hickey và nhiều người khác cũng đã lặp lại cùng một thông điệp. Cốt lõi rất đơn giản:
“Think. Và hãy hiểu vấn đề thực sự.”
15 bình luận
Tôi tình cờ thấy bài này qua phần gợi ý của Google rồi vào đọc, nhưng đây là một bài viết được viết quá nhiều từ góc nhìn của dân Geek. Từ góc độ kinh doanh thì hoàn toàn không phải là câu chuyện đúng. Vì sao lại như vậy?
Những công cụ lớn mà Big Tech dùng thì dễ tìm chuyên gia hơn.
Có rất nhiều người học chúng để vào Big Tech, và cũng có nhiều người học chỉ vì Big Tech đã chọn dùng. Đương nhiên, sẽ dễ tìm người hiểu về chúng hơn, cũng dễ tuyển người có kinh nghiệm hay chuyên gia hơn. Nhưng nếu là một công cụ hoàn toàn xa lạ thì sao? Không phải là không có người đào sâu vào nó, nhưng để tìm được những người như vậy chắc chắn sẽ khó hơn nhiều so với chuyên gia về các công cụ của Big Tech.
Những công cụ lớn mà Big Tech sử dụng có rất nhiều tài liệu tham khảo
Những công cụ lớn được nhiều người dùng thì có rất nhiều tài liệu để giải quyết vấn đề, và kết quả tìm kiếm trên Google cũng phong phú. Phần lớn vấn đề thường là thứ người khác cũng từng gặp, nên chỉ với một tìm kiếm đơn giản là có thể dễ dàng xác định vấn đề. Nhưng với một công cụ xa lạ, rất khó tìm tài liệu tham khảo, và nếu xảy ra sự cố thì khả năng cao sẽ tốn khá nhiều thời gian để xác định nguyên nhân. Mà tất cả những thứ đó đều là tiền. Vấn đề này có thực sự là do công cụ nhỏ mới được đưa vào hay không? Hay là đang hiểu nhầm vấn đề từ phía khác?
Ngược lại, chính Big Tech mới là bên dễ chuyển đổi những thứ này hơn. Vì với quy mô xử lý dữ liệu khổng lồ, chỉ một chút lợi ích về I/O cũng có thể trở thành lợi ích rất lớn đối với họ. Và cũng có nhiều người sẵn sàng học chỉ vì Big Tech đã áp dụng. Nhưng với các công ty quy mô vừa và nhỏ, do quy mô dữ liệu tương đối nhỏ nên một chút lợi ích về I/O không hẳn là lợi ích lớn đến vậy, trong khi những vấn đề ở trên lại rất nghiêm trọng. Cũng có ít người muốn học các giải pháp mà doanh nghiệp vừa và nhỏ áp dụng hơn. Vì thế, nếu là chủ doanh nghiệp vừa và nhỏ, thì thay vì cân nhắc những thứ này theo kiểu Geek, nhiều trường hợp sẽ đi đến kết luận rằng làm theo các công cụ của Big Tech mới là lựa chọn kinh tế hơn.
Đọc bài gốc thì thấy đây là bài viết từ năm 2017.
Đã 8 năm trôi qua kể từ đó mà nội dung này vẫn còn đúng, thật đáng ngạc nhiên.
Tôi rất đồng ý với nội dung ở trên!
Tuy vậy, tôi cũng cho rằng ở các công ty nhỏ, việc over-engineering đôi khi xảy ra vì những người nhắm đến các công ty lớn muốn tích lũy kinh nghiệm với những công cụ đó khi làm ở công ty nhỏ.
Tất nhiên là sếp chắc cũng không thích lắm đâu haha
Chẳng phải 80% lý do khiến các công ty nhỏ cũng dùng nguyên xi những công cụ được thiết kế theo nhu cầu của các tập đoàn lớn là vì điều này sao. Người cần kiểm soát chuyện đó lẽ ra phải là CTO, nhưng cũng có trường hợp ngay cả CTO lại đang nghĩ đến chuyện chuyển việc sang một tập đoàn lớn.
Nếu không có nhiều việc để làm thì kiểu gì cũng sinh ra mấy trò vô bổ thôi haha
Cả bài toán dễ cũng phải giải cho thành khó thì mới có cái để làm màu là mình đã làm được gì đó. Nếu làm đơn giản thì cũng có nhiều người tưởng là nó vốn dễ mà.. hahahaha
Vì sợ sau này phải sửa một thứ được làm nhỏ thành lớn, nên có những trường hợp ngay từ đầu đã làm nó thật lớn...
Tôi nghĩ đây là bài viết cũng có thể áp dụng cho K8s. Nó làm tôi nhớ đến cuốn sách "Cách code để khó bảo trì". Haha
Cuối cùng, cần hiểu vấn đề mà các công nghệ đang cố giải quyết, cũng như bối cảnh đã dẫn tới sự ra đời của công nghệ đó. Các ví dụ trong bài gồm những trường hợp như sau.
Tôi nghĩ cần xem xét kỹ xem vấn đề mà chúng giải quyết có thực sự phù hợp với vấn đề mà mình đang cố giải quyết hay không.
Ồ, tôi rất đồng cảm. Điều này làm tôi nhớ đến việc khi mentoring cho các bạn sinh viên/junior, tôi thường khuyên họ hãy thử tìm hiểu lịch sử của công nghệ.
Có vẻ khá nhiều người đôi khi quên mất rằng công nghệ là công cụ chứ không phải mục tiêu.
Khoảnh khắc những thứ như “đã được kiểm chứng ở Big Tech”, “dạo này được dùng nhiều”... trở thành điều kiện chính khi lựa chọn công nghệ, thì việc chi phí tăng lên một cách không cần thiết cũng tự nhiên đi theo.
Ở Hàn Quốc, kiểu sùng bái theo phong trào với Spring khá mạnh.
Mùa xuân dễ tuyển người nên...
Spring ở Hàn Quốc đúng hơn không phải là sự tôn sùng...
Mà là một thứ lai tạp, nơi sự bất tài của chính phủ và sự lười biếng của lập trình viên cùng tồn tại nhiều.
Rất đồng cảm. Suy cho cùng, Spring cũng chỉ là một công cụ để giải quyết vấn đề mà thôi.
Tư duy brainstorming, mind map, nghiên cứu deep learning, thời gian làm việc giảm, July, mydulleim, về lâu dài có hiệu quả.