Lâu lâu Code Dạo viết một bài hơi “sâu sắc” về công nghệ để bạn đọc cùng ngẫm nghĩ nhé.

Hôm nay, chúng ta cùng nghe một mẩu chuyện cười vì cây bút chì trị giá triệu đô của NASA, đến chuyện Netflix làm web, cũng như chuyện công nghệ của web developer nhé.

Chuyện cây bút bi triệu đô của NASA

Ngày xưa ngày xưa, có một câu chuyện cười về chuyện Mĩ và Nga lên vũ trụ như thế này:

Trong những năm 1960, khi mà cuộc đua gay gắt bay vào không gian của các nước đang diễn ra, các nhà khoa học NASA nhận ra một vấn đề: cấu tạo bút máy hay cấu tạo bút bi thường đều không thể viết được ở ngoài vũ trụ.

Họ cần phải tìm ra cách khác để các phi hành gia có thể viết được. Vì vậy, họ đã dành hàng năm và hàng triệu đô la đóng thuế để phát triển cấu tạo cây bút bi có thể viết được ra giấy trong môi trường không trọng lực.

Về phía đối lập, Liên Xô giải quyết được vấn đề chỉ với một biện pháp đơn giản: Họ đưa bút chì cho các phi hành gia!

Các bạn thấy đấy, có những vấn đề vốn có thể giải quyết vô cùng đơn giản, nhưng lại bị phức tạp hóa lên rất nhiều lần.

Từ chuyện bút chì vũ trụ đến chuyện lập trình

Dân lập trình tụi mình như vậy bác bên NASA vậy, đôi khi thích over-engineering, thích phức tạp hóa vấn đề lên và tìm cách giải quyết.

Bạn nào đọc series về lược sử lập trình front-end của mình cũng biết gần đây front-end web rất phát triển. Hiện các công ty to bự đang trào lưu sử dụng Client Side Rendering thay cho Server Side Rendering.

Chuyện đáng buồn … cười ở đây là, nhiều team sử dụng công nghệ vô tội vạ chỉ vì nó… mới, nó cool mà không biết rằng mình đang over-engineering.

 

Đôi khi, thứ họ cần build chỉ một website nho nhỏ như 1 landing page, một trang web tin tức, web bán hàng. Khi sử dụng Client Side Rendering, họ sẽ gặp những vấn đề sau:

• Initial load sẽ chậm hơn nếu không biết optimize.
• Đòi hỏi project phải chia làm 2 phần riêng là back-end (REST api) và front-end nên khó code hơn
• Không chạy được nếu JavaScript bị disable, hoặc ở các trình duyệt cũ không nhận JavaScript ES6
• SEO không tốt bằng Server Side Rendering (Do bot crawl không đọc được dữ liệu)

Tất cả những vấn đề này có thể giải quyết một phần bằng cách optimize code kĩ, bundle code, render riêng cho bot như chợ tốt đã làm.

Tuy nhiên, chúng lẽ ra có thể được giải quyết một cách đơn giản nếu ngay từ đầu họ sử dụng Server Side Rendering. Nói đâu xa, ngay cả trang web bán hàng lớn như Amazon cũng sử dụng Server Side Rendering + AJAX đấy thôi.

 

Đỉnh cao của trò over-engineering này là Netflix từng đăng một twitter: Bỏ React ở client, performance tăng đc 50%!

Những tưởng được khen, ai ngờ lại bị dân tình đồng loạt nhảy vào ném gạch: Ơ đm, có mỗi cái landing page đơn giản mà chúng mày dùng React để làm clgt!

(Thật ra cũng hơi oan cho Netflix, các bạn có thể xem chuyện full ở đây: https://news.ycombinator.com/item?id=15567657).

Chuyện về sau, khi cây bút chì là không đủ

Tuy nhiên, nói đi cũng phải nói lại, có nhiều bạn chỉ biết phần 1 mà chưa biết phần 2 của câu chuyện cây bút chì NASA:

Ban đầu, các phi hành gia NASA cũng giống như các phi hành gia Liên Xô, đã sử dụng bút chì, theo các sử gia của NASA. Trong thực tế, NASA đã đặt hàng 34 bút chì bấm từ Tycam Engineering Manufacturing, Inc ở Houston, vào năm 1965.

Thế nhưng, bút chì có thể không phải là lựa chọn tốt nhất. Những mảnh vụn đầu bút chì có thể bị bong tróc và vỡ ra cực nhỏ, trôi dạt trong môi trường không trọng lực, nơi chúng có khả năng gây hại cho một phi hành gia hoặc thiết bị. Và bút chì rất dễ cháy – điều mà NASA muốn tránh trong các vật thể trên tàu sau vụ hỏa hoạn Apollo 1 .

Bạn sẽ nhận ra rằng, đôi khi có những vấn đề thực sự phức tạp, không thể dùng các biện pháp đơn giản để giải quyết.

Tương tự với việc lập trình. Với một số trang web có flow phức tạp, cần interactive với người dùng nhiều, hoặc cần hiển thị thông tin theo kiểu realtime; lúc này Client Side Rendering là lựa chọn tốt nhất, hoặc có thể là duy nhất.

Hồi xưa, mình cũng có lấy ví dụ về chuyện over-engineering, viết Hello World mà dùng đủ thứ design pattern từ Factory, Strategy cho đến Dependency Injection.

Ở các dự án nhỏ, việc này là hoàn toàn dư thừa, lãng phí. Tuy nhiên, ở những dự án lớn đến siêu lớn, những pattern này sẽ đảm bảo code viết ra có cấu trúc tốt, dễ thay đổi cũng như bảo trì, sửa chữa!

Kết – Bài học rút ra là gì?

Thông thường, đa số vấn đề đều có thể dùng những cách rất đơn giản để giải quyết. Hãy cố gắng sử dụng cách đơn giản nhất có thể trước khi bỏ công sức đi theo cách phức tạp.

Trong trường hợp bất khả kháng, khi không còn cách đơn giản nào khác, ta bắt buộc phải dùng cách phức tạp để giải quyết nó.

Làm sao biết vấn đề nào có thể giải quyết đơn giản, vấn đề nào cần phức tạp?

Câu hỏi này khó đấy! Điều này còn phụ thuộc vào khả năng và kinh nghiệm của mỗi chúng ta thôi. Một người engineer giỏi sẽ biết khi nào cần tìm giải pháp đơn giản, khi nào cần giải quyết vấn đề theo cách phức tạp nhé.

Bạn đọc nào có kinh nghiệm gì về chuyện giải quyết vấn đề này thì cứ đăng chia sẻ trong phần comment nhé :D.

 

P/S: Để theo dõi bài viết trên Tôi Đi Code Dạo, nhớ Subscribe Chat Bot của tụi mình nha. Bot của Code Dạo sẽ gửi bạn những bài viết cực kì hay ho về kĩ năng mềm và cứng, kinh nghiệm trong ngành vào thứ 4 hàng tuần nhé!