Dạo này lướt TikTok, Facebook, thỉnh thoảng tôi – một “fossil” (hóa thạch) freelancer ~U40 – lại thấy các bạn tranh luận nảy lửa. Chủ đề hot nhất có vẻ là: “Code nghiệp dư mới viết query trực tiếp, ‘pro’ phải dùng Stored Procedure (SP) cho mọi thứ!”.

Nghe xong, tôi chỉ biết cười trừ, lắc đầu nhớ lại thời “trẻ trâu” của mình.

Các bạn nói SP bảo mật hơn (chống SQL Injection), chạy nhanh hơn (vì pre-compiled), tái sử dụng tốt hơn… Vâng, về lý thuyết, sách giáo khoa viết thế, không sai!

Nhưng các bạn à, sách giáo khoa nó khác với cái “thực tế phũ phàng” khi các bạn đi làm, nhất là freelancer, va chạm với 10 loại dự án, 5 loại khách hàng, và 3 loại “deadline dí sml” (sấp mặt luôn).

Là một người đã từng “thề non hẹn biển” chỉ dùng SP, đây là lý do tôi phải “quay xe” trong 80% các dự án hiện đại:

1. Ác mộng mang tên “Version Control” (Quản lý phiên bản)

Đây là cái “đau” nhất.

Code ứng dụng (C#, Java, Node.js) của các bạn nằm gọn gàng trên Git. Bạn feature/them-chuc-nang-A, bạn fix/bug-B. Mọi thứ rõ ràng.

Giờ bạn dùng SP. Cái SP đó nằm ở đâu? Nó nằm dưới Database.

Bạn sửa 1 cái SP. Làm sao bạn đồng bộ nó với cái branch code của em? Bạn viết script ALTER PROCEDURE à? Bạn commit cái file .sql đó lên Git à?

Rồi 10 ông dev cùng sửa 1 cái SP? Merge kiểu gì? Khóc thét!

Chưa kể dự án có CI/CD (DevOps). Deploy code thì dễ, auto-deploy thay đổi database (mà cụ thể là SP) nó là cả một câu chuyện “đau thương” mà chỉ người trong cuộc mới hiểu. Trong khi dùng ORM (như Entity Framework, TypeORM), mình chỉ cần “Code-First” rồi chạy migration, khỏe re.

2. “Đi tìm logic” – Cuộc phiêu lưu mệt mỏi

Dự án to lên, business logic (logic nghiệp vụ) bắt đầu phức tạp. Khi dùng SP, logic của các bạn bị xé ra làm hai:

• Một nửa nằm trong code (Application Layer).
• Một nửa nằm trong Database (Stored Procedures).

Tưởng tượng bạn nhận bug: “Anh ơi, sao đơn hàng X không tự động giảm giá 10%?”.

Bạn bắt đầu hành trình: Lục code… không thấy. À, chắc nó nằm dưới SP. Bạn mở cái sp_CalculateOrderTotal dài 1000 dòng, viết bằng T-SQL (thứ ngôn ngữ “tù” hơn C# hay JS vạn lần), với 15 cái IF...ELSE, 10 cái JOIN, 5 cái TEMP TABLE.

Bạn debug cái SP đó kiểu gì? PRINT à? Chúc bạn may mắn.

Trong khi nếu logic nằm hết trong code, mình chỉ cần đặt “breakpoint”, F10, F11 vài phát là ra bug.

3. “Khóa cổ” vào một Database (Vendor Lock-in)

Đây là cái freelancer rất sợ. Hôm nay bạn viết 500 cái SP bằng T-SQL cho SQL Server. Mọi thứ chạy mượt. Ngày mai, khách hàng bảo: “Ngân sách eo hẹp quá, mình chuyển sang PostgreSQL (miễn phí) đi em.”

Toang!

Toàn bộ 500 cái SP đó (vốn chứa logic nghiệp vụ) gần như phải viết lại từ đầu vì cú pháp khác nhau.

Nếu bạn viết logic trong code (dùng ORM), bạn chỉ cần đổi cái “ConnectionString”, cài cái “Provider” (driver) cho Postgres. Xong! Code nghiệp vụ giữ nguyên 99%.

4. Cái “Nhanh hơn” nó có thật sự “Nhanh”?

Ngày xưa, 15-20 năm trước, SP nhanh hơn rõ rệt. Giờ thì sao? Các ORM hiện đại quá thông minh rồi. Chúng biết “parameterize” (chống SQL Injection y hệt SP), biết “caching query plan” (cũng gần như pre-compiled).

Trừ khi bạn làm báo cáo (reporting) siêu nặng, xử lý dữ liệu hàng loạt (batch processing) cả triệu record, còn với 90% các nghiệp vụ CRUD (Create, Read, Update, Delete) thông thường, sự chênh lệch hiệu năng giữa SP và một câu query tối ưu (viết bằng Dapper hay EF Core) là không đáng kể.

Đánh đổi sự “nhanh hơn 0.01 giây” để lấy mớ “ác mộng” ở mục 1, 2, 3? Mình xin kiếu.

Khi nào thì “ông chú” này dùng SP?

Tất nhiên, SP không phải là rác. Mình vẫn dùng khi:

1. Làm báo cáo phức tạp: Những cái query JOIN 10 bảng, GROUP BY 5 tầng, PIVOT các kiểu. Nhét nó vào SP cho gọn code.
2. Xử lý dữ liệu lớn/theo lô: Cần import/export 1 triệu dòng, chạy job đêm… SP xử lý mấy cái này “nuốt” tốt hơn code ứng dụng.
3. Bảo mật cực cao: Một số nghiệp vụ yêu cầu ứng dụng không được phép SELECT trực tiếp vào bảng, mà chỉ được gọi qua SP (đã được phân quyền EXECUTE) để che giấu cấu trúc bảng. (Hiếm, nhưng có).

Túm cái váy lại…

Các bạn à, nghề lập trình không có “viên đạn bạc” (silver bullet) – tức là không có công nghệ nào “đúng” cho mọi trường hợp.

Việc các bạn cuồng tín SP (hoặc bất cứ thứ gì) và chê bai cách làm khác chỉ cho thấy các bạn … chưa “va chạm” đủ nhiều thôi.

Hãy dùng não, phân tích bối cảnh dự án, ưu nhược điểm của từng cái, rồi hãy chọn. Đừng vì thấy ai đó trên TikTok bảo “dùng SP mới pro” mà vội tin sái cổ.

Tools (công cụ) là để phục vụ mình, chứ đừng làm nô lệ cho tools.

Thân ái và chúc bớt “cuồng tín”! Một Freelancer già hay lướt TikTok.

The post Gửi các em GenZ mê Stored Procedure: “Không phải cứ nhét hết vào SP là ‘pro’ đâu!” first appeared on HaiNH.

Dạo này lướt các diễn đàn hay “tóp tóp”, tôi thấy anh em developer (cả trẻ lẫn “già”) hay khoe và tranh luận sôi nổi về một chủ đề muôn thuở: Code đẹp và Sạch.

Nào là “senior thì code phải gọn, phải clean”, “code phải theo chuẩn SOLID”, “mọi function phải < 10 dòng”, và tất nhiên, “phải đầy đủ comment” như một bài văn mẫu.

Đừng hiểu lầm tôi, với tư cách là một người đã “cày cuốc” trong ngành này đủ lâu, tôi hoàn toàn đồng ý rằng đó là những thói quen tuyệt vời. Code sạch giúp chúng ta dễ bảo trì, dễ mở rộng, và giúp đồng đội (hoặc chính chúng ta 6 tháng sau) đọc lại code mà không muốn… “nghỉ việc”.

Nhưng, (luôn có một chữ “nhưng” lớn) tôi thấy dường như mọi người đang biến nó thành một thứ tiêu chuẩn vàng duy nhất để đánh giá một lập trình viên.

Hôm nay, từ góc nhìn của một “lão làng” đã từng code “nhanh”, code “ẩu” rồi lại code “đẹp”, tôi muốn chia sẻ một quan điểm có thể hơi khác một chút:

“Code đẹp” có quan trọng bằng “Coder tốt” không?

OK, nói thẳng: Với anh em mình, đặc biệt là dân freelance hoặc làm product “nhà trồng”, code là “vốn lưu động”. Mà đã là “vốn” thì phải “xoay vòng” nhanh. Khi bạn bắt đầu tự code – tự kiếm sống, mọi quan điểm về “đẹp” hay “xấu” của code đều thay đổi. Khi tiền, deadline, và khách hàng cùng gõ cửa, thứ quan trọng nhất không phải là code “sạch”, mà là code mang lại giá trị nhanh và hiệu quả nhất.

Code là chi phí. Sản phẩm mới là nguồn thu.

Làm freelancer, tôi tự bỏ công, bỏ thời gian – đó là vốn đầu tư của mình.
Mỗi dòng code là một chi phí cơ hội.
Còn sản phẩm tôi viết ra – đó mới là tài sản sinh lời.

Nếu ví freelancer như một doanh nghiệp mini, thì:

Và giống như doanh nghiệp,

Freelancer không sống bằng code đẹp, mà sống bằng sản phẩm được dùng, được trả tiền.

Kịch bản 1: “Vay Nóng” để “Chớp Deal” (Code Nhanh)

Đây là thực tế ở Việt Nam: Khách hàng (đặc biệt là khách SME) tìm đến bạn và nói:

“Hải ơi, anh/chị cần làm gấp cái web bán hàng “mì ăn liền”. Tuần sau bên chị khai trương rồi! Chạy được là được!”

Ngân sách? Vừa phải. Deadline? “Cháy máy”.

Lúc này, bạn là “con buôn” đứng trước một “mối hàng” (deal).

• Lựa chọn A (Đầu tư dài hạn – Code Sạch): Bạn mở VS Code, set up project NestJS/Spring Boot, thiết kế Clean Architecture, chia 3-4 layer, viết Unit Test…
  • Kết quả: 2 tuần sau code vẫn “sạch” nhưng chưa “chạy”. Khách “lặn” mất tăm, họ đã tìm một bên khác làm bằng… WordPress/PHP thuần trong 3 ngày. Bạn “ôm” đống code sạch đó… để ngắm. Bạn “lỗ vốn” thời gian.
• Lựa chọn B (“Vay Nóng” – Code Nhanh): Bạn “vã” thẳng. Có thể là ExpressJS một file, hoặc PHP vứt thẳng logic vào file index.php.
  • Kết quả: 4 ngày xong. Web chạy. Khách “ok” chuyển khoản. Bạn có tiền.
  • Đây chính là “vay nóng kỹ thuật”. Bạn chấp nhận “lãi suất cao” (sau này code này bảo trì “muốn khóc”), để đổi lấy “vốn” (tiền) ngay lập tức.

Với các dự án nhỏ, dự án “thời vụ”, một “coder tốt” là một “con buôn” giỏi, biết khi nào cần “đánh nhanh thắng nhanh” để thu tiền về.

Kịch bản 2: “Trả Nợ” và “Đầu Tư” (Code Sạch)

Cái shop “mì ăn liền” kia bỗng làm ăn “phất” lên. 6 tháng sau, họ quay lại:

“Hải ơi, giờ chị muốn nâng cấp. Làm cho chị cái module quản lý kho, tích hợp Giao Hàng Tiết Kiệm, với thanh toán MoMo.”

Đây! “Tiền” đây! Họ sẵn sàng “xuống tiền” (pay) cho một thứ “xịn”.

Lúc này, nếu bạn lôi đống code “vay nóng” ngày xưa ra để “chắp vá”, bạn sẽ “chết”. Sửa một chỗ, sập 3 chỗ.

Đây là lúc “con buôn” trở thành “nhà đầu tư”.

Bạn nói với khách: “OK chị, để nâng cấp, em cần ‘đập đi xây lại’ phần lõi cho nó ‘chịu tải’ (scalable) và ổn định.”

Giờ là lúc bạn “trả nợ”: Dùng NestJS, dùng kiến trúc “xịn”, viết test. Bạn “đầu tư” code sạch, vì bạn biết cái “hệ thống” này giờ là “cỗ máy kiếm tiền” dài hạn cho cả bạn và khách.

Các dự án lớn có “code bẩn” lúc đầu không?

Câu trả lời là: CHẮC CHẮN CÓ!

Facebook những ngày đầu là minh chứng sống.
Mark Zuckerberg từng nói:

“Move fast and break things.”
(Di chuyển nhanh và phá vỡ mọi thứ.)

Câu này không dành cho “code đẹp” đâu — mà là “code nhanh”.

Facebook tập trung toàn lực vào việc thu hút người dùng, tăng trưởng, và chiếm thị trường.
Họ chấp nhận nợ kỹ thuật (technical debt) để đổi lấy tốc độ.
Code ban đầu chắc chắn lộn xộn nếu soi bằng tiêu chuẩn ngày nay.

Nhưng khi họ đã lớn mạnh, có người, có tiền, có thời gian, họ mới bắt đầu “trả nợ”:

• Viết lại toàn bộ hệ thống.
• Xây dựng React.
• Tạo ra ngôn ngữ Hack (từ PHP).

“Chuẩn hoá” đến sau khi thành công — và đó là lựa chọn chiến lược.

Kết luận: Đừng “sùng bái” Clean Code một cách mù quáng. Hãy hỏi: “Cái ‘deal’ này cần ‘quay vòng vốn’ nhanh hay ‘đầu tư’ dài hạn?”

The post “Code đẹp” có quan trọng bằng “Coder tốt” không? first appeared on HaiNH.

Hiểu rõ các vấn đề trước khi code.

Những lập trình viên giỏi thực sự là người rất cẩn thận khi coding, bằng việc tập trung vào chất lượng code chứ không số lượng. Người lập trình viên trung bình rất thích code, họ dường như ngồi lì trước máy tính hầu hết thời gian để sinh ra hàng đống code nhưng chất lượng chương trình của họ có hoặc không thể làm việc hiệu quả, thường gặp bug và họ phải sửa chúng nhiều lần. Việc “viết code và fix bug” này làm phí hoài thời gian và chẳng bao giờ đạt tới chất lượng như khách hàng mong đợi. Đoạn code tốt được tạo ra bởi người lập trình viên có kỉ luật, họ biết từng vấn đề gặp phải cần mất bao lâu thời gian, lập kế hoạch cẩn thận về cách tiếp cận của mình để đảm bảo rằng họ hoàn thành nhiệm vụ tương ứng.

Với mọi vấn đề đều có nhiều cách giải quyết nó nhưng người lập trình viên giỏi nhất sẽ cố gắng hiểu vấn đề trước khi làm bất cứ cái gì. Bằng việc hiểu vấn đề, người đó sẽ suy nghĩ cẩn thận về cách giải quyết nó và thảo luận nó với team của mình và tìm ra giải pháp tốt nhất. Việc lắng nghe các giải pháp từ mọi người sẽ khiến bạn nhìn nhận một vấn đề theo hướng đa chiều, thảo luận và tìm ra giải pháp tốt nhất cho vấn đề đó. Bằng việc nhìn vào vấn đề, hình dung ra kết quả, người đó sẽ hình dung mình cần giải quyết nó trong bao lâu. Ngược lại, với những lập trình viên trung bình sẽ ngay lập tức bắt đầu viết mã trước mà không suy nghĩ và rồi sửa nó nếu nó không đáp ứng yêu cầu. Kiểu “code trước tính sau ” và “sửa rồi code tiếp” này sẽ chẳng bao giờ tạo ra những phần mềm thực sự chất lượng cả, bởi vì họ càng sửa nó, họ sẽ càng tiềm ẩn bug trong tương lai.

Cùng chia sẻ để thành công.

Người lập trình viên giỏi nhất thường thích chia sẽ những công nghệ mới với team của mình và học lẫn nhau. Họ biết rằng bằng việc chia sẻ, họ sẽ học được nhiều hơn, thế nên khi họ tiếp cận công nghệ mới, họ sẽ thảo luận với team về những gì cần thiết cho công việc hiện tại để áp dụng, phần khác, nó giúp mọi người tránh mất thời gian và sai lầm thay vì tự mày mò nó một mình. Với những lập trình viên giỏi, họ luôn cố gắng trở nên tốt hơn bằng việc làm cho người khác giỏi hơn. Họ luôn tìm kiếm lời khuyên từ những người thâm niên trong ngành bởi vì những người này có kinh nghiệm, đã trải qua nhiều dự án và họ thường có những câu trả lời chính xác. Việc teamworks sẽ khiến công việc trở nên dễ dàng, khiến dự án có thể dễ dàng thành công hơn ngồi làm một mình.

Người lập trình viên trung bình có thể rất giỏi chuyên môn nhưng họ có tính khá giống một người hùng, được người khác thừa nhận nên họ không thích chia sẻ và giữ thông tin cho riêng mình, trong trường hợp này họ đánh mất giá trị của mình, vì thực sự, trong ngành công nghệ phần mềm, công việc cần sự chung tay từ mọi người và nếu trong một team mà có quá nhiều người thích tỏ ra anh hùng thì chung cuộc sẽ chẳng có ai thành anh hùng thực sự cả. Cho dù họ giỏi và có thể kết thúc công việc của mình đúng hạn nhưng nếu tất cả mọi người không thể hoàn thành dự án chung thì kết quả sẽ chẳng thể thay đổi. Thất bại vẫn sẽ đến vì sự ích kỷ.

Biết cách sắp xếp công việc.

Một trong những kĩ năng rất quan trọng của những lập trình viên hàng đầu đó là việc họ biết cách sắp xếp công việc. Người lập trình viên trung bình rất giỏi về kĩ thuật nhưng nếu họ không có khả tổ chức, hàng đống công việc cần được thực hiện và cuối cùng sẽ bị tràn ngập bởi sức ép dự án. Người lập trình viên giỏi luôn lên kế hoạch cho công việc của mình và đánh giá tầm quan trọng của dự án với các nhiệm vụ hàng ngày chi tiết và ưu tiên những việc quan trọng trước. Họ sắp xếp công việc hằng ngày, các cuộc họp, nhiệm vụ và cập nhật mọi thứ mà họ phải đạt được trong ngày để cho mọi việc sẽ không bị trì hoãn sang ngày sau. Họ lưu lại tất cả công việc của mình và có thể, báo cáo cho cuộc họp, và cung cấp các chi tiết khác khi được yêu cầu. Bằng cách làm việc theo thời gian biểu lịch biểu, công việc sẽ trở nên đơn giản hơn trong tầm tay, đạt được mục tiêu cuối cùng của dự án.

Ngược lại, người lập trình viên trung bình không nghĩ xa trước mà chỉ làm việc tương ứng với điều người quản lí giao cho họ . Khi có sự thay đổi hoặc vấn đề xảy ra, họ không biết phải ưu tiên cái gì và không có kế hoạch hoàn thành chúng mà dựa vào người quản lí dự án phân công cho họ việc tương ứng. Người lập trình viên giỏi nhất không chỉ nghĩ về mục đích dự án, mà còn hình dung nó và hiểu cách hoàn thành nó bởi vì họ có thể thấy chính xác điều họ phải làm từng ngày, từng tuần, từng tháng để đáp ứng mong đợi.

Không ngừng học hỏi.

Người lập trình viên giỏi nhất sẽ thường xuyên cải tiến kĩ năng của họ. Họ sẽ luôn tìm kiếm tri thức mới và thường không đợi Manager yêu cầu. Họ học điều mới theo cách riêng , bởi vì họ thực sự muốn là người giỏi nhất trong lĩnh vực mà họ biết. Các lập trình viên giỏi thật sự thường quan tâm đến các Event mới về công nghệ, các khóa học mới và họ sẽ chủ động tham dự, học hỏi những công nghệ mới để phát triển bản thân, cũng như mong muốn đóng góp các kiến thức mới vào công việc

Những lập trình viên trung bình không thích học cái mới nhiều bởi vì họ tin rằng họ đã tốt nghiệp đại học, đã có bằng cấp và biết “đủ để làm việc của mình”. Họ bằng lòng với điều đang có nhưng có lẽ, các bạn ấy quên rằng, công nghệ sẽ luôn thay đổi từng giây, và có lẽ sau vài năm nữa, các bạn ấy nên lo lắng về kĩ năng của mình liệu có đủ khả năng để đáp ứng được công việc hiện tại hay không. Công nghệ phần mềm là ngành rất năng động và nếu người ta không giữ cùng nhịp với sự thay đổi của công nghệ, họ có thể bị đào thải.

Có nhiều lập trình viên trung bình trong công nghiệp ngày nay nhưng có rất ít “lập trình viên giỏi thực sự”. Lí do thật đơn giản: ngày nay rất ít trường dạy cách làm việc nhóm trong chương trình đào tạo lập trình viên. Lập trình viên trung bình có thể giỏi về kĩ thuật nhưng lại nghèo nàn kiến thức làm việc nhóm và sắp xếp hệ thống công việc hằng ngày.

Không có đam mê, bạn sẽ không bao giờ vươn xa trong sự nghiệp lập trình viên cả. Thiếu đam mê chính là lí do chính tạo nên việc rất nhiều lập trình viên không thể trở thành giỏi cho dù họ có kiến thức và có cố gắng bằng mọi cách. Tất nhiên ai cũng hiểu, ngồi làm việc bạn không thích sẽ chẳng bao giờ mang lại kết quả tốt nhất.

Bài viết được mình tham khảo từ nguồn topitworks.com

The post Lập trình viên giỏi và lập trình viên trung bình khác nhau như nào ? first appeared on HaiNH.