lecture 4: validating your design

42
LECTURE 4: VALIDATING YOUR DESIGN MKT 101 – Introduction to Marketing Why should I learn about marketing? I’m in CSC to avoid this!

Upload: silas

Post on 22-Feb-2016

30 views

Category:

Documents


0 download

DESCRIPTION

Why should I learn about marketing ? I’m in CSC to avoid this!. MKT 101 – Introduction to Marketing. Lecture 4: VALIDATING Your Design. Today’s Goal. Learn to validate & fix designs before coding What matters in comments & how these can help - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Lecture 4: VALIDATING Your Design

LECTURE 4:VALIDATING YOUR DESIGN

MKT 101 – Introduction to Marketing

Why should I learn about

marketing?I’m in CSC to avoid

this!

Page 2: Lecture 4: VALIDATING Your Design

Today’s Goal

Learn to validate & fix designs before coding What matters in comments & how these

can help Techniques & tricks to avoid writing useless

code Javadoc v. regular comments: why have

both? Why both types of comments rely on

marketing Why is this vital for testing the proposed

solution?

Page 3: Lecture 4: VALIDATING Your Design

Today’s Goal

Learn to validate & fix designs before coding What matters in comments & how these

can help Techniques & tricks to avoid writing useless

code Javadoc v. regular comments: why have

both? Why both types of comments rely on

marketing Why is this vital for testing the proposed

solution?

Weeks of coding makes up for minutes of planning

Page 4: Lecture 4: VALIDATING Your Design

Time Required To Understand

Atte

ntio

n Pa

idHow My Homies Roll

Page 5: Lecture 4: VALIDATING Your Design

Already made#YouSuck

a trending topic

Time Required To Understand

Atte

ntio

n Pa

idHow My Homies Roll

Page 6: Lecture 4: VALIDATING Your Design

Reactions to Your Code

Time Spent

Use

r’s

Abili

ty

Passion Threshold

Suck Threshold

Page 7: Lecture 4: VALIDATING Your Design

Reactions to Your Code

Time Spent

Use

r’s

Abili

ty

Assembly Code

Java

Passion Threshold

Suck Threshold

Page 8: Lecture 4: VALIDATING Your Design

Reactions to Your Code

Time Spent

Use

r’s

Abili

ty

Assembly Code

Java

Passion Threshold

Suck Threshold

Page 9: Lecture 4: VALIDATING Your Design

Making people think is preying on their weakness Explicitly state details needed to use code

People will assume that everything has purpose Male nipples, appendix, Matt still talked

about If it serves no purpose, why would it be

created? Guessing game created from unused

parameters Don't make user probe what return value

means

Intuitive Is Key

Page 10: Lecture 4: VALIDATING Your Design

Making people think is preying on their weakness Explicitly state details needed to use code

People will assume that everything has purpose Male nipples, appendix, Matt still talked

about If it serves no purpose, why would it be

created? Guessing game created from unused

parameters Don't make user probe what return value

means

Intuitive Is Key

It returned 5.

What the $#&@#* does 5

mean?

Page 11: Lecture 4: VALIDATING Your Design

Making people think is preying on their weakness Explicitly state details needed to use code

People will assume that everything has purpose Male nipples, appendix, Matt still talked

about If it serves no purpose, why would it be

created? Guessing game created from unused

parameters Don't make user probe what return value

means

Intuitive Is Key

I DEFINITELY

need another drink…

Page 12: Lecture 4: VALIDATING Your Design

What To Do With Your Design

Move on to next step: write your javadoc Validate your thinking by forcing

communication Performs test that you are clear what

method does Team development easier, since method

use known If done well, will find helps develop 1st test

set

Page 13: Lecture 4: VALIDATING Your Design

What To Do With Your Design

Move on to next step: write your javadoc Validate your thinking by forcing

communication Performs test that you are clear what

method does Team development easier, since method

use known If done well, will find helps develop 1st test

set

Page 14: Lecture 4: VALIDATING Your Design

But We Cannot Document Yet!

Of course, do not yet know details such as… How method is coded or calls it makes Which of the class’s fields used within

method How it computes result to get return value Given an input, why specific algorithm used

javadoc does NOT need & should not include it You may (or should be asking yourself):

Why?

Page 15: Lecture 4: VALIDATING Your Design

Why Not Include Details?

You write code once… This is goal, idea is to solve problems not

write code Writing code is work & laziness means

minimizing this Once code bug free, do not want to look at

it again …but read comments often

If javadoc duplicates code, could just read code

Only provide what users need

Page 16: Lecture 4: VALIDATING Your Design

Why Not Include Details?

You write code once… This is goal, idea is to solve problems not

write code Writing code is work & laziness means

minimizing this Once code bug free, do not want to look at

it again …but read comments often

If javadoc duplicates code, could just read code

Only provide what users need

Page 17: Lecture 4: VALIDATING Your Design

What Should Comments Say?

javadoc works with design & does not repeat it For each class what instances do & where to

use What a method does & when it should be

called Given a methods actions, what method’s

