Technical debt – nhất thời dịch là “Khoản nợ kỹ thuật” được dùng các trong Software Engineering. Theo Henrik Kniberg, các số tiền nợ nghệ thuật là bất cứ vật dụng gì trong câu hỏi viết mã khiến cho các bạn chững lại về lâu dài. Ví dụ như thể mã khó hiểu, thiếu thốn (hoặc ko có) kiểm thử auto, mã trùng lặp, hoặc sự link xì xằng thân 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, laông xã of kiểm tra automation, duplication, tangled dependencies, etc. Henrik Kniberg).
Bạn đang xem: Legacy system là gì
10 bí mật để startup và FinTech startup thành công xuất sắc bất chợt phá
Cách thay đổi một MarTech Developer vào 2021
TDD đã nặng nề, TDD đến legacy system còn khó gấp nhiều lần. Bài viết dưới đây của Mark Levison bàn về vấn đề rất nhiều vấn đề chạm chán phải lúc vận dụng TDD trong Legacy System, thông qua đó trích dẫn một số phương thức của Keith Ray – XPhường Coach để gia công bài toán cùng với legacy code nhằm bớt (paying down) phần đa khoản technical debt, dựa trên căn cơ cốt lõi là viết mã không bẩn, tái kết cấu mã nguồn và vứt túi SOLID principles.
Xin trích dẫn nguyên vnạp năng lượng bài viết bởi Mark Levison từ http://www.infoq.com/news/2009/11/legacy-code
Allan Baljeu was trying to lớn TDD with a legacy C++ code base, he was running inkhổng lồ trouble because:
we end up with classes that don’t fully implement the functionality that’s eventually needed, và when others come around to use those classes, and eventually fuller implementations are required, then it turns out that the original design is not adequate, a new design is required, some expectations (tests) need lớn change & previous uses of the class need lớn be updated.
He wondered if Big Design Up Front would help solve sầu the problem. George Dinwiddie, Agile Coach, suggested that Alan’s thiết kế was trying to tell hyên ổn something. You have sầu khổng lồ pay attention lớn the fundamentals of clean code. You can look at basic coupling và 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 khổng lồ speed on refactoring, so your classes aren’t reallyminimalteam is not yet skilled at simplicity, so dittoteam doesn’t know how khổng lồ 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 ’40sKeith Ray, XP. 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 khổng lồ offer an approach:
To make the code more well-factored (paying down the technical debt), whenever you need lớn integrate a new feature into lớn it, you should pay cthua attention khổng lồ code smells in both the new code and the old code và consider refactoring to deal with each smell as you recognize it.
You can vày 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 & Rename. Rename understands scope, so it is safer than search-and-replace. Extract Method và 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” to show where changes have lớn be made.
Xem thêm: Định Nghĩa Pager Là Gì ? Định Nghĩa, Ví Dụ, Giải Thích Pager Là Gì
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 to lớn legacy code. On a higher level, code smells are violations of good design principles. For example, the Single Responsibility Principle (SRP) says there should one purpose for every class / method / module. There are principles about coupling & cohesion and managing dependencies, etc. It’s often easier to detect a code smell than it is khổng lồ apply these abstract principles. “Large Class” và “Large Method” are remedied by “Extract Class” & “Extract Method/Move sầu Method”, though knowing SRP.. helps in deciding what parts of a class or method should be extracted.
Perhaps the most important thiết kế principle is “Tell, don’t ask”: keep functionality & data together…. bad code often has the functionality in one place, và gets the data it needs from other places, creating problems with dependencies và laông xã 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 feedbaông xã will allow more refactoring, which will (eventually) allow faster development of new features. Try to lớn get parallel builds happening (distributed compilation). Try to get smaller source files và smaller header files. Reduce the complexity of header files – use forward declarations, avoid inline code, try lớn keep only one class per header tệp tin / source tệp tin. 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 and automated tests are good, then you should be able khổng lồ ship the code, even if it is a half-way state between a bad kiến thiết and a good design.
Keith also wrote “Refactoring: Small Steps Guaranteed lớn 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 và Solutions for Adopters
