Where to start to build a real codebase from scratch?

Question

Hi,

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.?

Answer 1

Use a version control service such as Google Code or GitHub. This way your code is backed up online, and you can revert to older versions if you need to.

Answer 2

First, recognize that this is a significant effort that will require the involvement of the other devs and management. You will probably need to stop work on new features while you reorganize your codebase, which is almost never an option for management. Even mentioning it to them can be bad. "We can put this off until after the re-org" is then followed by "we can't do the re-org until this piece is done", and both the big task and the re-org wait on eachother. It's the management-feature-deadlock, and it's hard to fix.

Moving along, you need to sit down with your team and identify what your products are, how they're constructed, where the overlap is, and how the products can benefit from this re-use. You need to closely examine the build structure of your products, and refactor that to include your commons-library (that you're about to build.)

Moving forward, you need to isolate dependencies. Don't let commons rely on a project. Don't let a project rely (projA) on another project (projB) if there's a good chance that project (projB) will end up relying on it (projA) in the future. Circular dependencies make for weeping and gnashing of teeth.

Answer 3

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