YAGNI trong phát triển ứng dụng: nó là gì, bản chất của nguyên tắc và lợi ích thực tế

YAGNI là gì?

YAGNI (You Aren't Gonna Need It) — một nguyên tắc của lập trình cực hạn (XP) có nghĩa là “bạn sẽ không cần nó”. Quy tắc nói: không bao giờ triển khai chức năng không được yêu cầu bởi các câu chuyện người dùng hiện tại. Nếu một tính năng không cần hôm nay — đừng xây dựng nó, ngay cả “để phòng khi”.

Thuật ngữ này được đặt ra bởi Ron Jeffries, một trong những đồng tác giả của phương pháp luận XP (cùng với Kent Beck). Jeffries tuyên bố: “Hãy triển khai thứ đơn giản nhất hoạt động và không thêm gì cho đến khi cần thiết”. YAGNI không phải là cấm lập kế hoạch, mà là cấm triển khai sớm.

Theo Standish Group CHAOS Report (2023), 64% chức năng trong một sản phẩm phần mềm trung bình hiếm khi hoặc không bao giờ được sử dụng. Ngoại suy cho ứng dụng di động — hơn một nửa mã được viết không mang lại giá trị cho người dùng. YAGNI ngăn chặn sự lãng phí tài nguyên này.

Hãy áp dụng YAGNI như một bộ lọc nghiêm ngặt: mọi tính năng phải trả lời câu hỏi “nó giải quyết vấn đề cụ thể nào của người dùng ngay bây giờ?” Nếu không có câu trả lời — tính năng đó không cần thiết.

Sự khác biệt giữa YAGNI và sự lười biếng hay cắt góc

YAGNI không phải là sự từ chối kiến trúc chất lượng. YAGNI cấm viết mã không cần thiết, nhưng không cấm viết mã đúng. Nếu một tính năng hiện tại cần một lớp trừu tượng sạch — hãy tạo nó. Nếu lớp không cần thiết — đừng tạo nó. Sự khác biệt chính: YAGNI là về chức năng, không phải về chất lượng.

Các nhà phát triển thường nhầm lẫn YAGNI với việc cố tình tích lũy nợ kỹ thuật (nợ kỹ thuật luôn là một sự thỏa hiệp, YAGNI là nguyên tắc hiệu quả). Sự khác biệt là nợ kỹ thuật được công nhận và ghi chép lại, trong khi vi phạm YAGNI chỉ đơn giản là công việc thêm.

Hãy tự hỏi: “Nếu tôi không tạo lớp trừu tượng này ngay bây giờ, thì khi cần, việc tái cấu trúc sẽ mất bao lâu?” Nếu thời gian tái cấu trúc ít hơn thời gian viết bây giờ — hãy hoãn lại.

Tại sao YAGNI quan trọng đối với dự án di động?

Phát triển di động đặc biệt nhạy cảm với vi phạm YAGNI vì ba lý do: kích thước APK/IPA ảnh hưởng trực tiếp đến tỷ lệ chuyển đổi cài đặt, thời gian biên dịch của dự án di động tăng tuyến tính với khối lượng mã và mỗi tính năng thêm vào đều tạo thêm điểm hỏng hóc. YAGNI không phải về sự lười biếng, mà về sự tập trung.

Một nghiên cứu của Google Play Console Data (2023) cho thấy: cứ 10 MB kích thước APK làm giảm xác suất cài đặt 1,2%. Mã không được sử dụng không chỉ là rác trong kho lưu trữ — đó là tổn thất tài chính trực tiếp. Các thư viện thêm (cho chức năng mà “có thể sẽ thêm sau”) là nguồn phổ biến nhất của việc phình to APK.

Theo Gradle Build Performance Report (2024), mỗi mô-đun bổ sung trong dự án Android làm tăng thời gian xây dựng hoàn chỉnh thêm 3–7 giây. Nếu bạn thêm 5 mô-đun “để phòng khi” — mức tăng thời gian xây dựng sẽ là 15–35 giây cho mỗi lần xây dựng. Trong một năm, một nhóm 5 nhà phát triển mất tới 200 giờ công chờ biên dịch.

Giám sát kích thước tệp nhị phân trong CI: đặt giới hạn cảnh báo (ví dụ: +500 KB cho mỗi commit). Nếu kích thước tăng lên mà không có tính năng mới — đó là vi phạm YAGNI cần được thảo luận trong quá trình đánh giá mã.

YAGNI so với mạ vàng: ví dụ thực tế

Mạ vàng: hoạt ảnh sớm

Mạ vàng (Gold-plating) — thêm chức năng vượt quá yêu cầu để cố gắng “cải thiện” sản phẩm. Một ví dụ điển hình: nhà phát triển thêm hoạt ảnh chuyển tiếp phức tạp giữa các màn hình, mặc dù thiết kế chỉ định một fade đơn giản. Hoạt ảnh mất 2 ngày, người dùng không nhận thấy nó và lỗi trên các thiết bị khác nhau ám ảnh dự án trong nhiều năm.

Theo UX Collective Annual Report (2023), 78% người dùng đánh giá ứng dụng dựa trên tốc độ và độ ổn định, không phải hoạt ảnh. YAGNI nói: nếu hoạt ảnh không được chỉ định trong yêu cầu — đừng triển khai nó. Nhà thiết kế sẽ thêm hoạt ảnh khi thực sự cần thiết để giải quyết vấn đề UX.

Chỉ triển khai những gì có trong bản thiết kế. Nếu nhà thiết kế không vẽ hoạt ảnh — thì nó không nên tồn tại. Bất kỳ sai lệch nào so với bản thiết kế đều là vi phạm YAGNI.

Bản địa hóa sớm sang 20 ngôn ngữ

Một sai lầm phổ biến của các startup: ngay lập tức xây dựng hỗ trợ cho 20+ ngôn ngữ “cho việc thâm nhập thị trường quốc tế trong tương lai”. YAGNI khuyến nghị: chỉ bản địa hóa sang ngôn ngữ của thị trường hiện tại. Thêm mỗi ngôn ngữ mới đòi hỏi thời gian của người dịch, kiểm tra chuỗi bị cắt và gỡ lỗi bố cục RTL.

Theo Deloitte Digital Globalization Survey (2022), 60% ứng dụng di động không bao giờ rời khỏi thị trường đầu tiên của chúng. Nếu đó là trường hợp của bạn — tài nguyên dành cho hỗ trợ đa ngôn ngữ bị lãng phí. Cách tiếp cận YAGNI: tiếng Anh (cơ bản) + ngôn ngữ thị trường mục tiêu. Các ngôn ngữ khác — khi bạn thực sự thâm nhập vào một khu vực.

Sử dụng YAGNI để ưu tiên: nếu một tính năng không có trong lộ trình của hai quý tới — đừng bắt đầu nó. Lộ trình phải được ghi chép và phê duyệt bởi quản lý sản phẩm.

Cách áp dụng YAGNI trong Android và iOS?

YAGNI trong Android: đừng thêm thư viện không cần thiết

Các dự án Android bị lạm phát thư viện. Các nhà phát triển thêm Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — ngay cả trước khi viết dòng logic kinh doanh đầu tiên. YAGNI khuyến nghị: thêm thư viện theo nhu cầu thực tế, không phải phòng ngừa.

// Vi phạm YAGNI: bao gồm thư viện phòng ngừa
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// Và ứng dụng hiện chỉ hiển thị "Hello World"

Thư viện là các phụ thuộc với độ phức tạp riêng của chúng. Mỗi thư viện yêu cầu cập nhật phiên bản, di chuyển khi có thay đổi phá vỡ và làm tăng kích thước APK. Thêm một thư viện khi xuất hiện một nhiệm vụ cụ thể mà thư viện đó giải quyết. Bắt đầu với OkHttp (trình khách HTTP tối thiểu), thêm Retrofit khi bạn cần trình khách REST, và cứ thế tiếp tục.

YAGNI trong iOS: đừng ép SwiftUI

SwiftUI là một framework mạnh mẽ, nhưng việc áp dụng nó nên được thúc đẩy bởi nhu cầu thực tế. Nếu một dự án bắt đầu với iOS 14+ và yêu cầu về thành phần UI tùy chỉnh là tối thiểu — SwiftUI là một lựa chọn tốt. Nếu một dự án phải hỗ trợ iOS 13 hoặc yêu cầu cử chỉ tùy chỉnh phức tạp — UIKit vẫn là giải pháp phù hợp. YAGNI phản đối việc di chuyển sang SwiftUI “bởi vì nó hợp thời”.

// YAGNI: sử dụng UIKit khi chưa có lợi ích thực sự từ SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Hồ sơ"
    }
}

