Technical debt – tạm dịch là “Khoản nợ kỹ thuật” được dùng nhiều trong Software Engineering.

Bạn đang xem: technical debt là gì

Nội dung được sự cho phép của tác giả Edward Thiên Hoàng

Technical debt – tạm dịch là “Khoản nợ kỹ thuật” được dùng nhiều trong Software Engineering. Theo Henrik Kniberg, những khoản nợ kỹ thuật là bất kì thứ gì trong việc viết mã khiến bạn chậm lại về lâu dài. Ví dụ như là mã khó đọc, thiếu (hoặc không có) kiểm thử tự động, mã trùng lặp, hoặc sự link nhì nhằ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 test automation, duplication, tangled dependencies, etc. Henrik Kniberg).

Cũng giống với những khoản nợ về tài chính: có vay mới có nợ, có nợ ắt sẽ sinh lời. Technical debt sinh ra vì nhiều nguyên nhân: căng thẳng kinh doanh, thiếu tuyệt kỹ trong phân tích thiết kế cũng như tuyệt kỹ lập trình, không có các bộ mã kiểm thử dẫn theo việc trì hoãn (hoặc không thể) tái cấu trúc lại mã nguồn… Nếu không được trả, theo thời gian, nợ sẽ đẻ lãi, dẫn theo việc chậm tiến độ, những đoạn mã mới được thêm vào sẽ mất nhiều thời gian và ngân sách hơn, mà đa số trong số này là ngân sách cho việc gỡ rối (debugging) và kiểm thử hồi quy (regression testing).

Technical Debt và Legacy System

Nếu bạn đang làm việc với 1 legacy system (có rất nhiều khái niệm về legacy code, nhưng mình thích nhất khái niệm của Robert ₵. Martin: legacy code = code without test) nghĩa là bạn đang mang trên mình món nợ về kỹ thuật. Một đoạn mã được viết cách đây 10 năm cũng gọi là legacy code, một đoạn mã được viết ngày ngày hôm qua cũng gọi là legacy code nếu chúng đều không được “chống lưng” bằng mã kiểm thử. Và nếu bạn vẫn tiếp tục tạo ra những đoạn mã “without test”, cũng tức là bạn đang tự đẻ thêm nợ cho chính system của mình. Điều đó cũng tương tự với việc bạn thêm vào những đoạn mã khó đọc, mã trùng lặp, hoặc sự kiên kết nhì nhằng giữa lớp, mô-đun… (Có phải mình cũng vừa lặp lại những gì đã nói ở trên?).

Vậy bạn sẽ trả nợ bằng cách nào? Hay thõa hiệp trước món nợ + lãi đang ngày một tăng khi mã mới được thêm vào?
Có hàng tá nguyên nhân để biện minh cho việc thõa hiệp, có thể kể ra như: đừng phá vỡ những đoạn mã đã chạy ổn định, hệ thống tất cả chúng ta quá phức tạp, do đó cần thêm thời gian để (tìm hiểu) thêm mới hoặc sữa chữa một đoạn mã nào đó (và đảm bảo không phá vỡ những đoạn mã hiện tại). Có một câu ví von khá hay về vấn đề này. “The code may not be pretty, but damnit, it works!” dùng để nói về Duct Tap Programmer – người viết mã chỉ để “chạy được”.
Nếu chọn cách trả nợ, những việc bạn sẽ làm là đừng (hoặc hạn chế) để lại nợ nần cho những thế hệ (mã) phía sau. Và điều trước tiên này là Hãy ngừng việc tạo ra những đoạn mã xấu (Stop writing crappy code).

Xem Thêm  Top 20 kết quả tìm kiếm tải tubemate cho ios mới nhất 2022

Technical Debt và Legacy System

TDD đã khó, TDD cho legacy system còn khó gấp nhiều lần. Nội dung dưới đây của Mark Levison bàn về việc những vấn đề gặp phải khi vận dụng TDD trong Legacy System, qua đó trích dẫn 1 số phương pháp của Keith Ray – XP Coach để làm việc với legacy code nhằm giảm (paying down) những khoản technical debt, dựa trên nền tảng cốt lõi là viết mã sạch, tái cấu trúc mã nguồn và bỏ túi SOLID principles.

Xin trích dẫn nguyên văn nội dung bởi Mark Levison từ http://www.infoq.com/news/2009/11/legacy-code

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

chúng tôi kết thúc với các lớp không triển khai đầy đủ tính năng thiết yếu cuối cùng và khi những người khác đến sử dụng các lớp đó và cuối cùng là yêu cầu triển khai đầy đủ hơn, thì hóa ra thiết kế ban đầu không thích hợp, α yêu cầu thiết kế mới, một số kỳ vọng (xác minh) cần thay đổi và các mục đích sử dụng trước đó của lớp cần được update.