results are Meaning of return values & any special

“magic” values For each real error: when exception will be

thrown How to call method including examples

(with return)

Page 18: Lecture 4: VALIDATING Your Design

Good javadoc

/** * Perform the basic work needed when a button is * pushed. This will illuminate the light in the * button. The first time a button is hit it will * also send a message to the elevator controller. */public void pushButton() { /* Code goes here… */ }

Page 19: Lecture 4: VALIDATING Your Design

How Does javadoc Test Design? What if do not know enough to write javadoc? Can you write code you cannot describe

what it does?

Page 20: Lecture 4: VALIDATING Your Design

How Does javadoc Test Design? What if do not know enough to write javadoc? Can you write code you cannot describe

what it does?Hint:

Page 21: Lecture 4: VALIDATING Your Design

How Does javadoc Test Design? What if do not know enough to write javadoc? Can you write code you cannot describe

what it does?Hint:

YourDesignSucks

DonkeyBalls

Page 22: Lecture 4: VALIDATING Your Design

Is This Method Really Usable?

Page 23: Lecture 4: VALIDATING Your Design

Is This Method Really Usable?

Page 24: Lecture 4: VALIDATING Your Design

What is the Goal Again?

Javadoc != Java and should not be confused If comments are good, easier to understand

than Java Only details users need to use method or

class For this to work must make sell its simplicity Show important connections to well-known

examples@see class @see #method @see class#method Explicitly state any "magic" param or return

values Provide examples to clarify how it will work

Page 25: Lecture 4: VALIDATING Your Design

Now This I Can Use

Page 26: Lecture 4: VALIDATING Your Design

Now This I Can Use

Page 27: Lecture 4: VALIDATING Your Design

Now This I Can Use

Page 28: Lecture 4: VALIDATING Your Design

Other Details To Describe

State all assumptions to prevent future bugs When calling this method, what else will

happen?

Page 29: Lecture 4: VALIDATING Your Design

Other Details To Describe

State all assumptions to prevent future bugs When calling this method, what else will

happen? Any assumptions upon which method relies

Page 30: Lecture 4: VALIDATING Your Design

Other Details To Describe

State all assumptions to prevent future bugs When calling this method, what else will

happen? Any assumptions upon which method relies Once method completes, details needed for

later

Page 31: Lecture 4: VALIDATING Your Design

Programming By Contract

Precondition true at start when method called Ensuring these met responsibility of calling

method Postconditions true at end of the

method call Guaranteeing this responsibility of called

method Only if preconditions met must this

happen, however

Page 32: Lecture 4: VALIDATING Your Design

Programming By Contract

Precondition true at start when method called Ensuring these met responsibility of calling

method Postconditions true at end of the

method call Guaranteeing this responsibility of called

method Only if preconditions met must this

happen, however

Page 33: Lecture 4: VALIDATING Your Design

Good Javadoc Example

/** * Perform the basic work needed when a button is * pushed. This will illuminate the light in the * button. The first time a button is hit it will * also send a message to the elevator controller.<br/> * * Precondition: lit.isOff(); controller is set<br/> * * Postcondition: !lit.isOff() && * request sent to elevator controller */public void pushButton() { }

Page 34: Lecture 4: VALIDATING Your Design

What's Next?

Could start to write code at this point in project But doing this means still may find many

bugs Fixing these hard if calling many other

methods Ideal if we could 1st check that method

actually works Remember key trait of successful

programmers

Page 35: Lecture 4: VALIDATING Your Design

Successful Programmers

Could start to write code at this point in project But doing this means still may find many

bugs Fixing these hard if calling many other

methods Ideal if we could 1st check that method

actually works Remember key trait of successful

programmers

Page 36: Lecture 4: VALIDATING Your Design

Outlining a Method

Write pseudocode outline of how method works Can be written assuming other methods

they work Can ignore coding details, so simpler &

easier to write Once done writing, tests check

algorithm works Fix errors BEFORE coding to limit

debugging needs Can then make the algorithm into

comments Check code against comment, since that

passed tests Plain English description makes reading

code easier

Page 37: Lecture 4: VALIDATING Your Design

Outlining a Method

How to write algorithm: what details important? Can skip punctuation of any sort: this is

not code Should include major loops, but can write in

English Important to translate: each action to take

is explicit Can write “swap values” or group

assignments Using shorthand fine, but translation to

code clear

Page 38: Lecture 4: VALIDATING Your Design

Pseudocode Needs More Detail

Page 39: Lecture 4: VALIDATING Your Design

Pseudocode Needs Less Detail

Page 40: Lecture 4: VALIDATING Your Design

Heated Handlebars

Page 41: Lecture 4: VALIDATING Your Design

Heated Handlebars

Page 42: Lecture 4: VALIDATING Your Design

For Next Lecture

Week #2 homework available on Angel page Due by 5:00PM Tuesday Submit assignment via e-mail & (possibly)

paper Reading for Friday linked to from Angel

schedule Discuss range of possible tests to perform How often to test code as we are writing it Present methods of handling failed test