this is good advice even if the code is 100% yours. separate out the non-core functionality into a library or framework, and divorce your core logic from it, even if you are developing the two in tandem.
There are lots of benefits:
1. Code reuse (You might only have one application at the moment, but the moment you start a second application you are going to wish you had a library of all the useful things from your first application)
2. Fix a bug in the library and the bug fix propagates to every application that uses it
3. Separation of concerns (When everything in the library is working fine then you can hack on the application and treat the library like a black box, on the other side of the coin when you are working on the library you can ignore the application code to a certain extent)
4. The separation process can help you write better code (“What if I want this code to use this code in both application A and application B?”, “Oh, this code shouldn’t have assumed this”, “Why is this code touching that code?”, “How can I make this more generic?”, “What if I don’t have access to some global variable in the application, ah hah, I’ll have to pass in arguments or a context object”)
5. The separation process can help you write tighter more trim code that deals with one thing only
6. You can open source the library and other people may use it, find/fix bugs and improve it
7. Optionally you could open source only the library and keep the application closed source
If you don’t have a library yet but have written a few applications, it is easy to gradually build up your library. Just find a core idea that could easily extracted into an independent module and pull it out. You can create multiple small libraries (libevent, sqlite) or a monolithic library (QT, wxWidgets). As with all refactoring you should try to use test driven development: Write tests, extract code to a library, verify the tests work, commit, repeat.
This can easily end up as a kind of inner-platform effect. I once worked on a codebase where the author had very carefully isolated their logic from that of the web framework and ORM they were using. It made the code longer, not really any more testable (Java has great mocking tools), and wasn’t providing any real value.
Careful decoupling is a feature like any other - don’t build it if you ain’t gonna need it.
Decoupling the what of an application (business rules) from the how (implementation details) has great value. You just don’t see it on a blog app.
In the past, one was mocked for cramming app logic into button click handlers, now we mock people who move it outside (because pragmatism and business business business). Progress.
this is good advice even if the code is 100% yours. separate out the non-core functionality into a library or framework, and divorce your core logic from it, even if you are developing the two in tandem.
I highly endorse this post.
There are lots of benefits:
1. Code reuse (You might only have one application at the moment, but the moment you start a second application you are going to wish you had a library of all the useful things from your first application)
2. Fix a bug in the library and the bug fix propagates to every application that uses it
3. Separation of concerns (When everything in the library is working fine then you can hack on the application and treat the library like a black box, on the other side of the coin when you are working on the library you can ignore the application code to a certain extent)
4. The separation process can help you write better code (“What if I want this code to use this code in both application A and application B?”, “Oh, this code shouldn’t have assumed this”, “Why is this code touching that code?”, “How can I make this more generic?”, “What if I don’t have access to some global variable in the application, ah hah, I’ll have to pass in arguments or a context object”)
5. The separation process can help you write tighter more trim code that deals with one thing only
6. You can open source the library and other people may use it, find/fix bugs and improve it
7. Optionally you could open source only the library and keep the application closed source
If you don’t have a library yet but have written a few applications, it is easy to gradually build up your library. Just find a core idea that could easily extracted into an independent module and pull it out. You can create multiple small libraries (libevent, sqlite) or a monolithic library (QT, wxWidgets). As with all refactoring you should try to use test driven development: Write tests, extract code to a library, verify the tests work, commit, repeat.
This can easily end up as a kind of inner-platform effect. I once worked on a codebase where the author had very carefully isolated their logic from that of the web framework and ORM they were using. It made the code longer, not really any more testable (Java has great mocking tools), and wasn’t providing any real value.
Careful decoupling is a feature like any other - don’t build it if you ain’t gonna need it.
Decoupling the what of an application (business rules) from the how (implementation details) has great value. You just don’t see it on a blog app.
In the past, one was mocked for cramming app logic into button click handlers, now we mock people who move it outside (because pragmatism and business business business). Progress.