Development is hard. You can do everything right, and according to spec, how the client wants, and still have it be wrong. Designs and requirements change. You rely on third parties, and other people's tools. The reality is no one is on their own and has to do the best that they can, with what they can. How we go about doing that is a set of strategies on their own.
- Design by Contract - The idea of design by contract seems almost common sense when we say it, but often we find that we don't do that. Breaking down our tasks into specific methods, with contracts and pulling out any sort of set up or validation for the method is an excellent approach. It makes the code clear and concise. How you get there will depend on your situation. Can your framework handle something like pre and post processing? How about Guards? It is important to apply what you can when you can.
- Dead Programs Tell No Lies - A poorly named chapter, I believe this goes to my idea of exceptions are for exceptional situations. The message here is that you do not want to corrupt or compromise the results of your application. Crashing it will prevent problems from happening further down the line.
For example, if I wrote a method that calculates the total cost of an item (item cost + sales tax), and failed to calculate the sales tax, I should just throw the exception. Just returning the item cost will cause problems down the line. Fail early and don't mislead your users. - Assertive Programming - There are times in our code base where we can get into a situation that we know we shouldn't be in. For example, if in our system we only enter in authors once they have a book, and a query that retrieves the books by said author doesn't have anything, we know there's a problem and can detect the error.
How you handle said assertions is important, but it should not cause an internal exception. It should be logged and the development team should be notified. - How to Balance Resources - This is a problem that many developers run into early on. Proof of concepts are built, and don't reveal resource cleanup. Closing a connection to a database, locking a record, closing a stream to a file all should be handled in the code. Do not wait for garbage collection to do this for you. What happens if garbage collection isn't called? What happens if that record in the database isn't released?
It causes problems down the line for others once you get some sort of significant load on your system. - Don't Outrun your Headlights -We've all been on projects with high aspirations. It will change the entire organization! But first, File -> New. It is important to be realistic with your expectations of the application, but the ambition is good too! It helps motivate the developers.
The problem becomes that projects change. Technologies and demands change. Management changes and so do demands. One of the best thing about the agile process is it takes away ultra long term goals and makes the more immediate become the focus. Do what you need to get done, and nothing more. If work wasn't part of your commitment, don't spend time on it just yet.
No comments:
Post a Comment