Clean code that works (simplicity is more complicity than you think is simpler than you think)

Your job when writing the code shoshould be to satisy the requirements No lessAnd No more

 

I l @ ve RuBoard

Preface Clean code that works, in Ron Jeffries 'pithy phrase, is the goal of Test-Driven Development (TDD). Clean code that works is a worthwhile goal for a whole bunch of reasons. It is a predictable way to develop. You know when you are finished, without having to worry about a long bug trail. It gives you a chance to learn all of the lessons that the code has to teach you. if you only slap together the first thing you think of, then you never have time to think of a second, better thing. It improves the lives of the users of your software. It lets your teammates count on you, and you on them. It feels good to write it. But how do we get to clean code that works? Please forces drive us away from clean code, and even from code that works. without taking too much counsel of our fears, here's what we do: we drive development with automatic tests, a style of development called Test-Driven Development (TDD ). in Test-Driven Development, we Write new code only if an automated test has failed Eliminate duplication These are two simple rules, but they generate complex individual and group behavior with technical implications such as the following. We must design organically, with running code providing feedback between decisions. We must write our own tests, because we can't wait 20 times per day for someone else to write a test. Our development environment must provide rapid response to small changes. Our designs must consist of lightweight highly cohesive, loosely coupled components, just to make testing easy. The two rules imply an order to the tasks of programming. Red? /Span> Write a little test that doesn't work, and perhaps doesn't even compile at first. Green? /Span> Make the test work quickly, committing whatever sins necessary in the process. Refactor? /Span> Eliminate all of the duplication created in merely getting the test to work. Red/green/refactor he TDD mantra. Assuming for the moment that such a programming style is possible, it further might be possible to dramatically reduce the defect density of code and make the subject of work crystal clear to all involved. if so, then writing only that code which is demanded by failing tests also has social implications. If the defect density can be forced CED enough, then quality assurance (QA) can shift from reactive work to proactive work. If the number of nasty surprises can be CED enough, then project managers can estimate accurately enough to involve real MERs in daily development. If the topics of technical conversations can be made clear enough, then software engineers can work in minute-by-minute collaboration instead of daily or weekly collaboration. Again, if the defect density can be CED enough, then we can have shippable software with new functionality every day, leading to new business relationships with MERs. So the concept is simple, but what's my motivation? Why wocould a software engineer take on the additional work of writing automatic tests? Why wocould a software engineer work in tiny little steps when his or her mind is capable of great soaring swoops of design? Courage.

I l @ ve RuBoard