The Professional Programmer
Download as ODP, PDF4 likes6,743 views
Unit testing is important for writing reliable code. Tests should exercise code modules to validate functionality. Source code control systems like Git help teams collaborate and manage code versions. Continuous integration runs tests on all new code to quickly detect errors. Coding standards like Perl Best Practices improve code quality and maintenance. Agile methods like Scrum emphasize frequent delivery of working software through short iterations and customer collaboration.
![The Professional Programmer Dave Cross Magnum Solutions Ltd [email_address]](https://image.slidesharecdn.com/prof-prog-091206074043-phpapp01/85/The-Professional-Programmer-1-320.jpg)
The Professional Programmer
- 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
- 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
- 19. Look for expected outputs
- 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 Output files
- 28. Etc
- 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
- 42. Draws pretty charts ./Build testcover
- 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
- 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
- 59. RCS
- 60. CVS
- 61. Subversion
- 62. Git
- 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
- 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
- 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
- 87. Strong support for branching and merging
- 88. GitHub GitHub offers free Git hosting to Open Source projects
- 89. Paid hosting also available
- 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
- 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
- 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
- 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
- 163. Command line program “perlcritic”
- 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
- 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
- 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
- 270. Fewer logic and syntax errors
- 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
- 278. The Professional Programmer A few more things to consider
- 279. Operating system
- 280. Editor/IDE
- 281. Language
- 282. Business
- 283. That's All Folks Any Questions?