Tại sao cần tiêu chuẩn hoá?

Có 2 lý do cơ bản để bạn và nhóm của mình cần thiết phải tiêu chuẩn hoá lập trình:

• Tiêu chuẩn hoá lập trình cần phản ánh chân thực và phong phú kinh nghiệm của cộng đồng. Nó phải chứa các Quy tắc/ Thành ngữ đã được chứng minh dựa trên kinh nghiệm và sự hiểu biết vững chắc về ngôn ngữ lập trình đó. Đặc biệt một bộ tiêu chuẩn cần được xây dựng dựa trên nền tảng tài liệu phát triển phần mềm phong phú; tập hợp các quy tắc, hướng dẫn và các phương pháp hay nhất được chọn lọc từ nhiều nguồn riêng rẽ.
• Sự trống rỗng không được chào đón.  Nguyên văn của tác giả là “Nature abhors a vacuum’, nghĩa là tự nhiên thì ghét chân không; nghĩa là tự nhiên luôn có xu hướng lấp đầy chân không. Nếu như bạn không cố gắng tiêu chuẩn hoá lập trình, không thiết lập những quy tắc hợp lý, tức là bạn tạo ra tình trạng “trống rỗng” và thả trôi theo tự nhiên thì điều gì sẽ xảy ra? Các Dev trong team bạn sẽ tự tạo ra quy tắc của họ và lập trình theo “sở thích” hay “quy tắc” mà họ nghĩ ra và họ cho là đúng, nghĩa là họ sẽ lấp đầy chỗ trống mà bạn để lại. Một tiêu chuẩn lập trình được xây dựng theo cách “tự nhiên” như thế này sẽ không thiếu một phẩm chất “tồi” nào. Ví dụ nhiều tiêu chuẩn như vậy thực thi ngôn ngữ C++ theo phong cách ngôn ngữ C tối giản.

Nhiều bộ tiêu chuẩn tồi được thiết lập bởi những người không hiểu rõ ngôn ngữ lập trình hoặc không hiểu rõ về phát triển phần mềm hoặc cố gắng áp đặt quá nhiều luật. Một bộ tiêu chuẩn hoá tồi sẽ nhanh chóng bị mất uy tín và làm nản lòng các Dev, những người đã quá chán nản với những quy tắc nghèo nàn và không thực tế. Cho dù các quy tắc có bị bắt phải thực hiện thì cũng chỉ là một bộ tiêu chuẩn bị cưỡng chế phải thực hiện mà thôi.

Phương pháp tư duy

Trong quá trình đọc, sẽ có nhiều vấn đề khó hiểu đến từ văn phong, kiến thức lập trình, kinh nghiệm với C++ cũng như từ ngữ phiên dịch. Áp dụng những phương pháp sau sẽ giúp hiểu vấn đề dễ dàng hơn.

Hãy tự tư duy.  Tuân theo quy tắc một cách nghiêm cẩn nhưng đừng mù quáng. Hãy chú ý đến những tình huống ngoại lệ ít phổ biến không áp dụng được với những hướng dẫn trong loạt bài này. Hãy nhớ rằng, không bộ hướng dẫn nào (cho dù tốt đến đâu) có thể thay thế sự suy nghĩ của bạn. Điều này nghĩa là bạn phải luôn tư duy và đặt câu hỏi tại sao lại có quy tắc này khi sử dụng chúng? phải hiểu thấu đáo bối cảnh, tác dụng khi sử dụng và hậu quả nếu không sử dụng chúng. Chúng ta phải bỏ ngay thói quen sử dụng mà không suy nghĩ gì cả.

Mỗi nhóm lập trình cần tự mình thiết lập bộ tiêu chuẩn hoá của riêng mình và chịu trách nhiệm trước điều đó. Nếu bạn là trưởng nhóm bạn nên để mọi người trong nhóm liên quan đến việc thiết lập tiêu chuẩn hoá. Mọi người có nhiều khả năng tuân theo các tiêu chuẩn mà họ coi là của riêng mình hơn là tuân theo một loạt các quy tắc mà họ cảm thấy đang bị áp đặt lên.

