Managing Technical Debt: Strategies and Benefits
Explore the concept of technical debt, including types, strategies for dealing with it, coding guidelines, and the benefits of managing it effectively in software development projects.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Dealing with Technical Debt LUG 2016 Developer Day Ben Evans
Defining Technical Debt Work that needs to be done to keep a codebase up to date Removal of old code Refactoring of existing code Commenting and documenting code Migrating to new standards (tabathon) Naming things Better grouping of related items etc.
Types of Debt Lack of design Lack of comments Lack of standards Old, unused code Search for #if 0 Run git blame Build up of changes
Coding Guidelines http://wiki.lustre.org/Lustre_Coding_Style_Guidelines Do what it says on the tin Naming: Keep them distinct: rq_reqmsg and rq_repmsg Use descriptive names: make_the_code_clearer, but do_not_let_things_get_out_of_hand Commenting Describe what a function does, input and outputs
Mantra: Code deleted is code debugged Taking 3 months to understand 3k lines Time well spent? Replacing it with and if statement and memcpy Priceless Don t get creative It s always harder to debug than write
Random Example! #define md_op_data_fid(op_data, fl) \ (fl == MF_MDC_CANCEL_FID1 ? &op_data->op_fid1 : \ fl == MF_MDC_CANCEL_FID2 ? &op_data->op_fid2 : \ fl == MF_MDC_CANCEL_FID3 ? &op_data->op_fid3 : \ fl == MF_MDC_CANCEL_FID4 ? &op_data->op_fid4 : \ NULL) Yep, that s a case statement
Dealing with Debt Learn what the standards are Adapt your code, and the code around them to it Make small changes It might take awhile, but it works
Benefits Readable, Maintainable code Easier to add features Easier to get new developers involved Consistency Reducing bugs
Bigger Questions When do we retire code? 1.x based code that is no longer needed When to reorganize code? Moving testing (DANGEROUS) out of lctl When to redesign code? ptlrpc When to change the UI/UX? Changelogs, changelog management Should there be an OpenSFS effort for this?
More Questions Tabathon is working It s slow Comment-athon? Design Doc-athon?
Things we can do Create a Jira label for tech debt Hunt through all the code for TODO: labels and replace them with jira tickets? Put design docs into /documentation Even if they re old, they re better than nothing Spend a little time making the code a better place Open a Jira ticket Assign it to yourself Submit a patch Code reviews
