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.