Code Leader By Patrick Cauldwell

Just now i completed reading Code Leader By Patrick Cauldwell

I think this book is for beginners in programming and should be a good book for them and remember all examples are in c# language though many java developers believe c# = (c#)java.clone();

I wanted to share few important points i found from this book.

1) There is always a risk, however. If you bank on functionality provided by the operating system (or any third-party software, for that matter), you could find yourself backed into a corner. Months into your development process, it might turn out that some functionality that is critical will be impossible to implement using the third-party software. If that happens, the only alternative is to write it yourself after all, only now you have to do it with time and resources you didn’t budget for at the beginning of the project.

The best way to mitigate this risk is by building a ‘‘baseline architecture.’’ If you can build out as much of your design as possible in ‘‘width’’ rather than ‘‘depth’’ (meaning that you touch as much of the macro-level functionality of the system as you can without going into detail), you will have a much better estimate of whether any third-party systems will meet your needs. It is particularly important to include third-party or operating system functionality into that baseline architecture because that is where the greatest risk often lies. As long as you can implement enough critical functionality in your baseline,you can be reasonably sure you won’t end up backed into a corner later on.

2) The process of TDD is often described, in abbreviated form, as ‘‘Red, Green, Refactor,’’ meaning that first you write tests so that the tests fail (causing a ‘‘red light’’ in most testing GUIs), then you write code to make the tests pass (causing the ‘‘light’’ to turn green), and then you are free to refactor or improve the structure of your code, safe in the knowledge that the tests still pass. Once
the refactoring is complete, the cycle begins again:

a) Write tests that fail.
b) Write code to make the tests pass.
c) Refactor your code to improve its structure.
d) Repeat.

3) Tests Define Your Contract

When you write tests first, then write code to make them pass, it forces you to focus on the contract that your code is making with the rest of the system. Every piece of code has a contract, whether implicit or explicit. Every piece of code does something (or at least it should), and what the code does and how it is called by other code constitutes its contract.

4) Dependency injection means loading dependencies dynamically at runtime, using interfaces and runtime type creation (which means you don’t have compile-time dependencies except on the interfaces), and an inversion of control system usually involves passing all of your dependencies to each object’s constructor. By setting up constructors that take only interfaces as their dependencies, an inversion of control system can insert itself at runtime and automatically create classes that implement those interfaces based on declarative configuration. It takes real discipline and quite a bit of work to implement these technologies well, but if it can be done, it is very easy to remove any and all dependency issues at test time by providing test or mock versions of your interfaces.

5) How Testing Will Make You a Better Developer

a) Your Designs Will Be Better

b) You’ll Have to Write Less Code to Achieve Your Goals

This is particularly true when you write your tests first. When you practice Test-Driven Development (TDD), you only write the code necessary to meet the customer’s requirements. No more and, hopefully,no less, which is why you have tests. It is widely known that one of the constant problems plaguing software development is the YAGNI (You Ain’t Gonna Need It) syndrome. You end up writing a lot of code that turns out not to be needed

c) You Will Make Your Project Sponsors Happy

d) You Will Develop Better Relationships with Your Testers

6) Unit tests should be your first line of defense against defects. They are meant to work at the lowest level, against the simplest building blocks of your code: individual interfaces. For your purposes, ‘‘unit tests’’ are ones that test code that has no external dependencies. Unit tests should be able to run on any machine that can compile your code. They should run quickly, so that developers can run them
continually without interrupting their work.

7) Static analysis means ‘‘stuff you can learn about your code without running it.’’

Cyclomatic complexity— The number of possible decision points that exist in a given method.Branching statements like if, case, while, and for all add to the cyclomatic complexity metric. The higher a method’s cyclomatic complexity, the harder it is to adequately test and to maintain. High cyclomatic complexity often points out code that needs to be refactored.

Afferent coupling — The number of types outside one assembly (library) that depend on types inside that assembly. If a library has high afferent coupling, making changes to that library can have a large impact on other libraries.

Efferent coupling — The number of types from other libraries that a type in one library depends upon. A library with high efferent coupling tends to be fragile because it has a wide range of dependencies that could change.

Instability— A metric derived from coupling that indicates how likely a library is to be affected by changes elsewhere.

Abstractness — The ratio of concrete to abstract types in any given library.

Hope you enjoy reading this book


About the Author

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.

Patrick pursues his passion for talking and writing about software development as often as possible.He teaches computer science classes at the Oregon Institute of Technology, speaks at numerous developer conferences across the country, and once talked about the challenges of building a highly scalable eCommerce web site as part of a 12-city developer road show.

After working for several product companies, Patrick recently returned to consulting full time.