1 CSE 403 Collaborative Programming: Pair Programming, Code Reviews, Walkthroughs and Maintenance and Refactoring These lecture slides are copyright (C)

Slides:



Advertisements
Similar presentations
Test-Driven Development and Refactoring CPSC 315 – Programming Studio.
Advertisements

SOFTWARE MAINTENANCE 24 March 2013 William W. McMillan.
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
12 Aug 2005CSE403, Summer'05, Lecture 15 Updated Schedule of Remaining Class-Related Deliverables Fri, Aug 10pm: hw#4 responses due Sun, Aug
1 Software Maintenance and Evolution CSSE 575: Session 2, Part 3 Moving Features Between Objects Steve Chenoweth Office Phone: (812) Cell: (937)
Week 7: Requirements validation Structured walkthroughs Why have walkthroughs When to have walkthroughs Who participates What procedures are helpful Thoughtless.
Design Patterns and Refactoring CSE 403. Outline Design Patterns Refactoring Refactoring patterns.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
SE is not like other projects. l The project is intangible. l There is no standardized solution process. l New projects may have little or no relationship.
Applied Software Project Management 1 Introduction Dr. Mengxia Zhu Computer Science Department Southern Illinois University Carbondale.
Algorithm Programming Coding Advices Bar-Ilan University תשס " ו by Moshe Fresko.
Design, Implementation and Maintenance
1CMSC 345, Version 4/04 Verification and Validation Reference: Software Engineering, Ian Sommerville, 6th edition, Chapter 19.
CSE 403 Lecture 13 Black/White-Box Testing Reading: Software Testing: Principles and Practices, Ch. 3-4 (Desikan, Ramesh) slides created by Marty Stepp.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Maintenance Refactoring and Code Smells. Where are we? Over the semester we have talked about Software Engineering. The overall goal of software engineering.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
1 CSE 403 Software Lifecycle Models Reading: Rapid Development Ch. 7, 25 (further reading: Ch. 21, 35, 36, 20) These lecture slides are copyright (C) Marty.
Prologue: The Software Process. Main Phases of Software Process 1. Requirements Analysis (answers “WHAT?”) Specifying what the application must do 2.
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
Refactoring Cristescu Marilena. Definitions Loose Usage: Reorganize a program(or something) As a noun: a change made to the internal structure of some.
1 Collaborative Programming: Pair Programming and Reviews and Maintenance and Refactoring CSE 403.
Week 7-10 MondayTuesdayWednesdayThursdayFriday Joel test & interviewing No reading GroupsReviewsSectionAspect-oriented design Progress report due Readings.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
CSE 403 Lecture 10 Code Reviews Reading: Code Complete, Steve McConnell slides created by Marty Stepp
17-Oct-15 Refactoring. 2 Refactoring is: restructuring (rearranging) code......in a series of small, semantics-preserving transformations (i.e. the code.
CSE403 ● Software engineering ● sp12 Week 7-10 MondayTuesdayWednesdayThursdayFriday Reading dueGroups Beta due SectionProgress report due Readings out.
Testing. 2 Overview Testing and debugging are important activities in software development. Techniques and tools are introduced. Material borrowed here.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
Code Reviews. Challenges of Large Code Base How to ensure… – Maintainable code? – DRY code? – Readable code? – Bug-free code? Average defect detection.
Chapter 12: Software Inspection Omar Meqdadi SE 3860 Lecture 12 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
1 CSC/ECE 517 Fall 2010 Lec. 3 Overview of Eclipse Lectures Lecture 2 “Lecture 0” Lecture 3 1.Overview 2.Installing and Running 3.Building and Running.
Software Engineering CS3003 Lecture 4 Code bad smells and refactoring.
REFACTORINGREFACTORING. Realities Code evolves substantially during development Requirements changes 1%-4% per month on a project Current methodologies.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Lecture 4 – XP and Agile 17/9/15. Plan-driven and agile development Plan-driven development A plan-driven approach to software engineering is based around.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Refactoring Mehdi Einali Advanced Programming in Java 1.
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
09 Mar 2007CSE403 Winter '07 What Happens after a Product Ships? Valentin Razmov (guest lecture) Special guest: Jim Bullock (Rare Bird Enterprises)
CSE 403 Lecture 25 Scheduling and Planning a Large Project Reading: The Mythical Man-Month, Ch. 2, by F. Brooks slides created by Marty Stepp
Refactoring Agile Development Project. Lecture roadmap Refactoring Some issues to address when coding.
1 CSE 403 Team Dynamics Reading: Rapid Development Ch. 13, Pragmatic Programmer Ch These lecture slides are copyright (C) Marty Stepp, 2007, with.
1 COS 260 DAY 12 Tony Gauvin. 2 Agenda Questions? 5 th Mini quiz –Chapter 5 40 min Assignment 3 Due Assignment 4 will be posted later (next week) –If.
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
Testing and Debugging. Testing Fundamentals  Test as you develop Easier to find bugs early rather than later Prototyping helps identify problems early.
Test Driven Development Introduction Issued date: 8/29/2007 Author: Nguyen Phuc Hai.
Welcome to Software Project Management. CONVENTIONAL SOFTWARE MANAGEMENT The BEST and WORST thing about software is its flexibility. 1.Software development.
09 Aug 2006CSE403 Summer'06 Lecture 19b Lecture 19: Software Quality (Part II) Valentin Razmov Conway’s Law: “The structure of a computer program reflects.
Extreme Software Engineering A Hands-On Approach From Extreme Software Engineering: A Hands-On Approach Daniel H. Steinberg Daniel W. Palmer.
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
CS 5150 Software Engineering Lecture 21 Reliability 2.
Verification and Validation
Chapter 18 Maintaining Information Systems
C++ coding standard suggestion… Separate reasoning from action, in every block. Hi, this talk is to suggest a rule (or guideline) to simplify C++ code.
Dilbert Scott Adams Manage It! Your Guide to Modern, Pragmatic Project Management. Johanna Rothman.
Refactoring and Code Smells
Objects First with Java
Design and Programming
Lecture 09:Software Testing
Improving the structure of existing code
Refactoring and Code Smells
Updated Schedule of Remaining Class-Related Deliverables
Applied Software Project Management
CSE 403 Scheduling These lecture slides are copyright (C) Marty Stepp, 2007, with significant content taken from slides written by Valentin Razmov. They.
Refactoring and Code Smells
Integration Reading: McConnell, Code Complete, Ch. 29
Refactoring and Code Smells
Presentation transcript:

1 CSE 403 Collaborative Programming: Pair Programming, Code Reviews, Walkthroughs and Maintenance and Refactoring These lecture slides are copyright (C) Marty Stepp, Significant content taken from CSE 403 slides by V. Rasmov. They may not be rehosted, sold, or modified without expressed permission from the authors. All rights reserved.

2 Pair programming pair programming: Programming. But with 2 people. take turns "driving", sharing one computer rotate pairs often pair people of different experience levels pros: Can produce better code. An inexperienced coder can learn from an experienced one. cons: It's just dreadful.

3 Code reviews code review: A required sign-off from another team member before a developer is permitted to check in changes or new code. Questions: Why? How? When? By whom?

4 Mechanics of code reviews when: When code author has finished a coherent system change that is otherwise ready for checkin change shouldn't be too large or too small before committing the code to the repository or incorporating it into the new build whom: Original developer and reviewer, sometimes together in person, sometimes offline. what: Reviewer gives suggestions for improvement on a logical and/or structural level, to conform to previously agreed upon set of quality standards. Feedback leads to refactoring, followed by a 2nd code review. Eventually reviewer approves code.

5 Motivation for code reviews why: Can catch ~60% of bugs, design flaws early. why: > 1 person has seen every piece of code. Prospect of someone reviewing your code raises quality threshold. why: Forces code authors to articulate their decisions and to participate in the discovery of flaws. why: Allows junior personnel to get early hands-on experience without hurting code quality Pairing them up with experienced developers why: Accountability. Both author and reviewer are accountable for allowing the code to be committed.

6 Code reviews in industry Code reviews are a very common industry practice. Made easier by advanced tools that: integrate with configuration management systems highlight changes (i.e., diff function) allow traversing back into history E.g.: Eclipse, SVN tools

7 Code review variations inspection: A more formalized code review with: roles (moderator, author, reviewer, scribe, etc.) several reviewers looking at the same piece of code a specific checklist of kinds of flaws to look for possibly focusing on flaws that have been seen previously possibly focusing on high-risk areas such as security specific expected outcomes (e.g. report, list of defects) walkthrough: informal discussion of code between author and a single reviewer code reading: Reviewers look at code by themselves (possibly with no actual meeting)

8 Comparison of reviews

9 Exercise public class Account { double principal,rate; int daysActive,accountType; public static final int STANDARD=0, BUDGET=1, PREMIUM=2, PREMIUM_PLUS=3; }... public static double calculateFee(Account[] accounts) { double totalFee = 0.0; Account account; for (int i=0;i<accounts.length;i++) { account=accounts[i]; if ( account.accountType == Account.PREMIUM || account.accountType == Account.PREMIUM_PLUS ) totalFee +=.0125 * ( // 1.25% broker's fee account.principal * Math.pow(account.rate* (account.daysActive/365.25)) - account.principal); // interest-principal } return totalFee; } "Code review" this checkin. What feedback would you give the author? What changes would you demand before checkin?

10 Improved code 1 // blah blah blah public class Account { private double principal; private double rate; private int daysActive; private Type type; // the various kinds of accounts our bank offers public enum Type {STANDARD, BUDGET, PREMIUM, PREMIUM_PLUS} // blah blah blah public double interest() { double years = daysActive / ; double compoundInterest = principal * Math.pow(rate * years); return compoundInterest – principal; } // blah blah blah public boolean isPremium() { return accountType == Type.PREMIUM || accountType == Type.PREMIUM_PLUS; }

11 Improved code 2 // blah blah blah public static double calculateFee(Account accounts[]) { double totalFee = 0.0; for (Account account : accounts) { if (account.isPremium()) { totalFee += BROKER_FEE_PERCENT * account.interest(); } return totalFee; } // blah blah blah public static final double BROKER_FEE_PERCENT = ; }

12 Refactoring

13 Problem: "Bit rot" After several months and new versions, many codebases reach one of the following states: rewritten: Nothing remains from the original code. abandoned: The original code is thrown out and rewritten from scratch. Why is this? Systems evolve to meet new needs and add new features If the code's structure does not also evolve, it will "rot" This can happen even if the code was initially reviewed and well-designed at the time of checkin

14 Code maintenance maintenance: Modification or repair of a software product after it has been delivered. Purposes: fix bugs improve performance improve design add features Studies have shown that ~80% of maintenance is for non-bug- fix-related activities such as adding functionality (Pigosky 1997)

15 Maintenance is hard It's harder to maintain (someone else's?) code than write your own new code. "house of cards" phenomenon (don't touch it!) must understand code written by another developer, or code you wrote at a different time with a different mindset most developers hate code maintenance Maintenance is how devs spend much of their time. It pays to design software well and plan ahead so that later maintenance will be less painful. Capacity for future change must be anticipated

16 Refactoring refactoring: Improving a piece of software's internal structure without altering its external behavior. Not the same as code rewriting Incurs a short-term time/work cost to reap long-term benefits A long-term investment in the overall quality of your system.

17 Why refactor? Why fix a part of your system that isn't broken? Each part of your system's code has 3 purposes: 1. to execute its functionality, 2. to allow change, 3. to communicate well to developers who read it. If the code does not do one or more of these, it is broken.

18 Some types of refactoring Refactoring to design patterns Renaming (methods, variables) Extracting code into a method Changing method signatures Performance optimization Naming (extracting) "magic" constants Extracting common functionality (including duplicate code) into a module/method/etc. Splitting one method into several to improve cohesion and readability (by reducing its size) Putting statements that semantically belong together near each other Exchanging risky language idioms with safer alternatives Clarifying a statement that has evolved over time or is unclear See also

19 IDE support for refactoring Eclipse / Visual Studio support: variable / method / class renaming method or constant extraction extraction of redundant code snippets method signature change extraction of an interface from a type method inlining providing warnings about method invocations with inconsistent parameters help with self-documenting code through auto-completion

20 Refactoring plan? When you identify an area of your system that: isn't especially well designed isn't especially thoroughly tested, but seems to work so far now needs new features to be added What should you do? Assume that you have adequate time to "do things right." (Not always a valid assumption in software...)

21 Recommended refactor plan When you identify an area of your system that: isn't especially well designed isn't especially thoroughly tested, but seems to work so far now needs new features to be added What should you do? Write unit tests that verify the code's external correctness. (They should pass on the current, badly designed code.) Refactor the code. (Some unit tests will break. Fix the bugs.) Add the new features.

22 "I don't have time to refactor!" Refactoring incurs an up-front cost. many developers don't want to do it most management don't like it, because they lose time and gain "nothing" (no new features) However... well-written code is much more conducive to rapid development (some estimates put ROI at 500% or more for well-done code) finishing refactoring increases programmer morale developers prefer working in a "clean house" When to refactor? best done continuously (like testing) as part of the SWE process hard to do well late in a project (like testing)

23 Should startups refactor? Many small companies and startups skip refactoring. "We're too small to need it!" "We can't afford it!" Reality: Refactoring is an investment in quality of the company's product and code base, often their prime assets Many web startups are using the most cutting-edge technologies, which evolve rapidly. So should the code If a key team member leaves (common in startups),... If a new team member joins (also common),...