// Nếu cần SwiftUI — tích hợp qua UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Phân tích của Point-Free: “SwiftUI vs UIKit Decision Guide” (2024) khuyến nghị: đừng di chuyển các màn hình UIKit hiện có sang SwiftUI mà không có lý do kinh doanh rõ ràng (ví dụ, nhu cầu Live Preview cho nhà thiết kế). Viết lại mã đang hoạt động là vi phạm trực tiếp YAGNI. SwiftUI — cho màn hình mới, UIKit — cho màn hình hiện có.

Những sai lầm điển hình khi tuân theo YAGNI

YAGNI như cái cớ cho kiến trúc tồi

Sai lầm nguy hiểm nhất là sử dụng YAGNI như cái cớ cho kiến trúc tồi. “Chúng ta sẽ không tạo lớp kho lưu trữ vì YAGNI — chúng ta sẽ viết truy vấn trực tiếp trong ViewModel”. Đây không phải YAGNI, mà là tích lũy nợ kỹ thuật. YAGNI cấm chức năng không cần thiết, không phải tính toàn vẹn kiến trúc.

Kiến trúc là một khoản đầu tư vào khả năng bảo trì. Nếu bạn đang viết hơn 3 màn hình — một lớp kiến trúc cơ bản (MVVM, kho lưu trữ) đã được biện minh. Nếu chỉ 1 màn hình — bạn có thể áp dụng cách tiếp cận đơn giản hơn. Chìa khóa: xác định mức tối thiểu kiến trúc cần thiết cho các tính năng hiện tại và không thêm gì hơn.

