Technical debt – tạm thời dịch là “Khoản nợ kỹ thuật” được sử dụng những trong Software Engineering. Theo Henrik Kniberg, hầu như số tiền nợ chuyên môn là bất kể lắp thêm gì vào bài toán viết mã khiến cho bạn chậm lại về lâu bền hơn. lấy ví dụ như như là mã khó hiểu, thiếu (hoặc không có) kiểm demo auto, mã trùng lặp, hoặc sự link xì xằng giữa lớp, mô-đun… (Think of technical debt as anything about your code that slows you down over the long term. Hard-to-read code, lack of thử nghiệm automation, duplication, tangled dependencies, etc. Henrik Kniberg).

Bạn đang xem: Legacy system là gì

10 bí mật nhằm startup và FinTech startup thành công xuất sắc chợt phá
Cách vươn lên là một MarTech Developer trong 2021


TDD vẫn khó khăn, TDD đến legacy system còn cạnh tranh gấp bội. Bài viết dưới đây của Mark Levison bàn về Việc các sự việc chạm chán cần Khi vận dụng TDD vào Legacy System, qua đó trích dẫn 1 số ít phương pháp của Keith Ray – XP.. Coach để làm Việc với legacy code nhằm mục tiêu giảm (paying down) mọi khoản technical debt, dựa vào căn cơ cốt tử là viết mã sạch mát, tái cấu tạo mã mối cung cấp cùng vứt túi SOLID principles.

Xin trích dẫn nguyên vnạp năng lượng nội dung bài viết bởi Mark Levison từ http://www.infoq.com/news/2009/11/legacy-code

Allan Baljeu was trying to TDD with a legacy C++ code base, he was running into trouble because:

we kết thúc up with classes that don’t fully implement the functionality that’s eventually needed, and when others come around lớn use those classes, and eventually fuller implementations are required, then it turns out that the original kiến thiết is not adequate, a new thiết kế is required, some expectations (tests) need to lớn change and previous uses of the class need lớn be updated.

He wondered if Big Design Up Front would help solve the problem. George Dinwiddie, Agile Coach, suggested that Alan’s kiến thiết was trying lớn tell him something. You have khổng lồ pay attention khổng lồ the fundamentals of clean code. You can look at basic coupling and cohesion (i.e. SOLID).

Mike “Geepaw” Hill, Agile Coach, says that in his years of coaching agile teams, one of the following has been at the root of these problems:

team is not yet up to speed on refactoring, so your classes aren’t reallyminimalteam is not yet skilled at simplithành phố, so dittoteam doesn’t know how lớn handle cross-team or company-to-public dependencies, e.g. shipping api’steam neither pairing nor open workspacing, dramatically slowing team-wide understanding.team likely has no jiggle-less buildteam could be using tools from the ’40s

Keith Ray, XPhường Coach, suggests that with legacy code (i.e. systems with high technical debt) the cost of repaying technical debt dominates the cost of implementing a story. He goes on to offer an approach:

To make the code more well-factored (paying down the technical debt), whenever you need khổng lồ integrate a new feature into lớn it, you should pay cchiến bại attention to code smells in both the new code và the old code và consider refactoring to giảm giá with each smell as you recognize it.

You can vì refactorings in small safe steps (even in C++) manually. Very closely follow the instructions in Fowler’s book on Refactoring until you learn them by heart. Eclipse with gcc has a few refactorings that actually work: Extract Method và Rename. Rename understands scope, so it is safer than search-and-replace. Extract Method and the other refactorings in Ecipse might be buggy, so be careful when you use them. For things lượt thích changing a function signature, “lean on the compiler” lớn show where changes have sầu to lớn be made.

Xem thêm: Tải Phần Mềm Chữ Thư Pháp, Huong Dan Chu Thu Phap Full, Cách Viết Chữ Thư Pháp Tết 2021 Trên Di Động

You also need tests khổng lồ make sure the refactorings are not damaging the existing features. Feather’s book on working with legacy code has lots of techniques for adding tests khổng lồ legacy code. On a higher cấp độ, code smells are violations of good thiết kế principles. For example, the Single Responsibility Principle (SRP) says there should one purpose for every class / method / module. There are principles about coupling & cohesion và managing dependencies, etc. It’s often easier lớn detect a code smell than it is to apply these abstract principles. “Large Class” and “Large Method” are remedied by “Extract Class” và “Extract Method/Move Method”, though knowing SRPhường helps in deciding what parts of a class or method should be extracted.

Perhaps the most important kiến thiết principle is “Tell, don’t ask”: keep functionality và data together…. bad code often has the functionality in one place, và gets the data it needs from other places, creating problems with dependencies and lack of locality — symptomized by “adding a new feature requires changing lots of code”. The code smells “Shotgun Surgery”, “Feature Envy”, “Long Parameter List” are applicable here.

Getting fast feedback will allow more refactoring, which will (eventually) allow faster development of new features. Try to get parallel builds happening (distributed compilation). Try khổng lồ get smaller source files và smaller header files. Reduce the complexity of header files – use forward declarations, avoid inline code, try to lớn keep only one class per header file / source file. Using the “pimpl” idiom widely can decrease compile time by 10%, but it can also disguise the “Large Class” and “Feature Envy” code smells.

The advantage of refactoring instead of rewriting, is that you always have sầu working code. If your manual & automated tests are good, then you should be able to ship the code, even if it is a half-way state between a bad thiết kế & a good kiến thiết.

Xem thêm: Common Baby Là Gì ? Dùng Trong Những Ngữ Cảnh Nào? Dùng Trong Những Ngữ Cảnh Nào

Keith also wrote “Refactoring: Small Steps Guaranteed to Help You Clean Up Your Code” an article on refactoring C++ code in Better Software Magazine.

Previously on InfoQ: Dealing with Legacy Code, Uncle Bob On The Applicability Of TDD andMaking TDD Stick: Problems & Solutions for Adopters