Refactoring – Mở đầu

Bài viết Refactoring – Mở đầu thuộc chủ đề về Câu Hỏi Quanh Ta đang được rất nhiều bạn lưu tâm đúng không nào !! Hôm nay, Hãy cùng sotaythongthai.vn tìm hiểu Refactoring – Mở đầu trong bài viết hôm nay nha !

Các bạn đang xem chủ đề về : “Refactoring – Mở đầu”


Refactoring

Refactoring - Mở đầu

Refactoring chắc hẳn ai đang làm phần mềm thì đều biết đến kỹ thuật này, trước đây thì tôi nghĩ refactoring chỉ là một bước phụ, không quan trọng, lúc nào mình thích thì mình làm thôi. Nhưng sau khi tham gia khóa học Agile Development tôi thấy việc refactoring là rất rất cần thiết trong một dự án. Trong series về refactoring này tôi sẽ trình bày refactoring là gì, tầm quan trọng của nó và các kỹ thuật để refactoring.

Refactoring là gì?

Refactoring là một quy trình cải tiến code khả năng kiểm soát được mà không tạo ra chức năng mới. Nó biến những thứ hỗn độn thành những thiết kế đơn giản hơn và clean code.

Bạn đang xem: refactoring la gi

Clean code

Về cơ bản, clean code có một vài tính năng như:

  1. Clean code rõ ràng cho các lập trình viên khác. Ở đây ta không kể đến những thuật toán cực kỳ phức tạp. Đặt tên biến, tên hàm thì khó hiểu, không liên quan đến chức năng của nó; các class và method viết thì dài, khó để nhớ hết chức năng của nó. Tất cả những điều đó làm cho code bị bẩn (code smell hay code sloppy) và khó để hiểu, nắm bắt.
  2. Clean code không trùng lặp. Khi code bị lặp và ta phải thay đổi ngay một vài thứ ở phần code bị lặp đó, thì ta phải thay đổi ngay tất cả những phần còn lại. Điều này làm chậm lại quy trình code.
  3. Clean code chứa ít code nhất khả năng. Code ít hơn thì ta chỉ cần nhớ ít hơn, dễ bảo trì hơn, ít bugs hơn. vì thế hãy giữ cho code ngắn và đơn giản.
  4. Clean code vượt qua tất cả các test. Nếu code của bạn chỉ vượt qua 95% test case thì code đó chưa được clean.
  5. Clean code thì bảo trì đơn giản hơn và chi phí ít tốn kém hơn.

Technical debt

Tất cả mọi người trong chúng ta đều cố gắng hết sức để viết code chuẩn ngay từ đầu. Có lẽ không có người nào cố ý viết code không clean để làm gây tác động dự án. Vậy tại thời điểm nào mà clean code trở nên không clean?

Phép ẩn dụ technical debt (tạm dịch là nợ kỹ thuật) liên quan đến code không clean được đề xuất bở Ward Cunningham.

Nếu bạn nhận được khoản vay từ ngân hàng, điều này giúp cho việc đầu tư nhanh hơn. Đương nhiên bạn phải trả thêm tiền việc này – tức là bạn không những phải trả nợ gốc, mà còn phải trả thêm lãi. Không cần phải nói, thậm chí bạn phải trả số tiền lãi nhiều hơn số tiền bạn thu được từ việc đầu tư, điều này làm cho việc trả lại số tiền cho ngân hàng là không thể.

Điều tương tự cũng xẩy ra khi ta code. Bạn khả năng tạm thời đẩy nhanh dự án bằng việc không viết test có các tính năng (tức là bạn đang nợ), nhưng điều này sẽ dần dần làm chậm tiến độ của bạn mỗi ngày do bug cho đến khi bạn phải trả hết nợ bằng cách viết test.

Các tác nhân của nợ kỹ thuật

Áp lực buôn bán

Đôi khi các tình huống về mặt buôn bán, khi mà khách hàng họ muốn danh mục của họ được đẩy lên sớm hơn khả năng buộc bạn phải triển khai các tính năng trước khi hoàn tất.

Trong trường hợp này, các bản bổ sung, fix bug sẽ được đẩy lên để hoàn thành những phần đó của dự án.

Thiếu hiểu biết về hậu quả của nợ kỹ thuật

Đôi khi sếp của bạn không hiểu về nợ kỹ thuật (nợ này ở mức chấp nhận được) cũng khả năng làm chận tốc độ phát triển dự án.

Xem thêm: Đánh giá về tới tháng là gì | Sen Tây Hồ

