Cách viết mã sạch
Nguồn: Dev.to Viết clean code cũng giống như viết thơ. Đây là thơ cần ngắn gọn, dễ hiểu và dễ thay đổi. Mã sạch ngụ ý một tổ chức có thể mở rộng. Điều này có nghĩa là việc thực hiện thay đổi không gây ra sự hỗn loạn. Khả năng viết mã như vậy là một trong những phẩm chất quan trọng của một nhà phát triển có kinh nghiệm. Sau khi được nhiều người khuyên tôi nên đọc cuốn Clean Code, cuối cùng tôi cũng lấy hết can đảm để đọc nó. Hóa ra đây là một trong những cuốn sách có bìa hoàn toàn phù hợp với sự cường điệu xung quanh nó. Những khuyến nghị trong sách rất rõ ràng, cụ thể, thiết thực và thậm chí còn được trình bày hài hước. Hôm nay tôi muốn chia sẻ với bạn những nội dung chính từ cuốn sách này.
1. Mã không chỉ hoạt động mà còn phải dễ đọc
Hầu hết chi phí của phần mềm gắn liền với việc hỗ trợ lâu dài. Vì vậy, đoạn code bạn viết phải thể hiện rõ ràng ý định của bạn. Nó phải như vậy để các nhà phát triển mới tham gia nhóm có thể dễ dàng hiểu chính xác những gì đang xảy ra trong mã và tại sao. Code mà tác giả viết càng dễ hiểu thì các nhà phát triển khác sẽ càng mất ít thời gian để hiểu nó. Điều này làm giảm các khiếm khuyết và chi phí bảo trì. Làm thế nào để đạt được điều này? Đặt tên tốt + các lớp và chức năng với trách nhiệm duy nhất + viết bài kiểm tra.2. Muộn hơn có nghĩa là không bao giờ
Thành thật mà nói: đôi khi tất cả chúng ta đều tự hứa với mình rằng chúng ta sẽ quay lại và làm sạch mã sau, nhưng cuối cùng chúng ta lại quên mất điều đó. Đừng để lại những đoạn mã vô dụng không còn cần thiết nữa. Chúng gây nhầm lẫn cho các nhà phát triển khác và không có giá trị. Do đó, khi thực hiện thay đổi chức năng, hãy luôn xóa mã cũ. Nếu có thứ gì đó bị hỏng ở đâu đó, các bài kiểm tra vẫn sẽ hiển thị ngay lập tức. Làm thế nào để đạt được điều này? Xóa mã có thể đáng sợ, đặc biệt là trong các kiến trúc lớn. Vì vậy, thử nghiệm là chìa khóa ở đây. Chúng cho phép bạn xóa mã một cách tự tin.3. Tính năng nên nhỏ
Nguyên tắc đầu tiên khi viết hàm là chúng phải nhỏ, tối đa khoảng 20 dòng . Chức năng càng nhỏ và càng tập trung vào một nhiệm vụ thì càng dễ dàng tìm được một cái tên hay cho nó. Đối với các đối số của hàm, số lý tưởng là 0. Tiếp theo là 1, 2, nhưng bạn nên cố gắng không có nhiều hơn 3 đối số . Các chức năng phải được viết theo nguyên tắc trách nhiệm duy nhất và mở/đóng.4. Sao chép mã là xấu
Sự trùng lặp là kẻ thù của một hệ thống được tổ chức tốt. Đó là công việc làm thêm, rủi ro thêm và sự phức tạp không cần thiết hơn. Phải làm gì về nó? Đảm bảo mã của bạn được viết theo nguyên tắc DRY, biệt lập và mô-đun.5. Lời nhận xét hay duy nhất là lời nhận xét mà bạn đã tìm ra cách không viết.
“Không có gì hữu ích hơn một bình luận hay ở đúng chỗ. Nhưng những bình luận, ngay cả trong trường hợp tốt nhất, vẫn là một điều ác cần thiết.” Các nhận xét nhằm mục đích bù đắp cho việc chúng ta không thể diễn đạt suy nghĩ của mình bằng mã. Nghĩa là, đây ban đầu là sự thừa nhận thất bại. Đúng, chúng tôi phải sử dụng chúng vì không phải lúc nào chúng tôi cũng có thể nói rõ ý định của mình bằng mã, nhưng đó không phải là lý do để ăn mừng. Vấn đề là, những bình luận thường nói dối. Không phải luôn luôn và không có mục đích, nhưng quá thường xuyên. Nhận xét càng cũ và càng xa mã mà nó mô tả thì càng có nhiều khả năng sai. Lý do cho điều này rất đơn giản: các lập trình viên không thể duy trì tốt cả mã và tất cả các nhận xét. Do đó, các nhận xét rất thường xuyên bị tách khỏi mã mà chúng tham chiếu đến và trở thành các chú thích mồ côi với độ chính xác tối thiểu. Phải làm gì về nó? Phải sử dụng các phương pháp đặt tên mang tính mô tả. Khi đọc tên biến, bạn sẽ hiểu ngay nó là gì. Các thử nghiệm cũng cần thiết để các nhà phát triển khác hiểu chức năng nào là quan trọng nhất.6. Đối tượng tiết lộ hành vi nhưng không tiết lộ dữ liệu.
Một mô-đun không nên biết về phần bên trong của các đối tượng mà nó thao tác. Các đối tượng ẩn dữ liệu và tiết lộ hoạt động của chúng. Điều này có nghĩa là một đối tượng không nên để lộ cấu trúc bên trong của nó thông qua các phương thức truy cập. Không nhất thiết mọi người phải nhìn thấy bạn khỏa thân. Phải làm gì về nó? Phạm vi của các biến phải càng cục bộ càng tốt để không lộ ra nhiều hơn mức cần thiết.
7. Kiểm tra
Mã kiểm tra cũng quan trọng như những gì được đưa vào sản xuất. Vì vậy, nó phải thay đổi và phát triển khi dự án phát triển. Kiểm thử giúp mã của bạn linh hoạt, dễ bảo trì và có thể tái sử dụng. Không có chúng, bất kỳ thay đổi nào cũng có thể dẫn đến lỗi. Các thử nghiệm cho phép bạn làm sạch mã của mình mà không sợ điều gì đó sẽ bị hỏng. Vì vậy, việc duy trì độ tinh khiết của các bài kiểm tra là rất quan trọng. Sự sạch sẽ của các bài kiểm tra đảm bảo khả năng đọc của chúng. Kiểm thử là cơ hội để giải thích cho các nhà phát triển khác bằng ngôn ngữ đơn giản về ý định của tác giả mã. Vì vậy, chúng tôi chỉ kiểm tra một khái niệm trong mỗi chức năng kiểm tra. Điều này làm cho bài kiểm tra mang tính mô tả, dễ đọc hơn và nếu thất bại, việc tìm ra lý do của nó sẽ dễ dàng hơn. Làm thế nào để đạt được điều này? Người ta phải tuân theo các nguyên tắc của các bài kiểm tra ĐẦU TIÊN sạch sẽ . Các thử nghiệm nên là:- Nhanh. Các bài kiểm tra phải chạy nhanh chóng. Nếu bạn phải đợi quá lâu để chạy thử nghiệm, bạn sẽ ít có khả năng chạy thử nghiệm đó thường xuyên hơn.
- Độc lập/cô lập (Independent). Các thử nghiệm nên càng tách biệt và độc lập với nhau càng tốt.
- Có thể lặp lại. Các thử nghiệm phải được lặp lại trong mọi môi trường—phát triển, dàn dựng và sản xuất.
- Tự xác thực. Kết quả kiểm tra phải là giá trị Boolean. Bài kiểm tra phải đạt hoặc không đạt.
- Triệt để. Chúng ta nên cố gắng giải quyết tất cả các trường hợp khó khăn, tất cả các vấn đề bảo mật, mọi trường hợp sử dụng (trường hợp sử dụng) và lộ trình hài lòng (kịch bản thuận lợi nhất cho mã) bằng các thử nghiệm.
8. Xử lý lỗi và ngoại lệ
Mỗi ngoại lệ bạn đưa ra phải cung cấp đủ ngữ cảnh để xác định nguồn và vị trí lỗi. Thông thường, bạn có dấu vết ngăn xếp của bất kỳ ngoại lệ nào nhưng dấu vết ngăn xếp sẽ không cho bạn biết mục đích của thao tác không thành công. Nếu có thể, hãy tránh chuyển giá trị rỗng vào mã của bạn. Nếu bạn muốn trả về null từ một phương thức, thay vào đó hãy xem xét việc ném một ngoại lệ. Biến việc xử lý lỗi thành một tác vụ riêng biệt có thể được xem độc lập với logic chính. Làm thế nào để đạt được điều này? Tạo thông báo lỗi mang tính thông tin và chuyển chúng cùng với các ngoại lệ của bạn. Chỉ định thao tác không thành công và loại lỗi.9. Lớp học
Các lớp học nên nhỏ. Nhưng điều cần tính không phải là những dòng mã mà là trách nhiệm. Tên lớp là chìa khóa để mô tả những gì chúng chịu trách nhiệm. Hệ thống của chúng ta nên bao gồm nhiều lớp nhỏ chứ không phải một vài lớp lớn. Mỗi lớp nhỏ như vậy phải gói gọn một trách nhiệm duy nhất. Chỉ có một lý do cụ thể để mỗi lớp tồn tại và mỗi lớp phải "hợp tác" với một số lớp khác để đạt được hành vi mong muốn của hệ thống. Hiếm khi có lý do chính đáng để tạo một biến công khai. Làm suy yếu sự đóng gói luôn là giải pháp cuối cùng. Ngoài ra, nên có ít biến thể hiện. Thiết kế phần mềm tốt cho phép thực hiện các thay đổi mà không cần đầu tư lớn hoặc làm lại. Việc thu hẹp phạm vi biến làm cho nhiệm vụ này dễ dàng hơn. Làm thế nào để đạt được điều này? Tách biệt các mối quan tâm là một trong những kỹ thuật thiết kế lâu đời nhất và quan trọng nhất. Các lớp học phải được mở để mở rộng nhưng phải đóng cửa để sửa đổi. Trong một hệ thống lý tưởng, chúng tôi kích hoạt các tính năng mới bằng cách mở rộng hệ thống thay vì thực hiện các thay đổi đối với mã hiện có.10. Định dạng
Mỗi dòng trống là một tín hiệu trực quan giúp xác định rằng một khái niệm mới, riêng biệt đã bắt đầu. Các biến cục bộ phải xuất hiện ở đầu hàm. Các biến thể hiện phải được khai báo ở đầu lớp. Những dòng ngắn tốt hơn những dòng dài. Thông thường giới hạn là 100-120 ký tự; bạn không nên dài hơn. Làm thế nào để đạt được điều này? Hầu hết các tham số có thể được chuyển tới kẻ nói dối trong CI hoặc trình soạn thảo văn bản của bạn. Sử dụng những công cụ này để làm cho mã của bạn sạch nhất có thể.Nguyên tắc phát triển chương trình
Hãy sử dụng các kỹ thuật sau và mã của bạn sẽ luôn rõ ràng: Đặt tên biến. Việc chọn tên thích hợp (đặt tên hay) là rất quan trọng để làm cho mã có thể đọc được và do đó có thể bảo trì được. “Bạn nên chọn tên cho một biến số một cách có trách nhiệm như cách bạn đặt tên cho đứa con đầu lòng của mình.” Việc lựa chọn những cái tên hay thường là một thách thức đối với các nhà phát triển. Điều này đòi hỏi kỹ năng mô tả tốt và nền tảng văn hóa chung. Mã sạch là mã được đọc và cải tiến bởi các nhà phát triển hoàn toàn khác nhau. Tên của một biến, hàm hoặc lớp phải trả lời tất cả các câu hỏi cơ bản: tại sao thực thể này tồn tại, nó được sử dụng như thế nào và như thế nào. Nếu một cái tên cần được bình luận, điều đó có nghĩa là nó không bộc lộ đầy đủ bản chất của những gì nó mô tả. Tên dài hơn quan trọng hơn tên ngắn hơn và bất kỳ tên nào có thể tìm kiếm đều tốt hơn một hằng số. Tên gồm một chữ cái chỉ có thể được sử dụng làm biến cục bộ bên trong các phương thức ngắn: độ dài của tên phải khớp với phạm vi. Tên phương thức phải là động từ hoặc cụm động từ; tên lớp không được là một động từ. Sự phụ thuộc nên được giữ ở mức tối thiểu. Tốt hơn là dựa vào những gì bạn kiểm soát được hơn là những gì bạn không thể kiểm soát. Nếu không những điều này sẽ kiểm soát bạn. Sự chính xác. Mỗi đoạn mã phải ở một nơi mà người đọc mong muốn tìm thấy nó. Việc điều hướng qua cơ sở mã phải trực quan và ý định của nhà phát triển phải rõ ràng. Làm sạch. Đừng để lại mã vô dụng trong cơ sở mã (cũ và không còn được sử dụng hoặc tạo "để đề phòng"). Giảm sự trùng lặp và tạo ra sự trừu tượng hóa đơn giản ngay từ đầu. Tiêu chuẩn hóa. Khi viết mã, bạn nên tuân theo phong cách và cách thực hành đã được thiết lập cho kho lưu trữ. Tự kỷ luật. Khi các công nghệ đã qua sử dụng phát triển và những công nghệ mới xuất hiện, các nhà phát triển thường mong muốn thay đổi và cải thiện điều gì đó trong mã hiện có. Đừng vội tin vào sự cường điệu quá nhanh: hãy nghiên cứu kỹ lưỡng các ngăn xếp mới và chỉ cho một mục đích cụ thể. Giữ cho cơ sở mã của bạn sạch sẽ không chỉ là lịch sự với các đồng nghiệp hiện tại và tương lai của bạn. Nó cần thiết cho sự tồn tại lâu dài của chương trình. Mã của bạn càng sạch thì các nhà phát triển càng vui vẻ, sản phẩm càng tốt và thời gian sử dụng càng lâu.Tại sao Java tốt hơn C++ cho các hệ thống có độ trễ thấp
Nguồn: StackOverflow Là nhà phát triển, tất cả chúng ta đều biết rằng có hai cách để thực hiện mọi việc: thủ công, chậm rãi và khó chịu, hoặc tự động, khó khăn và nhanh chóng. Tôi có thể sử dụng trí tuệ nhân tạo để viết bài này cho tôi. Điều này có thể giúp tôi tiết kiệm rất nhiều thời gian - AI có thể tạo ra hàng nghìn bài báo mỗi giây, nhưng biên tập viên của tôi có thể sẽ không vui khi biết rằng phải mất hai năm để tạo ra bài báo đầu tiên.
Tình huống tương tự cũng xảy ra khi phát triển hệ thống phần mềm có độ trễ thấp. Sự khôn ngoan thông thường là sẽ thật điên rồ nếu sử dụng bất cứ thứ gì khác ngoài C++ vì mọi thứ khác đều có độ trễ quá cao. Nhưng tôi ở đây để thuyết phục bạn về quan niệm ngược lại, phản trực giác, gần như dị giáo: khi nói đến việc đạt được độ trễ thấp trong hệ thống phần mềm, Java sẽ tốt hơn. Trong bài viết này, tôi muốn lấy một ví dụ cụ thể về phần mềm coi trọng độ trễ thấp: hệ thống giao dịch. Tuy nhiên, các lập luận được trình bày ở đây có thể được áp dụng cho hầu hết mọi trường hợp yêu cầu hoặc mong muốn độ trễ thấp. Sẽ dễ dàng hơn để thảo luận về lĩnh vực phát triển mà tôi có kinh nghiệm. Và sự thật là độ trễ rất khó đo lường. Tất cả đều bắt nguồn từ ý nghĩa của độ trễ thấp. Hãy tìm hiểu điều này ngay bây giờ.
Trí tuệ có được
Vì C++ gần với phần cứng hơn nhiều nên hầu hết các nhà phát triển sẽ nói với bạn rằng viết mã bằng ngôn ngữ này mang lại lợi thế về tốc độ. Trong các tình huống có độ trễ thấp, chẳng hạn như giao dịch tốc độ cao, trong đó mili giây có thể tạo ra sự khác biệt giữa một phần mềm khả thi và sự lãng phí dung lượng ổ đĩa, C++ được coi là tiêu chuẩn vàng. Ít nhất thì trước đây nó đã như vậy. Nhưng thực tế là nhiều ngân hàng và nhà môi giới lớn hiện nay sử dụng các hệ thống được viết bằng Java. Và ý tôi là được viết nguyên gốc bằng Java, không phải viết bằng Java và sau đó được diễn giải bằng C++ để giảm độ trễ. Các hệ thống này đang trở thành tiêu chuẩn ngay cả đối với các ngân hàng đầu tư cấp 1, mặc dù thực tế là chúng (được cho là) chậm hơn. Vì vậy những gì đang xảy ra? Đúng, C++ có thể có "độ trễ thấp" khi thực thi mã, nhưng chắc chắn độ trễ không thấp khi triển khai các tính năng mới hoặc thậm chí tìm kiếm các nhà phát triển có thể viết mã đó.(Thực tế) sự khác biệt giữa Java và C++
Vấn đề về thời gian phát triển chỉ là bước khởi đầu khi nói đến sự khác biệt giữa Java và C++ trong các hệ thống thế giới thực. Để hiểu giá trị thực sự của từng ngôn ngữ trong bối cảnh này, hãy tìm hiểu sâu hơn một chút. Đầu tiên, điều quan trọng cần nhớ là lý do thực sự khiến C++ nhanh hơn Java trong hầu hết các tình huống: con trỏ C++ là địa chỉ của một biến trong bộ nhớ. Điều này có nghĩa là phần mềm có thể truy cập trực tiếp vào các biến riêng lẻ và không phải thu thập thông tin qua các bảng tính toán chuyên sâu để tra cứu chúng. Hoặc ít nhất có thể được giải quyết bằng cách chỉ định chúng ở đâu, vì với C++ bạn thường phải quản lý rõ ràng thời gian tồn tại và quyền sở hữu của các đối tượng. Kết quả là, trừ khi bạn thực sự giỏi viết mã (một kỹ năng có thể mất hàng thập kỷ để thành thạo), C++ sẽ yêu cầu hàng giờ (hoặc hàng tuần) để gỡ lỗi. Và như bất kỳ ai đã thử gỡ lỗi công cụ Monte Carlo hoặc công cụ kiểm tra PDE sẽ cho bạn biết, việc cố gắng gỡ lỗi quyền truy cập bộ nhớ ở mức cơ bản có thể rất tốn thời gian. Chỉ cần một con trỏ bị lỗi có thể dễ dàng làm hỏng toàn bộ hệ thống, vì vậy việc phát hành một phiên bản mới được viết bằng C++ có thể thực sự đáng sợ. Tất nhiên, đó không phải là tất cả. Những người thích lập trình bằng C++ sẽ chỉ ra rằng trình thu gom rác của Java gặp phải vấn đề về độ trễ phi tuyến tính tăng đột biến. Điều này đặc biệt đúng khi làm việc với các hệ thống cũ, vì vậy việc gửi các bản cập nhật tới mã Java mà không làm hỏng hệ thống máy khách có thể khiến chúng chậm đến mức không thể sử dụng được. Để đáp lại, tôi muốn chỉ ra rằng rất nhiều công việc đã được thực hiện trong thập kỷ qua để giảm độ trễ do Java GC tạo ra. Bộ gây rối LMAXVí dụ: là một nền tảng giao dịch có độ trễ thấp được viết bằng Java, cũng được xây dựng dưới dạng một khung có “tương tác cơ học” với phần cứng chạy trên đó và không yêu cầu khóa. Các vấn đề có thể được giảm thiểu hơn nữa nếu bạn xây dựng một hệ thống sử dụng quy trình tích hợp và phân phối liên tục (CI/CD), vì CI/CD cho phép triển khai tự động các thay đổi mã đã được kiểm tra. Điều này là do CI/CD cung cấp một cách tiếp cận lặp đi lặp lại để giảm độ trễ thu thập rác, trong đó Java có thể dần dần cải thiện và thích ứng với các môi trường phần cứng cụ thể mà không cần quá trình chuẩn bị mã tốn nhiều tài nguyên cho các thông số kỹ thuật phần cứng khác nhau trước khi xuất xưởng. Vì khả năng hỗ trợ Java của IDE rộng hơn nhiều so với C++ nên hầu hết các khung công tác (Eclipse, IntelliJ IDEA) đều cho phép bạn cấu trúc lại Java. Điều này có nghĩa là IDE có thể tối ưu hóa mã để có hiệu suất có độ trễ thấp, mặc dù khả năng này vẫn còn hạn chế khi làm việc với C++. Ngay cả khi mã Java không hoàn toàn phù hợp với tốc độ của C++, hầu hết các nhà phát triển vẫn thấy việc đạt được hiệu suất chấp nhận được trong Java dễ dàng hơn so với C++.Chúng ta có ý gì khi nói "nhanh hơn"?
Trên thực tế, có lý do chính đáng để nghi ngờ rằng C++ thực sự "nhanh hơn" hoặc thậm chí có "độ trễ thấp hơn" so với Java. Tôi nhận ra rằng mình đang dấn thân vào một vùng nước khá âm u và nhiều nhà phát triển sẽ bắt đầu đặt câu hỏi về sự tỉnh táo của tôi. Nhưng hãy nghe tôi nói. Hãy tưởng tượng tình huống này: bạn có hai nhà phát triển - một người viết bằng C++ và người kia viết bằng Java và bạn yêu cầu họ viết một nền tảng giao dịch tốc độ cao từ đầu. Kết quả là, một hệ thống được viết bằng Java sẽ mất nhiều thời gian hơn để hoàn thành các giao dịch thương mại so với một hệ thống được viết bằng C++. Tuy nhiên, Java có ít trường hợp hành vi không xác định hơn C++. Chỉ lấy một ví dụ, việc lập chỉ mục bên ngoài một mảng là một lỗi trong cả Java và C++. Nếu bạn vô tình làm điều này trong C++, bạn có thể gặp lỗi phân tách hoặc (thường xuyên hơn) bạn sẽ chỉ nhận được một số ngẫu nhiên nào đó. Trong Java, việc vượt quá giới hạn luôn gây ra lỗi ArrayIndexOutOfBoundsException . Điều này có nghĩa là việc gỡ lỗi trong Java dễ dàng hơn nhiều vì lỗi thường được xác định ngay lập tức và vị trí lỗi dễ theo dõi hơn. Ngoài ra, ít nhất theo kinh nghiệm của tôi, Java tốt hơn trong việc nhận biết đoạn mã nào không cần chạy và đoạn mã nào quan trọng đối với hoạt động của phần mềm của bạn. Tất nhiên, bạn có thể dành nhiều ngày để điều chỉnh mã C++ của mình để nó hoàn toàn không chứa mã ngoại lai, nhưng trong thế giới thực, mọi phần mềm đều chứa một số lỗi phình to và Java sẽ tốt hơn trong việc tự động nhận dạng mã đó. Điều này có nghĩa là trong thế giới thực, Java thường nhanh hơn C++, thậm chí theo các số liệu về độ trễ tiêu chuẩn. Và ngay cả khi không phải như vậy, sự khác biệt về độ trễ giữa các ngôn ngữ thường bị lấn át bởi các yếu tố khác không đủ lớn để quan trọng ngay cả trong giao dịch tốc độ cao.Lợi ích của Java đối với các hệ thống có độ trễ thấp
Theo tôi, tất cả những yếu tố này tạo nên một lập luận khá thuyết phục cho việc sử dụng Java để viết các nền tảng giao dịch tốc độ cao (và các hệ thống có độ trễ thấp nói chung, sẽ nói thêm về điều đó sau). Tuy nhiên, để tác động một chút đến những người đam mê C++, hãy xem xét một số lý do bổ sung để sử dụng Java:-
Đầu tiên, bất kỳ độ trễ vượt mức nào mà Java đưa vào phần mềm của bạn có thể sẽ ít hơn nhiều so với các yếu tố khác ảnh hưởng đến độ trễ—chẳng hạn như sự cố Internet. Điều này có nghĩa là bất kỳ mã Java nào (được viết tốt) đều có thể dễ dàng hoạt động tốt như C++ trong hầu hết các tình huống giao dịch.
-
Thời gian phát triển Java ngắn hơn cũng có nghĩa là trong thế giới thực, phần mềm viết bằng Java có thể thích ứng với những thay đổi về phần cứng (hoặc thậm chí là các chiến lược giao dịch mới) nhanh hơn C++.
-
Nếu tìm hiểu sâu hơn về vấn đề này, bạn sẽ thấy rằng ngay cả việc tối ưu hóa phần mềm Java cũng có thể nhanh hơn (khi được xem xét trên toàn bộ phần mềm) so với tác vụ tương tự trong C++.
GO TO FULL VERSION