Cách viết mã sạch

Làm cho mã của bạn sạch và đẹp là một cách tuyệt vời để đáp ứng thời hạn. Robert Martin đã đánh trúng đích bằng một trong những tuyên bố ngắn gọn của mình: “Thước đo thực sự duy nhất về chất lượng mã là đơn vị What-The-F**ks/Minute .” “trong bản gốc). Hãy để tôi giải thích điều này có nghĩa là gì. Mỗi lần tôi xem lại mã, não tôi trải qua một trong ba cảm xúc:

• “Cái quái gì vậy?! Cái quái gì vậy?!" (với vẻ ghê tởm) - không phải vậy... mọi thứ rất tệ....
• “Cái quái gì vậy?! Cái quái gì vậy?!" (với sự ngưỡng mộ) - hmm, một anh chàng thông minh đã làm được điều đó!
• “Cái quái gì vậy?! Cái quái gì vậy?!" (với sự khó chịu) - một sự nhầm lẫn nào đó, chúng ta đang nói về cái gì vậy?!

Vậy điều gì là tối quan trọng và chính xác thì chúng ta đánh giá điều gì khi nhìn thấy một số mã? Thế thôi: sự tinh khiết và vẻ đẹp của nó. Khả năng viết mã sạch và đẹp là dấu hiệu của một nhà phát triển có tính chuyên nghiệp cao. Việc đào tạo kỹ năng này dựa trên hai thành phần - kiến ​​thức và công việc. Kiến thức dạy cho bạn những khuôn mẫu, nguyên tắc, cách thực hành, phương pháp phỏng đoán. Bạn cần họ để phát triển một cách chuyên nghiệp. Chỉ có bạn mới phải tiếp thu kiến ​​thức này như một miếng bọt biển thông qua việc luyện tập và làm việc chăm chỉ không ngừng. Tóm lại, viết clean code không hề dễ dàng. Đây là công việc khó khăn, vất vả và bạn sẽ phải nỗ lực hết mình. Thông qua việc thử và sai, bạn sẽ cải thiện bằng cách lặp đi lặp lại các bước tương tự cho đến khi tìm thấy giải pháp mình muốn. Đơn giản là không có cách nào đơn giản hơn. Dưới đây là một số mẹo giúp bạn học cách viết mã sạch.

Những gì trong một cái tên

Kendrick Lamar (nghệ sĩ hip-hop người Mỹ - ghi chú của biên tập viên) từng nhận định chính xác: “Nếu định kể câu chuyện có thật, tôi phải bắt đầu bằng tên của mình”. Những cái tên trong lĩnh vực phát triển phần mềm có ở khắp mọi nơi. Chúng ta đặt tên cho các hàm, lớp, đối số, gói, chương trình—mọi thứ. Chúng tôi đặt tên cho các tệp nguồn, sách tham khảo và mọi thứ liên quan đến nó. Chúng tôi đặt tên cho mọi thứ không ngừng nghỉ và điều này trở thành một phần quan trọng trong nỗ lực tạo ra mã sạch. Tên bạn đặt cho một cái gì đó nên phản ánh ý định. Việc tìm được một cái tên hay không hề dễ dàng, tốn thời gian nhưng cũng giúp bạn tiết kiệm rất nhiều thời gian khi phải xử lý mã và tình huống trở nên phức tạp. Vì vậy, hãy cẩn thận trong quá trình này và đừng ngại đổi tên sau này nếu bạn thấy cái gì đó phù hợp hơn. Mọi người xử lý mã của bạn sẽ rất biết ơn bạn.

“Một chức năng” - một thứ

Louis Henry Sullivan (kiến trúc sư theo chủ nghĩa duy lý và hiện đại người Mỹ) từng nói nổi tiếng: “công năng quyết định hình thức ” . Anh ấy nói điều này về kiến ​​trúc của những ngôi nhà, nhưng điều này không làm thay đổi bản chất. Mỗi hệ thống được xây dựng trên một số ngôn ngữ dành riêng cho miền mà các lập trình viên tạo ra để mô tả chính xác nó. Các hàm đóng vai trò là động từ của ngôn ngữ và các lớp là danh từ. Thông thường, các hàm đóng vai trò tối quan trọng trong việc tổ chức một ngôn ngữ lập trình và việc viết chúng một cách chính xác là điều cốt yếu để tạo ra mã tốt. Chỉ có hai quy tắc vàng để viết các hàm chất lượng:

