Company Code Base

Question

i'm thinking of building a code base for my company - to hold libraries, classes, etc. developed by employees internally and used in different applications in time. The purpose would be code reusability in time. The platform I target is .NET only - winForms, WPF, WEB, Silverlight, and others. I was thinking of building a solution that would hold 2 projects for each tech - 1 containing the code, and the other as a test site for that code. What would be the best solution to handle all this different technologies and code, what do you think ?

Answer 1

If you are after code re-use, you should identify commonality irrespective of whether the eventual UI is WinForms, WPF, Silverlight, WebForms or anything else.

For example, if you had a class that calculated a loan repayment, you don't want to have a version for each technology. You just want a dll that you can use anywhere and pass in a request and get a result.

You may also want to ensure that your data access is more data-centric rather than UI-centric, for example, ensure that only one "Service" talks to a database table, to ensure that nothing above that "Service" is affected by any changes to the table, or even database.

Essentially, my point is to base your common code on distinct vertical slices of functionality and don't base it on the eventual UI that displays the information. If you write good code, you should be able to put any UI over the top (or even multiple UIs over the top).

Answer 2

This can be much more difficult than you might imagine. It depends in large part on what kind of company you're working in, what kind of work they do, and the scope of your ambition.

First, you probably don't want to create a "framework". You already have the .NET Framework. Perhaps you want to agree on a common set of custom controls. There are many to choose from. I would strongly discourage you from trying to write your own set of custom controls that will be reused in many projects. Developing a coherent and consistent custom control library is a huge job all in itself, and halfway measures that work for a specific project fail miserably when you try to move them to other projects.

I've seen a consulting company (that mostly did custom .NET business applications for clients) try to reuse code, and mostly it wasn't pretty. Taking code that was written for and works in one custom application and moving it to another custom application is way more difficult than it sounds. All too often, that "general" piece of code makes assumptions about the overall application, or it's dependent upon some bit of application-specific code and removing that dependency is very difficult.

Now, if you're in an environment where everybody is working on programs that process the same types of data, you can probably leverage a common set of data access and reporting modules, and some common algorithms. Be careful here, though. Any shared code has to have as few dependencies as possible. Otherwise, potential clients (i.e. other programmers) will prefer to roll their own rather than "include the world."

You say that you want to build a code base that holds "libraries, classes, etc. developed by employees internally and used in different applications in time." To me this says that you want to share code between disparate projects, or at least take code that was written for one project and use it in another. It's a laudable goal, but often difficult. As I indicated above, there's a big difference between writing code that works for a single project, and writing code that can be used by multiple projects with a minimum of dependencies. Possible, but difficult. And time consuming.