Chúng ta muốn tạo ra những phần mềm tốt, đồng nghĩa với việc chúng ta phải viết ra những dòng code chất lượng. Code chất lượng thì ai cũng muốn, nhưng ít ai nói rõ cho bạn biết code như thế nào là chất lượng. Khi đánh giá một sản phẩm, chúng ta thường dễ sa lầy vào những suy nghĩ và phân tích có tính cảm tính cá nhân. Vì vậy, để đánh giá được một cách giải quyết là tốt hay xấu, chúng ta cần có những tiêu chí rõ ràng, và điều quan trọng là những tiêu chí này phải được định lượng cách dễ dàng.

Lập trình là một hành động đòi hỏi bạn phải suy nghĩ rất nhiều, công việc này đòi hỏi rất nhiều công sức và sự nỗ lực. Để lập trình tốt, tạo ra những đoạn code chất lượng, không những bạn cần phải duy sự được sự tập trung cao, mà còn phải tuân theo những quy tắc nhất định. Theo mình, những quy tắc sau đây có thể được dùng để đánh giá một đoạn code là ngon hay dở:

Thứ nhất: Code phải chạy được và chạy đúng.

Rất đơn giản, code của bạn phải chạy được sẽ là điều kiện tiên quyết. Nếu bạn viết ra những đoạn mã mà thường xuyên bị những lỗi cơ bản như: lỗi biên dịch, tràn bộ nhớ, truy cập quá index của mảng … thì tất nhiên code của bạn “dỏm” rồi. Là người phát triển phần mềm, bạn cần phải biết được chính xác điều bạn đang muốn là gì, các cấu trúc lưu trữ dữ liệu như nào và logic code xử lí dữ liệu ra sao, …

Sau khi đã hiểu được bạn muốn làm gì, lúc này mới tới giai đoạn viết code bằng ngôn ngữ lập trình. Lúc đó bạn sẽ dùng ngôn ngữ lập trình để thể hiện điều bạn muốn, trải dài từ việc tổ chức dữ liệu tới xử lí logic. “Clean code” là điều bắt buộc, ngoài ra bạn cũng cần hiểu và kiểm soát được sự tương tác giữa code của bạn với các thành phần khác trong hệ thống (từ ngôn ngữ, platform, kiến trúc, …).

Thứ hai: Code phải giải quyết được vấn đề khách hàng yêu cầu.

Đôi khi khách hàng đưa bạn yêu cầu, nhưng bản thân họ lại không thực sự lường hết được mọi tình huống có thể xảy ra, thậm chí còn mơ hồ về kết quả thực sự mà họ muốn. Hãy là người biết phân tích và làm rõ chúng, để thực sự đáp ứng được nghiệp vụ mà khác hàng yêu cầu. Làm rõ những thắc mắc và thực hiện những trao đổi giữa các bên liên quan (khách hàng, dev, tester, … ) để tất cả cùng hiểu đúng “đầu ra” của sản phẩm.

Thứ ba: Code mới phải tương thích với những thứ đang hiện hữu và dễ dàng mở rộng

Giả sử như bạn cần thêm một tính năng mới cho sản phẩm, bạn tích hợp thêm source code vào những gì có sẵn, bạn cần phải đảm bảo không được gây ảnh hưởng tới những gì đã và đang chạy đúng trong chương trình. Đừng làm cho code-based của bạn trở nên rối tung, mất đi tính thống nhất và khó kiểm soát. Hãy chú ý các nguyên lí thiết kế và lập trình, như SOLID chẳng hạn.

Bên cạnh đó, hãy chú ý tới khả năng tái sử dụng lại source code hoặc mở rộng tính năng mới sau này. Đừng để khi triển khai một tính năng tương tự trong tương lai, bạn lại phải clone source code ra một chỗ khác và chỉnh sửa chỉ một vài chỗ nhỏ. Thiết kế dạng modules và áp dụng nguyên lí “loose coupling” có thể giúp bạn trong những tình huống này.

Thứ tư: Không chỉ viết code cho máy tính, code còn dành cho cả cho con người.

Bởi vì phần mềm luôn cần được bảo trì, hãy chú trọng vào tính “trong sáng” của source code. Nó không chỉ là chuyện của việc có comment code hay không, đặt tên biến dài hay ngắn, code có lồng nhau quá nhiều, … Mà nó còn phải thể hiện được ý định thực sự của bạn khi triển khai viết những dòng code đó. Nói thì dễ, nhưng đây có thể là một việc cực kì khó.

Nhớ rằng, việc phát triển phần mềm không chỉ dừng lại ở việc viết code ban đầu, mà còn cần phải được bảo trì và tiếp tục phát triển sau này. Rất nhiều người khác tham gia vào chu trình này chứ không chỉ một mình bạn. Hãy để lại những dòng code mà người đến sau bạn có thể dễ dàng hiểu được.

Cũng như bất cứ một sự vật hay hiện tượng nào, để đánh giá đúng và đầy đủ về nó là một điều rất khó, không thể dễ dàng mà nhận xét được. Tuy nhiên, với phương châm tìm ra những cách thức “dễ định lượng”, những tiêu chí trên đây ít nhiều sẽ giúp bạn hình dung và đánh giá được những đoạn code mà bạn làm, ít nhất cũng giúp bạn biết được mình sẽ phải cải thiện những gì.