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.

 

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

You don’t design good software. A good design emerges by itself…
This chapter re-iterates Kent Beck’s four rules of simple design

Runs all the tests
Contains no duplication
Expresses the intent of the programmer
Minimizes the number of classes and methods

Having  good set of test cases is of utmost importance. Once you have a reliable set of test cases- you can fearlessly bring changes to the application. because you know that you can test what you are changing

Most software erodes by the plain fear of unknown impact of such changes. And once you have test cases- this fear goes away or at least diminishes…

The last rule mentioned is to minimize number of classes and methods. Ina way this is in contrast to SRP which advocates a separate class for every responsibility. But its also essential to keep in mind a necessity to keep number of classes and methods low.  Dogmas like- every class to be accompanied with an interface – should be rejected . Have interface whenever needed and maybe often. But a rule saying every class must have an interface is totally unreasonable.

For review of other chapters- please see this post.

© 2011 Technology Cafe Suffusion theme by Sayontan Sinha