This is review of the 14th chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin.

This is the second detailed project in the book

And I dutifully skipped this as well- so I will not write a review of this chapter either.

Though one anecdote caught my eye -the basics of JUnit were written during three hour flight with Kent Beck and Eric Gamma exchanging notes on Small talk testing framework and Java

And yes remember the “Boy Scout Rule”-

Leave the code cleaner than you found it. Fix a variable, method formatting- anything- as long as you have bettered the code in some way

For review of other chapters- please see this post.

 

This is review of the 14th chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin.

This chapter is a detailed case-study of a program made better with refinement
I did not read this chapter completely- (I guess I don’t have that kind of patience).

So i will skip the review of this chapter

But some food for thought…

Clean code doesn’t come the first time.The first time will be messy. But once you get it working- its your responsibility to make sure that the code is cleaned

Getting it done isn’t enough- you have to make sure it is clean enough for the next person to walk by.

For review of other chapters- please see this post.

 

This is review of the 13th chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin.

Concurrency increases the complexity of the program many-folds. Accordingly, the challenges to keep concurrency riddled code clean and efficient also increases exponentially.
To code well for concurrency- familiarize yourself with classical problems such as

Producer-Consumer
Readers-Writers
Dining Philosophers

Some other worthy recommendations are

Keep your concurrency-related code separate from other code.
Take data encapsulation to heart; severely limit the access of any data that may be shared.
Attempt to partition data into independent subsets than can be operated on by independent threads, possibly in different processors.
Know your library.
Know your execution models
Use copies of data
Avoid using more than one method on a shared object.
Keep your synchronized sections as small as possible.
Think about shut-down early and get it working early.
Don’t ignore a failure just because the tests pass on a subsequent run.
Do not ignore system failures as one-offs.
Get your non-threaded code working first
Make your thread-based code especially pluggable so that you can run it in various configurations.
Make your threaded code tunable.
Run with more threads than processors
Run your threaded code on all target platforms early and often.
Instrument your code to try and force failures

For review of other chapters- please see this post.

© 2011 Technology Cafe Suffusion theme by Sayontan Sinha