Efnisyfirlit

• Dedication
• A Note Regarding Supplemental Files
• Advance Praise for Head First Software Development
• Praise for Head First Object-Oriented Analysis and Design
• Praise for Head First Design Patterns
•  
• Author(s) of Head First Software Development
• How to use this Book: Intro
• Who is this book for?
• Who should probably back away from this book?
• We know what you’re thinking
• We know what your brain is thinking
• Metacognition: thinking about thinking
• Here’s what WE did
• Here’s what YOU can do to bend your brain into submission
• Read Me
• The technical review team
• Acknowledgments
• Safari® Books Online
• 1. Great Software Development: Pleasing your customer
• Tom’s Trails is going online
• Most projects have two major concerns
• How much will it cost?
• How long will it take?
• The Big Bang approach to development
• Flash forward: two weeks later
• Big bang development usually ends up in a BIG MESS
• If your customer isn’t happy, you built the wrong software
• Great software development is…
• Getting to the goal with ITERATION
• Each iteration is a mini-project
• Each iteration is QUALITY software
• The customer WILL change things up
• It’s up to you to make adjustments
• You’re already a long way into development…
• … and you’ve still got other features to build…
• … and the deadline hasn’t changed.
• Iteration handles change automatically (well, sort of)
• Your software isn’t complete until it’s been RELEASED
• Tools for your Software Development Toolbox
• 2. Gathering Requirements: Knowing what the customer wants
• Orion’s Orbits is modernizing
• Talk to your customer to get MORE information
• Bluesky with your customer
• Sometimes your bluesky session looks like this…
• Find out what people REALLY do
• Your requirements must be CUSTOMER-oriented
• Develop your requirements with customer feedback
• User stories define the WHAT of your project… estimates define the WHEN
• Cubicle conversation
• Playing planning poker
• Put assumptions on trial for their lives
• A BIG user story estimate is a BAD user story estimate
• The goal is convergence
• How close is “close enough”?
• The requirement to estimate iteration cycle
• Finally, you’re ready to estimate the whole project…
• And the total project estimate is…
• Tools for your Software Development Toolbox
• 3. Project Planning: Planning for success
• Customers want their software NOW!
• Prioritize with the customer
• What is “Milestone 1.0”?
• We know what’s in Milestone 1.0 (well, maybe)
• Sanity-check your Milestone 1.0 estimate
• If the features don’t fit, reprioritize
• More people sometimes means diminishing returns
• Work your way to a reasonable Milestone 1.0
• Iterations should be short and sweet
• Comparing your plan to reality
• Velocity accounts for overhead in your estimates
• Programmers think in UTOPIAN days…
• Here’s what a programmer SAYS…
• … but here’s what he’s really THINKING
• Developers think in REAL-WORLD days…
• When is your iteration too long?
• Deal with velocity BEFORE you break into iterations
• Time to make an evaluation
• Deliver the bad news to the customer
• Managing pissed off customers
• The Big Board on your wall
• How to ruin your team’s lives
• Tools for your Software Development Toolbox
• 4. User Stories and Tasks: Getting to the real work
• Introducing iSwoon
• Do your tasks add up?
• Plot just the work you have left
• Add your tasks to your board
• Start working on your tasks
• A task is only in progress when it’s IN PROGRESS
• What if I’m working on two things at once?
• Your first standup meeting…
• Task 1: Create the Date class
• Standup meeting: Day 5, end of Week 1…
• Standup meeting: Day 2, Week 2…
• You have to track unplanned tasks
• Unexpected tasks raise your burn-down rate
• Velocity helps, but…
• We originally calculated velocity as…
• So we have this much “float”…
• … but it may not be enough!
• We have a lot to do…
• You’ve got more work to do…
• …and your burn-down rate is going in the wrong direction.
• …but we know EXACTLY where we stand
• 5. Good-Enough Design: Getting it done with great design
• iSwoon is in serious trouble…
• This design breaks the single responsibility principle
• Spotting multiple responsibilies in your design
• Going from multiple responsibilies to a single responsibility
• Your design should obey the SRP, but also be DRY…
• The post-refactoring standup meeting…
• Unplanned tasks are still just tasks
• Part of your task is the demo itself
• When everything’s complete, the iteration’s done
• 6. Version Control: Defensive development
• You’ve got a new contract—BeatBox Pro
• And now the GUI work…
• And a quick test…
• And Bob does the same…
• Demo the new BeatBox for the customer
• Standup meeting
• Let’s start with VERSION CONTROL
• First set up your project…
• …then you can check code in and out.
• Most version control tools will try and solve problems for you
• Bob tries to check in his code…
• … but quickly runs into a problem.
• The server tries to MERGE your changes
• Nonconflicting code and methods are easy
• Your version control software will combine files
• But conflicting code IS a problem
• If your software can’t merge the changes, it issues a conflict
• Now show the customer…
• More iterations, more stories…
• Standup meeting
• We have more than one version of our software…
• Good commit messages make finding older software easier
• Play “Find the features” with the log messages
• Now you can check out Version 1.0
• (Emergency) standup meeting
• Tag your versions
• So what?
• Tags, branches, and trunks, oh my!
• Fixing Version 1.0…for real this time.
• We have TWO code bases now
• When NOT to branch…
• Branch when…
• Do not branch when…
• We fixed ersion 1…
• … and Bob finished ersion 2.0 (so he says)
• Version control can’t make sure your code actually works…
• Tools for your Software Development Toolbox
• 6 ½. Building your Code: Insert tab a into slot b…
• Developers aren’t mind readers
• Building your project in one step
• Ant: a build tool for Java projects
• Projects, properties, targets, tasks
• Good build scripts…
• … generate documentation
• … compile your project
• … clean up the mess they make
• Good build scripts go BEYOND the basics
• Your build script is code, too
• New developer, take two
• Tools for your Software Development Toolbox
• 7. Testing and Continuous Integration: Things fall apart
• Things will ALWAYS go wrong…
• Standup meeting
• There are three ways to look at your system…
• Your users see the system from the outside
• Testers peek under the covers a little
• Developers let it all hang out
• … and you need to consider each of these views
• Black-box testing focuses on INPUT and OUTPUT
• Grey-box testing gets you CLOSER to the code
• Grey-box testing is like black-box testing…but you can peek
• White-box testing uses inside knowledge
• White-box tests tend to be code-on-code
• Hanging your tests on a framework
• Testing EVERYTHING with one step
• Automate your tests with a testing framework
• Use your framework to run your tests
• Continuous integration tools run your tests when you check in your code
• At the wheel of CI with CruiseControl
• Testing guarantees things will work… right?
• Standup meeting
• Testing all your code means testing EVERY BRANCH
• Use a coverage report to see what’s covered
• Getting good coverage isn’t always easy…
• Standup meeting
• Tools for your Software Development Toolbox
• 8. Test-Driven Development: Holding your code accountable
• Test FIRST, not last
• So we’re going to test FIRST…
• Analyze the task
• Write the test BEFORE any other code
• Welcome to test-driven development
• Your first test…
• … fails miserably.
• NOW write code to get the test to pass.
• Get your tests to GREEN
• Red, green, refactor…
• In TDD, tests DRIVE your implementation
• Completing a task means you’ve got all the tests you need, and they all pass
• When your tests pass, move on!
• Different task, same process
• Red: write (failing) tests
• Green: write code to pass tests
• Simplicity means avoiding dependencies
• Always write testable code
• When things get hard to test, examine your design
• The strategy pattern provides for multiple implementations of a single interface
• Keep your test code with your tests
• Testing produces better code
• More tests always means lots more code
• Strategy patterns, loose couplings, object stand ins…
• We need lots of different, but similar, objects
• What if we generated objects?
• A mock object stands in for real objects
• Mock objects are working object stand-ins
• Good software is testable…
• A whole-lotta-nuthin’
• It’s still me…
• Ghosts from the past
• It’s not easy bein’ green…
• When all of your tests pass, you’re done
• A day in the life of a test-driven developer…
• Tools for your Software Development Toolbox
• 9. Ending an Iteration: It’s all coming together…
• Your iteration is just about complete…
• … but there’s lots left you could do
• Standup Meeting
• System testing MUST be done…
• … but WHO does system testing?
• Developer testing
• Tester testing
• System testing depends on a complete system to test
• Good system testing requires TWO iteration cycles
• More iterations means more problems
• The life (and death) of a bug
• So you found a bug….
• Bugs belong in a bug tracker
• Anatomy of a bug report
• But there’s still plenty left you COULD do…
• Time for the iteration review
• Elements of an iteration review
• Some iteration review questions
• A GENERAL priority list for getting EXTRA things done…
• Tools for your Software Development Toolbox
• 10. The Next Iteration: If it ain’t broke… you still better fix it
• What is working software?
• …completing your iteration’s work
• …passing all your tests
• … satisfying your customer
• You need to plan for the next iteration
• Velocity accounts for… the REAL WORLD
• And it’s STILL about the customer
• Someone else’s software is STILL just software
• Customer approval? Check!
• Testing your code
• Houston, we really do have a problem…
• Standup meeting
• Trust NO ONE
• You without your process
• You with your process
• 11. Bugs: Squashing bugs like a pro
• First, you’ve got to talk to the customer
• Standup meeting
• Priority one: get things buildable
• We could fix code…
• … but we need to fix functionality
• Figure out what functionality works
• NOW you know what’s not working
• Spike test to estimate
• What do the spike test results tell you?
• You can then figure out how long it will take for your team to fix all the bugs
• Your team’s gut feeling matters
• Feed confidence into your estimate
• Give your customer the bug fix estimate
• Things are looking good…
• … and you finish the iteration successfully!
• AND most importantly the customer is happy
• Tools for your Software Development Toolbox
• 12. The Real World: Having a process in life
• Pinning down a software development process
• There is no silver-bullet process
• A good process delivers good software
• Formal attire required…
• Do what you’re doing…just prettier
• Some additional resources…
• More knowledge == better process
• Tools for your Software Development Toolbox
• It’s time to leave a mark on the board world!
• A. Leftovers: The top 5 topics (we didn’t cover)
• #1. UML class diagrams
• Class diagrams show relationships
• #2. Sequence diagrams
• #3. User stories and use cases
• #4. System tests vs. unit tests
• #5. Refactoring
• B. Techniques and Principles: Tools for the experienced software developer
• Index
• About the Authors
• Copyright