Làm thế nào để cấu trúc lại một Codebase?

Mar 21 2022
Có, điều bạn muốn làm trước đây
Hôm nay tôi sẽ làm những gì người khác sẽ không làm vì vậy ngày mai tôi có thể làm những gì người khác không thể - Jerry Rice Cho dù đó là cố gắng cấu trúc lại mã của chính bạn hay đang cấu trúc lại mã của người khác, một nhà phát triển phần mềm sẽ phải đối mặt với người tái cấu trúc mã vào một lúc nào đó. Nhưng tại sao chúng ta thậm chí phải cấu trúc lại mã của mình, và chúng ta làm điều đó như thế nào? Cơ cấu lại mã là gì? Quá trình tái cấu trúc mã máy tính hiện có - thay đổi bao thanh toán - mà không thay đổi hành vi bên ngoài của nó.
Ảnh của Arnold Francisca trên Unsplash

Hôm nay tôi sẽ làm những gì người khác sẽ không để ngày mai tôi có thể làm những gì người khác không thể - Jerry Rice

Cho dù đó là cố gắng cấu trúc lại mã của riêng bạn hay đang cấu trúc lại mã của người khác, một nhà phát triển phần mềm sẽ phải đối mặt với người tái cấu trúc mã vào một lúc nào đó.

Nhưng tại sao chúng ta thậm chí phải cấu trúc lại mã của mình, và chúng ta làm điều đó như thế nào?

Cơ cấu lại mã là gì?

Quá trình tái cấu trúc mã máy tính hiện có - thay đổi bao thanh toán - mà không thay đổi hành vi bên ngoài của nó. Tái cấu trúc nhằm mục đích cải thiện thiết kế, cấu trúc và / hoặc triển khai của phần mềm (các thuộc tính phi chức năng của nó), trong khi vẫn bảo toàn chức năng của nó. - Wikipedia

Tóm lại, thay đổi mã mà không phá vỡ các chức năng hiện tại.

Mục tiêu chung của Refactor

  • Để làm cho mã của chúng tôi có thể bảo trì được trong tương lai
  • Để tăng khả năng đọc của mã
  • Để giảm bớt sự phức tạp
  • Để cải thiện hiệu suất của mã
  • Để giúp các tính năng trong tương lai được triển khai dễ dàng hơn
  • Thêm nhận xét / tài liệu có thể làm cho mã dễ hiểu hơn
  • Mã không được thay đổi tích cực.
  • Mã đáp ứng tiêu chuẩn mã hiện tại
  • Khi có thông số kỹ thuật phù hợp, việc viết lại có thể có ý nghĩa hơn
  • Mã hiện tại có lỗi chức năng
  • Khi một tính năng mới được thêm vào

Có một kế hoạch

Khi bạn và nhóm của bạn đã quyết định tái cấu trúc. Điều quan trọng là phải có một kế hoạch lỏng lẻo để thông báo cho nhóm của bạn.

  1. Gặp gỡ một số nhà phát triển đã làm việc trên mã mà bạn sẽ cấu trúc lại
  2. Lên kế hoạch từng bước với nhóm
  3. Thông báo cho các bộ phận khác của nhóm về kế hoạch

Nếu bạn tiếp cận refactor như xây dựng một công ty khởi động bí mật trong nhà để xe, bạn sẽ gặp rất nhiều phản kháng khi cố gắng hợp nhất mã. Không chỉ đồng nghiệp của bạn có thể cần viết lại một số công việc của họ, mà việc kiểm tra và tìm ra sai sót cũng sẽ khó hơn.

Có bài kiểm tra tại chỗ

Nếu bạn không có bài kiểm tra cho các bộ phận mà bạn sắp cấu trúc lại, bạn nên viết bài kiểm tra trước.

Nó sẽ giúp bạn tiết kiệm thời gian khi bạn muốn đảm bảo rằng việc tái cấu trúc không làm hỏng bất cứ điều gì.