Điều này khả năng làm cho nó quá khó để các thành viên trong team dành thời gian để refactor bởi vì sếp của bạn không nhìn thấy tổng giá trị mà nó đem lại.

Không đáp ứng được mối quan hệ tình dục chặt chẽ của các component

Đây là khi dự án của bạn là một khối chứ không phải là danh mục của từng module riêng lẻ.

Trong trường hợp này, bất kì thay đổi ngay nào đối với một phần trong dự án sẽ gây tác động các phần còn lại. Sự phát triển của cả team trở nên khó khắn hơn vì khó để khả năng tách riêng công việc của các thành viên.

Thiếu việc test

Việc thiếu phản hồi ngay lập tức khuyến khích việc sửa đổi nhanh, nhưng có nguy cơ gây ra ra lỗi, và đôi khi tác động trực tiếp đến môi trường production.

tác động của việc này khả năng trở thành thảm họa. Ví dụ, một hotfix vô tội khả năng gửi một email đến toàn bộ khách hàng hay xóa dữ liệu khách hàng hiện nay trong cơ sở dữ liệu.

Thiếu tài liệu

Điều này làm chậm việc giới thiệu cho người mới về dự án và khả năng làm chậm lại quy trình phát triển nếu những người chủ chốt rời khỏi dự án.

Thiếu sự tương tác giữa các thành viên trong nhóm

Nếu các kiến thức về dự án không được trao đổi, hiểu biết về dự án như các quy trình, thông tin dự án của mọi người sẽ lạc hậu.

Tình huống này khả năng trở nên trầm trọng hơn khi các bạn junior developer được đào tạo không chính xác bởi các mentor.

Phát triển cùng lúc ấy dài hạn tại một vài nhánh

Điều này khả năng kéo theo sự tích tụ về nợ kỹ thuật, sau đó sẽ tăng lên khi các thay đổi ngay, bổ sung được merge vào project.

Càng nhiều sự thay đổi ngay từ nhiều người làm cho nợ kỹ thuật ngày càng lớn.

Trì hoãn việc refactoring

bắt buộc dự án liên tục thay đổi ngay và tại một vài thời điểm các phần code đó sẽ trở nên lỗi thời, rườm rà và phải được refactor để đáp ứng các bắt buộc mới.

Tham khảo thêm: Nguyên Liệu trong Tiếng Anh là gì: Định Nghĩa, Ví Dụ Anh Việt

Mặt khác, các lập trình viên đang viết code mới mỗi ngày mà làm việc với các phần code quá cũ. vì thế, việc refactoring sẽ bị trì hoãn, những phần code bị phụ thuộc nhiều sẽ phải được làm lại trong tương lai.

Thiếu tuân thủ việc giám sát

Điều này xảy ra khi mọi người làm việc trong dự án viết code khi họ đã cảm thấy phù hợp.

Vậy khi nào thì cần refactor?

3 luật cơ bản

  1. Khi bạn làm một cái gì đó lần đầu tiên, ta chỉ cần hoàn thành phần đó thôi.
  2. Khi bạn làm một cái gì đó tương tự lần thứ hai, mặc dù cảm thấy hơi lo lắng nhưng vẫn hãy làm điều tương tự như bước 1.
  3. Khi bạn làm gì đó lần thứ ba, hãy bắt đầu refactoring.

Khi thêm một tính năng

  1. Refactoring giúp bạn hiểu được code của người khác viết Nếu bạn phải làm việc với code của người khác viết, hãy thử refactor nó trước tiên. Làm code trở nên clean thì mình sẽ đơn giản nắm bắt hơn. Bạn sẽ nâng cao hơn nó không những cho mình mà còn cho những người dùng nó sau bạn.
  2. Refactoring giúp ta đơn giản thêm các tính năng mới

Khi fix một bug

Các bug vận hành giống như ngoài đời thực (sâu, bọ): chúng sống ở những nơi tối nhất, bẩn nhất trong code. Làm code của bạn được clean thì khả năng khám phá ra những bug của chính mình.

Các sếp đánh giá cao việc chủ động refactoring vì nó loải bỏ sự refactoring rất cần thiết cho các task phức tạp sau này. Happy bosses make happy programmers!

Trong khi review code

Review code khả năng là cơ hội cuối cùng để làm code clean trước nó sẵn sàng để public.

Tốt nhất ta nên thực hiện việc review theo cặp. Bằng cách này ta khả năng khắc phục các vấn đề đơn giản một cách nhanh chóng và đánh giá được thời gian fix các bug khó hơn.