Các bạn hãy sử dụng loạt bài này nhằm mục đích làm cơ sở tham khảo xây dựng bản tiêu chuẩn hoá chứ không phải bản hướng dẫn cuối cùng, bởi lẽ nhóm của các bạn cần thêm những nội dung bổ sung cho phù hợp với nhóm của mình. Nhưng tôi cũng hy vọng nhóm của bạn sẽ tiết kiệm được nhiều thời gian và công sức khi áp dụng những điều được chấp nhận và áp dụng rộng rãi được nêu ra dưới đây, và do đó giúp tăng chất lượng và tính nhất quán của các tiêu chuẩn lập trình bạn xây dựng.

Yêu cầu các thành viên trong nhóm bạn cùng đọc và suy ngẫm logic về loạt bài này, chọn ra những mục mà tất cả mọi người đều đồng ý và cho vào các mục tiêu chuẩn hoá. Một khi đã tiêu chuẩn hoá thì mọi thành viên đều phải tuân theo nghiêm chỉnh và xuyên suốt.

Cuối cùng mọi người cùng định kỳ xem xét và phản hồi lại các quy tắc trong bộ tiêu chuẩn hoá nhằm bổ sung, sửa đổi nếu cần thiết cho phù hợp với nghiệp vụ của nhóm bạn.

Thái độ của chúng ta với tiêu chuẩn hoá lập trình

Một bộ tiêu chuẩn hoá tốt có thể mang lại nhiều lợi ích tương quan sau:

• Cải thiện chất lượng phần mềm: Khuyến khích Dev trong nhóm lập trình nhất quán theo một bộ quy tắc, hướng dẫn đúng đắn nhằm tăng chất lượng phần mềm và khả năng bảo trì.
• Cải thiện tốc độ lập trình: Dev không cần mất thời gian vào việc quyết định những nguyên tắc, định hướng đầu tiên.
• Teamwork tốt hơn: Giúp giảm bớt những cuộc tranh luận không cần thiết về những vấn đề vụn vặt và giúp các thành viên trong nhóm đọc và duy trì mã của nhau dễ dàng hơn.
• Tạo ra tính đồng nhất trong nhóm: Trên tinh thần giữ vững hướng đi, quy tắc mọi người có thể thoả sức sáng tạo của họ.

Dưới áp lực của thời gian và sự căng thẳng mọi người có xu hướng làm những gì mà họ được đào tạo, họ rơi vào thói quen của họ. Đó cũng là lý do mà bệnh viện muốn tuyển dụng những nhân viên đã được đào tạo và có kinh nghiệm. Ngay cả khi bạn có kiến thức nhưng nếu là người mới bạn cũng sẽ bị hoảng sợ.

Là nhà phát triển phần mềm, chúng ta thường xuyên phải đối mặt với áp lực to lớn để cung cấp phần mềm trong thời gian ngắn. Dưới áp lực của lịch trình, chúng ta làm những gì chúng ta được đào tạo và đã quen. Những Dev cẩu thả, những người trong thời gian bình thường không biết các phương pháp thực hành tốt về lập trình phần mềm (hoặc không quen áp dụng chúng) sẽ viết mã còn cẩu thả và lỗi hơn khi có áp lực. Ngược lại, những Dev có thói quen tốt và thực hành chúng thường xuyên sẽ giữ cho bản thân luôn ngăn nắp và cung cấp mã chất lượng một cách nhanh chóng.

Các tiêu chuẩn lập trình được giới thiệu trong loạt bài này là tập hợp các hướng dẫn để viết mã C++ chất lượng cao. Chúng là những kết luận chắt lọc từ kinh nghiệm tập thể phong phú của cộng đồng C++. Phần lớn kiến ​​thức này chỉ trước đây tồn tại rời rạc và truyền miệng. Chúng tôi thu thập và tổng kết thành các quy tắc ngắn gọn, hợp lý, dễ hiểu và dễ làm theo.

