2.23.2006
What to do or NOT
1) Design first, then code
Okay, things are going political now, but even though you will find many many people who disagree, I still feel that this is the single most valuable lesson that I have learned. Designing first and then coding simply doesn't work. The problem is that this is so counter intuitive that you more or less have to find it out for yourself.
I think every programmer has experienced a project with no planning turning into a mess. Changing such code can only be done with hacks and patches to everyones great frustration. It is at that time that you realize that the only decent way to code is by designing things right from the start. Only now the frustration is even greater when you realize that your beautiful design isn't prepared for exactly this new feature that you are to implement now. What to do then?
You should think before you code. Go ahead, but think for hours, not days. Don't kid yourself into believing you can sketch an entire design document with UML diagrams and everything without making mistakes. At least, don't think you can do so any faster than you could have simply written the code.
Now, if you're not familiar with agile methodologies such as eXtreme Programming, the whole concept of evolving design sounds like the very problem programmers are trying to solve with all their clever ways of abstracting things out. And indeed, evolving design only works well if you follow a number of practices. Short iterations, automated testing and frequent refactoring being the most important.
I suggest you read Martin Fowler's excellent article Is Design Dead? which explains it all a lot better that I am capable of.
2) Be tolerant with input and strict with output
A function that accepts a vast variety of input formats is harder to test and harder to validate.
3) Use the singleton pattern for variables that you KNOW you should have only one instance of
Global variables are evil. And just because you put a such into a class which in turn is put into a design pattern from nothing less than the GoF book, it is no less so. On a more philosophical level, what is "global"? "Global" in programming terms means per process. Which is sometimes fine but it is actually a rather arbitrary resolution given the distribution of many software systems. A software system can consist of many processes running on many machines - and each process may internally run many threads. In this perspective, process-level variables are really somewhat of an odd size.
4) Write lots of comments
I think my colleague Lars Thorup pointed out a very good test for comments: they should contain the word "beacuse". This way, you know that you are answering a why rather than a what.
Okay, things are going political now, but even though you will find many many people who disagree, I still feel that this is the single most valuable lesson that I have learned. Designing first and then coding simply doesn't work. The problem is that this is so counter intuitive that you more or less have to find it out for yourself.
I think every programmer has experienced a project with no planning turning into a mess. Changing such code can only be done with hacks and patches to everyones great frustration. It is at that time that you realize that the only decent way to code is by designing things right from the start. Only now the frustration is even greater when you realize that your beautiful design isn't prepared for exactly this new feature that you are to implement now. What to do then?
You should think before you code. Go ahead, but think for hours, not days. Don't kid yourself into believing you can sketch an entire design document with UML diagrams and everything without making mistakes. At least, don't think you can do so any faster than you could have simply written the code.
Now, if you're not familiar with agile methodologies such as eXtreme Programming, the whole concept of evolving design sounds like the very problem programmers are trying to solve with all their clever ways of abstracting things out. And indeed, evolving design only works well if you follow a number of practices. Short iterations, automated testing and frequent refactoring being the most important.
I suggest you read Martin Fowler's excellent article Is Design Dead? which explains it all a lot better that I am capable of.
2) Be tolerant with input and strict with output
A function that accepts a vast variety of input formats is harder to test and harder to validate.
3) Use the singleton pattern for variables that you KNOW you should have only one instance of
Global variables are evil. And just because you put a such into a class which in turn is put into a design pattern from nothing less than the GoF book, it is no less so. On a more philosophical level, what is "global"? "Global" in programming terms means per process. Which is sometimes fine but it is actually a rather arbitrary resolution given the distribution of many software systems. A software system can consist of many processes running on many machines - and each process may internally run many threads. In this perspective, process-level variables are really somewhat of an odd size.
4) Write lots of comments
I think my colleague Lars Thorup pointed out a very good test for comments: they should contain the word "beacuse". This way, you know that you are answering a why rather than a what.
Comments:
Post a Comment
