Code Leader : Using People, Tools, and Processes to Build Successful Software

by Cauldwell, Patrick; Hanselman, Scott

• ISBN13: 9780470259245
• ISBN10: 0470259248
• Edition: 1st
• Format: Paperback
• Copyright: 2008-05-05
• Publisher: Wrox

Summary

This book is for the career developer who wants to take his or her skill set and/or project to the next level. If you are a professional software developer with 34 years of experience looking to bring a higher level of discipline to your project, or to learn the skills that will help you transition from software engineer to technical lead, then this book is for you. The topics covered in this book will help you focus on delivering software at a higher quality and lower cost. The book is about practical techniques and practices that will help you and your team realize those goals.This book is for the developer understands that the business of software is, first and foremost, business. Writing code is fun, but writing high-quality code on time and at the lowest possible cost is what makes a software project successful. A team lead or architect who wants to succeed must keep that in mind.Given that target audience, this book assumes a certain level of skill at reading code in one or more languages, and basic familiarity with building and testing software projects. It also assumes that you have at least a basic understanding of the software development lifecycle, and how requirements from customers become testable software projects.Who This Book Is Not For: This is not a book for the entry-level developer fresh out of college, or for those just getting started as professional coders. It isn't a book about writing code; it's a book about how we write code together while keeping quality up and costs down. It is not for those who want to learn to write more efficient or literate code. There are plenty of other books available on those subjects, as mentioned previously.This is also not a book about project management or development methodology. All of the strategies and techniques presented here are just as applicable to waterfall projects as they are to those employing Agile methodologies. While certain strategies such as Test-Driven Development and Continuous Integration have risen to popularity hand in hand with Agile development methodologies, there is no coupling between them. There are plenty of projects run using SCRUM that do not use TDD, and there are just as many waterfall projects that do.Philosophy versus Practicality: There are a lot of religious arguments in software development. Exceptions versus result codes, strongly typed versus dynamic languages, and where to put your curly braces are just a few examples. This book tried to steer clear of those arguments here. Most of the chapters in this book deal with practical steps that you as a developer can take to improve your skills and improve the state of your project. The author makes no claims that these practices represent the way to write software. They represent strategies that have worked well for the author and other developers that he have worked closely with.Philosophy certainly has its place in software development. Much of the current thinking in project management has been influenced by the Agile philosophy, for example. The next wave may be influenced by the Lean methodologies developed by Toyota for building automobiles. Because it represents a philosophy, the Lean process model can be applied to building software just as easily as to building cars. On the other hand, because they exist at the philosophical level, such methodologies can be difficult to conceptualize. The book tries to favor the practical over the philosophical, the concrete over the theoretical. This should be the kind of book that you can pick up, read one chapter of, and go away with some practical changes you can make to your software project that will make it better.That said, the first part of this book is entitled "Philosophy" because the strategies described in it represent ways of approach

Author Biography

Patrick Cauldwell somehow found his way to a career in software despite earning a bachelor’s degree in East Asian Studies. From a work-study job in the student computer lab at college through early jobs in quality assurance and localization, and finally into full-time software engineering, Patrick has always been interested in what makes computers tick. He’s worked in a wide range of software operations, from very large projects at Intel to a very small start-up to a consulting job in the midst of the .COM boom.

Table of Contents

