Refactoring Risky Code

In this talk we will see how to refactor hard to test code, like bluetooth with no tests, without introducing new bugs and minimal manual testing effort.

Transcript

1. Make diabetes suck less
2. Refactoring Risky Code @muffls Philipp Hofmann
3. Why Should We Refactor?
4. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” Martin Fowler
5. Refactoring makes your code easier to understand.
6. 70 to 90% of our time we spend on understanding code. Robert C. Martin, Carola Lilienthal and The Mythical Man Month
7. Refactoring ! Clean Code ! Faster Delivery
8. Risky Code
9. Risky Code • Has no tests • Is not testable • Can break a lot • Can make users angry National Geographic
10. Bluetooth on Android can be risky
11. Bluetooth is difficult for test automation
12. To know it is working you need to test lots of different devices.
13. We had a stable bluetooth stack.
14. Make it extendable and changeable.
15. Refactor
16. Rewrite != Refactor
17. Things You Should Never Do Part 1
18. Refactoring
19. “Refactoring is the process of changing a software system in a way that does not alter the external behaviour of the code yet improves its internal structure.” Martin Fowler
20. How to change code without breaking anything?
21. Tests.
22. Loads of Tests.
23. It’s easy to refactor when having good tests.
24. If you have testable code. Add tests then refactor.
25. Refactoring Risky Code ?
26. There are no tests. 
 Neither is the code testable.
27. One false move and …
29. ?
30. make it testable risky code add tests refactor
31. make it testable risky code
32. Hyperaware coding.
33. Get rid of not testable dependencies.
34. Adding abstractions.
36. /** * Scans for Bluetooth Classic devices. */ interface ClassicScanner { /** * Starts a scan when subscribed, * stops the scan when unsubscribed. */ fun scan(): Observable<ClassicScanResult> }
37. class AndroidClassicScanner( private val bluetoothProvider: BluetoothProvider, private val context: Context ) : ClassicScanner { // … All the Android stuff }
38. is stupid. contains logic.
39. Refactoring Survival Guide Those tips can save your career.
40. 1. Only wear one hat at a time.
42. When refactoring we don’t change the behaviour of the code.
43. We improve the structure.
44. I know what I am doing.
45. No you don’t.
46. 2. Keep your code green.
47. 3. Keep your tests green.
48. Don’t continue with failing tests.
49. 4. Tests. Tests. Tests.
50. Why do I need to add tests when I know my code works?
51. What am I testing then?
52. One thing is certain.
53. Change.
54. Tests allow you to change your code.
55. 5. Small Tasks
57. Don’t go crazy.
58. Clearly define a goal.
59. Small Tasks • Merge often. • Avoid huge PRs.
60. 6. Commit a lot
61. When you reach a clear state, make a commit.
62. git reset HEAD --hard
63. 7. Use the tools.
64. Android Studio is your friend.
65. Don’t do stuff manually.
66. Find & Replace can help.
67. 8. Minimise The Damage
68. Staged rollout.
69. Use alpha testing.
70. Put your refactoring behind a feature switch.
71. You can roll back within a minute.
72. We duplicated our code and made small changes to it.
73. Secret status view for QA
74. 9. Ship.
75. It only counts when it’s shipped.
76. Make sure you get enough QA power.
77. Conclusion
78. Refactoring != Rewrite
79. Refactoring is improving the structure of code without changing its behaviour.
80. make it testable risky code
81. Hyperaware coding.
82. Refactoring Survival Guide 1. Only wear one hat at a time 2. Keep your code green. 3. Keep your tests green. 4. Tests. Tests. Tests. 5. Small tasks. 6. Commit a lot. 7. Use the tools. 8. Minimise the damage. 9. Ship.
83. Further Readings • Refactoring: Improving the Design of Existing Code • Working Efficiently With Legacy Code • Workflows of Refactoring • Opportunistic Refactoring • Clean Code: A Handbook of Agile Software Craftmanship
84. Slides on Speakerdeck tomorrow. Check my twitter account @muffls
85. Feedback bit.ly/refactor-feedback
86. Questions ?