We build software systems to some purpose. But when I read code, I see that some of that code directly serves that purpose while other code does not. I see three categories:
Features
This is the stuff you and your customers care about. It's the reason your software system exists.In an e-commerce system, that's code that says "when a customer uses a discount code, the discount is applied to the order."
If you learn about code smells, great names, and duplication, and then refactor with those in mind, you'll find that some code is explicitly the feature and some that is not. That leads to:
Utilities
Code that helps you write code, but has nothing to do with the problem domain you're working in.
It's often write in the middle of the rest of your code, but as you refactor to improve readability and reduce duplication, it can become visible. For example, consider this refactoring sketch:
If you refactor mercilessly, you'll end up with a lot of this stuff. It's not part of the value you offer, and it would be useful to the programming community. Factor it out to be an open source project and share with the world.
Some examples of this are Boost in C++ and Rails in Ruby.
In that e-commerce system, it might be class like "Money".
While this is not the value you are offering, it is key to offering that value. You get to decide whether to release it as open source (so other people can build more systems in the same domain), or keep it under wraps (so your competition has to build their own).
It's often write in the middle of the rest of your code, but as you refactor to improve readability and reduce duplication, it can become visible. For example, consider this refactoring sketch:
Loading Gist ae5bd627269cb00ceaa9f9c3d3294dea...
If you refactor mercilessly, you'll end up with a lot of this stuff. It's not part of the value you offer, and it would be useful to the programming community. Factor it out to be an open source project and share with the world.
Some examples of this are Boost in C++ and Rails in Ruby.
Domain Libraries
You'll also have some code that is specific to your domain, but is not the feature you're creating. This is code that lets you describe your feature. A library for building features in this domain. Maybe a DSL.In that e-commerce system, it might be class like "Money".
While this is not the value you are offering, it is key to offering that value. You get to decide whether to release it as open source (so other people can build more systems in the same domain), or keep it under wraps (so your competition has to build their own).
