Slashdot Mirror

See: Working Effectively with Legacy Code book review (2008) for a book of that title by Michael Feathers (PDF article) on that very topic.

There is even a summary of key points at Programmers @ StackExchange. Hundreds if not thousands of programmer's blogs address this very topic.

You're welcome. Now get back to work.

I've found that test driven development, refactoring, automation, continuous integration and related practices such as those endorsed by Object Mentor http://www.objectmentor.com/ and Pragmatic Programmers http://www.pragmaticprogrammer.com/ have helped reenergize me to some extent. If you've been programming for a long time and don't feel energized, it is possible that you've become entrenched in bad habits that detract from your productivity and the quality of the code you produce.

Knowing Perl is good. It is a good tool for automation, but you might want to move to a language like Ruby which is more modern. Ruby is greatly influenced by Perl so some aspects will seem familiar.

I worry that you say you need a paycheck soon. It generally isn't good to make important decisions about your career under such conditions, you are bound to do something you'll regret.

I work in the embedded field (+10 years), and while most of my work has been with C, switching to OOA, OOD, (C++) has been a huge eye opener. I had been using TDD in C, but there was much much more to learn.

I consider myself to be still on the learning path, but I believe I've advanced a great deal with the following:

1. You need a good metor (I've seen others mention the same)
2. The following books helped me:
- Code Complete 2
- Clean code (IMO these complement each other)
3. Have a look at these online resources:
- object mentor (I found the craftsman articles both entertaining and informative).
- Some design patterns

Good luck

Bob Martin has posted a response to Joel's article at http://blog.objectmentor.com/articles/2009/09/24/the-duct-tape-programmer

If you're looking for great software design principles, start with the greats: Liskov, Fowler, Martin. Go to Object Mentor's published articles, click on "Design Principles", and start reading.

These handful of articles changed the way I look at software, particularly OO software, but not necessarily restricted to OO, and highlighted the importance of controlling dependencies. All of the Gang of Four design patterns use one or more of the principles laid out in these white papers. I would go so far as to say that good architecture and design primarily revolves around managing dependencies correctly around your functional requirements and points of future extension, no matter what language you're in.

These concepts are going to become ever more important as we have to scale across more cores and more machines using functional languages like Erlang and Scala and techniques like map/reduce (see Hadoop, for Java).

you said design. look at cohesion and coupling from the structured programming era. also uncle bob's o-o design principles: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf. in architecture, the dependency inversion principle and http://en.wikipedia.org/wiki/Hollywood_Principle in http://en.wikipedia.org/wiki/Inversion_of_control frameworks like spring. you should expect to see o-o design patterns

Though I'm sure you can design a particular application in which a square is behaviorally a rectangle, and therefore it would be ok to have square extend rectangle, it is not universally the case.

One of the best things I ever did was head over to Object Mentor's published articles page and click on the Design Principles category. There you will find a paper on the Liskov Substitution Principle which defines exactly when it is appropriate for one class to extend another. (You won't go wrong reading all the papers in that Design Principles category—I found them riveting for hours on end.)

In this particular case, behaviorally speaking a rectangle has two degrees of configuration freedom whereas a square has one. So, if you think about the actual practice of defining a Rectangle API with get/setWidth() and get/setHeight() methods, you could then write a unit test against those methods to fix the proper behavior of a rectangle. One of those unit tests might go something like: {1} set width to 1, (2) set height to 2, (3) assert that getArea() returns 2. I challenge you to now implement the subclass of rectangle called square that will pass this unit test which behaviorally (and correctly) verifies rectangle-type behavior.

Your suggestion of making squareness an attribute of rectangle is interesting and one I have not yet heard in any of the instances I've presented this example. I imagine it would take the form of something like the method boolean Rectangle.isSquare(), and would return getHeight()==getWidth(). This would work, as long as clients to the rectangle API understood that its square-ness is temporally defined and could change in the next moment. This is, however, an important consideration, though. In making this a requirement of what it means to be a square, nearly all definition of the square is itself lost...the concept of a square becomes a temporal thing itself. The old mathematical standby of an object that forever and always has equal sides is no longer relevant to this implementation.

In my experience, the following principles seem to consistently produce good outcomes for both devs and customers alike:

• Use all or some aspects of Agile development methodologies. One of the pillars is that the customer is involved in the planning process, and can thus immediately see the affect on the progress of the project, and the deliverables, when he changes his mind.
• Use Design Patterns and generally accepted Good Design Principles.

