Xin chào anh em, lâu lắm rồi do việc làm dự án ở C.ty cái nào cũng gấp gáp nên không có nhiều thời hạn viết bài giải bày các kiến thức mà mình đã học hỏi đc. Giờ đây tiết trời chứa một chút sương sương lạnh, không khí thật trong lành nên mình xin được thiết kế một bài giải bày cũng sương sương thôi =)) Mong anh em đọc cảm nhận hay thì upvote còn không hay thì đừng có downvote nhé, mình buồn.
Bạn đang xem: Refactoring là gì
Bài Viết: Refactoring là gì
Như chúng ta biết đấy, khi mới code thì các bạn thường chăm lo đến việc chương trình ta viết ra nó chạy đc hay không mà quên mất công việc sao cho đoạn mã code mình vừa type ra áp dụng đc sau này. Hay là liệu nếu với code như này liệu có đúng cách convention hay chưa ? Ok một cái rất quan trọng khi các bạn khởi đầu làm dự án ở C.ty đó đó chính là cần phải có một chuẩn convention để mọi người follow cho dễ, code sao cho sạch xinh, né đc các code smell. Trong bài viết ngày hiện giờ thì mình xin đc giải bày tới mọi người thế nào là Code Smell and một số những kỹ thuật Refactoring mà các bạn hay thường gặp nhé. Nó rất căn bản and dễ chơi thôi, các bạn nếu né đc các lỗi này thì sẽ cứu cho các bạn biến thành các developer bài bản hơn.
1. Code Smell
Tóm Tắt
1.1 Thế nào là Code Smell ?
Thì theo chị wikipedia thì chị ý định nghĩa như sau:
In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem
Mình có thể nói theo cách khác của tôi như sau:
Nó không cần là BugNó không sau về mặt technicalNó không gây nên chương trình không chạy đc
1.2 Một vài Code Smell thường gặp
Biến
Các bạn hay đặt tên biến như sau:
Tên biến không có ý nghĩa and khó hiểu: vd $a, $bKhông áp dụng cùng tự vựng cho biến: lúc đặt tiếng anh, lúc đặt tiếng việtĐặt tên biến khó tìm kiếmThêm các content không thiết yếu:
trong class Car thì ai cũng hiểu là $carMake, $carModel, $carColor đểu là những thuộc tính của Car. Các bạn nên đặt tên biến ngắn gọn and dễ hiểu như sau
Hàm
Tham số truyền vào hàm quá nhiều: các bạn nên truyền vào hàm 3,4 tham số là nhiều rồi, đừng nên truyền quá nhiều tham số vào hàm nhé.Hàm tiến hành triển khai quá đa chức năng: bình thường hàm chỉ tiến hành triển khai một chức năng là phương thức viết hàm clear and đẹp tuyệt vời nhất, chúng ta nên nỗ lực áp dụng if-else switch-case tổi thiểu trong một hàm, vì khi các bạn đã áp dụng đến nó chắc chắn hàm đó sẽ tiến hành triển khai đa chức năng.Tên hàm khó đoán ra hàm ấy có công dụng gìHàm chứa nhiều cấp trừu tượng: Khi bạn có dộ trừu tượng nhiều hơn một cấp thì hàm thưởng phải làm quá nhiều việc.
Hàm tiến hành triển khai quá đa chức năng and trường hợp: Điều đó nó cũng khó cho chúng ta, vì mọi người sẽ câu hỏi rằng làm thế nào để làm gì đó mà nợ if-else đc. Các bạn cứ luôn nhớ mỗi hàm chỉ nên tiến hành triển khai một chức năng mà thôi. Bên dưới chính là một ví dụ tồi cho việc viết hàm làm quá đa chức năng.
Đối tượng người dùng
Không áp dụng đặc điểm đóng gói trong hướng đối tượng người sử dụng
Nếu các bạn áp dụng thì code các bạn phải như sau
Không áp dụng thuộc tính cách thức private/protected
Các bạn nên thêm các thuộc tính co cách thức hoặc cho thuộc tính của class. Đoạn mã rất tốt sẽ như sau
Mình đã vừa hiện ra Code Smell nó là đồ gì and một số những case mà chúng ta hay bận bịu phải khi code. Phần 2 mình sẽ nói đến nguyên lý thiết kế nhé.
2. Nguyên lý thiết kế
2.1 Định nghĩa
Nguyên lý thiết kế ứng dụng là một tập hợp những chỉ dẫn cứu các bạn né khỏi một thiết kế tồi. Ba nổi bật quan trọng của một thiết kế ứng dụng xấu ta nên né:
Tính chắc nịch: tức là khó có thể biên tập vì mỗi khi ta biên tập thì nó ảnh hướng quá nhiều đến phần khác của hệ thốngTính bất nhất định: tức là khi bạn tiến hành triển khai một sự biên tập nào đó, phần biên tập đó sẽ có thể gây phá vỡ hệ thốngTính kém linh động: tức là ta khó có thể tái áp dụng lại trong những phần mềm khác bởi nó đã không còn gì tách rời khỏi những phần mềm hiện hành
2.2 Nguyên lý SOLID
Single responsibility princible
Nguyên lý này ý muốn bảo rằng một class chỉ nên giữ một trách nhiệm duy nhất. Nếu không thì càng về sau class đó sẽ bị phình lớn ra các bạn cực khó để biên tập.
public class Data(){ public function read(); public function import(); public function export();}Ta cảm nhận rằng class trên có 3 trách nhiệm liền theo đó về sau class sẽ vẫn phình lớn ra nữa. Theo đúng nguyên tắc ở trên cao các bạn nên tách class trên thành 3 class bé dại hơn sao cho mỗi class giữ một trách nhiệm duy nhất.
public class readData() {…}public class passData() {…}public class exportData() {…}Open/closed principle
Các bạn có thể nhẹ nhõm mở rộng một class nhưng không đc sửa đổi bên phía trong class đó. Mỗi khi ta muốn thêm chức năng cho chương trình, ta nên viết class mới mở rộng class cũ ra, đừng nên sửa đổi class cũ.
Liskov Substitution Principle
Nguyên tắc này ta có thể phát biểu như sau: những object của class con có thể thay thế class cha mà không làm biên tập tính đúng chuẩn của chương trình.VD như ta có class Human có những class con là Male and Female. Nhưng nếu chúng ta viết Manikin thì khi kế thừa class Human nó sẽ bị gây lỗi vì Manikin không phải thực thể sống, vi phạm nguyên tắc.
Interface Segregation Principle
Các bạn thay thế vì cần sử dụng một interface to, ta nên tách thành nhiểu interface bé dại với nhiều mục đích khác nhau. Ví dụ các bạn chứa một interface với 100 method , việc implement sẽ khá đau khổ ngoài ra những class nó không cần sử dụng hết hay override lại đc hết cục bộ method trong interface này. Khi các bạn tách interface ra thành nhiều interface bé dại, gồm những nhóm method ảnh hưởng tới nhau, việc implement and quản trị sẽ dễ dàng hơn.
Dependency inversion principle
Những module cấp cao đừng nên chịu ảnh hưởng vào những module cấp thấp and ngược lại. Cả hai nên chịu ảnh hưởng vào abstraction. Interface đừng nên chịu ảnh hưởng vào rõ rệt mà ngược lại , những class tiếp xúc trải qua interface, không phải trải qua implementation.
Xem thêm: Nghĩa Của Từ Encompass Là Gì, Encompass Là Gì, Nghĩa Của Từ Encompass
Ví dụ sạc samsung có thể sạc những dòng samsung galãy, A5, A7, … Nó là interface , implementation những dòng samsung chứ không chăm lo tới phương thức thức sạc của mỗi dòng là gì.
2.3 Nguyên lý YAGNI
Nguyên lý này muốn nói lên các bạn chỉ cần tập trung thành lập chức năng vấn đề tại thời hạn hiện nay, đừng nên tự vẽ ra các chức năng có thể đc áp dụng đến.
2.4 Nguyên lý KISS
Nguyên lý này mang hàm ý muốn nói hãy gây nên mọi thứ cũng trở nên dễ chơi hơn để bạn cũng có thể luôn hiểu đc. Hãy viết ra các dòng code thật dễ hiểu and dễ chơi. Hãy để số lượng dòng code của một lớp hay cách thức ở con số hàng chục thôi đừng viết hàng trăm hàng ngàn dòng code trong một tệp tin, thực sự kém sang lắm.
2.5 Nguyên lý DRY
Nguyên lý này muốn nói là các bạn đừng lặp lại một đoạn mã nào mà hãy đóng gói nó thành cách thức riêng. Đến khi cần chỉ cần gọi tên nó ra thôi.
3. Những kỹ thuật Refactoring
3.1 Thế nào là refactor code ?
Refactor là những thao tác tùy chỉnh code nhằm cải thiện nó mà không biên tập chức năng thuở đầu.
3.2 Một số những kỹ thuật refactor thường cần sử dụng
Tách method
Khi các bạn code ra một method điều mà các bạn chăm lo trước tiên đó đó chính là method đó chỉ nên làm một nhiệm vụ duy nhất né áp dụng những từ khóa if-else, switch-case nhiều trong method đó. Nhưng điều ấy hình như cực khó đúng không chúng ta ? Tiếp theo chung ta đừng nên viết một method quá dài , hàng mấy trăm dòng code trong một method này là chứng tỏ method của các bạn có vấn đề rồi, nên tách method ra.
Hoặc có thể dễ chơi các bạn tìm ra một đoạn code nào lặp lại rất nhiều lần ở những method các bạn cần sử dụng and tách thành một method, điều ấy cứu bạn không bị lặp code.
Tách class
Đấy là kỹ thuật đc sử dụng cho các class to. Ta biết đấy, các cách thức and dữ liệu nào có ảnh hưởng đến nhau để được gom vào một class. Tuy vậy khi các bạn thiết kế class, có lúc các bạn thêm rất đông method vào class đó nhưng chẳng ảnh hưởng gì đến class đó cả. Đấy là lúc các bạn nên sử dụng kỹ thuật tách class. Các bạn xem có các thành phần nào ảnh hưởng tới nhau mà đã không còn gì chịu ảnh hưởng vào class to đó nữa thì tách hẳn ra một class khác.
Dễ chơi hóa biểu thức
Các bạn thử xem đoạn code bên dưới đây nhé
Nhìn trông khó khăn đúng không chúng ta, có lẽ rằng nếu mà chúng ta dev nào mới code thì vẫn có thể code theo như này, đồ gì có thể là nhét hết vào biểu thức trường hợp. Vậy code sạch đẹp tuyệt vời các bạn sẽ code như sau
Kéo method từ lớp con lên lớp cha
Việc các bạn kéo method and thuộc tính từ lớp con lên lớp cha có ảnh hưởng tới đặc điểm kế thừa trong lập trình hướng đối tượng người sử dụng. Các bạn sẽ kéo các thành phần nào có nổi bật chung giống nhau của những lớp con kế thừa từ một cha lên class cha.
Ta cảm nhận có cách thức chuVi() là chung của hai lớp con nên ta sẽ kéo cách thức này lên lớp cha
Kéo method từ lớp cha xuống lớp con
Y hệt như cách thức trên nhưng chỉ khác nhau là thay thế vì kéo lên ta lại kéo xuống. Các bạn tìm ra các thành phần mà chỉ hữu dụng cho một lớp con cần sử dụng trong các lớp con còn lại.
Xem thêm: Ê Đi Xơn Và Bà Cụ ” – Tập Đọc Lớp 3: Nhà Bác Học Và Bà Cụ
Như chúng ta cảm nhận đấy thì cách thức Bay() chỉ có lợi cho mỗi lớp con ConChim thôi mà lại không có lợi cho các lớp con kế thừa còn lại nên các bạn sẽ kéo function Bay() xuống lớp ConChim
4. Kết luận
Vậy qua một số các kiến thức căn bản ở trên cao mong rằng cũng cứu ích cho chúng ta code clean hơn, né đc những code smell hơn. Cảm ơn chúng ta đã đọc bài giải bày của tôi.
Thể Loại: Share Kiến Thức Cộng Đồng
Bài Viết: Refactoring Là Gì – Code Smell And Refactoring
Thể Loại: LÀ GÌ
Nguồn Blog là gì: https://ktktdl.edu.vn Refactoring Là Gì – Code Smell And Refactoring