1. Chúng nên nhỏ
2. Họ phải làm một việc, một nhiệm vụ và làm tốt nó

Nghĩa là, hàm của bạn phải nhỏ và không được chứa các cấu trúc lồng nhau. Vì vậy, mức thụt lề của hàm không được nhiều hơn một hoặc hai. Cách tiếp cận này làm cho mã dễ đọc, dễ hiểu và dễ hiểu hơn nhiều. Ngoài ra, chúng ta phải chắc chắn rằng các biểu thức bên trong hàm có cùng mức độ trừu tượng. Việc trộn lẫn các mức độ trừu tượng trong một hàm luôn tạo ra nhiều nhầm lẫn và cuối cùng dẫn đến mã không thể quản lý được. Những lập trình viên giỏi nhất coi các hàm như những câu chuyện để kể chứ không chỉ viết mã. Họ sử dụng các công cụ của ngôn ngữ lập trình đã chọn để tạo ra khối mã phong phú, biểu cảm và rõ ràng hơn, về cơ bản có thể đóng vai trò như một người kể chuyện tuyệt vời.

“Nhận xét không bù đắp cho mã xấu”

Venus Williams, vận động viên quần vợt người Mỹ và năm lần vô địch Wimbledon, đã gây ấn tượng mạnh khi nói: “Mọi người đều để lại nhận xét của mình. Đây là cách mà tin đồn xuất hiện . " Bình luận giống như con dao hai lưỡi, bình luận đúng chỗ sẽ rất hữu ích. Mặt khác, không có gì làm xáo trộn không gian hơn những bình luận phù phiếm, vô ích. Nhưng những bình luận gây tổn hại nhất là những bình luận truyền bá thông tin sai lệch và dối trá. Tóm lại, bình luận là một loại tội ác cần thiết. Không phải luôn luôn, nhưng phần lớn. Tại sao? Rất đơn giản, nhận xét càng cũ thì càng khó bảo trì và hầu hết các lập trình viên, như bạn đã biết, không phải lúc nào cũng thay đổi nhận xét cùng với những thay đổi trong mã. Mã di chuyển và phát triển. Các phần của mã được di chuyển qua lại nhưng không có nhận xét. Và điều này trở thành một vấn đề!

“Định dạng mã luôn được ưu tiên”

Điều này đã được nói bởi không ai khác chính là Robert C. Martin (Robert Cecil Martin), hay còn gọi là chú Bob, nhà phát triển, tác giả của nhiều cuốn sách về phát triển phần mềm, nhà tư vấn, đồng tác giả của tuyên ngôn Agile, v.v. Và anh ấy nói thêm: “Mã định dạng là một loại giao tiếp. Và giao tiếp là ưu tiên hàng đầu của bất kỳ nhà phát triển chuyên nghiệp nào.” Không nên đánh giá thấp câu nói trên vì nó nói lên một trong những đặc điểm quan trọng nhất của một nhà phát triển xuất sắc. Mã được định dạng cho phép bạn nhìn sâu vào tâm trí của mình. Chúng tôi muốn gây ấn tượng với mọi người bằng sự gọn gàng, chú ý đến từng chi tiết, khả năng sắp xếp và diễn đạt suy nghĩ của mình một cách rõ ràng. Nhưng nếu khi mọi người nhìn vào mã, họ thấy một số loại nhầm lẫn, gợi nhớ đến một loại dầu giấm, không có đầu cũng không có cuối, điều này sẽ phủ nhận nỗ lực của bạn và làm giảm danh tiếng của nhà phát triển. Thậm chí đừng nghi ngờ điều đó! Bạn còn rất xa sự thật nếu bạn nghĩ rằng điều cốt yếu trong công việc kinh doanh này là “mã chỉ hoạt động”. Chức năng bạn tạo hôm nay rất có thể sẽ được thay đổi trong bản phát hành tiếp theo, nhưng khả năng đọc mã sẽ không thay đổi. Kiểu mã và khả năng đọc tốt của nó giúp việc duy trì mã trong thời gian dài dễ dàng hơn, ngay cả sau khi mã gốc đã bị thay đổi đến mức không thể nhận dạng được.

Đầu tiên tạo khối "thử-bắt-cuối cùng"