Introduction	p. xxi
Philosophy
Buy, Not Build	p. 3
Cost versus Benefit	p. 4
Creating a Competitive Advantage	p. 5
Base Class Libraries	p. 6
Open Source Software	p. 7
Taking Advantage of Your Platform	p. 7
Design	p. 7
Risk	p. 8
Services	p. 9
Third-Party Components	p. 9
Summary	p. 10
Test-Driven Development	p. 11
Tests Define Your Contract	p. 13
Tests Communicate Your Intent	p. 16
Summary	p. 19
Continuous Integration	p. 21
Integrate Early and Often	p. 22
Keeping Testers Working	p. 22
Keeping Developers Working	p. 22
Barriers to Continuous Integration	p. 23
Build Servers	p. 25
Automating a Build Process	p. 26
Expanding the Build Process	p. 29
Setting Up a Cl Server	p. 31
Multiple Builds of the Same Project	p. 35
Coordinating Build Output	p. 35
Notifying People about Build Results	p. 36
Fix a Broken Build before Integrating Changes	p. 37
Summary	p. 39
Process
Done Is Done	p. 43
Discuss Design Decisions	p. 44
Every Class Has a Test Fixture	p. 45
Each Fixture Exercises Only One Class	p. 48
Code Coverage Is High	p. 49
No Compiler Warnings	p. 51
Static Analysis Tools Generate No Errors	p. 52
Before Committing, Update	p. 53
Documentation in Place	p. 53
Summary	p. 56
Testing	p. 57
Why Testing Doesn't Get Done	p. 58
How Testing Will Make You a Better Developer	p. 59
Your Designs Will Be Better	p. 59
You'll Have to Write Less Code to Achieve Your Goals	p. 59
You Will Learn More about Coding	p. 60
You Will Develop Better Relationships with Your Testers	p. 61
You Will Make Your Project Sponsors Happy	p. 61
Code Coverage	p. 64
Why Measure Code Coverage	p. 65
Code Coverage Tools	p. 67
Strategies for Improving Code Coverage	p. 72
Types of Tests	p. 74
Unit Tests	p. 75
Integration Tests	p. 84
Functional Tests	p. 89
Performance Testing	p. 93
Test Automation	p. 96
Strategies for Test Automation	p. 96
Testing Frameworks	p. 97
Automation and Your Organization	p. 104
Summary	p. 106
Source Control	p. 107
Some Source Control History	p. 108
Concurrent Versioning System (CVS)	p. 110
Picking the Right SCCS	p. 110
Performance and Scalability	p. 111
Locking Models	p. 111
Cost	p. 112
Atomic Commits	p. 112
Branching	p. 113
Merging	p. 114
Integration with Other Tools	p. 114
Reporting	p. 115
Extensibility	p. 115
Making Your Choice	p. 115
Organizing Your Source Tree	p. 117
Using TreeSurgeon	p. 117
Packaging	p. 121
Adding Folders to Work with Source Control	p. 121
Making the Most of Branching	p. 122
Version Branches	p. 123
Integration Branches	p. 127
Personal Branches	p. 129
Task Branches	p. 130
Merging Branches	p. 131
Summary	p. 133
Static Analysis	p. 135
Using Static Analysis Tools	p. 135
NDepend	p. 136
FxCop	p. 137
Simian	p. 139
Who Benefits from Static Analysis?	p. 139
How to Integrate Static Analysis into Your Process	p. 140
Summary	p. 143
Code Construction
Contract, Contract, Contract!	p. 147
Public Interfaces	p. 152
Data Contracts	p. 155
Summary	p. 158
Limiting Dependencies	p. 159
Limiting Surface Area	p. 162
Dependency Injection	p. 165
Inversion of Control	p. 167
Summary	p. 170
The Model-View-Presenter (MVP) Model	p. 173
Why MVP?	p. 173
What Is MVP?	p. 174
Constructing the MVP Application	p. 177
Testing MVP Applications	p. 184
Summary	p. 187
Tracing	p. 189
Different Kinds of Messages	p. 189
Log Sources and Log Sinks	p. 190
Activities and Correlation IDs	p. 192
Defining a Policy	p. 193
Making Messages Actionable	p. 196
Summary	p. 198
Error Handling	p. 199
Result Code Reading	p. 200
Exception Throwing	p. 201
Importance of a Policy	p. 203
Defining a Policy	p. 204
Where to Handle Errors	p. 207
Summary	p. 210
Putting It All Together
Calculator Project: A Case Study	p. 213
Wrapping Up	p. 220
Index	p. 223
Table of Contents provided by Ingram. All Rights Reserved.