Dưới đây là 13 mẹo cho các bài kiểm tra đơn vị:

Dưới đây là một số mẹo yêu thích của tôi phù hợp hơn với refactor:

  1. Thử nghiệm một điều tại một thời điểm trong sự cô lập
  2. Tuân theo Quy tắc AAA: Sắp xếp, Hành động, Khẳng định
  3. Viết các bài kiểm tra phát hiện ra một lỗi, sau đó sửa chữa nó
  4. Đặt tên cho các bài kiểm tra của bạn rõ ràng và không sợ tên dài
  5. Làm cho mỗi bài kiểm tra trở nên độc lập
  6. Chạy thử nghiệm thường xuyên

Tài liệu nên tồn tại nhưng nó không phải lúc nào cũng tồn tại. Khi nó không tồn tại và bạn không có liên hệ của người đã viết mã, bạn phải đọc để viết mã và hiểu những gì đang xảy ra.

Một số mẹo để hiểu mã hoạt động:

  • Chạy mã
  • Chạy trình gỡ lỗi với mã
  • Tìm điểm vào
  • Hình dung các kết nối
  • Nói chuyện với người dùng
  • Nói chuyện với ai đó đã làm việc trên mã trước đây

Cố gắng tuân theo nguyên tắc KHÔ, “Đừng lặp lại chính mình”, nói thì dễ hơn làm. Khi cơ sở mã đã qua tay một số nhà phát triển, mà không có tiêu chuẩn mã phù hợp và sự lựa chọn phong cách, thì một lúc nào đó sẽ xảy ra sự lặp lại.

Điều khó khăn là làm thế nào để phát hiện mã lặp lại và làm thế nào để viết lại nó khô?

Truy xuất lại nguồn

Giao diện người dùng:

  1. nhìn vào giao diện người dùng để xem những gì trông giống nhau
  2. sử dụng “Kiểm tra phần tử” trong bảng điều khiển để tìm một số thông tin mà bạn có thể sử dụng để tìm kiếm mã đó
  3. Nếu chúng thực sự là hai (hoặc nhiều) đoạn mã khác nhau, hãy biến chúng thành một thành phần có thể tái sử dụng
  4. Bất cứ khi nào có thể, hãy tách thành phần trình bày khỏi chức năng
  1. Tập trung vào một điểm cuối tại một thời điểm
  2. Tìm kiếm các từ khóa điểm cuối để tìm mã nhập, ví dụ: “/ user”
  3. Nếu tìm kiếm từ khóa không hoạt động, hãy tìm điểm nhập của dịch vụ phụ trợ. Sau đó, hiểu cách thiết lập điểm cuối
  4. Tìm dịch vụ / chức năng khác mà điểm cuối phụ thuộc vào
  5. Suy nghĩ về cách giảm các bước để đạt được phản hồi hiện tại (đầu ra của điểm cuối)

Nếu bạn may mắn, có thể có những từ khóa giống hệt nhau được sử dụng ở những nơi khác nhau. Và nếu bạn nhận ra rằng mã cũng làm điều tương tự, thì đó sẽ là một nơi tốt để thay thế nó bằng các chức năng có thể tái sử dụng.

Hình dung bất cứ khi nào có thể

Vẽ ra cấu trúc mã để xem mọi thứ được kết nối như thế nào. Mục đích của việc này là để thảo luận với đồng đội của bạn để xem liệu cách hiểu của bạn có đúng hay không. Ngoài ra, có sơ đồ sẽ giúp bạn phát hiện ra bất kỳ thiết kế nào không phải là không lý tưởng.

Một số công cụ sơ đồ:

  1. Miễn phí: draw.io
  2. Không quá miễn phí: Lucidchart

Suy nghĩ đầu vào và đầu ra

Điều này phù hợp với các nguyên tắc “ Trách nhiệm chung ” và “ Tách biệt các mối quan tâm ”.

