Coding Conventions – người hùng hay kẻ tội đồ?

Chào mừng bạn đến với Fx Studio. Hôm nay mình xin phép tản mạn về một chủ đề liên quan đến một khái niệm rất quen thuộc đối với các bạn đang cùng làm chung một dự án. Đó chính là Coding Conventions. Đây được xem là kim chỉ nam cho các dự án, nhằm đảm bảo tính thống nhất về mặt coding của team Devs. Tuy nhiên, Coding Conventions cũng có những mặt trái nhất định mà chúng ta sẽ cần cùng nhau tìm hiểu.

Nếu bạn là một người có quen freestyle khi code thì có thể bỏ qua bài viết này.

Bạn vẫn muốn tiếp tục theo dõi bài viết ?. Vậy thì …

Bắt đầu thôi!

Khái niệm về Coding Conventions

Đầu tiên, chúng ta sẽ tìm hiểu về những khái niệm trước. Không phải bất kì lập trình viên nào cũng sử dụng tới Coding Conventions như một thói quen hằng ngày vì chúng ta cần một số điều kiện nhất định thì mới áp dụng nó.

Coding Conventions

Quốc có quốc pháp, gia có gia quy.

(theo Ông bà ta)

Với bất kì một tổ chức hay cá nhân nào đó, thì đều có những quy tắc đặt ra mà bạn phải tuân theo dù có thể là bị bắt buộc hay tự nguyện. Chuyện coding cũng không nằm ngoài lề, bản thân việc coding cũng có những quy tắc nhất định.

Coding Conventions được tạm dịch là quy ước viết Code.

Ví dụ:

• Cách tổ chức cấu trúc thư mục trong project
• Đặt tên cho file, class, biến, hàm …
• Quy ước về cú pháp cho một số câu lệnh
• Cách tương tác giữa các đối tượng, module …
• …

Rất nhiều thứ trên đời này đều có thể trở thành Coding Conventions. Tuy nhiên, đôi lúc nó lại bị hiểu nhầm thành Quy tắc đặt tên (Naming Convention).

Coding Guidelines

Đây là một khái niệm mang tính chất bao quát nhiều hơn. Tuy nhiên, nó lại ít được các bạn lập trình viên biết tới. Mức độ ảnh hưởng của nó là tới cả cộng đồng ngôn ngữ lập trình theo Coding Guidelines đó.

Bao gồm:

• Coding Conventions
• Framework standards
• Language coding standards

Theo một cách đơn giản hơn, bạn chỉ cần hiểu Coding Conventions sẽ áp dụng cho nội bộ một team dự án hoặc một team kĩ thuật trong công ty. Còn Coding Guidelines sẽ là tài liệu hướng dẫn cho mọi lập trình viên của ngôn ngữ đó hay nền tảng đó.

Trong phạm vi bài viết này, ta sẽ dùng Coding Conventions là khái niệm chung cho 2 khái niệm ở trên nhóe. Vì tất cả chúng cũng chỉ là các quy tắc được đặt ra mà thôi.

Người hùng

Tiếp theo, chúng ta sẽ điểm danh lại các lợi ích mà Coding Conventions mang lại cho bạn trước đã.

Teamwork

Thông thường, một team dự án thường sẽ có nhiều người tham gia. Nếu bạn tham gia vào các dự án lớn, thì việc áp dụng Conventions là một điều hiển nhiên. Đơn giản, nó giúp bạn

Biết phải làm gì.

Còn nếu bạn làm một mình hay là freelancer, thì vẫn có thể tự tạo ra những Conventions của riêng bạn. Miễn sao đảm bảo rằng tất cả các dự án mà bạn code là cùng chung một quy tắc.

Ta tiếp tục quay về vấn đề teamwork với những lợi ích mà Coding Conventions mang lại:

• Quy tắc hoạt động của Code Conventions theo tính thống nhất và tuân thủ theo tiêu chuẩn sẽ giúp bạn dễ dàng làm việc hơn. Từ đó thúc đẩy năng suất làm việc nhóm nhanh hơn.
• Khi viết Code bằng Code Conventions, người khác dễ hiểu và nắm bắt được cái mà bạn truyền tải đến.
• Code Conventions có thể tái sử dụng trong nhiều phần mềm và các ứng dụng khác.
• Phần mềm áp dụng Code Conventions dễ dàng nâng cấp và được cải tiến.
• Việc bảo trì hệ thống với Code Conventions trở nên thuận lợi và dễ dàng hơn bao giờ hết.
• …

Các team kĩ thuật hay team dự án thì cũng sẽ sử dụng Conventions như là một tài liệu giáo dục cho các thành viên mới vào dự án của họ.

Giao tiếp

Bạn hiểu rằng: “Ngôn ngữ lập trình thì cũng là một ngôn ngữ”. Ý nghĩa chính mà nó tạo ra vẫn là để phục vụ cho việc giao tiếp. Ở đây, nó chỉ khác là giao tiếp giữa người với máy thay vì người với người.

Với một số phần mềm nhất định, nó sẽ hiểu được các Conventions phổ biến hiện nay. Xem như là một chuẩn giao tiếp chung.

Ví dụ, bạn hãy chú ý tới việc đặt tên class đúng với Conventions, thì Xcode sẽ hiểu được. Sau đó, Xcode sẽ tự động tách từ giúp bạn khi bạn gán class đó cho một UIViewController trên Xib.

Nhưng mà, các dev đã tiến hóa lên một trình độ cao hơn. Họ có thể sử dụng các đoạn code để nói chuyện hay tương tác với nhau. Đôi lúc, bạn chỉ cần nhìn qua 1 đoạn code thì đã biết ý đồ của người viết để lại rồi.

Ví dụ điển hình là chúng ta sẽ không bao giờ đọc lời giải thích ở các trang hướng dẫn mà chỉ cần copy đoạn code và chạy được. Thế là okay rồi!

Quốc tế

Một khi, bạn đã vượt qua cái ao làng để tới đại dương. Thì một lần nữa, Coding Conventions lại phát huy sức mạnh của nó trong việc chuẩn hóa giữa các bên cùng tham gia vào một dự án.

Đôi lúc, trong một dự án không chỉ có một team code, mà còn:

• Các team khác nhau ở các văn phòng khác nhau, quốc gia khác nhau
• Team dự án chia thành nhiều level để thực hiện việc code
• Nhờ tới sự hỗ trợ của ngoại quốc
• …

Nếu như bạn không code chuẩn thì công việc sẽ gặp khó khăn đi rất nhiều. Đặt trong bối cảnh hiện này, khi rất nhiều dev bỏ qua các phần căn bản thì mãi mãi sẽ không tiếp cận được môi trường quốc tế.

Đến một lúc, bạn sẽ thấy rằng:

Code 1 dòng mà viết document tới 1 trang.

Lúc đó, việc siết chặt tuân thủ Conventions lại càng được đầy mạnh hơn nữa.

Kẻ tội đồ

Bản chất của mọi vật mọi/việc đều có hai mặt của nó hết. Tuy nhiên, một số mặt hạn chế của nó lại trở thành điều giết dần giết mòn các bạn mà bạn không hề nhận ra chúng. Điều này còn tệ hại hơn là nhược điểm của chúng. Ta tạm thời gọi tên những mặt hạn chế này là Kẻ tội đồ.

Sự tiến hóa của ngôn ngữ lập trình

Tất cả mã nguồn đều sẽ thành rác.

Đây cũng là một câu châm ngôn mà mình được nghe. Nó đúng trong vài trường hợp nhất định. Nhưng nếu nó đã đúng rồi, thì việc tuân thủ theo Conventions liệu còn có ý nghĩa. Sau đây, là một số điểm theo mình xem là tội đồ của Conventions nhóe!

Đầu tiên, bạn hãy xem qua một ví dụ code nhỏ nhỏ với ngôn ngữ Swift.

typealias KiểuChuỗi = String
var tên : KiểuChuỗi = "Fx Studio"

Đoạn code trên vi phạm khá nặng quy tắc đặt tên trong Conventions. Tuy nhiên, bạn hiểu rằng:

Các ngôn ngữ lập trình đã tiến hóa rất nhiều, tất cả đều muốn cho mọi người tiếp cận lập trình một cách đơn giản hơn.

