Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Responsible Developer - XP days Ukraine 2014

753 views

Published on

Developers are the translators between ideas and code. They translate ideas about functionality to code so the end users can benefit from a usable program. This translation has to be done in a careful and responsible way. It should be done by a responsible developer.

What is a responsible developer then?

It is a developer that writes clean, testable and maintainable code. A developer who can explain and describe his work. Someone that knows that he grows by helping his fellow developers and never settles for second best.

I will discuss the properties of a responsible developer and suggest ways you can improve to become a responsible developer.ccc

Published in: Software
  • Be the first to comment

  • Be the first to like this

The Responsible Developer - XP days Ukraine 2014

  1. 1. The Responsible Developer Thomas Sundberg Think Code AB @thomassundberg tsu@kth. se
  2. 2. public int getNunber0fResults(l { llebfilernent searchfield = browser. findEleInent(By. naure("¢| ")): sea rchField . sendkeys ( "selenii-") : searchField. subr| it( ) : int tineoutlnseconds = 10: llebbriverilait wait = new Hebbrivenlaittbrowser, tirne0utInSeconds); llebfilernent searchResultArea = wa1t. until((Funct: i.on) (driver) -> { return driver. findEleInent(By. .id("1res")); }); List<HebElerIient> result = searchResultArea. findfilernentstay. tagIVaure("l1"l); return result. sizel ):
  3. 3. — 30107130 ‘S .427‘
  4. 4. An ordinary person with a passion for programming, who want to do a great job
  5. 5. Mindset
  6. 6. Embrace change
  7. 7. Not a utopi to divide a problem into smaller parts
  8. 8. Will program even if it isn't paid
  9. 9. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockbum Ron Jetfries Jeff Sutherland Ward Cunningham Jon Kem Dave Thomas Martin Fowler Brian Marick
  10. 10. Communication
  11. 11. Communication Uses the language of the customer
  12. 12. Principles behind the Agile Manifesto We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and efiective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  13. 13. Ir%KL&. l LI’ 411%? SCI L15? €Il¢I' $1 LlK&L. I«ILO Working software is the primary measure of progres Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. A4 I ' n I 41 g I‘
  14. 14. The 4 rules of simple design ~ Tests passes Express intent « l| o duplication ~ Small 3.. ..
  15. 15. How do you build a system?
  16. 16. Incremental, adding piece by piece?
  17. 17. Paint by number
  18. 18. Iterative: Build and evaluate Build more and evaluate Change and evaluate Repeat”
  19. 19. . Jeff Patton
  20. 20. Divide and conquer
  21. 21. The Unix way
  22. 22. Solves one problem Can be combined | s|wc-|
  23. 23. if i / /I; Bi
  24. 24. Small tasks
  25. 25. Small solutions Is wc
  26. 26. The better way to future proof a system I
  27. 27. Unix has been around a long time. ..
  28. 28. I973 mg an--—-—v]__ nun, I900 — u~u~u~u————— J 1981 rm . __, 4, . i was in-. ... u,_j :1 was j. v-nun-vi. .. 1956 -. u—--. --. . . _. --j I037 _ Axum man 191! | __. ,_, ._. # if we . ... ... ... .. D90 mi —- I--I 1991 1993 I996 I995 I996 I995 It'll) 1 t. ..-‘an’ an . ... _.e l . —u--—. 2|'Kl§ flu) -nu anus . ... i.. u. —. . . ... .., .. ... .,. ..,
  29. 29. How do you build a system?
  30. 30. Walking skeleton
  31. 31. Vertical slices
  32. 32. l-low TO BUILD i‘-ll? "-JIl~IUr~I ‘I/ I.! .=l’-JLE ivaooucr NOT LIKE THIS A . “ . - 1 .1 LIKE THIS
  33. 33. Simple code is better than smart code
  34. 34. Simple code on smart data (structures) instead of smart code on simple data (structures) A hash table could be smarter than a linked list
  35. 35. Istead of simple data (structures) A hash table could be smarter than a linked list
  36. 36. Sharing and learning
  37. 37. Pair programming
  38. 38. Shared code ownership
  39. 39. Sharing and learning
  40. 40. Mentoring other devs You must understand it before you can explain it
  41. 41. ntoring other devs You must understand it before you can explain it
  42. 42. Constantly learning
  43. 43. Win - Win You learn as long as you have students
  44. 44. Want to know that it works
  45. 45. Constantly testing
  46. 46. Constantly testing Writes code that tests code
  47. 47. Write test code first Test Dri eeeeeeeeeeee nt
  48. 48. Test Driven Development
  49. 49. The tests must be cleanest Understanding the tests means that you can understand what the system should do
  50. 50. e tests must be cleanest Understanding the tests means that you can understand what the system should do
  51. 51. Clarity always trumps DRY (in a test) Aslak Hellesray, 2011-10-06 (DRY — Don't Repeat Yourself)
  52. 52. Automated acceptance criteria
  53. 53. Outside in
  54. 54. Avoid testing implementation details
  55. 55. Focus on the high level, don't get lost among the details
  56. 56. Scenario: Sign up with a valid e-mail address Given I want to sign up to receive important market information When I enter a valid e-mail address Then should I get a welcome message
  57. 57. Always able to keep an eye on the overall picture
  58. 58. Clean code
  59. 59. Code is written once
  60. 60. Read and maintained during a long time
  61. 61. public void execute(Account a1, Account a2, float n) { a1.add(n); a2.add(—n); } public void transferFunds(Account payee, Account payer, float amount) { payee. credit(amount); payer. debit(amount); } The best kind of code clearly tells the story of what the code does. Jason Gorman, Programming Well h: mnhi. . rl mll? i=2
  62. 62. Readability simplifies maintenance
  63. 63. The boy scout rule Always leave the code in a better shape than you found it
  64. 64. Refactoring
  65. 65. What does refactoring mean?
  66. 66. It does not mean "Improving the code"
  67. 67. Refactoring means "Improving the code while maintaining the functionality"
  68. 68. No need for (large) rewrites Rewrites are done in small steps with maintained functionality
  69. 69. 3r (large) rewrites Rewrites are done in small steps with maintained functionality
  70. 70. Delivering value
  71. 71. Deploy often
  72. 72. WI Iv,
  73. 73. Why? The only way to deliver features to our customers A prototype is worth a thousand words
  74. 74. may to deliver features to our customers A prototype is worth a thousand words
  75. 75. Build the system often, after each commit
  76. 76. Continuous Integration
  77. 77. Keep the build green
  78. 78. Keep the build green Fix broken builds immediately
  79. 79. . ‘ 1 I ta‘: ‘II . — I iv - I ' r I clldw I II I ‘. 7 I I I it I 1 l I IN I . lb ‘la . II I I. .II . ion. .. I . I I l . I. » . bI ' . l ll ‘tv. I ' ' III N I . {I I . . II» I 1 — - . ' I . I . .. I . I
  80. 80. Commit and run is illegal
  81. 81. Continuous Integration
  82. 82. Deliver deployable artefacts A| AIn/ Q l(nnn tho hnrln in 2
  83. 83. Deliver deployable artefacts Always keep the code in a deployable state
  84. 84. Feature switches Hides stuff that's not ready yet
  85. 85. Deploy often
  86. 86. I/ I/IIII I I»;
  87. 87. Never before you go home
  88. 88. Before lunch, early in the week
  89. 89. early in the week Deploy often means deploying small things
  90. 90. Scary to deploy large things | |n hF
  91. 91. No heroes Not brave
  92. 92. Deploy often
  93. 93. II , t
  94. 94. Automated
  95. 95. Laziness wins in the end Viktor Olsson, bass player, arranger and Manual deployment is developer, August 2014 - boring - error prone - stupid
  96. 96. Manual deployment is -bonng - error prone - stupid
  97. 97. Easy to operate Simple to deploy Reread new properties Good logging
  98. 98. Good software doesn't scare users with bad error messages
  99. 99. Sm‘-t 0-t‘>b5u'~. ':—: T '” Mr. ‘ Sorfieu. ”‘E’<5’“’5RlENCERocKs. cam
  100. 100. Constantly learning
  101. 101. Bad news if you prefer status quo
  102. 102. New techniques New tools Customers/ Users domain
  103. 103. New techniques
  104. 104. THE 2% MINDSET 2% OF THE ‘? O'PULATION GOING FOR youg pggAMg EMBRACING THE UNKNOWN 92% 0: Tfiz ?0?ULATlON cxcxrzucnr EONEIDENEE acme LIKE EVER‘/ ONE use ~ L K 1 me came: “SECURE SURVIVING emorzme ‘/ OUR COMFORT ZONE L1»/ me wmcour NEW THINGS FEAR JUST GETTING By LIMITS A ‘DULL use ? LA‘/ rr SAFE ABUNMNCE cuoosme -~ rzzerzc-r HAWMESS ? RocIzAsTmA'r1o~ . SETTLING cor: LESS ACT 1" 57175 or: can FULFILLMENT GETTING THE MOST OUT OF LIFE
  105. 105. New techniques New tools Customers/ Users domain
  106. 106. New tools
  107. 107. Isn't fooled by sexy tools or framework
  108. 108. Still need to think for yourself
  109. 109. Use the best tools you currently know
  110. 110. CI ILIy fI ILIVV Always be on the lookout for better tool;
  111. 111. A poor craftsman blames the tools, a worse don't even realize how shitty his tools are
  112. 112. ,/ .,. ,r»‘~? i /11. ll _. g_, ._E__. =8fl©W= ’ @R° V/ - mg I : -
  113. 113. New techniques New tools Customers/ Users domain
  114. 114. Customers/ Users domain
  115. 115. Domain knowledge
  116. 116. Divide and concur given our current knowledge
  117. 117. Then do it again with our new knowledge We probably learned something
  118. 118. new knowledge We probably learned something
  119. 119. Guesstimates
  120. 120. Hard and always wrong You underestimate the complexity of the problem and overestimate your own capabilities
  121. 121. 1d always wrong You underestimate the complexity of the problem and overestimate your own capabilities
  122. 122. A II. b. .___ , u. :.~Iu5=r~g_ . . l. - W43 1) ill l). ca°. I,
  123. 123. What you are doing haven't been done before Done or Don't know
  124. 124. Done or Don't know
  125. 125. Being responsible does not mean doing as you are told; that's obedience
  126. 126. Being responsible means doing what we know is right
  127. 127. Sustainable pace
  128. 128. pérwf. ’ A . E, J. ._ :1‘ ~, . Plan for a marathon ’. ' - '. .-’ -3‘, z - ‘ Eh‘) , E. v. _
  129. 129. C“/ flfl/ //(/ /7* (‘E3/r/ /i’«j/ /((1/zei/2/'2 R i, in‘, the b. .r. A s aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships That is, in pursuit of the items on the left we have found the items on the right to be indispensable. I '. -0:>9.lhu Jndur '~*'1cd, [has st. :.L~n1m'. l'! '.. l) be fr: -cly _ rd in any funzi, bu: only in . ts mtin-I) zhm.1g‘r. '. l.l. - notio. -.
  130. 130. er "2 A s aspiring Software Craftsmen we are raising the bar of ‘Q-‘_: professional software development by practicing it and helping '3, others learn the craft. Through this work we have come to value: ' Not only working software, ‘ ' _'7 but also well-crafted software ‘*7; Not only responding to change, i but also steadily adding value -, _‘ 2%: Not only individuals and interactions, but also a community of professionals Not only customer collaboration, - { but also productive partnerships That is, in pursuit of the items on the left we have found the _: items on the right to be indispensable.
  131. 131. /
  132. 132. Action points: « -/ -= t-t-er-*. »el-G-le»ba! -'9ay-ef-Gede-Re-t: =ea*4£—N-evembm « Try TDD ~ Try Pair Programming « Get a GitHub account and share a pet project
  133. 133. Remember
  134. 134. #xpHves
  135. 135. The Responsible Developer Thomas Sundberg Think Code AB @thomassundberg tsu@kth. se

×