Cách để refactor

Refactoring nên được thực hiện từ các thay đổi ngay nhỏ, trong mỗi chúng làm cho code hiện nay tốt hơn một chút trong khi chương trình vẫn vận hành.

Checklist of refactoring done right way

  1. Code trở nên clean hơn Nếu code vẫn chưa clean sau khi refactoring thì coi như ta đang lãng phí 1 giờ trong cuộc đời dành cho việc refactoring. Hãy cố gắng tìm ra lý do tại sao điều này lại xảy ra.

    • Điều này nhiều xảy ra khi ta trộn lẫn việc refactoring thay đổi ngay nhỏ với nhau thành một thay đổi ngay lớn. vì thế ta rất dễ mất tâm trí của mình, đặc biệt nếu ta có một khoảng thời gian giới hạn.
    • Nhưng nó khả năng xảy ra khi ta làm việc với code rất bẩn. Dù bạn nâng cao hơn, toàn bộ code còn lại vẫn là một thảm họa. Trong trường hợp này ta nên nghĩ đến việc đập đi toàn bộ code và code lại. Nhưng trước đó ta nên dành ra một khoảng thời gian để viết test. Nếu không bạn sẽ gây ra ra hậu quả không đáng có.
  2. nhớ đừng nên tạo chức năng mới trong quy trình refactor nhớ đừng nên kết hợp việc refactoring và phát triển các chức năng mới với nhau. Cố gắng tách những quy trình này độc lập đối với từng commit.

  3. Tất cả các test case phải được pass sau khi refactoring Có hai trường hợp khi các test case không còn dùng được sau khi refactoring:

    • gây ra ra lỗi khi refactoring. Cái này thì đơn giản, chỉ cần sửa lỗi đó là xong.
    • Các test case ở mức thấp Trong trường hợp này, các bài test như là để đổ lỗi, và cách duy nhất để sửa lỗi này là refactor các bài test và viết các test ở mức cao hơn. Một cách tuyệt vời để tránh điều này là dùng Behavior Driven Development (BDD).

Tài liệu tham khảo

  • https://refactoring.guru
  • Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin

Đây chỉ mới là phần giới thiệu mở đầu về refactoring, ở phần sau tôi sẽ giới thiệu chi tiết các phương pháp để refactoring, các trường hợp nên dùng các phương pháp đó, lý do dùng và cách xử lý.

Tham khảo thêm: VLAN là gì? 2 loại VLAN cơ bản nên biết!!! – TOTOLINK Việt Nam

Bạn thấy bài viết thế nào?

Các câu hỏi về Refactoring – Mở đầu

Team Sổ Tay Thông Thái mà chi tiết là Mỹ Chi đã biên soạn bài viết dựa trên tư liệu sẵn có và kiến thức từ Internet. Dĩ nhiên tụi mình biết có nhiều câu hỏi và nội dung chưa thỏa mãn được bắt buộc của các bạn.

Thế nhưng với tinh thần tiếp thu và nâng cao hơn, Mình luôn đón nhận tất cả các ý kiến khen chê từ các bạn & Quý đọc giả cho bài viêt Refactoring – Mở đầu

Nếu có bắt kỳ câu hỏi thắc mắt nào vê Refactoring – Mở đầu hãy cho chúng mình biết nha, mõi thắt mắt hay góp ý của các bạn sẽ giúp mình nâng cao hơn hơn trong các bài sau nha <3 Chốt lại nhen <3 Bài viết Refactoring - Mở đầu ! được mình và team xem xét cũng như tổng hợp từ nhiều nguồn. Nếu thấy bài viết Refactoring - Mở đầu Cực hay ! Hay thì hãy ủng hộ team Like hoặc share. Nếu thấy bài viết Refactoring - Mở đầu rât hay ! chưa hay, hoặc cần bổ sung. Bạn góp ý giúp mình nha!!

Các Hình Ảnh Về Refactoring – Mở đầu

Refactoring - Mở đầu

Các từ khóa tìm kiếm cho bài viết #Refactoring #Mở #đầu

Tìm thêm kiến thức về Refactoring – Mở đầu tại WikiPedia

Bạn nên tìm thêm thông tin về Refactoring – Mở đầu từ web Wikipedia tiếng Việt.◄

Tham Gia Cộng Đồng Tại

💝 Nguồn Tin tại: https://sotaythongthai.vn/

💝 Xem Thêm Giải Đáp Câu Hỏi tại : https://mangraovat.edu.vn/hoi-dap/

Related Posts

About The Author

Add Comment