Foundations of Programming - Karl Seguin
Foundations of Programming - Karl Seguin
Foundations of Programming - Karl Seguin
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Wrapping It Up<br />
Wrapping It Up<br />
WE ALL TEND TO TIE OUR SELF-ESTEEM STRONGLY TO THE QUALITY OF THE<br />
PRODUCT WE PRODUCE - NOT THE QUANTITY OF PRODUCT, BUT THE QUALITY. - TOM<br />
DEMARCO & TIMOTHY LISTER (PEOPLEWARE)<br />
F<br />
or many, programming is a challenging and enjoyable job that pays the bills. However, given that<br />
you've managed to read through all <strong>of</strong> this, there's a good chance that, like me, programming is<br />
something much more important to you. It's a craft, and what you create means more to you than<br />
probably any non-programmer can understand. I take great pleasure and pride is building something<br />
that stands up to my level <strong>of</strong> quality, and learning from the parts that I know need to be improved.<br />
It isn't easy to build quality s<strong>of</strong>tware. A new features here or a misunderstanding there, and our hard<br />
work starts, ever so slightly, to show weakness. That's why it's important to have a truly solid<br />
understanding <strong>of</strong> the foundations <strong>of</strong> good s<strong>of</strong>tware design. We managed to cover a lot <strong>of</strong> real<br />
implementation details, but at a high level, here are my core principles <strong>of</strong> good s<strong>of</strong>tware engineering:<br />
� The most flexible solution is the simplest. I've worked on projects with flexibility built into the<br />
system upfront. It's always been a disaster. At the core <strong>of</strong> this belief lie in YAGNI, DRY, KISS and<br />
explicitness.<br />
� Coupling is unavoidable, but must be minimized. The more dependent a class is on another<br />
class, or a layer on another layer, the harder your code is to change. I strongly believe that the<br />
path to mastering low-coupling is via unit tests. Badly coupled code will be impossible to test<br />
and plainly obvious.<br />
� The notion that developers shouldn't test has been the anti-silver bullet <strong>of</strong> our time. You are<br />
responsible (and hopefully accountable) for the code that you write, and thinking that a method<br />
or class does what it's supposed to isn't good enough. The pursuit <strong>of</strong> perfection should be good<br />
enough reason to write tests, but, there are even better reasons to do so. Testing helps you<br />
identify bad coupling. Testing helps you find awkwardness in your API. Testing helps you<br />
document behavior and expectations. Testing lets you make small and radical changes with far<br />
greater confidence and far less risk.<br />
� It's possible to build successful s<strong>of</strong>tware without being Agile - but it's far less likely and a lot less<br />
fun. My joys would be short-lived without ongoing customer collaboration. I would quit this field<br />
without iterative development. I would be living in a dream if I required signed <strong>of</strong>f specifications<br />
before starting to develop.<br />
� Question the status quo and always be on the lookout for alternatives. Spend a good amount <strong>of</strong><br />
time learning. Learn different languages and different frameworks. Learning Ruby and Rails has<br />
made me a far better programmer. I can pinpoint the beginning <strong>of</strong> my journey in becoming a<br />
better programmer to a few years ago when I was deeply entrenched in the source code for an<br />
open source project, trying to make heads <strong>of</strong> tails <strong>of</strong> it.<br />
<strong>Foundations</strong> <strong>of</strong> <strong>Programming</strong> Copyright © <strong>Karl</strong> <strong>Seguin</strong> www.codebetter.com<br />
78