CFSDN nhấn mạnh vào giá trị tạo ra nguồn mở và chúng tôi cam kết xây dựng nền tảng chia sẻ tài nguyên để mọi nhân viên CNTT có thể tìm thấy thế giới tuyệt vời của bạn tại đây.

Bài viết trên blog CFSDN Trò chuyện PHP "Tái cấu trúc - Cải thiện thiết kế mã hiện có" là phần một trong việc sắp xếp lại các chức năng của bạn. Nó được tác giả sưu tầm và biên soạn. Nếu bạn quan tâm đến bài viết này, hãy nhớ thích nó.

Bấm vào hình ảnh bản đồ tư duy bên dưới để xem hình ảnh lớn hơn.

  Giới thiệu Mình sẽ viết ra điều mình thích và điều mình quan tâm nhất rồi chia sẻ với các bạn. Lần trước tôi có viết bài "Đối thoại giữa PHP và Sếp". Tôi vẫn còn rất nhiều câu hỏi và cuốn sách này đã giúp tôi rất nhiều. Nếu bạn bận hoặc quá lười đọc văn bản, tôi khuyên bạn chỉ cần nhìn vào ảnh chụp màn hình và bạn sẽ thu được rất nhiều điều. Bạn có thể biết cái nào tốt hơn bằng cách so sánh mã trong ảnh chụp màn hình. Tại sao tôi sử dụng hình ảnh trong phần mã? Vì tôi thường xuyên sử dụng điện thoại di động để đọc mã nên mã trong bãi blog lộn xộn trên điện thoại di động nên xem hình sẽ thoải mái hơn. Thuật ngữ chuyên nghiệp Xét cho cùng, chúng tôi sử dụng các chữ cái tiếng Anh để mã hóa, vì vậy việc sử dụng một số từ tiếng Anh có thể thể hiện tính chuyên nghiệp của chúng tôi tốt hơn. Nếu nắm vững các từ tiếng Anh sau đây, bạn sẽ trực tiếp và chuyên nghiệp hơn khi giao tiếp với các lập trình viên khác. --Hãy thể hiện mùi hôi thối của chúng ta nào, haha. "*" biểu thị nội tuyến thường được đề cập trong bài viết: hàm nội tuyến: hàm *phương thức: phương thức mịn: đổi tên chi tiết: đổi tên truy vấn: truy vấn temp: tạm thời (tạm thời) - thường đề cập đến các biến tạm thời *extract: extract - —Cá nhân tôi thích dịch nó là "tinh chỉnh" *trùng lặp: tách bản sao: phân tích biến: hệ số biến: hệ số, nguyên tắc tái thiết hệ số 1. Tái thiết là gì? Dạng danh từ: Sự điều chỉnh cấu trúc bên trong của phần mềm, với mục đích cải thiện khả năng hiểu và giảm chi phí sửa đổi mà không thay đổi hành vi có thể quan sát được của phần mềm. Dạng động từ: Sử dụng một bộ nguyên tắc tái cấu trúc để điều chỉnh cấu trúc của phần mềm mà không thay đổi hành vi có thể quan sát được của nó. 2. Tại sao phải tái cấu trúc? 1. Tái cấu trúc thường xuyên có thể giữ mã ở dạng phù hợp. 2. Để mã tìm vị trí thích hợp. 3. Làm cho phần mềm dễ hiểu hơn. 4. Có thể tìm thấy lỗi. 5. Cải thiện tốc độ mã hóa của chúng tôi. 3. Các vấn đề khi tái cấu trúc 1. Sửa đổi cách đặt tên giao diện Nếu phương thức trong lớp của bạn là công khai thì bạn sẽ gặp rủi ro lớn khi đổi tên. Bạn không biết mô-đun nào đang gọi phương thức của mình (chúng tôi có một cách tiếp cận phổ biến là thực hiện một phép đổi tên). grep trên toàn bộ dự án, sau đó xem xét từng lệnh gọi và logic của từng mô-đun). --Vì vậy, khi chúng tôi viết một lớp, chúng tôi cố gắng đặt các thuộc tính và phương thức ở mức riêng tư nhất có thể để tránh mở giao diện. 2. Khi nào không nên refactor (1) Viết lại toàn bộ code, mà code hiện tại quá khó hiểu nên refactor không bằng viết lại. (2) Nên tránh tái cấu trúc khi dự án sắp kết thúc. Chúng ta có thể đưa việc tái thiết vào giai đoạn thứ hai để giải quyết nó. Mã xấu có mùi 1. Mã trùng lặp 1. Hai phương thức của cùng một lớp chứa cùng một biểu thức. Giải pháp: Bạn có thể Giải nén Phương thức để trích xuất mã trùng lặp, sau đó để cả hai phương thức gọi Phương thức trích xuất này. 2. Hai lớp có phương thức tương tự nhau. Giải pháp: (1) Đưa ra các phương thức của hai lớp và cùng nhau xây dựng lớp cha. (2) Xóa phương thức của một lớp và gọi phương thức của lớp khác. 2. Phương thức dài 1. Hàm ngắn: Đọc mã mất chút công sức vì chúng ta phải thường xuyên chuyển ngữ cảnh để xem chương trình con làm gì. Nhưng chìa khóa thực sự để làm cho một phương pháp nhỏ trở nên dễ hiểu là một cái tên hay. Người đọc có thể hiểu chức năng của hàm thông qua tên gọi của nó mà không cần phải đọc nội dung ghi trong đó. --Trong các ngôn ngữ lập trình ban đầu, các phương thức gọi yêu cầu thêm chi phí, điều này khiến các lập trình viên không muốn sử dụng các phương thức nhỏ. Nhưng các ngôn ngữ OO hiện đại đã loại bỏ gần như hoàn toàn chi phí bổ sung (các lệnh gọi hàm) trong quy trình. 2. Tinh chỉnh các tín hiệu trong nhận xét: Bất cứ khi nào chúng ta cảm thấy cần sử dụng nhận xét để giải thích điều gì đó, chúng ta viết những gì cần giải thích thành một hàm độc lập và đặt tên theo mục đích của nó. Điều này có thể được thực hiện bằng một nhóm mã hoặc thậm chí chỉ với một dòng mã. - Chỉ cần tên hàm giải thích được cho người sử dụng thì chúng ta không ngần ngại thực hiện. “Hàm” được hiểu là “làm gì” hoặc “làm như thế nào” 3. Các biểu thức và vòng lặp có điều kiện thường cũng là những tín hiệu được tinh chỉnh. 4. Một ví dụ về "Độ sạch của mã". Chúng ta có thể suy nghĩ về nó! .

