The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
A lot of times we get to work on an existing system. We’re lucky if the system is of high quality: easy to read, easy to understand, and easy to maintain. A lot of times, though, we get a system that’s messy: long methods, complex code. Anotherwords, the code smells.
We are asked to make changes to the system. What do we do? We make the change, verify that the system works, and submit the changes. We keep the system in the same state. We don’t want to introduce other changes. We are afraid of taking the risk and moving some of the code out of long methods to a new method. We have deadlines to meet, we don’t mess around. We think copy and paste is not so bad under those conditions. We’re ordinary programmers. That’s not the way good programmers approach it.
Good programmers always, I mean always, try to make the system better after every change. The least they can do is keep the system the same. I like to think of myself as a decent programmer. How do I improve the system? Whenever I’m making a change and I see something that’s not clear to me, I refactor it. I don’t change the functionality; I just try to make the code look better. Why? Because I know when I come to fix something else here, I’ll have the same problem of trying to understand what’s happening. I don’t want to think hard on the same thing twice. I like things simple.
For me, a bad smell in the system is a smell of opportunity. Opportunity to improve the system. This applies to any type of a system in any state. No matter how good or how bad it is. How do good systems decay? Programmers don’t try to improve it. They just do their thing and they’re done. Ordinary programmers do that. Good programmers like to understand the code. They try to make it better every time. You might say, I don’t have time to do that, we have deadlines to meet. I don’t buy that. Not under any condition. Most likely, you don’t know how to make it better. You don’t know how to program well. You know how to hack.
Part of being a good programmer is keeping the codebase clean. To know that you’re programming for other people, not for computers. That’s why when you see a long method, duplicated code, or unclear piece of code, refactor it. How do you do that? Read Refactoring by Fowler and he’ll show you how. Keep your code DRY (Don’t Repeat Yourself); keep it SHY (don’t reveal too much — data hiding, encapsulation); and TELL the other guy (to do the work for you — ie, no getter methods). Or as Thomas and Hunt say: Keep it DRY, Shy, and Tell the Other Guy (great article — May 2004, IEEE Software).
The degrading of the system starts with a single broken window that’s not fixed. Don’t let that happen, always fix any code smell that you see. Be a good programmer, not ordinary one. Also, if you’re serious about improving, check out The Pragmatic Programmer and Code Complete 2, they’ll help you. They helped me. 
Effective Java
by Joshua Bloch
ISBN 0201310058
Date Read 4/2005
My Rating
Let me ask you a simple question? Have you programmed in Java for more than a year or two? If no, than this book might not be for you. On the other hand, if you’ve been programming in Java, why haven’t you read this book? Seriously. Why haven’t you? How about you, Stas. I know. I know. I’ve been programming in Java for 5+ years and I read this book last month. I should have read it sooner. Much sooner. Anyway, I read it, so I’ll tell you why you should read it as well.
The Foreword of the book sums up the book very nicely:
Nice job, Mr. Bloch. Very nice work. I rate it 5 stars.
Like I said, I’ve had decent exposure to Java over the years, but when I was reading this book, I was constantly telling myself: Wow. This is cool. This is a neat way of doing things. How come I did not come across this earlier.
Mr. Bloch shows you how you can effectively use Java. He does not cover everything, but the areas he covers are really helpful. Plus, he writes good English: easy to read and down to earth (I wish more authors were writing like that).
Read it and you will be a better Java programmer.
Yukihiro Matsumoto, the creator of Ruby, the object-oriented scripting language (I don’t know it but I hear it is a good language — Pragmatic Programmers recommend learning it), shares his top 10 tips for programmers. I like the list. The list is inline with what I believe good programmers should do and believe in. The list describes what a crafstman should do. Read this interview on Aritma, Matz on Craftsmanship, where he is asked about the tips that are found below. I extracted the Top 10 list and showing it to you below.
Yukihiro Matsumoto (creator of Ruby – OO scripting language):
What’s happening in the software engineering world? Here are two articles that are worth reading.
Gary Pollice looks at changes and progress in software engineering over the past two decades.
Improve the quality of your J2EE-based projects
Jimmy Jarret advises developers on tasks they need to perform to ensure their system’s quality. He basically explains different plug-ins that are available for Eclipse that can be used to ensure quality. If you’re using Eclipse, read it.
Joel Spolsky, my favorite blog author, gives his advice to college students. The advice is also applicable to people that are just moving to programming fields. Interesting read — click on the link, below, to see the whole article.
Joel’s Seven Pieces of Free Advice for Computer Science College Students:
How do you build a good software? In this article, What Do Users Want?, Larry Constantine explains what users want and how you build software to accomodate that. I’ll give you the portions of the article that I liked the best. However, you should read the first four pages of the article: it will give the the principles of usability. A required read for all software engineers.
What users really want is good tools. They want systems that are easy to learn and easy to use, and that help them do their work. They want software that doesn’t slow them down, that doesn’t trick or confuse them, that doesn’t make it easier to make mistakes or harder to finish the job.
How do you achieve that? Usage-Centered Design
User-centered development was not really such a bad idea but it, too, missed an important point: all software systems are just tools. Since good tools support work, making someone’s job easier, faster, simpler, more flexible, or more fun, what is really important is not building software around users, but around uses. It may be nice to get software and applications developers to understand users, but what really matters is understanding what users are doing or trying to do, to understand the intended and necessary usage. Users are not the center of the universe. To design more usable software the most important issue is neither the user nor the user interface, but usage.
Ask Why
Why? Why is this needed? Why would users interact with this software? What are they trying to accomplish?
Just asking the question helps focus on fundamental issues of what would make the system more usable.
Principal Principles of Usability
Second Rule: Efficacy: “Good systems do not interfere with or impede efficient use by a skilled user having substantial experience with the system.”
Third Rule: Progression: “Good systems facilitate continuous advancement in knowledge, skill, and facility and accommodate progressive change in usage as the user gains experience with the system.”
Fourth Rule: Support: “Good systems support the real work that users are trying to accomplish, making it easier, simpler, faster or more fun.”
Fifth Rule: Context: “Good systems are suited to the conditions and environment of the actual operational context within which they are deployed.”
Visibility Principle: Keep all needed options and materials for a given task visible without distracting the user with extraneous or redundant information. Instead of WYSIWYG, use WYSIWYN: What-You-See-Is-What-You-Need.
Feedback Principle: Keep users informed of actions or interpretations, changes of state or condition, and errors or exceptions using clear, concise, and unambiguous language familiar to users.
Structure Principle: Organize the user interface purposefully, in meaningful and useful ways that put related things together and separate unrelated things based on clear, consistent models that are apparent and recognizable to users.
Reuse Principle: Reduce the need for users to rethink and remember by reusing internal and external components and behaviors, maintaining consistency with purpose rather than merely arbitrary consistency.
Tolerance Principle: Be flexible and tolerant, preventing errors where possible by tolerating varied inputs and sequences and by interpreting all reasonable actions reasonably; reduce the cost of mistakes and misuse by allowing undoing and redoing.
Simplicity Principles: Make simple, common, tasks simple to to, communicating straightforwardly in the user’s own language and providing good shortcuts that are meaningfully related to longer procedures.
Do you know Singleton, Factory, Decorator, Adapter, Fa軋de, Strategy, State, MVC? As you might have guessed, they are all patterns from the GoF book. But if you are like me, you might know couple of them and a lot of times you are confused. If that’s the case, you should read this article on java.net about those patterns. The authors prepare you for a holiday conversation on design patterns. They will help you look like a true guru. Fun and interesting article. I really liked it.
|
Simple systems are easier to build, easier to maintain, smaller, and faster than complex ones. … Simplicity is often not an easy goal to achieve. Programmers love complexity, so they have a strong tendency to over complicate their work. It’s often easier to quickly build an overly complex system than it is to spend the time required to make the system simple.
–Allen Holub
in his recent book, Holub on Patterns, 2004 |
Did you know that you could write a JSP tag without writing a single line of Java code? I didn’t. I was surprised today when I discovered that. I’m going to show you how easy it is. Let’s take an anchor tag (<a href=”">link</a>). If you don’t get to write it very often, you might forget the exact syntax. Why not write a simple tag? This would make things easier.
Here is a simple tag, link.tag:
<%@ attribute name="address" required="true" description="Location"%><%@ attribute name="title" required="false" description="Label"%><a href="${address}">${title}</a>
That’s it! You’ve got yourself a jsp tag. Here is an example, link.jsp, of its actual usage.
<%@ taglib tagdir="/WEB-INF/tags/" prefix="tags"%><html><body><p><tags:link address="http://aol.com" title="aol.com" /></p></body></html>
How about that? That’s one cool feature of JSP. Read some other cool stuff about JSP 2.0 here.
Another cool feature is the use of JSTL, which is a pre-defined tag library for common tasks. What tasks? Access to request parameters, access to beans, logic, and other. If you use JSTL, your JSP pages are without Java code. You use a simple scripting language EL (Expression Language) for that. After all, JSP is a view. It should not have any Java code. Period. If you are considering JSP, or if you want to move to JSP, use JSTL. It will make your life much easier. Plus, you’re not going to fall into the trap of doing most of your business logic inside your page. JSTL gives you a seperation of layers by default.
Here is a link to very good JSP 2.0 article, Faster Development with JavaServer Pages Standard Tag Library (JSTL 1.0), by Qusay H. Mahmoud.
|
|
… best programmers think through the design of their code before they actually write it.
–Scott W. Ambler
|