Phân tích từ Code "chạy được" đến Code "hoàn hảo"

Chào các bạn, trong các bài post trước, tôi đã giới thiệu ngắn gọn về sự khác biệt trong tư duy code giữa junior và senior devs. Hôm nay, tôi muốn chia sẻ về một chủ đề mà tôi nghĩ sẽ hữu ích cho cả junior và senior developers: sự khác biệt trong tư duy lập trình giữa code chỉ "chạy được", và code "perfect". Đây cũng chính là yếu tố phân biệt rõ ràng giữa yếu tố phân biệt rõ ràng giữa junior và senior devs.

Tôi sẽ đưa ra và phân tích một số case study để chúng ta cùng phân tích nhé.

Code "chạy được" (Just Works): chỉ tập trung vào chức năng cơ bản, thiếu chất lượng và Best Practices

Các bạn developers mới thường ưu tiên làm code hoạt động nhanh chóng, mà chưa chú trọng đến chất lượng. Đây là giai đoạn "survival", code chạy đúng là thành công, nhưng dễ dẫn đến technical debt.

Hãy lấy ví dụ từ .NET trong .NET, một junior dev có thể viết method đơn giản để lấy dữ liệu users:

Nó bình thường và chạy được đúng không :) Giờ ta thử phân tích kỹ hơn:

• Vấn đề Performance: Query SQL dùng SELECT * trả ra toàn bộ bảng, không tối ưu khi dữ liệu lớn, bảng nhiều trường, nhiều cột. Và trong .NET, không sử dụng async/await dẫn đến blocking I/O, làm app chậm khi concurrent requests cao.
• Security Risks: Không dùng parameterized queries (dễ SQL injection). Connection string hard-coded, không dùng configuration.
• Readability & Maintainability: Không có comment, không tuân thủ naming conventions (như PascalCase cho methods). Không có exception handling, nếu connection fail, app crash.
• Testing: Không có unit test. Junior chưa nghĩ đến mock DbContext với Entity Framework để test isolated.
• Scalability: Khi app scale, method này có thể gây connection pool exhaustion vì không dispose đúng cách (mặc dù using có giúp, nhưng chưa optimize).

Code một cảm giác tuyệt vời, một cú "hit" dopamine đầu tiên. Thông thường, nó mang những đặc điểm dễ nhận thấy:

