Currently, I have a more or less organized set of projects I work or worked on. Some are refactored, documented and unit-tested, others are not.
When I want to reuse a code I’ve written before, I spend a few minutes searching for the project where I’ve written this code, than copy-paste this code to a new one, refactoring, documenting and unit-testing if need.
It’s ugly, because it requires to do extra work, to remember what was written and where, and (probably the ugliest one) to duplicate code across projects. Working with other developers without having a common codebase is a problem too.
Now, I want to create a codebase, but I don’t know anything about it and have never seen a serious one in any company.
So where to start? Are there books or online documentation either explaining how to create such codebase or describing an existing or imaginary codebase, how does it work, how is it maintained, etc.?
I think you are referring to re-usable libraries. It’s a little bit language dependant because languages with linkers and compilers will strip out code which is not used to make the deliverable smaller whereas just-in-time compiled or interpreted languages don’t so resources can be wasted by having the whole library loaded.
The long and the short of it is to look at your code, realise the tasks that are commonly performed and the parameters that are used. Add a little room for change and create an interface in which to hide all that functionality behind. Defining the interface correctly is the most important part. Try to avoid a collection of function calls, but rather create related functions behind an interface, then an interface per operational task – you are trying to split the work into operations.
The interfacing solution will de-couple the implementation (of the refactored work) and the work that uses the interface. This will help with separating the common code with the project code allowing them to be developed at different rates.
Try to group all the related information regarding a particular job or task behind an interface so the interfaces don’t rely on each other.
Some useful links about interfaces. Some of the links talk about object oriented languages but the principles and ideas can be applied to any other type of language.
http://en.wikipedia.org/wiki/Interface_%28computer_science%29#Software_interfaces_in_object_oriented_languages
http://en.wikipedia.org/wiki/Interface_%28computer_science%29#Programming_against_software_interfaces