Khi nhìn vào một chức năng, nếu bạn biết mục đích của nó là gì, thì việc giảm đầu vào hoặc đầu ra sẽ dễ dàng hơn rất nhiều.

Giảm các biến

Đo tiến độ lập trình bằng các dòng mã giống như đo tiến độ chế tạo máy bay theo trọng lượng. - Bill Gates

Mặc dù ít dòng mã hơn không phải lúc nào cũng có nghĩa là mã tốt hơn, nhưng càng ít mã có nghĩa là nhà phát triển càng tải ít nhận thức hơn.

Tải ít nhận thức hơn có nghĩa là một nhà phát triển có thể hiểu cơ sở mã nhanh hơn và tìm ra lỗi nếu có.

Một cách tiếp cận khác để khấu trừ biến số:

  • Sắp xếp → Hiểu → Đổi tên → Xóa dự phòng
  • Hiểu → Đổi tên → Sắp xếp → Loại bỏ Dự phòng

Giảm các điều kiện lồng ghép

Tương tự như các biến có tên sai, các điều kiện lồng nhau cũng có thể làm tăng tải nhận thức đối với nhà phát triển.

Xuất cảnh sớm

Hãy suy nghĩ về cách bạn có thể viết lại điều kiện mà bạn có thể thoát khỏi hàm càng sớm càng tốt. Bằng cách này, bạn có thể tránh được rất nhiều elsetình trạng bệnh.

Tránh Ternary lồng nhau

Tôi cũng đã từng viết chuỗi ba lồng nhau, vì thông thường nó yêu cầu ít mã hơn. Nhưng sau khi nhận được một số con chim nhạn điên cuồng lồng vào nhau, nó chắc chắn có thể từ từ khiến ai đó phát điên.

Bình luận, bình luận và bình luận

Luôn lập mã như thể kẻ cuối cùng duy trì mã của bạn sẽ là một kẻ tâm thần bạo lực, kẻ biết bạn sống ở đâu. - John Woods

Ngay cả khi người đang tiếp quản mã của bạn không phải là kẻ thái nhân cách, bạn vẫn có thể viết bình luận để giúp người đó không trở thành kẻ thái nhân cách.

Bình luận giống như một luồng gió mới sau khi một người chìm trong biển rác và bụi bẩn.

Ngay cả khi bạn không quan tâm đến người bên cạnh, hãy nghĩ về bản thân trong tương lai của bạn. Bạn có thể đảm bảo rằng bạn sẽ luôn nhớ những gì bạn đã viết không?

Tính nhất quán và định dạng

Mẫu tên, mẫu thiết kế và định dạng mã phải nhất quán. Ít nhất từ ​​bản thân bạn, hãy kiên định với một phong cách.

Đối với nhóm, bạn sẽ cần một số tài liệu và thông tin liên lạc. Đồng thời, bạn có thể tận dụng pre-hook và eslint để thực thi một số loại định dạng mã.

Tập trung vào một mục tiêu cho một cam kết

Chủ nghĩa hoàn hảo có thể ngăn cản bạn tái cấu trúc. Đặc biệt, mục tiêu chính của tái cấu trúc là cải thiện cấu trúc mã.

Thật hấp dẫn khi có một bộ tái cấu trúc giải quyết mọi vấn đề của thế giới, nhưng bộ tái cấu trúc có thể không bao giờ hoàn thành.

Ngoài việc có một kế hoạch để chia nó thành các bước, mỗi cam kết có thể được dành riêng cho một mục tiêu.

Ví dụ,

git commit -m 'renamed variables'

git commit -m 'renamed variables in profile page'

Rõ ràng, điều này dựa trên kinh nghiệm của bản thân tôi từ việc lăn lộn trong lĩnh vực code trong nhiều năm, tôi nhận ra rằng có nhiều người có kinh nghiệm hơn với tư cách là nhà phát triển phần mềm.

Want to Connect?
Let’s connect on LinkedIn.

© Copyright 2021 - 2023 | vngogo.com | All Rights Reserved