Georges Canguilhem (nhà sử học khoa học, triết gia) đã nhận xét rất đúng: “Con người mắc sai lầm là điều đương nhiên, nhưng cứ khăng khăng nhận sai lầm là của ma quỷ ” . Khắc phục sự cố là điều mà tất cả các lập trình viên đều làm. Dữ liệu không hợp lệ có thể được nhập vào đầu vào và thiết bị có thể bị lỗi. Và với tư cách là nhà phát triển, chúng ta cần đảm bảo mã thực hiện những gì nó phải làm. Vấn đề không chỉ là xử lý lỗi mà còn là xử lý lỗi “sạch sẽ và dễ đọc”. Nhiều chương trình thích ứng với việc xử lý lỗi. Nếu bạn làm điều này, mọi thứ sẽ trở nên hỗn loạn đến mức mục đích và logic của mã chính sẽ bị phá hủy. Điều này là sai, nó không nên như vậy. Mã phải rõ ràng và đáng tin cậy, đồng thời việc xử lý lỗi phải được đưa vào mã một cách liền mạch và tự nhiên. Đây là dấu hiệu của một lập trình viên đẳng cấp. Và một trong những cách để đạt được điều này là thông qua việc lồng ghép và bao phủ tất cả các lỗi trong các khối thử bắt đúng cách. Các khối này xác định phạm vi mã của bạn. Khi bạn thực thi mã trong phần thử của khối thử-bắt-cuối cùng, bạn đang tuyên bố rằng quá trình thực thi có thể bị hủy bỏ bất kỳ lúc nào và sau đó tiếp tục trong quá trình bắt. Do đó, chúng tôi khuyên bạn nên bắt đầu bằng thử-bắt-cuối khi bạn viết mã. Điều này sẽ giúp xác định những gì người dùng có thể mong đợi từ mã, bất kể mã có vấn đề gì trong quá trình thử.

Hãy tóm tắt lại

Một cụm từ bất thường sẽ giúp chúng tôi tóm tắt tất cả những điều trên. Đây là ý thức về mã hay “ý thức về mã thông thường”, một loại lập trình viên tương đương với ý nghĩa thông thường. Theo lời của Robert Martin: “Viết mã sạch đòi hỏi phải sử dụng một cách có hệ thống nhiều kỹ thuật nhỏ, được áp dụng nhờ cảm giác “sạch sẽ” tỉ mỉ và có phần đau đớn. Những kỹ thuật nhỏ này được gọi chung là code-sense ” . Một số người trong chúng ta có “ý nghĩa mã âm thanh” này ngay từ đầu, trong khi những người khác phải phát triển nó thông qua thực hành kiên trì. Bản năng này không chỉ giúp nhận ra sự khác biệt giữa mã xấu và mã tốt mà còn giúp hình thành các chiến lược nhằm chuyển mã xấu thành tốt. Mã xấu phá hỏng mọi thứ. Nói theo nghĩa bóng, nếu bạn phủ phân chó lên chiếc bánh ngon nhất, thì... ừ... khó có ai thích nó. Nhận biết mã giúp lập trình viên sử dụng các công cụ phù hợp để đạt được mục tiêu tạo mã sạch. Một lập trình viên hiểu ý nghĩa mã là một nghệ sĩ có thể tạo ra một tác phẩm nghệ thuật trên một màn hình trống sẽ được ghi nhớ trong nhiều năm. Như Harold “Hal” Abelson, giáo sư khoa học máy tính tại Mit và là giám đốc sáng lập của Creative Commons và Quỹ Phần mềm Tự do, đã tóm tắt: “Các chương trình cần phải được viết trước tiên để mọi người có thể đọc chúng, sau đó để chúng có thể được sử dụng. bị xử tử.” ô tô” . Những gì bạn có thể đọc về chủ đề: “Sổ tay về tay nghề thủ công phần mềm linh hoạt” - Robert Martin. “Sổ tay ước lượng Agile” - Mike Cohn Về tác giả: Ravi Shankar Rajan là Giám đốc Chương trình CNTT Toàn cầu đến từ Mumbai (Ấn Độ). Blogger nổi tiếng, nhà thơ haiku, người đam mê khảo cổ học và lịch sử. Bạn có thể kết nối với anh ấy trên Twitter , Medium , LinkedIn