Chia các quyết định thành “kiến trúc” và “chức năng”. Các quyết định kiến trúc (lớp, điều hướng, DI) không bị YAGNI chi phối — chúng cần thiết cho khả năng bảo trì. Các quyết định chức năng (tính năng, ảnh chụp màn hình, hoạt ảnh) — bị chi phối.

Mù quáng tuân theo YAGNI khi làm việc với API

Một thái cực khác — bỏ qua các hợp đồng API tương lai. Một nhà phát triển nhận JSON từ backend với 5 trường và chỉ phân tích 3, bởi vì “phần còn lại không cần thiết theo YAGNI”. Vấn đề: khi một trường được thêm vào, backend có thể phá vỡ việc phân tích nếu phản hồi thay đổi. Giải pháp là ánh xạ tất cả các trường phản hồi, ngay cả khi không phải tất cả đều được sử dụng ngay bây giờ.

Theo Meta API Design Guidelines (2023), máy khách phải phân tích tất cả các trường mà máy chủ trả về, bỏ qua những trường không được sử dụng, nhưng không loại bỏ toàn bộ cấu trúc. YAGNI ở đây là về một điều khác: đừng thêm xử lý cho các trường chưa có trong đặc tả “phòng khi backend trả về chúng”.

Phân tích toàn bộ cấu trúc phản hồi (tất cả các trường mà máy chủ hiện đang trả về). Đừng thêm xử lý cho các trường không có trong đặc tả API hiện tại. Đây là sự cân bằng giữa YAGNI và khả năng chống chịu với thay đổi.