Day2 - Refactoring (Lecture SS 2015)
- 1. TDD + JavaScript Refactoring Wolfram Kriesing, uxebu @wolframkriesing
- 2. Schedule Intro Collect Dive in Crowd Start Solid break we hack
- 3. What did you take away?
- 5. no IFs
- 7. Refactoring
- 8. Design is hard. The design of reusable software is especially hard. Reusable software usually is the result of many design iterations. William F. Opdyke, 1992 it’sallaboutdesign
- 9. Books, papers • „REFACTORING OBJECT-ORIENTED FRAMEWORKS“ William F. Opdyke, 1992 http://www.ai.univ-paris8.fr/~lysop/opdyke-thesis.pdf • „Refactoring: Improving the Design of Existing Code“ Martin Fowler, 1999 • „Working Effectively with Legacy Code“ Michael Feathers, 2004 • „31 Days of Refactoring“ http://lostechies.com/wp-content/uploads/2011/03/31DaysRefactoring.pdf • „Subjective evaluation of software evolvability using code smells: An empirical study“ http://www.soberit.hut.fi/~mmantyla/ESE_2006.pdf
- 11. Our software …
- 12. we plan first
- 13. over time …
- 15. we should …
- 17. improve design after code was written
- 18. Improve design after code was written what? isn’t it reverse?
- 20. Where does it come from?
- 22. smalltalk
- 23. - made it popular - enables agility get from the book: - code smells - refactoring techniques
- 25. Incremental Design Improve structure all the time was not possible with this tower, of course
- 28. Refactoring in action • monolithic • >1 indention levels • nested loops • modular • explicit function names • tiny functions • max. one level indent • no nested loops • composing
- 29. • transparent responsibilities • separation of concerns • possible reusability • code structure • no unmaintained comments
- 30. • transparent responsibilities • separation of concerns • possible reusability • code structure
- 34. $ prefixing Artificial selectors Inefficient jQuery usage Hard-code dependencies Chain explosion No-caching
- 35. It’s all automatically detectable! Explore Stabilize Commoditize e.g. with esprima
- 36. :-)
- 39. Comments • may be wrong • they rot • useless • actual good (method) name
- 40. Long methods • hard to read • many contexts • too many LOC • too many statements • define your own
- 41. Duplicated code • duplicated bugs • double the fixes • more code to ship • performance break
- 42. Bad names
- 43. Long parameter list • too many responsibilities • bad API • hard to use • hard to maintain • points to design defects
- 44. Boolean trap • intention not clear • easy to understand wrong
- 45. Complexity
- 46. Inconsistent names Dead code many more …
- 47. Common Code Smells https://www.flickr.com/photos/awnisalan/352498081 1) Low-hanging fruit 2) Boomerang
- 48. Conditionals Combinatorial Explosion Type embedding Data Clumps sets of variables that are always together, get passed in, etc. => extract into class avoid placing types in method names; it's not only redundant, but it forces you to change the name if the type changes You have lots of code that does almost the same thing watch out for large conditional logic blocks particularly blocks that tend to grow larger or change significantly over time
- 49. Feature envy a method making more use of another class than the one it is in Speculative Generality write code to solve today's problems and worry about tomorrow's problems when they actually materialize
- 50. Common Code Smells https://www.flickr.com/photos/awnisalan/352498081 1) Low-hanging fruit 2) Boomerang 3) In tests
- 52. Obscure test it is difficult to understand the test at a glance Conditional test logic • tests take too long to run • make developers not run the tests • leads to untested code • demotivates continuous testing • make code rot
- 53. Setup too complex Unclear Act Multiple asserts No assert
- 54. Logic in test Duplication in tests Dependent tests Modification of unit under test
- 55. General fixture a setUp method contains code only used by some tests Lazy test using the same fixture for multiple tests Test run war test can only be run by one person at a time, due to use of same external ressource
- 57. Refactorings