The first point mainly addresses issues at the project/team level. You can find more information on Agile at http://www.objectmentor.com/resources/articles/Agile_Methods_-_The_Bottom_Line.pdf

My second points bears directly to the issue of code. There are many ways of solving problems. One is to bulldoze ahead and use ad hoc programming, dealing with bugs and design issues cropping up everywhere as you go along. Another one is to leverage other people's experience in the forms of design patterns and good design principles.

I used to use OOA/D and ad hoc programming. Code would work, but defect repair and adding new features would most of the time take a huge effort. I now realize that good OOA/D skills alone isn't enough. Without the aid of design patterns and good design principles, I would be much worse off (no, there's no kool-aid involved.)

In my experience, the following principles seem to consistently produce good outcomes for both devs and customers alike:

• Use all or some aspects of Agile development methodologies. One of the pillars is that the customer is involved in the planning process, and can thus immediately see the affect on the progress of the project, and the deliverables, when he changes his mind.
• Use Design Patterns and generally accepted Good Design Principles.

The first point mainly addresses issues at the project/team level. You can find more information on Agile at http://www.objectmentor.com/resources/articles/Agile_Methods_-_The_Bottom_Line.pdf

My second points bears directly to the issue of code. There are many ways of solving problems. One is to bulldoze ahead and use ad hoc programming, dealing with bugs and design issues cropping up everywhere as you go along. Another one is to leverage other people's experience in the forms of design patterns and good design principles.

I used to use OOA/D and ad hoc programming. Code would work, but defect repair and adding new features would most of the time take a huge effort. I now realize that good OOA/D skills alone isn't enough. Without the aid of design patterns and good design principles, I would be much worse off (no, there's no kool-aid involved.)

and this is why you should not be using C. (what)

I don't know about books per se, but these links help:
http://joel.reddit.com/
http://programming.reddit.com/
The design patterns book website with, as I understand it most if not all of the content for the book:
http://lci.cs.ubbcluj.ro/~raduking/Books/Design%20 Patterns/

The next three I keep the bookmarks to in a folder called "Practicing programming:
http://www.devblog3000.com/archives/2-Practicing-P rogramming.html
http://butunclebob.com/
http://www.objectmentor.com/resources/publishedArt icles.html

...I'd say here:

http://mindview.net/Books

and here:

http://www.c2.com/cgi/wiki?WelcomeVisitors

and maybe here:

http://www.objectmentor.com/resources/articleIndex

And although a lot of people around here would probably disagree, I think it would be worth your time to go back and try to get a Computer Science degree. Programming != Computer Science, but it's helpful to understand the scientific principles that modern software development is based on.

Don't get your advice from Joel. Or Fred. Rather follow professional's like Robert C. MartinJoel's example is Netscape. Now IE is eating Mozilla's dust, thanks to the rewrite.

It takes a lot of time to understand the benefits. It isn't just "about objects" it's about a completely different design philosophy. Not "objects", but "object orientation" which contains a lot of different facets. I was the same way until I had a class in Object Oriented Design and saw how the structure of a properly designed object oriented program reduced rigidty and fragility in a design. Also, how it made the interfaces clear and made division of responsibilities simpler for multiple programmers working on a big project.

This is one paper (PDF document) that helped me start seeing the light. If you're interested, give that a read for starters.

Not really a different approach. There are some fundamentally defined tenants of good programming however and they include strong typing for one. In order to advance Software Engineering, approaches to good design have to be codified. Things like fragility, rigidity, and immobility run rampant in Perl. A good analogy would be you defending the ability to make a house out of mud and sticks instead of brick and aluminum. It's not that you can't make the house out of sticks because you have the philosophy that sticks are an expression of your artistic side, but do you want to live in that house?

If you're at all interested, this is one of the better articles on the subject--it's a really enlightening and interesting read for code writers! It's imperative for the software-writing "industry" to improve its practices, IMO (well, and others) and form a stronger discipline. Touchy-feely-I-have-the-right-to-write-unsafe-slop py-stuff doesn't necessarily make for good design!

UML lets you use an Activity Diagram for this as well. Typically activity diagrams are used to document a business process. Activity diagrams explicitly include synchronization and timing information. Sometime that's better than using a DFD as you know that a particular action must complete before its successor starts. Sometimes, it's worse because you may represent synchronization in the model that is simply an artifact of the current process. For example, I worked on cell phone point of sale system that would not let the sales rep take money until the phone activation was completed. This syncrhonization point was't really required for the business process (and actually caused lost sales when the activation system was slow or down), but had crept in through an activity diagram that listed activation as a pre-requisite for billing.

