Architecting is Difficult: London Web March 2014

Transcript

1. Architecting is Difficult @Jack_Franklin
2. Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ! Martin Fowler [@martinfowler]
3. What makes code difficult to work with?
4. YMMV
5. you’re never going to get it perfect first time
6. Defer concrete decisions as late as possible - you'll never again know less about the problem than you do right now and the correct abstraction will become clearer over time. ! Andy Appleton [@appltn]
7. writing good code improving existing code
8. Writing Good Code: Tests
9. drive your API design
10. difficult to test == difficult to use
11. confidence when refactoring (but we’ll come back to this later)
12. Writing Good Code: Naming Conventions
13. There are only two hard things in Computer Science: cache invalidation and naming things. ! Phil Karlton
14. There are only two hard things in Computer Science: cache invalidation, naming things and off by one errors. ! ???
15. prefer verbosity
16. be consistent use the same nouns and verbs
17. Writing Good Code: Coding Standards
18. editorconfig.org
19. actual standard is irrelevant pick one and stick to it
20. Writing Good Code: Single Responsibility
21. do one thing and do it well
22. Not one thing well class EmailSender def initialize(csv) ! def parse_csv_for_emails ! def send_email end
23. Better class EmailSender def initialize(csv) def parse_csv_for_emails Parser.new(csv).emails def send_email end ! class Parser def initialize(csv) def emails end
24. Writing Good Code: Decoupled Components
25. class EmailSender def initialize(csv) def parse_csv_for_emails Parser.new(csv).emails def send_email end ! class Parser def initialize(csv) def emails end This knowledge isn’t needed here
26. class EmailSender def initialize(emails) def send_email end ! class Parser def initialize(csv) def emails end ! emails = Parser.new(csv).emails EmailSender.new(emails).send_email knows how to send an email to an array of emails knows how to parse a CSV and get the email addresses
27. Writing Good Code: Separate Aggressively
28. don’t be afraid to create classes / objects
29. easier to merge two tiny classes than split up one massive one
30. Refactoring
32. Refactoring: alter code without changing behaviour
33. you have to have tests!
34. Code Smells
35. Code Smell: some code which may indicate a problem
36. You don’t fix code smells. You look at them and see if they indicate a problem you can fix. ! Joe Ferris [@joe_ferris]
37. class SomeMapThing def initialize(x, y) end ! class LatLong def self.get_lat_long(x, y) end ! class User def coords [x, y] end
38. data clumps continually passing round two objects as arguments
39. class SomeMapThing def initialize(coords) ! class LatLong def self.get_lat_long(coords) ! class User def coords ! class Coords def x def y ! coords = Coords.new(2, 3) LatLong.get_lat_long(coords)
40. if two arguments are tightly related, encapsulate that knowledge
41. class GraphDrawer def draw width = 165 + bar_width height = 170.2 + bar_height … end
42. why 165? why 170.2? This is very common in JavaScript / jQuery code, and CSS too.
43. class GraphDrawer GRAPH_HEIGHT_PADDING = 170.2 GRAPH_WIDTH_PADDING = 165 def draw width = GRAPH_WIDTH_PADDING * bar_width height=GRAPH_HEIGHT_PADDING + bar_height end
44. no knowledge should be left in your head
45. <% if user != nil %> <h2><%= user.welcome_message %></h2> <% else %> <h2>Please sign in</h2> <% end %>
46. checking for nil / undefined
47. what does nil mean? no first name? system error? no name yet? no user logged in?
48. implicit knowledge in a codebase is bad
49. class NullUser def welcome_message “Please sign in” end ! user = current_user || NullUser.new <h2><%= user.welcome_message %></h2>
50. don’t check for nil
51. def check_for_overheating(system_monitor) if system_monitor.temperature > 100 system_monitor.sound_alarms end end
52. def check_for_overheating(system_monitor) if system_monitor.temperature > 100 system_monitor.sound_alarms end end
53. tell, don’t ask http://robots.thoughtbot.com/tell-dont-ask
54. system_monitor.check_for_overheating ! class SystemMonitor def check_for_overheating if temperature > 100 sound_alarms end end end
55. we’re now telling the object what to do rather than asking it if it can do it
56. coupling http://robots.thoughtbot.com/types-of-coupling
57. def save(should_run_validations=true) if should_run_validations validate store else store ! # in our app, everywhere user.save post.save(false)
58. control coupling
59. if I update the save method every usage of the method has to change
60. (this actually happened in Rails)
61. better solution would be to split the methods up
62. you have to have some coupling, else nothing could talk to anything
63. “If I change this method, how many changes do I have to make else where?”
64. Publish and Subscribe
65. class ModuleA def init(b) def a_thing do_a_thing b.do_thing ! ! class ModuleB def do_thing # has to happen after ModuleA#a_thing
66. Module A knows too much
67. class ModuleA def init(event) def a_thing do_a_thing event.publish(‘a_thing_complete’) ! ! class ModuleB def init(event) event.subscribe(‘a_thing_complete’) { do_thing } ModuleA doesn’t know (or care) what modules listen to a_thing_complete
68. Now no module knows about the other
69. class ModuleA def init(event) def a_thing do_a_thing event.publish(‘a_thing_complete’) ! class ModuleB … class ModuleC def init(event) event.subscribe(‘a_thing_complete’) { do_thing }
70. class User def posts_by_user blog.posts.where(user_id: id) end
71. The Law of Demeter
72. It’s an actual law!
73. A method of an object should only invoke only the methods of the following kinds of objects: ! 1. itself 2. its parameters 3. any objects it creates 4. its direct component objects
74. class User def posts_by_user blog.posts.where(user_id: id) end multiple dots
75. class User def posts_by_user blog.posts_by_user(id) end ! class Blog def posts_by_user(id) posts.where(user_id: id) end
76. avoid duplication of knowledge across your system
77. OK, so it’s not an actual law
78. Approaches to maintaining code
79. Every time you work with some code, leave it a tiny bit better than when you left it
80. don’t ignore a problem or leave #FIXME comments
81. #todo: this entire class is screwed, fix it
82. if you need to make the change, but the change is difficult
83. first refactor to make the change easy then make the change!
84. you can’t get it right first time every time
85. keep friction to running tests low
86. because then you’ll run them
87. code reviews
88. http://robots.thoughtbot.com/ ! https://speakerdeck.com/jackfranklin ! http://refactoring.com/
89. Thanks! javascriptplayground.com @Jack_Franklin