Software Development Cross Solution - Index of - Free

More documents

Recommendations

Info

apply other techniques Figure out what dependencies this code has and if it has any impact on Orion’s Orbits’ code. 408 Chapter 11 Back to the magnets we didn’t use on page 391. Would you do any of these activities now? Why? Any others you might add that aren’t on this list? Figure out how to package the compiled version to include in Orion’s Orbits. Document the code. Run a coverage report to see how much code you need to fix. Get a line count of the code and estimate how long it will take to fix. Do a security audit on the code. Use a UML tool to reverse-engineer the code and create class diagrams. Download at WoweBook.Com Would you do this now? Why? Maybe. It’s possible that some kind of library conflict is behind one of our bugs. You’re going to need to figure this out to get everything working by the end of the iteration anyway. Would you do this now? Why? Only if the current packaging approach isn’t going to cut it. This is basically refactoring at the packaging level. If things are working and it’s maintainable, you should probably skip this. Would you do this now? Why? Absolutely! Every file you touch should come out of your cleanup with clear documentation. At a minimum, explain the code you’ve touched while fixing a bug. Would you do this now? Why? Probably. You now have a set of tests that scope how much of the system you need. This will give you an idea of how much of the overall code base you actually use, which is a useful metric. Would you do this now? Why? Nope. Still not a terribly useful measure. Who cares how big a code base is, except as to how it relates to the functionality you need to get working? Would you do this now? Why? Yes. Any code that gets touched with your tests should be checked for security issues. If you can fix any problems as part of getting your test to pass, go for it. If not, capture it and prioritize it in a later iteration. Would you do this now? Why? Maybe—it depends on how complicated the code is. If you’re having trouble figuring out what a block of code is trying to do, this might help you get your head around it.
Q: I noticed that the bug fixing tasks on page 406 both had estimates. Where did those estimates come from? A: Good catch! Bug fixing tasks are just like any other type of task; they need an estimate, and there are a number of ways that you can come up with that. You can derive the estimate, dividing the total amount of days you’ve calculated evenly by the number of bugs to fix, or you can play planning poker with your team. Whichever approach you take, your total planned tasks for bug fixes must never be greater than the number of days calculated from your spike test. Q: When fixing bugs, how much time should I spend on cleaning up other problems I notice, or just generally cleaning up the code? A: This is a tough call. It would be great to fix every bug or problem you see, but then you’ll likely finish all your tasks late or, worse, end up refactoring your code indefinitely. The best guideline is to get the code into a working, pretty decent state, within the time allotted for your bug fixing task, and then move on to the next task. First priority is to get the code working; second is to make it as easily readable and understandable as possible so that bugs are not accidentally introduced in the future. If there are problems you found but couldn’t get to, file them as new bugs and prioritize them into a later iteration. Q: What did that five-day spike test period do to our iteration length? A: Right now, we’re getting ready for the next iteration so we’re between iterations. If there’s a master schedule, the five days needs to be accounted for there, but in terms of iteration time, it’s basically off the clock. After you get your board sorted out and everything approved by the customer, though, you should kick off a normal iteration. If you’re forced to do a spike test in the middle of an iteration, that’s a case where it’s probably OK to slip the iteration end date by a week, assuming nearly everyone is participating. If only a small number of developers are participating in the spike test and everyone else is continuing the iteration, you probably want to drop that five days’ worth of other work from the iteration, but still end on time. Remember, this is five days per person, not five days total. Download at WoweBook.Com bugs Q: You said try and get code into a “pretty decent” state. What does that really mean? A: This is really a judgment call, and in fact this is where you get into the aesthetics of code, which is a whole book on its own. However there are some rules of thumb that can help you decide when your code is good enough and you can move on. First, the code must work according to your tests. Those tests must exercise your code thoroughly, and you should feel very confident that the code works as it should. Secondly, your code should be readable. Do you have cryptic variable names? Do the lines of code read like Sanskrit? Are you using too much complicated syntax just because you can? These are all huge warning signs that your code needs to be improved in readability. And finally, you should be proud of your code. When your code is correct and easily readable by another developer, then you’ve really done your job. It doesn’t have to be perfect, but “pretty decent” starts with your code doing what it should and ends with it being readable. Q: This sounds like the same approach as the perfect-versusgood-enough design stuff we talked about earlier, right? A: Yes, it’s based on exactly the same principle. Just as you can spend hours improving a design, trying to reach perfection, you can waste exactly the same time in your coding. Don’t fall into the trap of perfection. If you achieve it, then that’s great, but what you’re aiming for is code that does what it should, and that can be read and understood by others. Do that, and you’re coding like a pro. Beautiful code is nice, but tested and readable code is delivered on time. you are here 4 409
Page 2 and 3:
Download at WoweBook.Com
Page 4 and 5:
Praise for Head First Object-Orient
Page 6 and 7:
Other related books from O’Reilly
Page 8 and 9:
Head First Software Development by
Page 10 and 11:
the authors Author(s) of Head First
Page 12 and 13:
table of contents x 1 If The Goal g
Page 14 and 15:
table of contents xii 3 project pla
Page 16 and 17:
table of contents xiv 5 good-enough
Page 18 and 19:
table of contents xvi 6 / It buildi
Page 20 and 21:
table of contents xviii 8 Sometimes
Page 22 and 23:
table of contents xx 10 Think the n
Page 24 and 25:
table of contents xxii 12 You’ve
Page 26 and 27:
table of contents xxiv ii appendix
Page 28 and 29:
how to use this book Who is this bo
Page 30 and 31:
how to use this book xxviii intro W
Page 32 and 33:
how to use this book Here’s what
Page 34 and 35:
how to use this book Read Me This i
Page 36 and 37:
the review team The technical revie
Page 38 and 39:
safari books online Safari® Books
Page 40 and 41:
Tom’s Trails Tom’s Trails is go
Page 42 and 43:
the Big Bang approach The Big Bang
Page 44 and 45:
the Big Bang ends with a big mess B
Page 46 and 47:
great software development is... 8
Page 48 and 49:
delivering with iteration Getting t
Page 50 and 51:
an iteration delivers working softw
Page 52 and 53:
an iteration is a complete developm
Page 54 and 55:
uild a plan out of iterations and f
Page 56 and 57:
deciding on a iteration tempo for y
Page 58 and 59:
change happens The customer WILL ch
Page 60 and 61:
handle change with iteration Iterat
Page 62 and 63:
use the right process for you The r
Page 64 and 65:
CHAPTER 1 your software development
Page 66 and 67:
exercise solutions 28 Chapter 1 1 P
Page 68 and 69:
orion’s orbits Orion’s Orbits i
Page 70 and 71:
equirements start with customer ide
Page 72 and 73:
capturing what’s in your customer
Page 74 and 75:
getting more with role playing and
Page 76 and 77:
customer-oriented requirements Our
Page 78 and 79:
keep your customer in the loop Q: W
Page 80 and 81:
user stories capture what your soft
Page 82 and 83:
estimates come with assumptions 44
Page 84 and 85:
assumptions kill confidence in your
Page 86 and 87:
highlighting assumptions and obtain
Page 88 and 89:
assumptions are killed or become ri
Page 90 and 91:
use your customer effectively 52 Ch
Page 92 and 93:
keep estimates small A BIG user sto
Page 94 and 95:
aim for estimates you and your team
Page 96 and 97:
your estimates are your promise Q:
Page 98 and 99:
develop your estimates cyclically T
Page 100 and 101:
sum your estimates to find out your
Page 102 and 103:
when your project is too long 64 Ch
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
deliver what you can, when it’s n
Page 110 and 111:
priorities come from your customer
Page 112 and 113:
Title: Description: Est: Title: 15
Page 114 and 115:
factoring in team performance 76 Ch
Page 116 and 117:
uilding achievable milestones Work
Page 118 and 119:
your customer decides priority Titl
Page 120 and 121:
milestone = paid, iteration = on tr
Page 122 and 123:
continuously buildable and runnable
Page 124 and 125:
inging reality to your plan 86 Chap
Page 126 and 127:
velocity applies your real performa
Page 128 and 129:
from ideal to real estimates Progra
Page 130 and 131:
confidence comes at a price When is
Page 132 and 133:
iterations with velocity The maximu
Page 134 and 135:
eality means being honest Title: Es
Page 136 and 137:
eaking realistic but bad news Manag
Page 138 and 139:
introducing the big board The Big B
Page 140 and 141:
happiness is a project that can be
Page 142 and 143:
performance and burn down Work left
Page 144 and 145:
Page 146 and 147:
Page 148 and 149:
introducing iSwoon Introducing iSwo
Page 150 and 151:
eak up user stories into tasks Task
Page 152 and 153:
tasks have estimates Your task desc
Page 154 and 155:
tasks on your board Add your tasks
Page 156 and 157:
moving tasks to in progress Start w
Page 158 and 159:
multiple tasks at the same time Wha
Page 160 and 161:
keep communication flowing with dai
Page 162 and 163:
doing your first task Task 1: Creat
Page 164 and 165:
inging your design to life with a s
Page 166 and 167:
exercise solution The date is asked
Page 168 and 169:
monitoring your progress Standup me
Page 170 and 171:
updating your project board 132 Cha
Page 172 and 173:
updating your project board 134 Cha
Page 174 and 175:
into the second week Standup meetin
Page 176 and 177:
detecting problems with the design
Page 178 and 179:
surprises... 140 Chapter 4 We inter
Page 180 and 181:
dealing with unplanned tasks If the
Page 182 and 183:
velocity doesn’t account for surp
Page 184 and 185:
you know where you are We have a lo
Page 186 and 187:
meet velocity Head First: Welcome,
Page 188 and 189:
inging iSwoon under control iSwoon
Page 190 and 191:
detecting bad design ...you needed
Page 192 and 193:
design refactoring The Date class c
Page 194 and 195:
srp analysis Spotting multiple resp
Page 196 and 197:
single responsibility It makes sens
Page 198 and 199:
don’t repeat yourself Your design
Page 200 and 201:
efactoring iSwoon’s design A date
Page 202 and 203:
standup meeting The post-refactorin
Page 204 and 205:
unplanned work Unplanned tasks are
Page 206 and 207:
good-enough delivers “Good Enough
Page 208 and 209:
end of iteration board When everyth
Page 210 and 211:
exercises 172 Chapter 5 Take each o
Page 212 and 213:
exercise solutions Unplanned tasks
Page 214 and 215:
Page 216 and 217:
introducing beatbox pro You’ve go
Page 218 and 219:
digging into code Here’s the code
Page 220 and 221:
finish the story And now the GUI wo
Page 222 and 223:
merging changes And Bob does the sa
Page 224 and 225:
disaster recovery What went wrong?
Page 226 and 227:
version control in action Let’s s
Page 228 and 229:
1 2 creating a repository First set
Page 230 and 231:
merging changes Most version contro
Page 232 and 233:
identifying conflicts If your softw
Page 234 and 235:
esolving conflicts Make these chang
Page 236 and 237:
dealing with older code More iterat
Page 238 and 239:
dealing with multiple releases We h
Page 240 and 241:
viewing logs Good commit messages m
Page 242 and 243:
tagging revisions (Emergency) stand
Page 244 and 245:
anches and tags 1 Use the mkdir com
Page 246 and 247:
working with branches Fixing Versio
Page 248 and 249:
anches, tags, and subversion Q: I
Page 250 and 251:
avoiding unnecessary branches When
Page 252 and 253:
214 Chapter 6 What version control
Page 254 and 255:
CHAPTER 6 Development Techniques Us
Page 256 and 257:
Page 258 and 259:
uilding buildable software Develope
Page 260 and 261:
introducing ant Ant: a build tool f
Page 262 and 263:
more exercises 224 Chapter 6 ½ Are
Page 264 and 265:
a full build script The javac task
Page 266 and 267:
habits of good build scripts Good b
Page 268 and 269:
even more build script tricks Good
Page 270 and 271:
version control your build script Y
Page 272 and 273:
CHAPTER 6 1/2 Development Technique
Page 274 and 275:
it never rains but it pours Things
Page 276 and 277:
lack box testing There are three wa
Page 278 and 279:
grey box testing Grey-box testing g
Page 280 and 281:
white box testing was Below is a us
Page 282 and 283:
testing functionality BeatB These s
Page 284 and 285:
you create tests test for establish
Page 286 and 287:
one-click testing Testing EVERYTHIN
Page 288 and 289:
making the most of a framework Auto
Page 290 and 291:
continuous integration For you and
Page 292 and 293:
setting up continuous integration A
Page 294 and 295:
tests only cover what you tell them
Page 296 and 297:
tested code is completed code } 258
Page 298 and 299:
putting code to the test 260 Chapte
Page 300 and 301:
100% coverage All three of these te
Page 302 and 303:
using a coverage report Testing all
Page 304 and 305:
the cost of testing Q: How do cover
Page 306 and 307:
is 100% coverage efficient? 268 Cha
Page 308 and 309:
an environment for testing 270 Chap
Page 310 and 311:
exercise solutions 272 Chapter 7 Te
Page 312 and 313:
Page 314 and 315:
test before code Test FIRST, not la
Page 316 and 317:
unit testing Your first test... The
Page 318 and 319:
green means pass Get your tests to
Page 320 and 321:
testing a user story’s functional
Page 322 and 323:
implement a test in code import org
Page 324 and 325:
drive your code with TDD In TDD, te
Page 326 and 327:
task done when tests pass Completin
Page 328 and 329:
first fail Red: write (failing) tes
Page 330 and 331:
keep it simple You can just make up
Page 332 and 333:
simple code is testable code Always
Page 334 and 335:
switching to test code with the str
Page 336 and 337:
where to place your test code Remem
Page 338 and 339:
etter code through testing Testing
Page 340 and 341:
tests = code and lots of it More te
Page 342 and 343:
mock objects We need lots of differ
Page 344 and 345:
using a mock object framework Mock
Page 346 and 347:
why mock objects? Q: These mock obj
Page 348 and 349:
all green, you’re done It’s not
Page 350 and 351:
test, red, code, green A day in the
Page 352 and 353:
Page 354 and 355:
Page 356 and 357:
esults from an iteration Your itera
Page 358 and 359:
daily standup meetings Standup Meet
Page 360 and 361:
urn-down analysis 322 Chapter 9 Bef
Page 362 and 363:
system testing System testing MUST
Page 364 and 365:
incorporating system testing System
Page 366 and 367:
issues with test iterations More it
Page 368 and 369:
enabling communication 330 Chapter
Page 370 and 371:
This is usually called acceptance t
Page 372 and 373:
filing and fixing a bug The life (a
Page 374 and 375:
ug trackers So you found a bug....
Page 376 and 377:
learn from your iteration But there
Page 378 and 379:
different project hurdles 340 Chapt
Page 380 and 381:
iteration reviews Time for the iter
Page 382 and 383:
other things to do A GENERAL priori
Page 384 and 385:
CHAPTER 9 346 Chapter 9 Tools for y
Page 386 and 387:
crossword solution 13 B 1 S Iterati
Page 388 and 389:
an iteration finishes with more tha
Page 390 and 391:
planning the next iteration You nee
Page 392 and 393:
uilding your board for the next ite
Page 394 and 395:
uilding your board for the next ite
Page 396 and 397: factoring in real velocity Q: A tea
Page 398 and 399: the customer still rules And it’s
Page 400 and 401: it’s still software Someone else
Page 402 and 403: integration tasks on your board Tit
Page 404 and 405: integrating third-party code How yo
Page 406 and 407: euse means trust too //... 368 Chap
Page 408 and 409: when reuse lets you down Testing yo
Page 410 and 411: trust no one Standup meeting 372 Ch
Page 412 and 413: looking for problems in reused sour
Page 414 and 415: finding problems in reused source c
Page 416 and 417: your process deals with it You with
Page 418 and 419: oken code happens � � � � Q
Page 420 and 421: exercise solutions 2 R 1 R 3 E S P
Page 422 and 423: At the end of the last chapter, thi
Page 424 and 425: always communicate First, you’ve
Page 426 and 427: prioritize what you do 388 Chapter
Page 428 and 429: ump some things for later 390 Chapt
Page 430 and 431: apply your process Priority one: ge
Page 432 and 433: focus on functionality We could fix
Page 434 and 435: test for bugs Figure out what funct
Page 436 and 437: think about estimating Even though
Page 438 and 439: spike tests Spike test to estimate
Page 440 and 441: estimate what’s left What do the
Page 442 and 443: factor in confidence Your team’s
Page 444 and 445: always communicate Give your custom
Page 448 and 449: successful deliveries matter Things
Page 450 and 451: functionality wins most importantly
Page 452 and 453: CHAPTER 11 414 Chapter 11 Tools for
Page 454 and 455: crossword solution 10 F 15 H 5 P Bu
Page 456 and 457: software process defined Pinning do
Page 458 and 459: evaluate everything The big board 4
Page 460 and 461: ensure changes improve things The b
Page 462 and 463: formalize if necessary Formal attir
Page 464 and 465: other resources Some additional res
Page 466 and 467: CHAPTER 12 428 Chapter 12 Tools for
Page 468 and 469: exercise solutions 4 S 11 P 14 A So
Page 470 and 471: Download at WoweBook.Com
Page 472 and 473: uml and class diagrams #1. UML clas
Page 474 and 475: sequence diagrams #2. Sequence diag
Page 476 and 477: user stories and use cases #3. User
Page 478 and 479: system testing vs. unit testing #4.
Page 482 and 483: CHAPTER 1 development techniques CH
Page 484 and 485: development principles Deliver soft
Page 488 and 489: the index building projects (contin
Page 490 and 491: the index H Head First Java BeatBox
Page 492 and 493: the index No Dumb Questions (contin
Page 494 and 495: the index singularly focused 152 so
Page 496 and 497:
the index third-party code bugs in
show all

Software Development Cross Solution - Index of - Free

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?