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.

1. The Professional Programmer Dave Cross Magnum Solutions Ltd [email_address]

3. What else do you need to be a successful programmer?

5. David Thomas

7. Source code control

8. Continuous integration

9. Coding Standards

10. Agile techniques

11. Unit Testing

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

18. Provide known inputs

19. Look for expected outputs

20. “Bottom-up” testing

22. Call methods with known inputs

23. Look for expected outputs

25. Call functions rather than methods

27. Effect on databases

28. Etc

30. Modular code is easier to test

31. Well-tested code is good

32. Easy to test code is better

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

40. Devel::Cover can help you to find out

41. Deep internal magic

43. Devel::Cover Output

44. Devel::Cover Output

45. Devel::Cover Output

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

52. chromatic

53. Source Code Control

55. If you lose your source code you are in trouble

56. Ensure your source code is always safe

59. RCS

60. CVS

61. Subversion

62. Git

66. Only one developer working on code at a time

67. No chance of conflicts

68. Development bottlenecks

70. Anyone can work on any file at any time

71. Conflicts detected at check-in

74. Development version

76. Merging easier with more modern systems

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

85. Written by Linus Torvalds for the Linux kernel

86. Distributed model

87. Strong support for branching and merging

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

95. Ensure all checked-in code compiles

96. Run perltidy

97. Etc...

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

104. Giving visibility to the changes that are being made

106. Every time it sees a check-in

107. Run unit tests

108. Produce a web site

109. See if your build is broken

111. Instantly know when tests are failing

112. Instantly know which tests are failing

113. Instantly know who broke the build

115. Perl would be an excellent choice

118. Measure test coverage

119. Generate documentation

120. Code complexity statistics

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

129. Anything goes

130. Should probably tighten up on that

134. Naming conventions

135. Code layout

136. Disallowed constructs

137. Recommended CPAN modules

139. But you should consider his ideas

140. And have a good reason for any disagreements

142. But the maintenance programmer will

143. Make your code as easy as possible to follow

144. Consistent formatting is a big help

148. I find it helps me focus

150. No right answer

151. Brace positioning

152. Cuddled else

153. Size of indent

154. Maximum line length

156. Decide on a project standard

157. Create a perltidy config file with those rules

158. Everyone can use their own local rules

161. Enforce them automatically

162. Perl::Critic does this

163. Command line program “perlcritic”

164. $ perlcritic your_program.pl

165. Very depressing output

167. Gentle, stern, harsh, cruel, brutal

169. $ perlcritic –brutal your_program.pl

171. Configure behaviour with .perlcriticrc

172. Turn off certain policies

175. $ perlcritic –statistics your_program.pl

176. $ perlcritic –statistics-only your_program.pl

179. Choose one set of options

180. Enforce with perltidy and perlcritic

181. Agile Techniques

183. Analysts would spend months analysing a problem

184. Huge specification documents would be written

185. All before a line of code was written

187. How the system looks now

188. How the system should look

189. Data flow diagrams

190. Entity-Relationship diagrams

191. Jackson Structured Programming

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

198. Able to respond to demands more quickly

199. Turn around projects in less time

200. Deliver value sooner

202. Extreme programming

203. Scrum

204. Meeting Utah Feb 2001

205. Agile Manifesto

207. Working software over comprehensive documentation

208. Customer collaboration over contract negotiation

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

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

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

224. Be flexible

225. Plan for change

227. In use at many companies

229. Product Owner: represents the stakeholders

230. Team: people responsible for analysis, design, implementation and testing

231. Stakeholders: people who are requesting the work

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

243. Current progress plotted

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

250. Changes made to make next steps easier

251. Run test plan

252. Refactor

253. Run test plan again

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

260. Write test for new feature

261. Run new test plan

262. Code/refactor until new tests pass

263. Run complete test plan

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

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

279. Operating system

280. Editor/IDE

281. Language

282. Business