Activity diagrams are actually part of the UML replacement for flowcharts. State diagrams and sequence diagrams (plus, to a lesser extent collaboration diagrams (which are sort of a translation of sequence diagrams mapping objects spatially and time through notation) nostly complete the picture of UML things that replace flowcharts.

UML sequnce diagrams can be pretty useful to show these things. Especialy if you have asyncronus events, or multiple threads or processes, which ordinary flow charts dont model very well. PDF on sequnce diagrams.

The first wow, that's cool moment I had with test driven development was from an article on Object Mentor called The Bowling Game. It also highlights pair programming a bit.

The unique thing about the article was that it was presented as a discussion between two developers pair programming doing agile test driven development of the game. It was like watching over their shoulders.

If you want to get an idea of what extreme programming is like, I suggest reading this article AND writing the code and tests along with it, either in Java (and JUnit) or C#/VB.NET (and NUnit) or another language with a xUnit unit testing framework. Most object oriented languages have them now so you don't have to roll your own framework.

Is this book really as authoratitive as it tries to appear?

Hmm, my experience is slightly different. The 'fun' part is, of course, rather subjective-- I find dyanmically typed languages more frustrating, which is why I personally wouldn't agree with that, but, of course, YMMV-- but I definitely disagree about the part with "good results being produced faster".
They do produce results faster, often even reasonable results. But good results (i.e. stable code) take much longer to achieve, in my experience.

Interesting experience; definitely at odds with mine. In my experience quite stable code is produced quite quickly with either. The key is testing and design (and how they work together), not static or dynamic typing.

As for the other points -- yes, fun is definitely in the eye of the beholder. I've definitely had fun in every language I've worked with (even Fortran); but my experience is that languages like Python are a blast to program in -- the difference is highly noticable, more so every time I switch.

I've rarely had to "work against" strong type systems in the past. Sufficiently expressive type systems are important for this to make sense, I'll admit that; it requires a certain kind of thinking to be able to make use of strong typing effectively. This restriction on "free thought" may be what people find most offensive, but I'm not sure.

I've seen some type systems proposed which would allow almost as much freedom as dynamic typing; the problem is that they uniformly require a LOT of keyboarding. As a result, I haven't seen any of them actually implemented.

[...]the neccessity for implementing a test suite can be considered as a sign of weakness of static checking.

That's fine, and I would agree, but keep in mind that it's a fundamental, natural "weakness" of static checking. You can't get around it. You mention that in your next paragraph, but it needs to be made clear that you can't skip the testing even if you've got arbitrarily strong type correctness.

No test suite writer will ever be able to test for all the things that fall out of a static checker for free.

That's just completely false. A simple test suite can check for almost all the things a strong static typecheck gives; it takes a lot more to test for EVERYTHING, of course, but it's definitely possible.

Good tests are easy to write. I used to think they were hard; but then I started treating tests as part of my design, to be written at the same time as my design; and suddenly what used to be boring work (making my design break) became part of the most interesting work (making my design complete). I can highly recommend "Test Driven Development", known as TDD.

In conclusion, I believe that we need static typechecking, static checking in general, and test suites for everything we cannot formalise (for whichever reason) if we want to ever resolve the "software crisis". Without any of these, we'll just keep inventing more crappy code.

Sounds like the voice of reason and experience to me! I don't give formalism any place there, since in my experience it can't shortcut testing at all; but otherwise I agree with you.

-Billy

The only automated testing tools you can find is for regression tests.

Excluding, of course, things like HttpUnit, where you write code that drives a simulated browser and then check the results.

I've used it for automated testing of a couple of sites, and I like it plenty. Between HttpUnit, JUnit, and Test-Driven Development, we launched a complicated web site and have had it in production for six months with a total of one user-reported bug. And that bug was when the graphic designer broke a link.

General Books

Bertrand Meyer: Object Oriented Software Construction
Robert C. Martin: Designing Object Oriented C++ Applications using the Booch Method (this is useful for any OO programmer. You can read some good essays of Martin's at his company)
Gamma et. al.: Design Patterns
Martin Fowler: Refactoring
Kent Beck: Extreme Programming Explained

Java Books
Any O'Reilly book for specific parts of the API
Joshua Bloch: Effective Java

Off Topic
Hofstadter: Godel, Escher, Bach -- still a must-read IMHO

The world is much too interesting, even the parts, like programming languages, which we've created, to be so easily pigeoned into such small compartments.