Clean Code: Cách trở thành một lập trình viên giỏi hơn

clean-code-principles-square

Khi nhắc đến mã sạch, hay tái cấu trúc mã nguồn bạn có từng suy nghĩ:

“Mã của tôi đang hoạt động tốt, trang web tôi xây dựng trông rất tuyệt và khách hàng của tôi rất vui. Vậy tại sao tôi vẫn quan tâm đến việc viết mã sạch?

Nếu điều này giống suy nghĩ của bạn ngay lúc này, thì hãy đọc tiếp.

Cách đây ít lâu, tôi đang thảo luận với một trong những người bạn của mình, Kabir. Kabir là một lập trình viên có kinh nghiệm. Anh ấy đang làm việc trong một dự án phức tạp, và anh ấy đang thảo luận một vấn đề với tôi. Khi tôi yêu cầu xem mã nguồn cho vấn đề đó, anh ấy nói, có vẻ tự hào, “Tôi đã xây dựng dự án này nên chúng tôi là những người duy nhất có thể hiểu mã nguồn của nó.”

Tôi đã khá kinh hoàng. Tôi hỏi anh ta có phải anh ta cố tình viết mã bẩn không.

“Khách hàng đã không cho tôi đủ thời gian,” bạn tôi nói với tôi. “Họ luôn vội vàng và thúc giục việc bàn giao sản phẩm, vì vậy tôi không có thời gian để nghĩ về việc viết mã sạch”.

Đây hầu như luôn là lý do tôi nghe thấy khi hỏi về mã bẩn. Một số lập trình viên viết mã bẩn bởi vì họ dự định phát hành phiên bản đầu tiên và sau đó làm việc để làm cho nó sạch sẽ. Nhưng thường, điều đó sẽ không bao giờ xảy ra; không có khách hàng nào cho bạn thời gian để làm sạch mã. Khi phiên bản đầu tiên được phát hành, họ sẽ đẩy bạn lên phiên bản thứ hai. Vì vậy, hãy tạo thói quen viết mã sạch nhất có thể từ dòng mã đầu tiên.

Tôi luôn biết rằng việc sử dụng các nguyên tắc mã sạch mang lại nhiều lợi ích và bài viết này sẽ cho bạn biết lý do tại sao.

Công việc của người quản lý dự án, trưởng phòng kinh doanh hoặc khách hàng là hoàn thành dự án trong thời gian tối thiểu để họ có thể kiểm soát chi phí của dự án. Nhưng sản xuất chất lượng, mã sạch là nhiệm vụ của bạn với tư cách là lập trình viên.

Viết mã sạch không phải là một nhiệm vụ lớn hoặc tốn thời gian, nhưng biến nó thành thói quen của bạn và cam kết thực hiện nó, sẽ giúp bạn thăng tiến trong sự nghiệp và cải thiện khả năng quản lý thời gian của chính mình.

Mã sạch luôn trông giống như nó được viết bởi một người có tâm. Giống như Martin Fowlermột chuyên gia hàng đầu về phát triển phần mềm từng phát biểu:

Bất kỳ kẻ ngốc nào cũng có thể viết mã mà máy tính có thể hiểu được. Các lập trình viên giỏi viết mã mà con người có thể hiểu được.

Có thể bạn đã đọc đến đây vì hai lý do: Thứ nhất, bạn là một lập trình viên. Thứ hai, bạn muốn trở thành một lập trình viên giỏi hơn. Tốt. Chúng tôi cần những lập trình viên giỏi hơn.

Hãy tiếp tục theo dõi để tìm hiểu tại sao mã sạch lại quan trọng và bạn sẽ trở thành một lập trình viên giỏi hơn.

Tại sao chúng ta nên cố gắng làm cho mã sạch?

Mã sạch có thể đọc được và dễ hiểu bởi mọi người, cho dù người đọc là tác giả của nó hay một lập trình viên mới.

Viết mã sạch là một tư duy cần thiết. Cần thực hành để viết mã có cấu trúc và rõ ràng, và bạn sẽ học cách làm điều đó theo thời gian. Nhưng bạn cần bắt đầu với tư duy viết theo cách này. Và bạn sẽ quen với việc xem xét và sửa đổi mã của mình để mã sạch nhất có thể.

Không ai là hoàn hảo, và bạn cũng vậy. Bạn sẽ luôn tìm thấy một số cơ hội để cải thiện hoặc tái cấu trúc lại mã khi bạn quay lại để xem lại mã của mình sau vài ngày hoặc vài tuần.

Vì vậy, hãy bắt đầu viết mã rõ ràng nhất có thể từ dòng mã đầu tiên để sau này bạn có thể làm việc nhiều hơn về cải thiện hiệu suất và logic.

Lợi ích của mã sạch

“Tại sao tôi nên quan tâm đến việc viết mã sạch?” bạn vẫn có thể tự hỏi mình.

Có nhiều lý do để có được tư duy mã sạch mà tôi đã mô tả ở trên. Một số lý do quan trọng nhất là:

1.    Sử dụng thời gian của bạn tốt hơn

Người hưởng lợi đầu tiên của mã sạch là lập trình viên

Nếu bạn đang thực hiện một dự án trong nhiều tháng, rất dễ quên những điều bạn đã làm trong mã nguồn cũ, đặc biệt là khi khách hàng của bạn quay lại với các thay đổi. Các dòng mã rõ ràng giúp bạn thực hiện các thay đổi dễ dàng hơn.

Năng suất lập trình có mối quan hệ trái chiều với thời gian.

2.    Tham gia dễ dàng hơn cho các thành viên mới

Sử dụng các nguyên tắc mã sạch sẽ giúp các lập trình viên mới dễ tiếp cận với mã nguồn đang phát triển hơn. Không cần tài liệu để hiểu mã nguồn; lập trình viên mới có thể trực tiếp tham gia vào dự án. Điều này cũng tiết kiệm thời gian đào tạo lập trình viên mới cũng như thời gian để lập trình viên mới điều chỉnh theo dự án.

3.    Debug dễ dàng hơn

Cho dù bạn viết mã bẩn hay mã sạch, bug là không thể tránh khỏi. Nhưng mã sạch sẽ giúp bạn gỡ lỗi nhanh hơn, bất kể bạn có bao nhiêu kinh nghiệm hoặc chuyên môn. Và không có gì lạ khi đồng nghiệp hoặc người quản lý của bạn giúp bạn giải quyết vấn đề. Nếu bạn đã viết mã sạch, không vấn đề gì: Họ có thể nhảy vào và giúp bạn một cách dễ dàng hơn. Nhưng nếu người quản lý của bạn phải xử lý mã bẩn của bạn, thì bạn có thể sẽ giống như Kabir, bạn của tôi.

4.    Bảo trì hiệu quả hơn

“Tất nhiên mã xấu có thể được viết lại. Nhưng nó rất tốn kém. “ Robert C. Martin

Bảo trì không đề cập đến việc sửa lỗi. Khi phát triển bất kỳ dự án nào, nó sẽ cần các tính năng mới hoặc các thay đổi đối với các tính năng hiện có. Khi đó mã sạch sẽ giúp chúng ta dễ dàng bảo trì, hay nâng cấp tính năng mới hơn.

Ba điểm đầu tiên giải thích cách mã sạch có thể tiết kiệm thời gian của lập trình viên. Và, tiết kiệm một ít thời gian mỗi ngày sẽ có tác động kép đến thời gian hoàn thành và chi phí của phần mềm. Điều đó tốt cho công ty của bạn.

Vậy làm thế nào để chúng ta có thể cải thiện chất lượng mã của mình? Hãy cùng theo dõi tiếp nhé.

Cách viết mã sạch

“Bạn nên đặt tên cho một biến bằng cách sử dụng cùng một cách mà bạn đặt tên cho đứa con đầu lòng.” Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship.

Một lập trình viên là một tác giả, nhưng họ có thể mắc sai lầm trong việc xác định đối tượng. Đối tượng của một lập trình viên là các lập trình viên khác, không phải máy tính. Nếu máy tính là đối tượng, thì bạn có thể viết mã bằng ngôn ngữ máy.

Vì vậy, để dễ hiểu, bạn nên sử dụng danh pháp có ý nghĩa cho các biến, hàm và lớp. Và làm cho nó dễ đọc hơn bằng cách sử dụng lùi đầu dòng, phương pháp rút gọn và câu lệnh ngắn, nếu thích hợp:

  • Sử dụng tên dễ phát âm cho các biến và phương thức. Không sử dụng chữ viết tắt trong tên biến và phương thức. Sử dụng tên biến ở dạng đầy đủ để có thể dễ dàng phát âm và mọi người có thể hiểu được.

Sử dụng tên dễ phát âm cho các biến và phương thức.

  • Sử dụng tên để thể hiện đúng mục đích. Mục đích của biến phải dễ hiểu đối với người đọc tên của biến. Viết tên như bạn sẽ nói.

Sử dụng tên để thể hiện đúng mục đích

  • Đừng đổi mới; đơn giản. Cho thấy sự đổi mới trong logic, không phải trong việc đặt tên biến hoặc phương thức. Có một cái tên đơn giản khiến mọi người dễ hiểu.

Đừng đổi mới; đơn giản

  • Hãy kiên định. Sử dụng một từ cho các chức năng tương tự. Không sử dụng “get” trong một lớp và “fetch” trong lớp khác.
  • Đừng ngần ngại sử dụng các thuật ngữ kỹ thuật trong tên. Hãy tiếp tục, sử dụng thuật ngữ kỹ thuật. Đồng nghiệp của bạn sẽ hiểu nó. Ví dụ: “jobQueue” tốt hơn “job”.
  • Sử dụng một động từ làm từ đầu tiên trong phương thức và sử dụng một danh từ chỉ lớp. Sử dụng camelCase cho tên biến và hàm. Tên lớp bắt đầu bằng từ viết hoa.

Sử dụng camelCase cho tên biến và hàm

  • Sử dụng các quy ước đặt tên nhất quán. Luôn sử dụng chữ hoa và phân tách các từ bằng dấu gạch dưới.
  • Làm cho các hàm rõ ràng. Giữ một hàm càng ngắn càng tốt. Độ dài lý tưởng của một function là tối đa 15 dòng. Đôi khi nó có thể kéo dài hơn, nhưng về mặt khái niệm thì mã phải sạch để hiểu.
  • Tham số của hàm nên nhỏ hơn hoặc bằng ba. (Nếu các tham số lớn hơn ba, thì bạn phải suy nghĩ để cấu trúc lại hàm thành một lớp.)
  • Một lớp nên làm một việc. Nếu nó dành cho người dùng, thì tất cả các phương pháp phải được viết hoàn toàn cho trải nghiệm người dùng.
  • Hạn chế comment vô tội vạ. Nếu bạn phải thêm comment để giải thích mã của mình, điều đó có nghĩa là bạn cần phải cấu trúc lại mã của mình. Chỉ comment nếu điều đó là bắt buộc về mặt pháp lý hoặc nếu bạn cần ghi chú về tương lai hoặc lịch sử của chương trình.
  • Sử dụng Git đánh version cho ứng dụng. Đôi khi, các tính năng thay đổi và các phương thức cần được viết lại. Thông thường, chúng tôi nhận xét mã cũ vì sợ rằng khách hàng sẽ thay đổi và yêu cầu phiên bản cũ hơn. Nhưng nếu bạn sử dụng hệ thống kiểm soát phiên bản Git, hệ thống này sẽ lưu trữ tất cả các phiên bản, vì vậy bạn không cần phải giữ mã bẩn. Xóa nó và làm cho mã của bạn sạch sẽ hơn.
  • Tránh làm việc với một mảng lớn. Tránh tạo một mảng cho một tập dữ liệu lớn; thay vào đó, hãy sử dụng một lớp. Điều đó làm cho nó dễ đọc hơn, chưa kể rằng nó tạo ra một sự an toàn bổ sung cho ứng dụng của bạn.
  • Không lặp lại mã. Mỗi khi bạn viết một phương thức, hãy tự hỏi bản thân xem liệu điều gì đó tương tự đã được xây dựng chưa. Kiểm tra thư viện mã hoặc tài liệu khác.
  • Đừng ”hardcode”. Xác định hằng số hoặc sử dụng các biến thay vì fix cứng các giá trị. Việc sử dụng biến sẽ không chỉ làm cho nó có thể đọc được mà còn giúp bạn dễ dàng thay đổi nếu nó đang được sử dụng ở nhiều nơi.
  • Làm cho câu lệnh có thể đọc được. Để làm cho câu lệnh có thể đọc được, hãy giữ dòng ngắn gọn để bạn không cần phải cuộn theo chiều ngang để đọc hết dòng.

Làm cho câu lệnh có thể đọc được

Một số mẹo khác cho mã sạch hơn

  • Tự xem lại mã của bạn. Xem lại mã của bạn một lần sau một thời gian. Tôi chắc chắn rằng bạn sẽ tìm thấy một cái gì đó mới để cải thiện mỗi khi bạn xem lại nó.
  • Xem lại mã của bạn với đồng nghiệp. Xem lại mã của đồng nghiệp của bạn và yêu cầu họ xem lại mã của bạn. Đừng ngần ngại xem xét các đề xuất, các phản hồi của đồng nghiệp rất tốt với bạn
  • Sử dụng coding convention. Nếu bạn đang viết cho PHP, hãy sử dụng hướng dẫn về kiểu viết mã của PSR-2.
  • Sử dụng TDD, bạn nên sử dụng phương pháp TDD và viết các bài kiểm tra đơn vị để tăng chất lượng mã nguồn…

Tôi mong rằng qua bài viết này, bạn sẽ nghiệm lại nhiều điều và khi đọc lại mã nguồn cũ, tôi tin bạn sẽ thốt ra: “mình đã code cái quái gì vậy”. Thực hành Clean Code không phải chuyện ngày một ngày hai, hãy luyện tập từng ngày với những thay đổi nhỏ nhất. “Những thay đổi nhỏ, sẽ làm nên thành công to”. Chúc bạn thành công.

Nguồn: https://simpleprogrammer.com/clean-code-principles-better-programmer

 

Leave a Reply

Your email address will not be published.