Exercise 49: sed

You implemented a "baby version" of sed in exercise 9 when you were learning how to make quick and dirty hacks. In this exercise you'll attempt another exact faithful copy of the command. In the Study Drills of Exercise 48 you were tasked with creating a module from your ed implementation. If you didn't do that, then you'll need to do this for your sed command and have sed use it.

How is your process working out? Are you finding that it's helping you on these longer projects? Are there things you think you need to change? Have you been collecting metrics or do you feel that you are past that now? Take the time before you start this exercise to look through your journal and see how much you've improved since you started the book.

The challenge for this exercise is to take code from the ed project in Exercise 48 and reuse it in this project. The concept or "reusability" is central to how software works, but many times planning for reuse in a project leads to disaster. Too often people design software so that every component can be used in other software, but in doing so they merely overcomplicate the design with no real plan to use anything in any other project. It's better to make software that is discrete and stands on its own, and then pull pieces out that you can use when starting another project.

I typically write my software with absolutely no concern for reusability. I do not care if parts of the project will be used in other projects. I only care that this one piece of software works well and has high quality. When I start a new project I'll go look at other things I've written and see if there's anything I can use again. If there is I spend the time in the older project to pull out the part I can use into a module. This makes my reuse process look like this:

• Implement a fully working high quality piece of software with automated tests. Do not care about any part of it being used by any other software.

• Start a new project that might use code from the other project.

• Go back to the first project and pull the code out into a separate module, making this first project use it and change absolutely nothing else.

• Once all my original automated tests run fine with the module in place in the original project, I use the module in the new project.

• Finally, attempting to use the new module in the new project will find changes I need to make in the module. I'll make the changes and make sure they work with the original software as well.

You cannot do this without automated tests, so if your ed project didn't have tests I'm wondering if you've been reading this book or not. Go back and make sure you have full coverage of your ed project with your tests.