1. Code as a Communication Tool AKA Usando as Linguagens ao Seu Favor Vinicius Gomes Mozair May, 23rd 2011 © ThoughtWorks2008

3. Introduction

4. What?

5. Why?

6. How?

7. Conclusion© ThoughtWorks2008

9. Introduction

10. What?

11. Why?

12. How?

13. Conclusion© ThoughtWorks2008

15. github.com/macskeptic© ThoughtWorks2008

17. Introduction

18. What?

19. Why?

20. How?

21. Conclusion© ThoughtWorks2008

22. Introduction © ThoughtWorks2008

23. Reading existing code is expensive

24. Understanding existing code is expensive

25. Finding out where to change is expensive

26. Maintenance is expensive

27. So, what to do?

29. Introduction

30. What?

31. Why?

32. How?

33. Conclusion© ThoughtWorks2008

34. What? © ThoughtWorks2008

39. Communicate through code effectively

40. Make it fast to read

41. Make it easy to understand

42. Express domain knowledge through software

43. Keep maintenance costs low

47. Introduction

48. What?

49. Why?

50. How?

51. Conclusion© ThoughtWorks2008

52. Why? © ThoughtWorks2008

53. Maintenance

54. Tech Debt © ThoughtWorks2008

55. Time to market vs. Technical debt © ThoughtWorks2008

57. Communication

58. Simplicity

59. Feedback

60. Courage

61. Respect© ThoughtWorks2008

62. Feedback © ThoughtWorks2008

63. Feedback Project1 Unitary Project2 Unitary Project1 Functional Project2 Functional Project1 Regression Project2 Regression © ThoughtWorks2008

64. Help your team

67. Avoid ambiguous interpretation

69. Avoid ambiguous interpretation

70. Drop stress levels

72. Introduction

73. What?

74. Why?

75. How?

76. Conclusion© ThoughtWorks2008

77. How? © ThoughtWorks2008

80. Implementation Patterns

82. Implementation Patterns

83. Domain Driven Design

85. Implementation Patterns

86. Domain Driven Design

87. Test Driven Development / Design

89. Implementation Patterns

90. Domain Driven Design

91. Test Driven Development / Design

92. Refactoring

96. © ThoughtWorks2008

97. © ThoughtWorks2008

98. © ThoughtWorks2008

99. © ThoughtWorks2008

100. Avoid the Comic Sans Effect

105. Tell “what”, not “how”

106. © ThoughtWorks2008

107. © ThoughtWorks2008

108. © ThoughtWorks2008

109. Implementation Patterns

110. Name by role

113. Abiding by the law of Demeter

118. Abstraction symmetry

121. One-line ifs

124. Test Driven Design/Development © ThoughtWorks2008

125. © ThoughtWorks2008

126. © ThoughtWorks2008

127. © ThoughtWorks2008

128. © ThoughtWorks2008

129. © ThoughtWorks2008

130. Refactoring © ThoughtWorks2008

131. © ThoughtWorks2008

132. © ThoughtWorks2008

133. © ThoughtWorks2008

134. © ThoughtWorks2008

135. © ThoughtWorks2008

136. © ThoughtWorks2008

137. Domain Specific Languages

138. © ThoughtWorks2008

139. © ThoughtWorks2008

141. Introduction

142. What?

143. Why?

144. How?

145. Conclusion© ThoughtWorks2008

146. Conclusion

147. Start to think about the code as a communication tool

148. Harness the power of the tools at hand

149. Make the code talk the domain knowledge

150. Write code for human beings

152. TDD by Exampleby Kent Beck

153. Implementation Patternsby Kent Beck

154. Refactoring by Martin Fowler

155. Clean Codeby Bob Martin

156. Domain Driven Desingby Eric Evans

158. Thanks :)

159. Did you like this subject? Would you like to work with things like that on a daily basis? 05/20/11 © ThoughtWorks2008

160. Come get to know us, we are looking for smart people interested in doing awesome stuff  www.thoughtworks.com/career-opportunities work@thoughtworks.com 05/20/11 © ThoughtWorks2008