Have you ever had this happen to you? -- You're wading through code, analyzing one expression after another. After getting forty lines into the method, you pause and ask yourself, "Wait, what is this method supposed to do again?" It's easy to miss the forest for the trees.
This happens a lot when the code is
So, you've been tasked with restructuring your object model. After hours of thinking through the implications of each design decision, you've sketched up your new object model in a UML class diagram. You're ready to present it to your peers! Now, how are you going to sell them on it?
Take a look at
I don't know about you, but when I first learned about UML, I was ecstatic! I was just so excited to have a standard way to represent my object model in class diagrams in ways that were easy to sketch and understandable by others. I created diagrams every chance I got.
Here's an example of what my class diagrams looked like back then:
Yep, that's what they looked like, except with about three or four times the number of classes as we see here. Sure, they were factually correct, but they were also so doggone verbose that they were only good for stuff like auto-generating stubbed out classes.
Reading a diagram like that is a bit like
We all know that goal setting is important, and the beginning of the year is a great time to recalibrate your compass! So to start your year off right, here are a few tips for goal-setting, from a programmer's perspective.