Anh ấy tự hỏi liệu Big Thiết kế Up Front có giúp khắc phục vấn đề không. George Dinwiddie , Huấn luyện viên Agile , cho rằng thiết kế của Alan đang nỗ lực nói lên anh ta một cái gì đó. Bạn phải lưu ý đến các phép tắc cơ bản của mã sạch. Bạn có thể xem xét khớp nối và link cơ bản (tức là SOLID).

Mike “Geepaw” Hill , Huấn luyện viên Agile , nói rằng trong những năm huấn luyện các đội nhanh nhẹn của mình, một trong những điều sau đây là gốc rễ của những vấn đề này:

  • nhóm chưa bắt kịp vận tốc tái cấu trúc, vì vậy các lớp học của các bạn không thực sự
    tối thiểu
  • nhóm chưa có tuyệt kỹ về tính đơn giản, vì vậy hãy nỗ lực
  • nhóm vẫn chưa hoạt động tích cực & amp; microtesting nhanh chóng (hay còn gọi là trải nghiệm nhà cung cấp ), do đó, các thay đổi phá vỡ xác minh quá thường xuyên
  • nhóm không biết cách xử lý sự phụ thuộc giữa nhiều nhóm hoặc giữa công ty tư vấn du học với công chúng, ví dụ: api vận tải
  • nhóm không ghép nối hoặc không mở không gian làm việc, làm chậm đáng kể sự hiểu biết của toàn nhóm.
  • nhóm có thể không có bản dựng ít rung lắc
  • nhóm có thể đang sử dụng các dụng cụ từ những năm 40

Keith Ray , XP Coach , gợi ý điều đó với mã kế thừa (tức là các hệ thống có nợ kỹ thuật cao ) thì ngân sách trả nợ kỹ thuật chiếm ưu thế ngân sách triển khai một mẩu chuyện. Anh ấy tiếp tục mang ra một cách tiếp cận:

Để làm cho mã được kiểm chứng tốt hơn (trả bớt nợ kỹ thuật), bất kì khi nào bạn cần tích hợp một tính năng mới vào nó, chúng ta nên lưu ý đến mùi mã trong cả mã mới và mã cũ. và xem xét tái cấu trúc để ứng phó với từng mùi khi bạn nhận thấy.

Bạn có thể thực hiện tái cấu trúc theo các bước nhỏ an toàn (ngay cả trong ₵ ++) theo cách thủ công. Hãy làm theo rất chặt chẽ các hướng dẫn trong sách của Fowler về Cấu trúc lại cho đến khi bạn học thuộc chúng. Eclipse với gcc có một số cấu trúc lại thực sự hoạt động: Phương pháp giải nén và đổi tên. Đổi tên hiểu được phạm vi, vì vậy nó an toàn hơn so với tìm kiếm và thay thế. Extract Method và các tái cấu trúc khác trong Ecipse có thể có lỗi, vì vậy hãy cảnh giác khi bạn sử dụng chúng. So với những việc như thay đổi chữ ký hàm, hãy “dựa vào trình biên dịch” để biết những nơi cần thực hiện các thay đổi.

Bạn cũng nên xác minh để đảm nói rằng việc tái cấu trúc không làm hỏng các tính năng hiện có. Quyển sách của Feather về làm việc với mã kế thừa có rất nhiều kỹ thuật để thêm trải nghiệm vào mã kế thừa. Ở cấp độ cao hơn, mùi mã là vi phạm các phép tắc thiết kế tốt. Ví dụ, Phép tắc trách nhiệm duy nhất (SRP) nói rằng phải có một mục đích cho mọi lớp / phương thức / mô-đun. Có những phép tắc về khớp nối và sự gắn kết và quản lý sự phụ thuộc, 𝒱.𝒱. Thông thường, việc phát xuất hiện mùi mã sẽ đơn giản hơn so với việc vận dụng những phép tắc trừu tượng này. “Lớp lớn” và “Phương thức lớn” được khắc phục bằng “Lớp trích xuất” và “Phương pháp trích xuất / Phương pháp di chuyển”, mặc dù biết SRP sẽ giúp quyết định phần nào của lớp hoặc phương thức nên được trích xuất.

Có vẻ phép tắc thiết kế trọng yếu nhất là “Nói, không hỏi”: giữ tính năng và dữ liệu cùng nhau…. mã xấu thường có tính năng ở một nơi và lấy dữ liệu mà nó cần từ những nơi khác, tạo ra các vấn đề về phụ thuộc và thiếu cục bộ – được triệu chứng bằng cách “thêm một tính năng mới yêu cầu thay đổi nhiều mã”. Mã có mùi “Phẫu thuật bằng súng ngắn”, “Tính năng đố kỵ”, “Danh sách thông số dài” có thể vận dụng ở đây.