3. Lớp lớn 1. Nếu một số biến thuộc tính trong Lớp có cùng tiền tố hoặc hậu tố thì có thể sử dụng Lớp trích xuất. 2. Không phải hầu hết các biến trong Class đều sử dụng biến thuộc tính, Extract Class có thể được sử dụng. 3. Nếu có quá nhiều mã, bạn có thể Trích xuất lớp. 4. Tham số dài được tạo thành Đối tượng tham số giới thiệu. ---Tôi không đồng ý với điều này, vì khi sử dụng phương pháp của người khác, tôi hiếm khi nhìn vào code thực hành chứ đừng nói đến tính chất hoặc phương thức của các đối tượng được sử dụng trong đó để lấy dữ liệu tôi muốn. 5. Câu lệnh chuyển đổi 1. Sử dụng câu lệnh chuyển đổi một cách tiết kiệm. ---Vấn đề là sự trùng lặp. Khi thêm các trường hợp mới, bạn phải tìm tất cả các trường hợp và sửa đổi chúng. 2. Thay thế nó bằng tính đa hình. Phương thức: 1. Thực hiện Phương thức trích xuất trên switch 2. MoveMethod đặt mã thực tế trong trường hợp vào lớp đa hình. 6. Nhận xét Hãy thử Phương pháp trích xuất Nếu cách đó không hiệu quả, hãy thử Đổi tên phương pháp. Khi bạn cảm thấy cần phải viết bình luận, hãy thử tái cấu trúc trước để làm cho tất cả các bình luận trở nên dư thừa. Nhận xét thường được sử dụng cho các kế hoạch trong tương lai, nhưng cũng có thể được sử dụng cho những lĩnh vực mà bạn không hoàn toàn chắc chắn (tại sao bạn lại làm điều gì đó). Sắp xếp lại các chức năng của bạn. Phương thức dài thường chứa quá nhiều thông tin, bị che khuất bởi logic phức tạp và khó xác định. 1. Phương pháp trích xuất.

 

Tóm tắt Đây chỉ là một phần nội dung của cuốn sách này. Tôi biết rằng sẽ có nhiều lập trình viên có quan điểm khác nhau. Tôi cũng có những ý kiến ​​​​khác nhau. Vì vậy, chúng ta phải “làm theo cái tốt và sửa cái xấu”. Mọi người đều được chào đón để bày tỏ ý kiến ​​​​của bạn.

Cuối cùng, bài viết này về việc sắp xếp lại các chức năng của bạn trong một trong các cuộc trò chuyện PHP "Tái cấu trúc-Cải thiện thiết kế mã hiện tại" có ở đây. Nếu bạn muốn biết thêm về Trò chuyện PHP "Tái cấu trúc-Cải thiện thiết kế mã hiện có". sắp xếp lại nội dung chức năng của bạn, vui lòng tìm kiếm các bài viết của CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .