Refactoring Risky Code

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.


Philipp Hofmann

March 07, 2019


  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 …

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

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

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

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

  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

  86. Questions ?