Không biết đã mất bao lâu để các ngôn ngữ lập trình hiện đại chấp nhận Unicode cho việc đặt tên biến/lớp/hàm … Hoặc bạn tới một ví dụ nữa với Swift.

func hamA(so a: Int) {
    return a
}

hamA(so: 10)

// or

func hamA(_ a: Int) {
    return a
}

hamA(10)

Câu hỏi đặt là: “team của bạn sẽ chọn cách nào để đặt tên cho function?”.

Cho dù chọn cách 1 hay 2, chúng ta đều bỏ phí đi những lợi ích mà Swift (một ngôn ngữ hiện đại) đã cố gắng giúp cho chúng ta. Ta đã hi sinh đi nhiều thêm nhiều lựa chọn hơn nữa để viết 1 đoạn code cho hay.

Tính cập nhật của công nghệ

Điều thứ hai, đó chính là tính cập nhật. Khi bạn nhìn vào phần header của một file code trong dự án mà bạn đang làm. Nó có thể còn lớn hơn tuổi nghề của bạn nữa. Đây là một sự thật đắng cay, bản thân các dự án đều rất chậm chạp trong việc cập nhật công nghệ.

Nhưng mà việc cập nhật của Conventions còn lâu hơn việc cập nhật version hay cập nhật công nghệ trong dự án nữa. Có rất nhiều quy tắc có trước khi bạn sinh ra, theo thời gian nó góp phần cản trở đi nhiều việc coding.

Con người ta sẽ tìm cách fix hay tùy chỉnh lại để cho các mã nguồn hiện tại vẫn chạy tốt với các cập nhật của ngôn ngữ, hay của công nghệ …

Sự phức tạp

Có khi nào, bạn bị giới hạn lại viết một lớp với 200 dòng code chưa. Có thể giải quyết bằng việc tách lớp đó thành nhiều lớp nhỏ. Đấy cũng là một ví dụ cho thấy sự phức tạp mà Conventions gián tiếp gây ra cho bạn.

Hoặc ta xem ví dụ sau để viết một Singleton.

class DataManager {
    
    //singleton
    private static var sharedDataManager: DataManager = {
        let dataManager = DataManager()
        
        //config
        dataManager.configDatabase(databaseName: "BD")
        
        return dataManager
    }()
    
    class func shared() -> DataManager {
        return sharedDataManager
    }
    
    // ...
}

Hoặc bạn có thể làm đơn giản hơn một chút.

static var dataManager = DataManager()

Ví dụ trên, mình chỉ để minh hoạ thôi nhóe. Có thể đúng hoặc cũng có thể sai.

Nhưng mà hầu hết các Conventions đều làm cho việc diễn đạt logic trở nên phức tạp hơn. Và khi trình độ của bạn chưa đủ quản lý, thì bugs là điều không tránh khỏi được.

Các ngôn ngữ, công nghệ đều cập nhật mỗi ngày. Đôi lúc, việc cập nhật quá nhiều mà nhân lực dành cho việc cập nhật Conventions lại không có. Dần dần, Conventions đó sẽ trở thành lạc hậu mà thôi.

Đây là sự thật tồn tại khá nhiều trong hầu hết các team kĩ thuật.

Sáng tạo

Conventions là cứng nhắc, là khuôn khổ, là rập khuôn … nó sẽ giết chết đi

Sự sáng tạo

Đây cũng là hai mặt đối lập nhau về bản chất. Thực sự rằng, việc coding là một việc sáng tạo. Ta sẽ suy nghĩ và diễn đạt suy nghĩ bằng việc viết code. Nhưng chúng ta sẽ phải đưa chúng vào một số quy tắc nhất định.

Có một câu chuyện ở team mình: dòng code của anh Technical Leader tồn tại 5~6 năm rồi. Không một ai dám sửa nó. Rồi tới một lúc, cả team trở thành cái máy code. Dự án dù to dù nhỏ đều áp dụng chung một khung như vậy.

Nó gây tác động tâm lý rất lớn tới các bạn trẻ. Lâu dần, các bạn sẽ sợ không dám đổi mới hay sáng tạo gì. Uây da!

