1. Dealing with Technical Debt LUG 2016 Developer Day Ben Evans

2. 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.

3. 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

4. Coding Guidelines ●http://wiki.lustre.org/Lustre_Coding_Style_Guidelineshttp://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

5. 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

6. 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

7. 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

8. Benefits ●Readable, Maintainable code ●Easier to add features ●Easier to get new developers involved ●Consistency ●Reducing bugs

9. 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?

10. More Questions ●Tabathon is working ● It’s slow ●Comment-athon? ●Design Doc-athon?

11. 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