• Tập trung vào "cái gì" (what), không phải "như thế nào" (how).
• Có thể lặp code (vi phạm nguyên tắc DRY - Don't Repeat Yourself).
• Logic phức tạp, khó hiểu, thiếu comment.
• Không xử lý hết các trường hợp ngoại lệ.
• Hiệu năng chưa được quan tâm (ví dụ: query N+1 trong vòng lặp là một "đặc sản").

Tuy nhiên từ kinh nghiệm cho thấy, trong dự án, code kiểu này dẫn đến timeout khi traffic tăng, techdebt, có khi buộc phải refactor toàn bộ.

Code "tối ưu trong phạm vi" (Optimized Within Constraints): cân bằng Best Practices, Performance, và thực tế dự án

Là senior developers, chúng ta không chỉ làm code chạy mà còn tối ưu trong giới hạn thời gian, ngân sách, và team skills. Tư duy thực dụng: áp dụng best practices như code chỉnh chu, comment chi tiết, unit/integration test đầy đủ, và query performance-tuned, nhưng không over-engineer.

Refactor ví dụ trên trong .NET với Entity Framework Core (EF Core) và SQL tối ưu:

Phân tích kỹ hơn đoạn code trên:

• Performance Optimization: dùng async/await và EF Core để tránh blocking. Đồng thời, Query SQL với index trên age (index scan thay full scan), pagination (OFFSET/FETCH) để handle large datasets, giảm thời gian từ giây xuống ms với giảm cả triệu records. Sử dụng projection (Select specific columns) để minimize data load.
• Security & Best Practices: Parameterized auto từ EF, tránh injection. Dependency injection cho DbContext và Logger. Comment xml-style cho để dễ đọc hơn.
• Maintainability: Tuân thủ SOLID (Single Responsibility, method chỉ làm 1 việc). Exception handling với custom exception và logging (e.g., Serilog hoặc Application Insights).
• Testing: Viết unit test với xUnit/Moq: Mock DbSet để test query logic mà không hit real DB. Integration test với InMemoryDatabase để verify SQL generated.
• Trade-offs: Không dùng stored proc nếu EF đủ tốt (giảm complexity). Nếu budget cho phép, thêm caching (DistributedCache) cho frequently accessed data. Và cân nhắc business: Optimize chỉ nếu query chạy thường xuyên.

Khi đã có kinh nghiệm, bạn không còn thỏa mãn với việc code chỉ "chạy được". Bạn bắt đầu đặt câu hỏi:

• Nó chạy có nhanh không?
• Người khác đọc có hiểu không?
• Thêm tính năng mới có dễ không?
• Hệ thống có chịu được tải lớn không?

Đây là lúc tư duy về chất lượng và sự bền vững xuất hiện.

• Áp dụng đủ thứ nguyên tắc thiết kế như SOLID, KISS, DRY.
• Sử dụng cấu trúc dữ liệu và thuật toán phù hợp.
• Viết code sạch, dễ đọc, dễ bảo trì (Clean Code).
• Chú trọng performance: tối ưu câu lệnh SQL, sử dụng caching, xử lý bất đồng bộ (async/await trong .NET).
• Viết Tests để đảm bảo sự ổn định.

Code "HOÀN HẢO" (The Myth of Perfection)

Code hoàn hảo luôn là dộng lực cho cải tiến liên tục, cả server side như .net, java,... hay client side framework như react, vuejs, angular,... nhưng tất cả đó chỉ là ảo tưởng, không tồn tại.

Ngay cả các framework đó cũng thay đổi từng ngày, từ .NET Framework đến .NET 8, từ Angular 13 đến 20, rồi 2 tháng nữa thôi là ra 21 rồi. Nhu cầu + yêu cầu thay đổi, và luôn có trade-offs. Chúng ta cần hiểu rằng pursue perfection có thể delay delivery.

• Tại sao code perfect chỉ là ảo tưởng?: Code .NET "perfect" hôm nay (ví dụ, với LINQ) có thể kém performant khi data lớn, cần thay bằng Dapper cho raw SQL. Query SQL perfect có thể vulnerable với new attacks hoặc outdated với schema changes.
• Rủi Ro: Over-optimize như viết custom ORM thay vì EF dẫn đến maintenance nightmare. Senior tránh gold-plating – ví dụ, không add full auditing nếu không thực sự dùng đến.
• Approach thay thế: Evolutionary design, bắt đầu với code tốt nhất có thể đã, refactor via CI/CD (Azure DevOps). Tận dụng code reviews, static analysis (SonarQube) để cải thiện từng buớc. Trong database, monitor với Query Store để tuning queries liên tục qua từng ngày.

Junior vs Senior: không phải tuổi tác, mà là tư duy và kinh nghiệm xử lý tình huống

Trong lập trình các bạn junior thường tập trung functionality, code .NET, UI nhanh nhưng thường thiếu thiếu validation, test hay comment, query SQL cơ bản. Họ giỏi adopt những tính năng mới, nhưng cần học và có tầm nhìn xa hơn.

Trong khi đó, Senior dev xem xứt hệ thống toàn diện hơn, code .NET chỉnh chu với patterns (Repository, CQRS), validator cẩn thận trên UI, query tuned cho perf, align với business. Và họ mentor để build resilient teams. << làm được chi li như này, thì bạn đã là Senior rồi đấy.

Sự khác biệt lớn nhất giữa một Senior và một Junior không chỉ nằm ở kỹ năng code, mà nằm ở khả năng sự chi li, ra quyết định dựa trên bức tranh toàn cảnh, bao gồm cả kỹ thuật và con người.

Các bạn có đồng ý với quan điểm này không? Dựa vào đây chúng ta cùng thay đổi để bản thân tốt hơn, team tốt hơn được chứ :)

Hãy chia sẻ suy nghĩ và trải nghiệm của bạn ở phần bình luận bên dưới nhé!

#DotNetDeveloper #DatabaseOptimization #SeniorDev #CodeBestPractices #TechMentorship #LinkedInTech #1percentbetter