Thu được phản hồi nhanh sẽ cho phép tái cấu trúc nhiều hơn, điều này (cuối cùng) sẽ cho phép phát triển các tính năng mới nhanh hơn. Nỗ lực làm cho các bản dựng song song xảy ra (biên dịch phân tán). Nỗ lực lấy các tệp nguồn nhỏ hơn và các tệp tiêu đề nhỏ hơn. Giảm độ phức tạp của tệp tiêu đề – sử dụng khai báo chuyển tiếp, tránh mã nội tuyến, nỗ lực chỉ giữ một lớp cho mỗi tệp tiêu đề / tệp nguồn. Sử dụng rộng rãi thành ngữ “ma cô” có thể giảm thời gian biên dịch xuống 10%, nhưng nó cũng có thể che giấu mùi mã “Lớp học lớn” và “Sự ghen tị với tính năng”.

Ưu thế của việc tái cấu trúc thay vì viết lại là bạn luôn có mã hoạt động. Nếu xác minh thủ công và tự động của các bạn tốt, thì bạn sẽ có thể gửi mã, ngay cả khi này là trạng thái nửa vời giữa thiết kế xấu và thiết kế tốt.

Keith cũng từng viết “ Tái cấu trúc: Các bước nhỏ được đảm bảo để giúp bạn làm sạch mã của mình ” một bài báo về cấu trúc lại mã ₵ ++ trên Tạp chí PM tốt hơn. < / p>

Xem Thêm  Top 7 điện thoại thông minh smartphone giá rẻ dưới 1 triệu tốt nhất hiện nay - dien thoai suntek co tot khong

Trước đó trên InfoQ: Xử lý mã kế thừa , Chú Bob về khả năng vận dụng của TDD Tạo TDD Stick: Vấn đề và phương án cho người tiêu dùng

Bạn có thể quan tâm:

Xem thêm Việc làm kỹ sư hệ thống mê hoặc trên TopDev < / strong>


Xem thêm những thông tin liên quan đến đề tài technical debt là gì

Slaying Technical Debt

alt

  • Tác giả: Scrum.org
  • Ngày đăng: 2018-07-20
  • Nhận xét: 4 ⭐ ( 7488 lượt nhận xét )
  • Khớp với kết quả tìm kiếm: In this Scrum Tapas video, Professional Scrum Trainer Todd Miller discusses the concept of Technical Debt and ideas on how to work to remove it. He looks at different concepts and why removal over time is important to the long-term viability of α product.

Technical Debt là gì? Khái niệm và giải thích ý nghĩa

  • Tác giả: filegi.com
  • Nhận xét: 4 ⭐ ( 8754 lượt nhận xét )
  • Khớp với kết quả tìm kiếm: Khái niệm và ý nghĩa của từ Technical Debt. Nghĩa tiếng Việt của từ Technical Debt Thuật ngữ công nghệ tiếng Anh của Technical Debt. What is the Technical Debt Definition and meaning

Technical debt – Có nợ ắt phải trả mà chẳng dev nào muốn trả cả

  • Tác giả: blog.ntechdevelopers.com
  • Nhận xét: 3 ⭐ ( 1019 lượt nhận xét )
  • Khớp với kết quả tìm kiếm: Technical debt được nghe đến là một món nợ kỹ thuật mà đa số các lập trình viên đều đã , đang và sẽ gặp phải. Tuy nhiên không ít người chưa hiểu rõ Technical debt là gì và Technical debt có thật sự nghiêm trọng hay không khi nó là một “món nợ”. Bài
Xem Thêm  Work-life balance có đồng nghĩa với một công việc nhàn rỗi? - work life balance là gì

Technical debt hay mẩu chuyện về nợ kĩ thuật – Thảo Trịnh

  • Tác giả: thaotrinh.info
  • Nhận xét: 5 ⭐ ( 1949 lượt nhận xét )
  • Khớp với kết quả tìm kiếm:

Series Phản Phác Quy Chân – Luận về Technical Debt – Nợ kiếp này, duyên kiếp trước

  • Tác giả: toidicodedao.com
  • Nhận xét: 4 ⭐ ( 8739 lượt nhận xét )
  • Khớp với kết quả tìm kiếm: Technical Debt (Nợ kĩ thuật) là một món nợ mà hầu như lập trình viên nào cũng phải gánh trong quá trình làm việc. Hẳn bạn sẽ thắc mắc: Hầu như lập trình viên chúng mình đều là những nhân loại siêng năng chăm chỉ, không cờ bạc gái gú, hết giờ làm là đi nhậu, mát…

Technical debt

  • Tác giả: www.tigosolutions.com
  • Nhận xét: 3 ⭐ ( 5956 lượt nhận xét )
  • Khớp với kết quả tìm kiếm: Nợ kỹ thuật (technical debt) là gì?

Xem thêm các nội dung khác thuộc thể loại: Thủ thuật máy tính

By ads_php