The Professional Programmer

  • 2,708 views
Uploaded on

Tutorial that I gave at the London Perl Workshop in December 2009.

Tutorial that I gave at the London Perl Workshop in December 2009.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,708
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
97
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. The Professional Programmer Dave Cross Magnum Solutions Ltd [email_address]
  • 2. The Professional Programmer
    • Looking beyond programming skills
    • 3. What else do you need to be a successful programmer?
  • 4. The Pragmatic Programmer
    • The Pragmatic Programmer
      • Andrew Hunt
      • 5. David Thomas
  • 6. What We Will Cover
    • Unit testing
    • 7. Source code control
    • 8. Continuous integration
    • 9. Coding Standards
    • 10. Agile techniques
  • 11. Unit Testing
  • 12. Unit Testing
    • Never program without a safety net
    • 13. Does your code do what it is supposed to do?
    • 14. Will your code continue to do what it is supposed to do?
    • 15. Write unit tests
    • 16. Run those tests all the time
  • 17. What is Unit Testing?
    • Code that exercises an individual element (unit) of your code
    • 18. Provide known inputs
    • 19. Look for expected outputs
    • 20. “Bottom-up” testing
  • 21. Typical Unit Tests
    • Create an object
    • 22. Call methods with known inputs
    • 23. Look for expected outputs
  • 24. Non-OO Unit Tests
    • Possible to test non-OO code
    • 25. Call functions rather than methods
    • 26. Even call programs and examine their output
  • 29. Unit Testing Advantages
    • Confidence in the building blocks of your program
    • 30. Modular code is easier to test
    • 31. Well-tested code is good
    • 32. Easy to test code is better
  • 33. Unit Testing in Perl
    • Perl has a culture of unit testing
    • 34. All Perl modules ship with test suites
    • 35. Lots of work in this area since 2001
    • 36. Perl makes it easy to write test suites
  • 37. Simple Test Program
    • use Test::More tests => 4; BEGIN { use_ok('My::Object'); } ok(my $obj = My::Object->new); isa_ok($obj, 'My::Object'); $obj->set_foo('Foo'); is($obj->get_foo, 'Foo');
  • 38. Simple Test Output
    • $ prove -v test.t test.... 1..4 ok 1 - use My::Object; ok 2 ok 3 - The object isa My::Object ok 4 ok All tests successful. Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.00 csys = 0.07 CPU) Result: PASS
  • 39. How Good Are Your Tests?
    • How much of your code is exercised by your tests?
    • 40. Devel::Cover can help you to find out
    • 41. Deep internal magic
    • 42. Draws pretty charts
      • ./Build testcover
  • 43. Devel::Cover Output
  • 44. Devel::Cover Output
  • 45. Devel::Cover Output
  • 46. Other Advantages
    • A test suite gives you confidence in your code
    • 47. But it's also a specification of your code
    • 48. Your code works if it passes the tests
    • 49. Once the tests pass you can stop writing code
    • 50. See Test-Driven Development later
  • 51. Further Information
    • Perl Testing – A Developer's Notebook
      • Ian Langworth
      • 52. chromatic
  • 53. Source Code Control
  • 54. Source Code Control
    • Source code is a programmer's most valuable asset
    • 55. If you lose your source code you are in trouble
    • 56. Ensure your source code is always safe
  • 57. Other Advantages
    • Rewind to previous versions of code
      • Encourages experimentation
    • Mark particular versions as important
      • Released versions
    • Branching and merging
  • 58. Brief History
  • 63. Typical Workflow
    • Network-available centralised repository of source code
      • LAN or internet
    • Developer checks out local copy of code
    • 64. Makes changes
      • Ensures unit tests still pass
    • Uploads new versions
  • 65. Locking
    • Older systems locked code whilst a developer worked on it
    • 66. Only one developer working on code at a time
    • 67. No chance of conflicts
    • 68. Development bottlenecks
  • 69. Non-Locking
    • “Optimistic concurrency”
    • 70. Anyone can work on any file at any time
    • 71. Conflicts detected at check-in
    • 72. Most of the time people don't work on the same files
      • Or, at least, on the same parts of the same file
    • More effective use of time
  • 73. Branching & Merging
    • Multiple versions of code available simultaneously
      • Released version
      • 74. Development version
      • 75. Experimental version
    • Merge changes back into older branches
    • 76. Merging easier with more modern systems
  • 77. Distributed Version Control
    • Network model allows many people to work on same codebase
    • 78. Single master repository on the internet
    • 79. Need internet access to check in
    • 80. Distributed model has no master repository
    • 81. Many equal peers
    • 82. Check into local repository
    • 83. Merge with peers when online
  • 84. Git
    • Git is currently the most popular source code control system
    • 85. Written by Linus Torvalds for the Linux kernel
    • 86. Distributed model
    • 87. Strong support for branching and merging
  • 88. GitHub
    • GitHub offers free Git hosting to Open Source projects
    • 89. Paid hosting also available
    • 90. Very popular choice
    • 91. No excuse for not having public git hosting for your project
    • 92. Also wiki and ticket tracker
  • 93. Hooks
    • Most systems support some kind of hooks
    • 94. Code that is run when something is checked in
      • Or at other times
    • Send email for every check-in
    • 95. Ensure all checked-in code compiles
    • 96. Run perltidy
    • 97. Etc...
  • 98. Conclusions
    • Source code control is a problem that all programmers have
    • 99. No excuse for not being familiar with source code control systems
    • 100. At some point in your career, source code control will save you from an embarrassing mistake
    • 101. The file you accidentally delete is never under source code control
  • 102. Continuous Integration
  • 103. Continuous Integration
    • Continuously monitoring the health of your codebase
    • 104. Giving visibility to the changes that are being made
  • 105. What Does It Do?
    • Monitors source code repository
    • 106. Every time it sees a check-in
    • 107. Run unit tests
    • 108. Produce a web site
    • 109. See if your build is broken
  • 110. Advantages
    • Instant feedback on the quality of codebase
    • 111. Instantly know when tests are failing
    • 112. Instantly know which tests are failing
    • 113. Instantly know who broke the build
  • 114. Software
    • Easy to build something to do this
    • 115. Perl would be an excellent choice
    • 116. Plenty of ready-built software
      • Much of it Open Source
    • Most popular choice is currently CruiseControl
  • 117. Enhancements
    • Don't just run tests
    • 118. Measure test coverage
    • 119. Generate documentation
    • 120. Code complexity statistics
    • 121. Coding standards checks
      • Perl Critic
    • Etc...
  • 122. Build Radiator
    • Standard practice is to build an internal web site
    • 123. But people have to choose to visit it
    • 124. Large monitor on the wall of the development office
    • 125. Rolling dashboard of important stats
    • 126. No excuse for not seeing the data
  • 127. Coding Standards
  • 128. Coding Standards
    • Perl is a very loosely-structured language
    • 129. Anything goes
    • 130. Should probably tighten up on that
    • 131. “perldoc perlstyle”
      • How Larry Wall writes Perl
  • 132. Perl Best Practices
    • Perl Best Practices
      • Damian Conway
  • 133. Perl Best Practices
    • Damian Conway's ideas on what makes a good Perl program
    • 134. Naming conventions
    • 135. Code layout
    • 136. Disallowed constructs
    • 137. Recommended CPAN modules
  • 138. Disagreeing With PBP
    • You don't need to agree with everything that Damian says
    • 139. But you should consider his ideas
    • 140. And have a good reason for any disagreements
  • 141. Code Layout
    • Perl compiler doesn't care about your code layout
    • 142. But the maintenance programmer will
    • 143. Make your code as easy as possible to follow
    • 144. Consistent formatting is a big help
  • 145. Maintenance Programmers
    • Always write code as though it will be maintained by a homicidal, axe-wielding maniac who knows where you live
  • 146. Maintenance Programmers
    • Always write code as though it will be maintained by a homicidal, axe-wielding maniac who knows where you live
  • 147. Maintenance Programmers
    • Bear that image in mind whilst writing code
    • 148. I find it helps me focus
  • 149. Enforcing Code Layout
    • Different programmers have different ideas about good code layout
    • 150. No right answer
    • 151. Brace positioning
    • 152. Cuddled else
    • 153. Size of indent
    • 154. Maximum line length
  • 155. perltidy
    • Perl tidy automatically reformats code according to various rules
    • 156. Decide on a project standard
    • 157. Create a perltidy config file with those rules
    • 158. Everyone can use their own local rules
    • 159. But run standard config before check-in
      • Or even during check-in
  • 160. Enforcing Best Practices
    • Many suggestions in Perl Best Practices are well worth following
    • 161. Enforce them automatically
    • 162. Perl::Critic does this
    • 163. Command line program “perlcritic”
    • 164. $ perlcritic your_program.pl
    • 165. Very depressing output
  • 166. perlcritic
    • Five levels of criticism available
    • 167. Gentle, stern, harsh, cruel, brutal
    • 168. Gentle is default
      • Reports only most severe violations
    • Change that on command line
    • 169. $ perlcritic –brutal your_program.pl
  • 170. Configuring perlcritic
    • Not everyone agrees with all perlcritic rules
    • 171. Configure behaviour with .perlcriticrc
    • 172. Turn off certain policies
    • 173. Or invent your own
      • Based on PPI
    • Have a project-wide .perlcriticrc
  • 174. Criticism Statistics
    • For continuous integration it's useful to get statistics from a file
    • 175. $ perlcritic –statistics your_program.pl
    • 176. $ perlcritic –statistics-only your_program.pl
  • 177. Criticism Statistics
    • $ perlcritic --statistics-only lib/Calendar/Simple.pm 1 files. 4 subroutines/methods. 128 statements. 269 lines. Average McCabe score of subroutines was 8.50. 1 violations. Violations per file was 1.000. Violations per statement was 0.008. Violations per line of code was 0.004. 1 severity 5 violations. 1 violations of BuiltinFunctions::ProhibitStringyEval.
  • 178. Coding Standards
    • Many valid options in Perl
    • 179. Choose one set of options
    • 180. Enforce with perltidy and perlcritic
  • 181. Agile Techniques
  • 182. Systems Analysis and Design
    • In the bad old days, Systems Analysis and Design was a huge task
    • 183. Analysts would spend months analysing a problem
    • 184. Huge specification documents would be written
    • 185. All before a line of code was written
  • 186. System Design Diagrams
    • The specs were always full of diagrams
    • 187. How the system looks now
    • 188. How the system should look
    • 189. Data flow diagrams
    • 190. Entity-Relationship diagrams
    • 191. Jackson Structured Programming
  • 192. The Flaw
    • This all took too long
    • 193. Months before spec was complete
    • 194. Then more time whilst system was coded, tested and deployed
    • 195. By the time the system was complete, the problem had changed
    • 196. Back to the drawing board
  • 197. Agile Programming
    • Analysis and design needed to be more agile
    • 198. Able to respond to demands more quickly
    • 199. Turn around projects in less time
    • 200. Deliver value sooner
  • 201. Agile Methodologies
    • Many “lightweight” methods arose in mid 1990s
    • 202. Extreme programming
    • 203. Scrum
    • 204. Meeting Utah Feb 2001
    • 205. Agile Manifesto
  • 206. Agile Manifesto
    • 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
      • 207. Working software over comprehensive documentation
      • 208. Customer collaboration over contract negotiation
      • 209. 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.
  • 210. Individual & Interactions
    • People are more important than processes
    • 211. Development teams know how to organise their work
    • 212. Business says what they need
    • 213. Development team works out how to achieve that
    • 214. Giving people more control and responsibility
  • 215. Working Software
    • Documentation is often out of date before it is finished
    • 216. Mismatch between business language and technical language
    • 217. Business often don't know what they want until they see the options
    • 218. Build prototypes and discuss alternatives
  • 219. Customer Collaboration
    • Don't just involve users when the project is specified
    • 220. Have user representatives as a part of the development team
    • 221. Instant response to developer questions
    • 222. More involvement leads to more business ownership of project
  • 223. Responding to Change
    • Requirements will change during the project lifetime
    • 224. Be flexible
    • 225. Plan for change
  • 226. Scrum
    • Common agile process for software development
    • 227. In use at many companies
  • 228. Scrum Roles
    • Scrum Master: manages the process (like project manager)
    • 229. Product Owner: represents the stakeholders
    • 230. Team: people responsible for analysis, design, implementation and testing
    • 231. Stakeholders: people who are requesting the work
  • 232. Scrum Process
    • Team decides on the length of a sprint (between one and four weeks)
    • 233. Stakeholders build up a product backlog
    • 234. Stakeholders (with product owner) prioritise most important work
    • 235. Team work out how much they can do in one sprint
    • 236. Team carry out work
    • 237. Team demonstrate progress at end of sprint
  • 238. Scrum Meetings
    • Sprint planning: start of sprint
      • Converts product backlog to sprint backlog
    • Daily scrum: short meeting where team members report on progress and plan day
    • 239. Sprint demo: end of sprint
      • Demo work to stakeholders
    • Sprint retrospective: end of sprint
      • Team discusses what went well and what can be improved
  • 240. Scrum Artifacts
    • Product backlog
      • Long list of things to do
      • 241. High level
    • Sprint backlog
      • More detailed descriptions of current projects
      • 242. Broken down to tasks of about a day
    • Burn down chart
      • Lists work planned for current sprint
      • 243. Current progress plotted
  • 244. YAGNI
    • “You Ain't Gonna Need It”
    • 245. Do not plan for the future
    • 246. Only implement what is required now
    • 247. The simplest thing that could possibly work
    • 248. Refactor and add functionality later
  • 249. Refactoring
    • Changing internal structure without modifying external behaviour
    • 250. Changes made to make next steps easier
    • 251. Run test plan
    • 252. Refactor
    • 253. Run test plan again
  • 254. Refactoring
    • Refactoring
      • Martin Fowler
  • 255. Test Driven Development
    • Test plans give you confidence that you code does what it is supposed to do
    • 256. And that your refactoring hasn't broken anything
    • 257. They can also act as a specification for a change
    • 258. If the code passes this test then this feature has been implemented
  • 259. Test Driven Development
    • Run existing test plan
    • 260. Write test for new feature
    • 261. Run new test plan
    • 262. Code/refactor until new tests pass
    • 263. Run complete test plan
  • 264. Test Driven Development
    • Test-Driven Development
      • Kent Beck
  • 265. Pair Programming
    • Code review is useful
    • 266. Constant code review is better
    • 267. Two people working together on a problem
    • 268. Two heads are better than one
    • 269. Better initial design
    • 270. Fewer logic and syntax errors
    • 271. Benefits outweigh costs
  • 272. Agile Development
    • Agile methods are becoming more popular
    • 273. I see many clients using versions of Scrum or Extreme Programming
    • 274. More common in smaller companies
    • 275. Larger companies of still prefer their huge specifications
    • 276. This is changing slowly
  • 277. The Professional Programmer
  • 278. The Professional Programmer
  • 283. That's All Folks
    • Any Questions?