What are the "standard framework" code that we should build?

Question

We are in a situation whereby we have 4 developers with a bit of free time on our hands (talking about 3-4 weeks).

Across our code base, for different projects, there are a number of framework-y type of code that is re-written for every new project that we start. Since we have some free time on our hands, I'm in the process of creating a "standard" set of libraries that all projects can re-use, such as:

1. Caching
2. Logging

Although these 2 above would rely on libraries such as Enterprise Library, each new project would write its own wrappers around it, etc, so we're consolidating all these code.

I'm looking for suggestions on the standard libraries that you built in-house that is shared across many projects.

To give you some context, we build LOB internal apps and public facing websites - i.e. we are not a software house selling shrink-wrap, so we don't need stuff like a licensing module.

Any thoughts would be much appreciated - our developers are yearning to write some code, and I would very much love to give them something to do that would benefit the organization in the long run.

Cheers

Answer 1

• Unit Testing Infrastructure - can you easily run all your unit tests? do you have unit tests?
• Build Process - can you build/deploy an app from scratch, with only 1 or 2 commands?

Answer 2

A previous job encountered a little down time while the business sorted out what the next version should be. There were a few things we did that helped

• Migrated from .net reoting to WCF
• Searched for pain points in the code that all devs just hate to work with and refactor them
• Introduce a good automated build system that would run unit tests and send out emails for failed builds. It would also package and place that version in a shared directory for the QA to pick up
• Scripted the DB so that you can easily upgrade the database rather than being forced to take an out of date copy polluted with irrelevant data that other devs have been playing with.
• Introduced proper bug tracking and triage process
• Researched how we could migrate from winforms to wpf
• Looked at CAB (composite application) or plugin frameworks so configuration would get simplier. (At that time setup and configuration was a tremendous amount of time)

Other things I would do now might be

• Look at Postsharp to weave cross cutting concerns which would simplify logging, exception handling or anywhere code was repeated over and over again
• Look at Automapper so that conversions from one type to another was driven by configuration rather than changing code in many places.
• Look at education around TDD (if you dont do it) or BDD style unit tests.
• Invest time in streamlining automated integration tests. (As this one is difficult to set up and configure manually it tends to get dropped of within SDLC)
• Look at the viability on dev tools such as Resharper

HTH

Answer 3

My attitude is that one should almost never write standard libraries. Instead, one should refactor existing, working code to remove duplication and improve ease of use and ease of testing.

The result will be very much like a "standard library", except that you will know that it works (you reran your unit tests after every change, right?), and you'll know that it will be used, since it was already being used. Otherwise, you run the risk of creating a wonderful standard library that isn't used and doesn't work when it is used.

Answer 4

Some of the major things we do:

• Logging (with some wrappers around TraceSource)
• Serialization wrappers (so you can serialize/deserialize in one line of code)
• Compression (wrappers for the .NET functionality, to make it so you can do this in one line of code)
• Encryption (same thing, wrappers for .NET Framework functionality, so the developer doesn't have to work in byte[]'s all the time)
• Context - a class that walks the stack trace to bring back a data structure that has all the information about the current call (assembly, class, member, member type, file name, line number, etc)
• etc, etc...

Hope that helps

Answer 5

Here is one thing that can keep all developers busy for a month:

1. Run your apps' unit tests in a profiler with code coverage (nUnit or VS Code Coverage).
2. Figure out which areas need more tests.
3. Write unit tests for those sub-systems.

Now, if the system was not written using TDD, chances are it'd be very monolithic and will require significant refactoring to introduce test surfaces. Hopefully, at the end of it you end up with a more modular, less tightly coupled. more testable system.

Answer 6

ok, most importantly, don't reinvent the wheel!

Spend some time researching libraries which you can easily leverage:

• For logging I highly recommend Log4Net.
• For testing nUnit
• For mocking, Rhino.

Also, take a look at Inversion of Control Containers, I recommend Castle Windsor.

• For indexing I recommend Solr (on top of Lucene).

Next, write some wrappers:

These should be the entry point of you API (common library, but think of it as an API).

Focus on abstracting all the libraries you use internally in your API, so if you don't want to use Log4Net, or Castle Windsor anymore, you can by writing well structured abstractions and concentrating on loosely coupled design patterns.

Adopt Domain Driven Development:

Think of API(s) as Domains and modular abstractions that internally use other common APIs like you common Data Access library.

Suggestions:

I'd start with a super flexible general DAL library, that makes it super easy to access any type of data and multiple storage mediums.

I'd use Fluent nHibernate for the relational DB stuff, and I'd have all the method calls into the you data access implement LINQ, as it's a c# language feature.

using LINQ to query DBs, Indexes, files, xml etc.