Bất cứ ai cũng có thể viết code. lập trình cơ bản dòng khó là làm sao code được cho tốt?
Chúng ta từng nghe các câu chuyện về code kiểu spaghetti kinh dị, các chuỗi code if-else ngùng ngoằng, những chương trình mà chỉ cần thay đổi 1 biến thôi là hồ hết chương trình sở hữu thể bị phá vỡ, các hàm làm cho người ta hoa cả mắt… đó là điều thường xảy ra các người thiếu kinh nghiệm cứ cố hoàn thành 1 sản phẩm sở hữu thể chuyển giao.
Bạn đừng thỏa mãn có việc code của bạn có thể hoạt động mà hãy quyết tâm để code với thể hoạt động trong khoảng thời gian dài – để sau này ko chỉ bạn, mà bất cứ người nào khác cũng có thể dùng. Để làm cho được điều đấy, sau đây là 1 số nguyên tắc bạn phải nhớ như in.
KISS
Nguyên tắc “Đơn giản thôi, đồ ngốc” (“keep it simple, stupid”) mang thể ứng dụng cho mọi mặt của cuộc sống, nhưng đặc trưng thiết yếu cho các Dự án lập trình vừa và lớn.
Nguyên tắc này bạn phải áp dụng ngay từ đầu lúc bạn xác định khuôn khổ của của Công trình. Bạn đam mê tăng trưởng game không mang tức là bạn với thể tạo ra một thế hệ mới của Warcraft hay Grand Theft Auto đâu. Lúc nghĩ rằng bạn đã đủ thuần tuý hóa rồi, hãy đơn giản hóa nó thêm một lần nữa – bạn sẽ ko giảm thiểu khỏi việc gặp những “tính năng kinh tởm” (feature creep), do dó, hãy diễn ra từ các thứ nhỏ và đơn giản thôi.
Ngay cả lúc đã đang code rồi, hãy code thật thuần tuý. Code phức tạp cần đa dạng thời kì hơn để bề ngoài và viết, dễ bị lỗi, và khó sửa đổi sau này. Antoine de Saint-Exupery từng nói: “Hoàn hảo, chẳng phải là thiên nhiên có gì để thêm, mà là khi chẳng hề bớt thứ gì”.
DRY
Để viết được code clean và dễ sửa đổi thì nguyên tắc “đừng bao giờ viết mã bị trùng lặp” là học lập trình game khôn cùng quan yếu. Khi viết code, cố nhiên bạn muốn tránh trùng lặp dữ liệu và logic. Nếu như bạn tự thấy mình đang viết lặp đi lặp lại cộng một đoạn code, bạn đang vi phạm nguyên tắc này rồi đó.
trái lại với lề luật DRY là WET: “viết mọi thứ hai lần” (“write everything twice”) (hoặc “lãng phí thời gian” – “waste everyone’s time”). 1 Trong những phương pháp tốt nhất để rà soát WET là tự hỏi bản thân: nếu như muốn thay đổi hành vi của chương trình, mình cần phải sửa đổi bao nhiêu vùng mã?
ví thử bạn đang viết ứng dụng podcast. Trên trang tìm ****, bạn code để sắm nạp chi tiết của một podcast. Và trên trang podcast, bạn cũng code tìm nạp chi tiết podcast. Cùng một code tương tự trên trang yêu thích. Vậy cố gói gọn phần lớn trong một hàm thôi để ví như sau này cần sửa đổi thì bạn chỉ cần thực hiện 1 lần.
Mở / đóng
Cho dù bạn đang code trong Java hay các mô-đun Python, bạn nên ưu tiên những code cho phép mở mang nhưng giảm thiểu sửa đổi. Nguyên tắc này vận dụng cho rất nhiều các loại project, nhưng đặc biệt quan trọng với những loại thư viện hoặc khuông làm cho việc được hướng đến phổ thông người sử dụng.
ví dụ, bạn đang bảo trì lại khung làm việc GUI. Bạn mong muốn người mua đích có thể trực tiếp sửa đổi mà vẫn tích hợp code của mình. Nhưng giả dụ sau đấy tận 4 tháng bạn cho ra một bản cập nhật quan yếu thì sao? Thật khó để cập nhật chúng mà không tác động các sửa đổi trong khoảng người mua đích.
Xem thêm =>>https://mindx.edu.vn/
Thay vào đó, hãy giảm thiểu sửa đổi trực tiếp code mà khuyến khích mở rộng. Code ban đầu và những code sửa đổi sau sẽ được tách biệt. Ích lợi là gì? Code sẽ ổn định hơn (người sử dụng sẽ không sơ suất phá tan vỡ những code căn bản) và khả năng bảo trì rẻ hơn (người dùng chỉ phải lo về mã mở rộng). Nguyên tắc mở / đóng là chìa khóa để tạo ra 1 API tốt.
Đối tượng -> Thừa kế
Nguyên lý “hợp đối tượng thay vì thừa kế lớp” cho rằng đối sở hữu đối tượng sở hữu hành vi phức tạp, nên bao gồm những miêu tả của nó cộng có những hành vi riêng lẻ hơn là sử dụng lại 1 lớp (class) và thêm các hành vi mới.
Lạm dụng thừa kế sở hữu thể dẫn tới 2 vấn đề chính. Thứ nhất, sự phân cấp thừa kế với thể phát triển thành lộn xộn. Thứ 2, sẽ khó xác định hành vi của 1 trường hợp cụ thể hơn, đặc biệt khi bạn muốn ứng dụng hành vi từ một nhánh thừa kế vào 1 nhánh khác.
Composition thì code sẽ sạch hơn, dễ bảo trì hơn và sở hữu độ cởi mở gần như vô tận, miễn sao bạn có thân xác định được hành vi bạn muốn. Mỗi hành vi là một class riêng, và bạn chỉ việc thêm những hành vi lẻ vào để tạo ra một hành vi phức tạp.
Nguyên lý Single responsibility
Theo nguyên lý Single responsibility, mọi lớp hoặc mô-đun trong một chương trình chỉ nên sản xuất một tí chức năng cụ thể. Như Robert C. Martin đã kể, “Một lớp thì chỉ nên đổi thay vì 1 lí do độc nhất vô nhị.”
các lớp và mô-đun thường bắt đầu như thế, nhưng khi bạn thêm các tính năng và những hành vi mới, những class hay mô-đun này dễ cần tới hàng trăm hoặc thậm chí hàng nghìn mẫu code. Đây chính là khi bạn cần chia chúng ra thành rộng rãi lớp và mô-đun nhỏ hơn.
Nguyên lý Separation of Concerns
Nguyên lý Separation of Concerns tương tự như nguyên lý Single responsibility nhưng ở 1 chừng độ trừu tượng hơn. Về thực chất, một chương trình phải được thiết kế sao cho nó bao gồm đa dạng gói ko giống nhau, và các gói này không nên liên quan đến những gói khác.
một tỉ dụ nổi danh về mô phỏng này là mô hình MVC (Model-View-Controller), MVC phân chia 1 chương trình thành ba vùng riêng biệt: dữ liệu (“mô hình”), logic (“controller”), và những gì mà người mua đích nhận ra (“View”). Những biến thể của mô phỏng MVC rất hay gặp trong những khung làm cho việc của các trang web nức tiếng nhất ngày nay.
Ví dụ: Mã xử lý việc chuyển vận và lưu dữ liệu vào cơ sở vật chất dữ liệu không cần phải biết cách thức hiển thị dữ liệu trên web. Mã rendering mang thể lấy dữ liệu đầu vào từ các bạn đích, nhưng sau đó chuyển dữ liệu nhập vào mã logic để xử lý. Mỗi phần mang đều hoạt động độc lập.
Điều này đã mang đến cho chúng ta mã mô đun, giúp bảo trì tiện lợi hơn phổ quát. Và trong khoảng thời gian dài, nếu như bạn cần code lại số đông mã rendering, bạn hòan tòan chẳng phải lo lắng xem dữ liệu được lưu hay mã logic được xử lý như thế nào.
YAGNI
Nguyên tắc “bạn sẽ không cần nó” (you aren’t gonna need it) tức thị bạn không bao giờ nên code những chức năng mà sau này bạn mới cần. Việc đấy rất tốn thời kì vì rất có thể bạn sẽ không cần – không chỉ vậy, mã của bạn còn phát triển thành phức tạp một cách thức ko cần yếu.
với thể xem đây là một ứng dụng cụ thể của nguyên lý KISS và phản bác bỏ lại các người quá tuân thêo định lý DRY. Các lập trình viên thiếu kinh nghiệm thường nỗ lực viết mã trừu tượng và chung chung nhất có thể để hạn chế mã WET, nhưng quá nhiều mã tương tự lại làm mã của bạn không thể bảo trì được.
cách ở đây là chỉ áp dụng nguyên tắc DRY khi cần. Giả dụ bạn thấy những chuỗi code bị lặp lại, hãy trừu tượng hóa chúng – nhưng đừng bao giờ làm thế giả dụ chỉ 1 đoạn mã bị lặp lại. Không hề khi nào cũng ‘thừa còn hơn thiếu’.
hạn chế optimize code sớm
Nguyên lý Avoid Premature Optimization cũng tương tự như nguyên lý YAGNI. Điểm khác biệt là YAGNI giải quyết việc thực hành các hành vi chưa nhu yếu khi mà nguyên tắc này xử lý việc nâng cao tốc những thuật toán chưa cần phải có.
Vấn đề là nếu như optimize sớm thì bạn không bao giờ biết được những điểm cốt lõi của chương trình cho tới khi nó đi vào thực tiễn. Đương nhiên là người ta sở hữu thể đoán, thậm chí thỉnh thoảng đoán đúng. Nhưng thường thì bạn sẽ chỉ hoang phí thời gian nâng cao tốc độ 1 hàm không chậm như bạn tưởng, hoặc những hàm ít khi được tiêu dùng tới.
Hãy đi dần tới từng chỉ tiêu của bạn 1 phương pháp thuần tuý nhất với thể, sau ấy profile mã của bạn để tậu ra những điểm cốt lõi thực thụ.
Refactor, Refactor, và Refactor
1 lập trình thiếu kinh nghiệm hiếm khi code được đúng ngay trong khoảng lần đầu. Khi bạn thực hành các tính năng mới bóng bẩy thì nó mang lại cảm giác khá đúng, nhưng khi mã ấy mở rộng, các tính năng mới sẽ bị tác động bởi những code trước.
Codebase thì liên tiếp phát triển. Việc phải xem lại, viết lại, hoặc thậm chí kiểu dáng lại toàn bộ khối mã là hoàn toàn thông thường – và thậm chí là được khuyến khích. Vì so có ngày mới khởi đầu, giờ bạn đã hiểu hơn về nhu cầu của Dự án, và bạn nên thường xuyên dùng kiến thức vừa mới học được để refactor mã cũ.
Cũng nên nhớ rằng refactor không nhất mực phải là 1 quá trình dài. Như câu kể truyền thống của the Boy Scouts of America: “Hãy làm khu cắm trại sạch hơn khi Cả nhà mới tới đó”, vậy nếu như cần kiểm tra hoặc sửa đổi mã cũ, hãy luôn khiến chúng sạch hơn và trong trạng thái tốt hơn.
Chúng ta từng nghe các câu chuyện về code kiểu spaghetti kinh dị, các chuỗi code if-else ngùng ngoằng, những chương trình mà chỉ cần thay đổi 1 biến thôi là hồ hết chương trình sở hữu thể bị phá vỡ, các hàm làm cho người ta hoa cả mắt… đó là điều thường xảy ra các người thiếu kinh nghiệm cứ cố hoàn thành 1 sản phẩm sở hữu thể chuyển giao.
Bạn đừng thỏa mãn có việc code của bạn có thể hoạt động mà hãy quyết tâm để code với thể hoạt động trong khoảng thời gian dài – để sau này ko chỉ bạn, mà bất cứ người nào khác cũng có thể dùng. Để làm cho được điều đấy, sau đây là 1 số nguyên tắc bạn phải nhớ như in.
KISS
Nguyên tắc “Đơn giản thôi, đồ ngốc” (“keep it simple, stupid”) mang thể ứng dụng cho mọi mặt của cuộc sống, nhưng đặc trưng thiết yếu cho các Dự án lập trình vừa và lớn.
Nguyên tắc này bạn phải áp dụng ngay từ đầu lúc bạn xác định khuôn khổ của của Công trình. Bạn đam mê tăng trưởng game không mang tức là bạn với thể tạo ra một thế hệ mới của Warcraft hay Grand Theft Auto đâu. Lúc nghĩ rằng bạn đã đủ thuần tuý hóa rồi, hãy đơn giản hóa nó thêm một lần nữa – bạn sẽ ko giảm thiểu khỏi việc gặp những “tính năng kinh tởm” (feature creep), do dó, hãy diễn ra từ các thứ nhỏ và đơn giản thôi.
Ngay cả lúc đã đang code rồi, hãy code thật thuần tuý. Code phức tạp cần đa dạng thời kì hơn để bề ngoài và viết, dễ bị lỗi, và khó sửa đổi sau này. Antoine de Saint-Exupery từng nói: “Hoàn hảo, chẳng phải là thiên nhiên có gì để thêm, mà là khi chẳng hề bớt thứ gì”.
DRY
Để viết được code clean và dễ sửa đổi thì nguyên tắc “đừng bao giờ viết mã bị trùng lặp” là học lập trình game khôn cùng quan yếu. Khi viết code, cố nhiên bạn muốn tránh trùng lặp dữ liệu và logic. Nếu như bạn tự thấy mình đang viết lặp đi lặp lại cộng một đoạn code, bạn đang vi phạm nguyên tắc này rồi đó.
trái lại với lề luật DRY là WET: “viết mọi thứ hai lần” (“write everything twice”) (hoặc “lãng phí thời gian” – “waste everyone’s time”). 1 Trong những phương pháp tốt nhất để rà soát WET là tự hỏi bản thân: nếu như muốn thay đổi hành vi của chương trình, mình cần phải sửa đổi bao nhiêu vùng mã?
ví thử bạn đang viết ứng dụng podcast. Trên trang tìm ****, bạn code để sắm nạp chi tiết của một podcast. Và trên trang podcast, bạn cũng code tìm nạp chi tiết podcast. Cùng một code tương tự trên trang yêu thích. Vậy cố gói gọn phần lớn trong một hàm thôi để ví như sau này cần sửa đổi thì bạn chỉ cần thực hiện 1 lần.
Mở / đóng
Cho dù bạn đang code trong Java hay các mô-đun Python, bạn nên ưu tiên những code cho phép mở mang nhưng giảm thiểu sửa đổi. Nguyên tắc này vận dụng cho rất nhiều các loại project, nhưng đặc biệt quan trọng với những loại thư viện hoặc khuông làm cho việc được hướng đến phổ thông người sử dụng.
ví dụ, bạn đang bảo trì lại khung làm việc GUI. Bạn mong muốn người mua đích có thể trực tiếp sửa đổi mà vẫn tích hợp code của mình. Nhưng giả dụ sau đấy tận 4 tháng bạn cho ra một bản cập nhật quan yếu thì sao? Thật khó để cập nhật chúng mà không tác động các sửa đổi trong khoảng người mua đích.
Xem thêm =>>https://mindx.edu.vn/
Thay vào đó, hãy giảm thiểu sửa đổi trực tiếp code mà khuyến khích mở rộng. Code ban đầu và những code sửa đổi sau sẽ được tách biệt. Ích lợi là gì? Code sẽ ổn định hơn (người sử dụng sẽ không sơ suất phá tan vỡ những code căn bản) và khả năng bảo trì rẻ hơn (người dùng chỉ phải lo về mã mở rộng). Nguyên tắc mở / đóng là chìa khóa để tạo ra 1 API tốt.
Đối tượng -> Thừa kế
Nguyên lý “hợp đối tượng thay vì thừa kế lớp” cho rằng đối sở hữu đối tượng sở hữu hành vi phức tạp, nên bao gồm những miêu tả của nó cộng có những hành vi riêng lẻ hơn là sử dụng lại 1 lớp (class) và thêm các hành vi mới.
Lạm dụng thừa kế sở hữu thể dẫn tới 2 vấn đề chính. Thứ nhất, sự phân cấp thừa kế với thể phát triển thành lộn xộn. Thứ 2, sẽ khó xác định hành vi của 1 trường hợp cụ thể hơn, đặc biệt khi bạn muốn ứng dụng hành vi từ một nhánh thừa kế vào 1 nhánh khác.
Composition thì code sẽ sạch hơn, dễ bảo trì hơn và sở hữu độ cởi mở gần như vô tận, miễn sao bạn có thân xác định được hành vi bạn muốn. Mỗi hành vi là một class riêng, và bạn chỉ việc thêm những hành vi lẻ vào để tạo ra một hành vi phức tạp.
Nguyên lý Single responsibility
Theo nguyên lý Single responsibility, mọi lớp hoặc mô-đun trong một chương trình chỉ nên sản xuất một tí chức năng cụ thể. Như Robert C. Martin đã kể, “Một lớp thì chỉ nên đổi thay vì 1 lí do độc nhất vô nhị.”
các lớp và mô-đun thường bắt đầu như thế, nhưng khi bạn thêm các tính năng và những hành vi mới, những class hay mô-đun này dễ cần tới hàng trăm hoặc thậm chí hàng nghìn mẫu code. Đây chính là khi bạn cần chia chúng ra thành rộng rãi lớp và mô-đun nhỏ hơn.
Nguyên lý Separation of Concerns
Nguyên lý Separation of Concerns tương tự như nguyên lý Single responsibility nhưng ở 1 chừng độ trừu tượng hơn. Về thực chất, một chương trình phải được thiết kế sao cho nó bao gồm đa dạng gói ko giống nhau, và các gói này không nên liên quan đến những gói khác.
một tỉ dụ nổi danh về mô phỏng này là mô hình MVC (Model-View-Controller), MVC phân chia 1 chương trình thành ba vùng riêng biệt: dữ liệu (“mô hình”), logic (“controller”), và những gì mà người mua đích nhận ra (“View”). Những biến thể của mô phỏng MVC rất hay gặp trong những khung làm cho việc của các trang web nức tiếng nhất ngày nay.
Ví dụ: Mã xử lý việc chuyển vận và lưu dữ liệu vào cơ sở vật chất dữ liệu không cần phải biết cách thức hiển thị dữ liệu trên web. Mã rendering mang thể lấy dữ liệu đầu vào từ các bạn đích, nhưng sau đó chuyển dữ liệu nhập vào mã logic để xử lý. Mỗi phần mang đều hoạt động độc lập.
Điều này đã mang đến cho chúng ta mã mô đun, giúp bảo trì tiện lợi hơn phổ quát. Và trong khoảng thời gian dài, nếu như bạn cần code lại số đông mã rendering, bạn hòan tòan chẳng phải lo lắng xem dữ liệu được lưu hay mã logic được xử lý như thế nào.
YAGNI
Nguyên tắc “bạn sẽ không cần nó” (you aren’t gonna need it) tức thị bạn không bao giờ nên code những chức năng mà sau này bạn mới cần. Việc đấy rất tốn thời kì vì rất có thể bạn sẽ không cần – không chỉ vậy, mã của bạn còn phát triển thành phức tạp một cách thức ko cần yếu.
với thể xem đây là một ứng dụng cụ thể của nguyên lý KISS và phản bác bỏ lại các người quá tuân thêo định lý DRY. Các lập trình viên thiếu kinh nghiệm thường nỗ lực viết mã trừu tượng và chung chung nhất có thể để hạn chế mã WET, nhưng quá nhiều mã tương tự lại làm mã của bạn không thể bảo trì được.
cách ở đây là chỉ áp dụng nguyên tắc DRY khi cần. Giả dụ bạn thấy những chuỗi code bị lặp lại, hãy trừu tượng hóa chúng – nhưng đừng bao giờ làm thế giả dụ chỉ 1 đoạn mã bị lặp lại. Không hề khi nào cũng ‘thừa còn hơn thiếu’.
hạn chế optimize code sớm
Nguyên lý Avoid Premature Optimization cũng tương tự như nguyên lý YAGNI. Điểm khác biệt là YAGNI giải quyết việc thực hành các hành vi chưa nhu yếu khi mà nguyên tắc này xử lý việc nâng cao tốc những thuật toán chưa cần phải có.
Vấn đề là nếu như optimize sớm thì bạn không bao giờ biết được những điểm cốt lõi của chương trình cho tới khi nó đi vào thực tiễn. Đương nhiên là người ta sở hữu thể đoán, thậm chí thỉnh thoảng đoán đúng. Nhưng thường thì bạn sẽ chỉ hoang phí thời gian nâng cao tốc độ 1 hàm không chậm như bạn tưởng, hoặc những hàm ít khi được tiêu dùng tới.
Hãy đi dần tới từng chỉ tiêu của bạn 1 phương pháp thuần tuý nhất với thể, sau ấy profile mã của bạn để tậu ra những điểm cốt lõi thực thụ.
Refactor, Refactor, và Refactor
1 lập trình thiếu kinh nghiệm hiếm khi code được đúng ngay trong khoảng lần đầu. Khi bạn thực hành các tính năng mới bóng bẩy thì nó mang lại cảm giác khá đúng, nhưng khi mã ấy mở rộng, các tính năng mới sẽ bị tác động bởi những code trước.
Codebase thì liên tiếp phát triển. Việc phải xem lại, viết lại, hoặc thậm chí kiểu dáng lại toàn bộ khối mã là hoàn toàn thông thường – và thậm chí là được khuyến khích. Vì so có ngày mới khởi đầu, giờ bạn đã hiểu hơn về nhu cầu của Dự án, và bạn nên thường xuyên dùng kiến thức vừa mới học được để refactor mã cũ.
Cũng nên nhớ rằng refactor không nhất mực phải là 1 quá trình dài. Như câu kể truyền thống của the Boy Scouts of America: “Hãy làm khu cắm trại sạch hơn khi Cả nhà mới tới đó”, vậy nếu như cần kiểm tra hoặc sửa đổi mã cũ, hãy luôn khiến chúng sạch hơn và trong trạng thái tốt hơn.
Relate Threads
