1 / 33

Pair Programming

Pair Programming. Presented by Michael Welker Members 1 st Federal Credit Union. Little bit about myself:. Worked at Members 1 st Federal Credit Union for 27 years. Platforms I’ve worked on: HP Unix Systems HP MPE/MPEX IBM Unix Systems Positions I’ve held: Computer Operator

mcarothers
Download Presentation

Pair Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Pair Programming Presented by Michael Welker Members 1st Federal Credit Union

  2. Little bit about myself: • Worked at Members 1st Federal Credit Union for 27 years. • Platforms I’ve worked on: • HP Unix Systems • HP MPE/MPEX • IBM Unix Systems • Positions I’ve held: • Computer Operator • Checks Processor • PC Technician and Network Administrator • Programmer Analyst

  3. What is pair programming? • Two developers working side by at one computer. • One developer writes the code, the other is giving suggestions/collaborates. • Driver • Navigator

  4. Why Pair Programming? • Increased discipline • Better code • Better approaches/directions • Improved morale • Collective code ownership • Mentoring • Team cohesion • Fewer interruptions 4

  5. Increased discipline • Pairing partners are more likely to "do the right thing" and are less likely to take long breaks. 5

  6. Better code • Pairing partners are less likely to go down Gopher Holes and Blind Alleys and tend to come up with higher quality designs. • Code reviews are done during coding sessions between the pair. • Less help desk tickets and more maintainable code. • “ I will not write any more bad code.” 6

  7. Better approaches/directions • Working in pairs leads to different thinking that leads to better approaches when creating code. 7

  8. Improved morale • Pair programming, done well, is much more enjoyable than programming. On the other hand, pair programming done poorly is much less enjoyable than programming alone done poorly. 8

  9. Collective code ownership • When everyone on a project is pair programming, and pairs rotate frequently, everybody gains a working knowledge of the entire codebase. 9

  10. Mentoring • Everyone, even junior programmers, has knowledge that others don't. Pair programming is a painless way of spreading that knowledge. 10

  11. Team cohesion • People get to know each other more quickly when pair programming. Pair programming may encourage team jelling. 11

  12. Fewer interruptions • People are more reluctant to interrupt a pair than they are to interrupt someone working alone. 12

  13. How we applied the concept • Large Online Banking program that needed to be re-written that gathers account, share, loan and Visa information: • Designed the program for unit testing. • Eliminated repetitive code. • Removed technical debt. 13

  14. End result • Re-usable code/procedures that were placed into their own library • Code review(s) conducted as the code is being written • Getting to know your colleague and how they think • Less bugs • Transfer of domain knowledge (business logic) 14

  15. Questions? 15

  16. References • Books • Beyond Legacy Code – David Scott Bernstein Internet http://wiki.c2.com/?PairProgrammingBenefits 16

  17. Unit Testing with PowerOn Presented by Dan Wolf Members 1st Federal Credit Union

  18. Who am I? • Programmer Analyst at Members 1st FCU • 35 years software development • Retail • Logistics/Order Fulfillment • Education • Government • Insurance • Communications • Platforms • IBM AS/400 and Microsoft .NET • Oracle and SQL Server 18

  19. Definitions • Program – a specfile or repgen • Include Library – a set of related include files (.DEF, .SET, .PRO) where the .PRO contains procedures used by different programs • Constants Include File – a .DEF file containing named constants for values of various Episys fields, used by different programs 19

  20. Who does unit testing? This is not a new concept, many platforms have unit testing integrated into their development tools, languages, and methodologies. • Java – JUnit • .NET – Live Unit Testing (Visual Studio 2017) • JavaScript – Jasmine Unit Test Framework • PowerOn - ? (nope) 20

  21. What is a unit test? First of all, what it is NOT: • It is not system testing • It is not integration testing • It is not QA testing Okay, so, what is a unit test? 21

  22. What is a unit test? • A unit test verifies a specific behavior of a unit of code in a program • Every branch condition is tested, every possible result is considered • one unit test covers the “true” • another unit test covers the “false” • The testresult is compared with the expected result • Unit Testing is running multiple unit tests for a program • Detailed feedback is given for which test failed and why 22

  23. Practical Thinking • We, as developers, (should) test our code as we write it • Unit testing is a way to replicate these tests in such a way that they are performed in an automated fashion for the life of the program • Basically, in the PowerOn world, a procedure is the unit of code to be unit tested • Procedures need to be small and single-purpose • Procedures take input, do work, and produce output • A unit test supplies the input, calls the procedure, and checks the output 23

  24. Anatomy of a unit test • Arrangement • Assign values to variables with the intent to cause an expected result • Assign the expected result to a variable for comparison • Act • Call the procedure to be tested • Assert • Compare the test result with the expected result • Record the results of the test 24

  25. Example of a PowerOn Unit Test procedureTestAccountListBeginsWithComma testName="TestAccountListBeginsWithComma" procedureName="ParseAccountList" [Arrangement] parmAccountList=",0000123456,0000234567" expectedCharResult="The account list begins with a comma" [Act] callParseAccountList actualCharResult=errorMessage [Assert] ifactualCharResult=expectedCharResultthendo passFail="Pass" endelsedo passFail="Fail" end [Report] printActualResult=actualCharResult printExpectedResult=expectedCharResult callPrintTestResults end[TestAccountListBeginsWithComma] 25

  26. When do unit tests run? Unit tests (should) run often • Can be automated to run during certain events (“continuous Integration”) • As code is written* • When code is saved* • When code is checked-in/merged* • When code is staged/deployed • When a SYM is refreshed, brought online • Can be scheduled • Can be run manually as needed 26

  27. Where Do We Begin?(Questions, questions, questions…) • What can be unit tested? What should be unit tested? • Where will we realize the most benefits for the required effort? • How will we write and implement unit tests? • What obstacles must we overcome? • How, when, and where do we run unit tests? • How do we communicate unit test results? 27

  28. What Should Be Unit Tested? • SymConnect programswhich serve Episys data to critical, member-facing apps • Include Librariesused by multiple PowerOn programs • Constants Include Files used by multiple PowerOn programs • Validate programs (future) • Important or complex calculations • The list goes on . . . you decide and prioritize what is important to you! 28

  29. PowerOn Unit Testing FRAMEWORK We built a framework to assist in performing unit tests in PowerOn, consisting of: • A unit test template program • Provides the basic Arrange-Act-Assert structure for individual unit tests • Executes several unit tests to provide coverage for a program • Records the results of the unit tests • An include library to support common unit test tasks • Variable definitions used for testing, reporting, etc. • Logging and reporting results in a consistent, pre-defined format • Sending notifications 29

  30. PowerOn Unit Testing FRAMEWORK Other components in the framework: • A “controller” job to run unit test programs • A program to scan test results and send notifications • A way to customize how unit testing runs in different environments 30

  31. More Details • Each program or library to be unit tested has a dedicated unit test program • Procedures to be tested are put into a separate .PRO file so they can be used by the main program and used by the unit test program • Where possible, separate data access from business logic so business logic can be unit tested • Store unit test results in a letter file. Crude, but it works. 31

  32. In Summary, Why Unit Test? • Ensures code behaves as expected • Identifies logic errors before they become unwelcome surprises • Helps ensure other programs sharing the same code will not unexpectedly fail • Contributes towards producing better organized, easier to maintain, higher quality code Reliable applications = Happier members Happier members = Happier associates Happier associates = Happier IT staff Extra work and planning? Yes. Worth the effort? We think so. 32

  33. Questions? 33

More Related