Bản chất của mô hình là gì?

Bạn đã được học qua các mô hình lập trình, ví dụ: MVC, MVVM … Bạn được người ta dạy phải xây dựng project theo một mô hình nào đó. Rằng abc rồi xyz các kiểu vâng vâng. Nhưng bạn có biết rằng:

Bản chất của mô hình là sự tách code mà thôi.

Như vậy, khi nhiều người cùng thống nhất về việc tách code ra các thành phần nhất định. Cùng với cách các thành phần liên lạc với nhau. => Một mô hình mới được hình thành.

Các quy tắc bó buộc con người

Mô hình đóng vai trò quan trọng trong một Coding Conventions của một nền tảng kỹ thuật nào đó. Nhưng đó vẫn là những quy tắc mà con người tạo ra mà thôi. Các quy tắc này sẽ bó buộc bạn.

Có thể bạn được dạy rằng: “Không được tương tác với API (model) tại các View”. Nhưng bạn vẫn biết là chúng ta có thể tương tác ở bất kì đâu trong project đều vẫn được.

Rồi rằng tại sao “Controller phải gồng gánh khổ đau”? Vâng vâng và mây mây … đủ thứ trên đời mà các khứa lead/manager bắt bạn phải tuân theo. Nhưng:

Các quy tắc lại giúp bạn không đánh mất đi bản thân mình.

Trong trường hợp coding, nó giúp bạn code đúng khi bạn chỉ mới là học viên hay tập sự vào nghề mà thôi. Hoặc lý do đơn giản khác là các khứa lead/manager họ không muốn giải thích cho bạn hiểu. Vì

Mệt mà thôi!

Sáng tạo phải dựa trên nền tảng cơ bản

Kiến thức là sự tích lũy

Nên không phải vì “mệt” mà các khứa lead/manager họ không giải thích cho bạn hiểu đâu. Chỉ là trình độ của bạn chưa đủ chín mà thôi. Do đó, cũng để hạn chế một phần “trẻ trâu” trong dự án và các khứa lead/manager khỏi phải bung sức ra gánh còng lưng. Thì bạn cần biết được:

Sáng tạo phải dựa trên nền tảng cơ bản!

Ví dụ, bạn biết được các view hay cell thường sẽ bị tái sử dụng lại (reuse). Và nếu bạn tương tác bất đồng bộ (API) tại đó, thì các đối tượng view đó có khi đã bị giải phóng hết rồi. Bugs tự động xuất hiện mà thôi. NGU!

Nên kiến thức căn bản rất quan trọng. Khi bạn hiểu được MVC, thì bạn có thể sáng tạo ra MVC của riêng bạn. Như bao người đã làm trước rồi: MVP, MV* …  Nó giúp bạn:

• Hạn chế được những nhược điểm của mô hình
• Cứng nhắc của Conventions
• Tùy biến với project cụ thể nào đó
• Đảm bảo được bản chất của vấn đề/đối tượng

Đơn giản vậy thôi, bạn vừa hạn chế được tính trẻ trâu của mình, vừa có tiếng nói và dấu ấn cá nhân riêng trong dự án!

Tạm kết

Bài viết này dựa trên kinh nghiệm và sự quan sát của mình trong việc áp dụng Coding Conventions trong team của mình. Từ việc áp dụng triệt để tới thả lỏng … Có thể, các kinh nghiệm này chỉ ở trong một số trường hợp cụ thể. Nên nếu bạn thấy

• Đúng. Thì hãy like, share và tham khảo nhóe!
• Sai. Thì cũng like, share, nhưng đừng tham khảo nhóe!

Còn vấn đề Coding Conventions – người hùng hay kẻ tội đồ?  thì hãy để cho bạn & các thế hệ sau phán xét.

Okay! Tới đây, mình xin kết thúc bài viết này. Nếu có gì thắc mắc hay góp ý cho mình thì bạn có thể để lại bình luận hoặc gửi email theo trang Contact.

Cảm ơn bạn đã đọc bài viết này!

Written by chuotfx

Hãy ngồi xuống, uống miếng bánh và ăn miếng trà. Chúng ta cùng nhau đàm đạo về đời, về code nhóe!