Đặt tên luôn là vấn đề tốn nhiều thời gian cũng như nước bọt của dân lập trình. Đôi khi tìm kiếm được một tên tốt cũng khiến chúng ta vui vẻ và thỏa mãn cả ngày. Làm nghề đủ lâu thì mọi người đều hiểu rằng trong lập trình, việc đọc code chiếm phần lớn thời gian chứ không phải việc viết code. Vì thế, không lạ gì việc các lập trình viên thâm niên luôn khắt khe trong việc đặt tên. Những cái tên tốt có thể không mấy người nhắc tới nhưng những cái tên xấu sẽ bị réo lên nhiều năm về sau, vì một API được xuất bản thì không ai có thể thay đổi được nó nữa. Bài viết này sẽ điểm qua những tình huống khó khăn khi đặt tên. Xin các bạn hiểu cho rằng, khó khăn là tốt, vì chúng ta có ý thức tìm kiếm cái tên nào tốt hơn, tốt nhất. Không có khó khăn khi đặt tên thì thường là đặt tên vô tội vạ mà thôi.
Bí từ
Dù chúng ta có đặt tên theo tiếng Việt hay tiếng Anh thì bí từ cũng khá phổ biến. Hầu hết các đội ngũ yêu cầu đặt tên theo tiếng Anh. Chúng ta đang hội nhập để kiếm ngoại tệ mà! Yêu cầu sử dụng các từ thông dụng và cái tên không nên dài làm cho việc đặt tên lắm lúc bí bách. Điều này xảy ra cả với tây chứ chả riêng gì ta. Cách giải quyết: chẳng có cách nào tốt hơn là đi hỏi quanh thưa các bạn. Cứ việc hỏi bâng quơ giữa phòng, trong group chat, nhận câu trả lời, và sử dụng nó. Tình huống trớ trêu có thể xảy ra sau đó, là các câu trả lời bạn đều đã biết và không vừa lòng. Xin đừng ngại mở ra một cuộc bàn luận nhỏ để chọn đáp án. Những cuộc bàn luận này thường không lâu và chí ít một giải pháp thỏa hiệp sẽ được thông qua. Đừng quên cung cấp đầy đủ ngữ cảnh cho đồng nghiệp của bạn.
Tên quá dài
Một cái tên dài mà đủ nghĩa cũng không phải tệ. Viết tắt một số từ trong tên có thể giảm độ dài, nhưng chắc bạn đã biết thừa và thử thực hiện điều đó. Những từ viết tắt có thể đã không quá phổ biến trong dự án và việc dùng nó còn khiến cái tên mù mờ, khó hiểu. Trước khi chấp nhận cái tên, hãy đặt ra một vài câu hỏi để chắc chắn với quyết định của mình:
- Cái tên có đơn nhiệm hay không? Nếu nó thể hiện hơn một chức năng thì thiết kế của bạn gặp vấn đề. DoThisThenDoThat, GetXxxAndYyy không bao giờ xuất hiện trong một dự án tốt. Một kiểu tên mà có thể bạn sẽ thấy là ThisModelWithSomething. Mở rộng một lớp sẵn có nhưng lại không tìm được tên phù hợp. Trớ trêu là nhiều khi chúng ta thỏa hiệp với kiểu tên này.
- Trong scope, có tên nào khiến cái tên hiện tại phải dài để phân biệt hay không? Hãy thử điều chỉnh hai cái tên.
- Kiểm tra lại sự hỗ trợ từ namespace/package/class name/method name. Trong một phương thức có tên GetXml, ‘xml’ có thể được bỏ qua cho nhiều tên biến.
- Hãy hỏi ý kiến đồng nghiệp.
Tên trùng với tên sẵn có trong thư viện hay dự án
Hầu hết trường hợp bạn sẽ tìm được cái tên thay thế. Một vài dịp đặc biệt thì nó thực sự khó nhằn. Vấn đề khiến chúng ta lăn tăn là nó có thể gây hiểu nhầm về sau này. Bằng cách nào đó thì tình trạng này lại khá phổ biến ngay trong những framework nổi tiếng. Hãy tham khảo ý kiến đồng nghiệp, biết đâu chúng ta bắt được một sáng kiến tốt hơn.
Có nhiều hơn một lựa chọn và không biết lựa chọn nào tốt hơn
Có lẽ bộ não thích đánh lừa chúng ta. Cái tên tốt thì chỉ có một thôi. Hãy theo thứ tự ưu tiên sau để loại bỏ các lựa chọn:
- Đối chiếu theo convention của dự án.
- So với các mẫu tên đã có trong dự án. Không nên trùng tên. Nên dùng lại các từ vựng đã từng được sử dụng.
- Ý kiến đồng nghiệp sẽ luôn hữu ích.
Kết
Khi đọc code, không khó để nhận ra một lập trình viên kì cựu so với phần còn lại. Đơn giản nhất là qua những cái tên. Các lập trình viên ít kinh nghiệm thường dùng những cái tên có phần ngớ ngẩn mà lại không nhận ra điều đó. Việc đặt tên là một kĩ năng cần rèn giũa qua thời gian và cần các lập trình viên nhận thức về tầm quan trọng của nó, cũng như đặt tâm huyết vào những dòng code. Code Review là hoạt động bắt buộc trong các dự án phần mềm hiện tại, nó cũng tạo cơ hội cho các lập trình viên thể hiện sự tiến bộ và học hỏi của bản thân vì kết quả công việc của bạn được cả đội nhìn nhận (thậm chí ngay lập tức). Và biểu hiện của sự tiến bộ chắc chắn có những cái tên.