Tất nhiên, kể cả có một bộ tiêu chuẩn tốt nhất, Dev vẫn có thể viết ra một mã tồi. Điều này đúng với bất kỳ ngôn ngữ, quy trình hoặc phương pháp nào. Nhưng một bộ tiêu chuẩn lập trình tốt không chỉ cung cấp các quy tắc đơn thuần mà còn thúc đẩy những thói quen và kỷ luật tốt. Nền tảng đó, một khi có được, sẽ mở ra cánh cửa cho những cấp độ cao hơn. Ở đây không có đường tắt; bạn phải phát triển năng lựng từ vựng + ngữ pháp trước khi làm thơ.

Loạt bài này thích hợp với tất cả các lập trình viên C++ ở mọi cấp độ:

• Nếu bạn là một người mới (Fresher), chúng tôi hy vọng bạn sẽ hiểu những phong cách, thành ngữ, quy tắc C++ một cách tự nhiên nhất. Chúng tôi cung cấp cơ sở lý luận và thảo luận ngắn gọn cho từng quy tắc nhằm hướng dẫn bạn suy nghĩ và hiểu rõ chúng hơn là chỉ học thuộc lòng.
• Đối với lập trình viên trung/ cao cấp (Junior & Senior), chúng tôi cung cấp danh sách chi tiết các tài liệu tham khảo chính xác cho từng quy tắc. Bằng cách này, bạn có thể nghiên cứu sâu hơn về nguồn gốc của quy tắc trong hệ thống kiểu, cú pháp và mô hình đối tượng của C++.
• Dù sao, rất có thể bạn đang làm việc theo nhóm trong một dự án phức tạp. Đây là lúc các tiêu chuẩn lập trình thực sự mang lại hiệu quả – bạn có thể sử dụng chúng để đưa nhóm đến một cấp độ chung và cung cấp cơ sở cho việc đánh giá (review) mã.

Mục tiêu của loạt bài

Chúng tôi đặt ra các mục tiêu thiết kế sau đây cho loạt bài này:

• Ngắn tốt hơn dài: Các tiêu chuẩn mã hóa dài có xu hướng bị bỏ qua; những cái ngắn được đọc và sử dụng.
• Mỗi mục phải không gây tranh cãi: Chúng tôi tập hợp những tiêu chuẩn đã được thống nhất rộng rãi chứ không phải phát minh ra chúng. Nếu có điều gì đó không phù hợp, chúng tôi sẽ trình bày theo cách (ví dụ: “Cân nhắc X…” thay vì “Thực hiện X…”) và chúng tôi sẽ lưu ý các trường hợp ngoại lệ.
• Mỗi mục phải có độ tin cậy cao: Các hướng dẫn trong cuốn sách này được chứng thực bằng các tham chiếu đến các tác phẩm đã xuất bản hiện có. Cuốn sách này cũng nhằm mục đích cung cấp một chỉ mục tham khảo về tài liệu C++.
• Mỗi mục phải mang một thông điệp: Chúng tôi sẽ không đơn giản cho vào những quy tắc mà trình biên dịch (Compiler) có thể phát hiện hoặc thực thi.
  • Ví dụ: Quy tắc “Không trả về con trỏ/ tham chiếu của biến tự động” là một quy tắc tốt, nhưng tất cả các trình biên dịch đều đưa ra cảnh báo về điều này, và vì vậy vấn đề là đã được đề cập trong mục “Biên dịch sạch sẽ ở mức cảnh báo cao”.
  • Ví dụ: “Đừng lạm dụng goto” là một mục tuyệt vời, nhưng theo kinh nghiệm của chúng tôi, các Dev đều biết điều này và không cần phải nói thêm nữa.

Bố cục của mỗi đề mục

Mỗi đề mục được trình bày như sau:

• Tên đề mục: Sao cho đơn giản và dễ nhớ nhất.
• Tóm tắt: Những điểm trọng yếu của đề mục.
• Thảo luận: Trao đổi mở rộng và lý do của các đề mục.
• Ví dụ
• Ngoại lệ
• Tham khảo

Chúng tôi cố gắng đưa các mục quan trọng nhất lên đầu tiên của mỗi phần nhưng cũng tuỳ vào dòng chảy nhằm dễ đọc và dễ hiểu, thứ tự này có thể thay đổi đôi chút.