Dựa trên video hướng dẫn của Fireship
Bạn có đang chạy theo những “cách làm tốt nhất” và “khuôn khổ công nghệ thịnh hành” mà không biết rằng chúng đang lãng phí thời gian quý báu của mình? Mình cũng từng như vậy đấy!
Trong bài viết này, mình sẽ tóm tắt video tuyệt vời từ kênh Fireship về 7 quan niệm sai lầm trong lập trình đã khiến nhiều lập trình viên lãng phí thời gian. Hãy cùng khám phá xem bạn có đang mắc phải những sai lầm này không nhé?
Nội Dung Chính
- Nhìn nhận lại hành trình lập trình (00:00-00:33)
- Quan niệm sai lầm #1: Bạn cần dùng công nghệ mới nhất để theo kịp thời đại (00:33-02:04)
- Quan niệm sai lầm #2: Chỉ có một cách đúng để viết mã (02:04-02:40)
- Quan niệm sai lầm #3: Mã sạch là chân lý (02:40-03:31)
- Quan niệm sai lầm #4: 100% độ phủ kiểm thử = mã an toàn (03:31-04:11)
- Quan niệm sai lầm #5: Luôn tối ưu hiệu năng (04:11-04:32)
- Quan niệm sai lầm #6: Bạn cần hạ tầng phức tạp như Facebook (04:32-04:54)
- Quan niệm sai lầm #7: AI sẽ sớm thay thế lập trình viên (04:54-05:30)
- Giải pháp: Xây dựng nền tảng giải quyết vấn đề vững chắc (05:30-06:05)
Nhìn nhận lại hành trình lập trình
Video bắt đầu với một chia sẻ khá thú vị – tác giả nhận ra rằng phần lớn thời gian trưởng thành của anh ấy đã dành cho việc viết mã nguồn. Và một sự thật phũ phàng: phần lớn mã đó là “rác rưởi hoàn toàn” – những đoạn mã chưa bao giờ được đưa lên máy chủ thực tế, bị bỏ rơi, viết lại, hoặc nằm im trong “nghĩa địa” của GitHub.
Điểm Chính:
- Nhiều “cách làm tốt nhất”, “khuôn khổ công nghệ thịnh hành”, và cấu trúc thư mục “hoàn hảo” thực ra không quan trọng với người dùng cuối
- Tác giả đã lãng phí vô số giờ để theo đuổi những “con rồng lập trình” tưởng chừng làm mình hiệu quả hơn nhưng cuối cùng chẳng đi đến đâu
Ý Kiến Của Mình:
Mình nghĩ đây là trải nghiệm mà hầu hết lập trình viên đều gặp phải. Chúng ta thường bị cuốn vào việc làm mọi thứ “đúng đắn” theo tiêu chuẩn nào đó mà quên đi mục tiêu chính: tạo ra sản phẩm hữu ích cho người dùng. Đôi khi, “làm xong còn tốt hơn làm hoàn hảo” thực sự là châm ngôn đáng để suy ngẫm đấy!
Quan niệm sai lầm #1: Bạn cần dùng công nghệ mới nhất để theo kịp thời đại
Một trong những quan niệm sai lầm phổ biến nhất là bạn cần sử dụng công nghệ mới nhất để luôn theo kịp thời đại. Nhưng thực tế, bạn có thể trở nên “dễ được tuyển dụng hơn” bằng cách tập trung vào những công nghệ “khủng long” cũ kỹ như WordPress và PHP – vẫn đang chạy hầu hết các ứng dụng web, Java vẫn đang vận hành phần lớn thế giới doanh nghiệp, và hầu hết cơ sở dữ liệu vẫn dựa trên SQL.
Điểm Chính:
- Công nghệ “khủng long” như PHP, Java, SQL và C++ vẫn đang vận hành phần lớn các hệ thống quan trọng
- Có nhiều công nghệ “mới sáng bóng” thay thế như Next.js, Kotlin, NoSQL, và Rust
- Nỗi sợ bỏ lỡ (FOMO) khiến chúng ta cảm thấy phải theo kịp công nghệ tiên tiến nhất
- Hệ thống ngân hàng quan trọng vẫn chạy trên COBOL và Java sẽ vẫn là nền tảng cho 3 tỷ thiết bị trong tương lai dài
Ý Kiến Của Mình:
Mình hoàn toàn đồng ý với quan điểm này! Trải nghiệm của mình cho thấy nhiều dự án thực tế vẫn đang sử dụng những công nghệ “cũ” vì lý do đơn giản: chúng đáng tin cậy. Một ví dụ điển hình được đề cập trong video là về Fauna – một cơ sở dữ liệu “thịnh hành” từ các kỹ sư Twitter nhưng cuối cùng đã thất bại, khiến những người áp dụng sớm gặp rắc rối. Đôi khi, cái nhàm chán lại đẹp đẽ – đặc biệt khi nói đến hạ tầng công nghệ!
Quan niệm sai lầm #2: Chỉ có một cách đúng để viết mã
Trong lập trình, có rất nhiều cách để giải quyết cùng một vấn đề, nhưng một số người tin rằng chỉ có MỘT cách “đúng đắn” để viết mã. Hai “giáo phái” phổ biến là “những người thuần túy hướng đối tượng” và “những người cực đoan về lập trình hàm”.
Điểm Chính:
- Có nhiều “giáo phái” trong lập trình như lập trình hướng đối tượng thuần túy và lập trình hàm cực đoan
- Dành cả đời để theo đuổi chỉ một mô hình lập trình là lãng phí thời gian
- JavaScript là ngôn ngữ “đa mô hình” có thể thỏa mãn nhiều “giáo phái” khác nhau
- Năm 2018, lập trình hàm được phục hưng trong phát triển web, khiến việc sử dụng lớp bị coi là “tệ hại không thể chấp nhận”
Ý Kiến Của Mình:
Mình đã từng là “nạn nhân” của giáo điều này! Khi mới học React, mình cứ nghĩ rằng thành phần hàm với hooks là cách duy nhất “đúng đắn”, và thành phần lớp là “mã cũ lỗi thời”. Nhưng thực tế, mỗi cách tiếp cận có ưu điểm riêng và việc kết hợp những bài học từ nhiều mô hình lập trình khác nhau sẽ giúp bạn trở thành lập trình viên toàn diện hơn. Lập trình thực dụng hơn lập trình giáo điều, đúng không?
Quan niệm sai lầm #3: Mã sạch là chân lý
“Mã sạch” – cuốn sách huyền thoại của Bob Martin (thường được gọi là Chú Bob) được coi là “cẩm nang cho nghề thủ công phần mềm linh hoạt”. Hầu hết lời khuyên trong sách đều tuyệt vời: đặt tên có ý nghĩa, viết hàm nhỏ, sử dụng định dạng nhất quán… Nhưng một số lời khuyên lại có nhiều điểm cần xem xét kỹ hơn.
Điểm Chính:
- Nguyên tắc DRY (Đừng Lặp Lại Chính Mình) nghe có vẻ hợp lý nhưng có thể dẫn đến kỹ thuật quá mức cần thiết
- Cố gắng giữ mã “sạch” quá mức có thể dẫn đến “vô số lớp bọc, giao diện, và sự chuyển hướng vô nghĩa”
- Tê liệt vì phân tích: dành quá nhiều thời gian viết lại mã thay vì xây dựng tính năng thực tế
- Tác giả đề xuất nguyên tắc RUG (Lặp Lại Cho Đến Khi Tốt): chấp nhận mã trùng lặp lúc đầu, rồi viết lại khi sự lặp lại trở nên khó chịu
Ý Kiến Của Mình:
Mình đã từng ám ảnh về việc áp dụng mọi nguyên tắc trong “Mã sạch” và kết quả là… dự án không bao giờ hoàn thành! Nguyên tắc RUG (Lặp Lại Cho Đến Khi Tốt) là một cách tiếp cận thực tế hơn nhiều: mã trùng lặp ban đầu không phải là việc tồi tệ, và việc viết lại mã chỉ nên được thực hiện khi thực sự cần thiết. Trừu tượng hóa quá sớm là nguồn gốc của nhiều vấn đề, nhé!
Myth #4: 100% test coverage = code an toàn
Test-driven development và testing nói chung đều rất giá trị, nhưng quan niệm cho rằng 100% test coverage đồng nghĩa với code được bảo vệ tốt là một myth lớn. Sếp của bạn, người không có kinh nghiệm lập trình, có thể rất thích công cụ code coverage vì nó cho thấy bao nhiêu phần trăm source code được thực thi khi chạy test suite.
Điểm Chính:
- Tối ưu hóa để đạt 100% coverage thường là lãng phí thời gian và có thể gây hiểu lầm
- Coverage cao không đồng nghĩa với chất lượng cao
- Tối ưu coverage khuyến khích developers viết những test vô nghĩa chỉ để “chạm” vào các dòng code mà không bắt được bugs thực sự
- Điều này tạo ra false sense of security và làm CI builds chậm hơn (tốn tiền hơn)
- Đối với test coverage, chất lượng quan trọng hơn số lượng
Ý Kiến Của Mình:
Mình đã từng làm việc trong team đặt KPI là đạt 95% test coverage, và kết quả là chúng mình viết vô số test vô nghĩa chỉ để tăng con số đó! Thực tế, một vài unit test và integration test chất lượng cao tập trung vào business logic quan trọng còn giá trị hơn 100 test chỉ để tăng coverage. Focus on testing what matters, not what’s easy to test!
Quan niệm sai lầm #5: Luôn tối ưu hiệu năng
Một việc lãng phí thời gian khác là đánh giá hiệu năng và tối ưu hóa mã nguồn không chạy ở quy mô đủ lớn để biện minh cho những nỗ lực tối ưu đó. Điều quan trọng hơn nhiều là đảm bảo mã của bạn chính xác, và chỉ tối ưu hóa hiệu năng khi trở nên rõ ràng rằng mã của bạn “hoạt động tệ khi triển khai thực tế”.
Điểm Chính:
- Tối ưu hóa quá sớm là lãng phí thời gian
- Đảm bảo mã chạy đúng quan trọng hơn mã chạy nhanh
- Chỉ nên tối ưu hóa khi có vấn đề thực sự về hiệu năng trong môi trường thực tế
Ý Kiến Của Mình:
Donald Knuth đã nói: “Tối ưu hóa quá sớm là nguồn gốc của mọi điều xấu” và mình không thể đồng ý hơn! Mình đã từng dành cả tuần để tối ưu một hàm chạy nhanh hơn vài phần nghìn giây… mà chỉ được gọi vài lần mỗi ngày. Thay vì ám ảnh với việc tối ưu nhỏ lẻ, hãy tập trung vào những điểm nghẽn thực sự ảnh hưởng đến trải nghiệm người dùng nhé!
Quan niệm sai lầm #6: Bạn cần hạ tầng phức tạp như Facebook
Bạn không cần phải tối ưu hóa hạ tầng đám mây như thể bạn sắp mở rộng quy mô như Facebook. Tác giả từng nghĩ rằng anh ấy cần một “kiến trúc vi dịch vụ không máy chủ phức tạp với phân mảnh toàn cầu và bộ nhớ đệm biên”, nhưng hóa ra một máy chủ ảo nhỏ là hoàn toàn đủ cho 5 người dùng của anh ấy.
Điểm Chính:
- Không cần xây dựng hạ tầng phức tạp khi bạn không có quy mô như các công ty công nghệ lớn
- Một máy chủ ảo đơn giản có thể đủ cho nhiều dự án nhỏ và vừa
- Kỹ thuật quá mức cho hạ tầng là một việc lãng phí thời gian phổ biến
Ý Kiến Của Mình:
Mình đã từng bị cuốn vào việc xây dựng kiến trúc vi dịch vụ phức tạp cho một ứng dụng… chỉ có vài trăm người dùng! YAGNI (“Bạn Sẽ Không Cần Nó”) là nguyên tắc quan trọng cần nhớ. Bắt đầu đơn giản, mở rộng khi cần thiết – đừng tối ưu cho vấn đề bạn chưa gặp phải!
Quan niệm sai lầm #7: Trí tuệ nhân tạo sẽ sớm thay thế lập trình viên
Cuối cùng, chúng ta đến với “con voi trong phòng” – quan niệm rằng trí tuệ nhân tạo sẽ sớm thay thế tất cả lập trình viên. Có nhiều công cụ trí tuệ nhân tạo viết mã tuyệt vời, nhưng ngày càng rõ ràng rằng nhiều lập trình viên đang lãng phí thời gian vì phụ thuộc quá nhiều vào trí tuệ nhân tạo.
Điểm Chính:
- Claude Sonnet 3.7 giỏi viết mã nhưng cũng nổi tiếng với việc viết quá dài dòng
- Bạn có thể yêu cầu trí tuệ nhân tạo xây dựng một trang web đơn giản và nó sẽ tự động tạo ra một khuôn khổ JavaScript mới từ đầu
- Vì quên cách viết mã, bạn sẽ chỉ chấp nhận và tiếp tục cuộc sống
- Công cụ lập trình trí tuệ nhân tạo vừa là công cụ tăng năng suất lớn nhất, vừa có thể là thứ lãng phí thời gian lớn nhất nếu sử dụng không đúng cách
Ý Kiến Của Mình:
Mình thấy điều này quá đúng! Trí tuệ nhân tạo như ChatGPT hay GitHub Copilot đã giúp mình rất nhiều trong việc viết mã nhanh hơn, nhưng đôi khi lại khiến mình lười suy nghĩ về giải pháp. Không hiếm khi trí tuệ nhân tạo đưa ra những giải pháp phức tạp không cần thiết hoặc thậm chí có lỗi tinh vi. Ai cũng cần một nền tảng vững chắc để biết khi nào nên tin trí tuệ nhân tạo và khi nào nên tự mình xử lý vấn đề. Trí tuệ nhân tạo nên hỗ trợ, không phải thay thế kỹ năng của bạn!
Giải pháp: Xây dựng nền tảng giải quyết vấn đề vững chắc
Chìa khóa để thành công là có nền tảng vững chắc trong giải quyết vấn đề. Fireship giới thiệu Brilliant – nền tảng học tập tương tác giúp bạn học các khái niệm toán học và khoa học máy tính nhanh chóng.
Điểm Chính:
- Mã lập trình vô dụng nếu bạn không hiểu toán học và khoa học máy tính đằng sau nó
- Brilliant cung cấp các bài học ngắn, thú vị và tương tác – phương pháp được chứng minh hiệu quả gấp 6 lần so với xem video bài giảng
- Quan trọng nhất, bạn sẽ xây dựng kỹ năng tư duy phản biện thông qua giải quyết vấn đề, không phải ghi nhớ
- Trước khi nhảy vào “Lập trình theo cảm hứng”, nên học khóa “tư duy và lập trình” để xây dựng nền tảng giải quyết vấn đề bền vững
Ý Kiến Của Mình:
Mình hoàn toàn đồng ý với tầm quan trọng của kỹ năng giải quyết vấn đề! Bất kể công nghệ nào đang thịnh hành, khả năng tư duy logic và giải quyết vấn đề sẽ luôn có giá trị. Thay vì học khuôn khổ mới mỗi 6 tháng, hãy đầu tư vào những kỹ năng nền tảng như thuật toán, cấu trúc dữ liệu, và thiết kế hệ thống – những kỹ năng sẽ theo bạn suốt sự nghiệp!
