Home > Software Development > What do you consider good software development practices?

What do you consider good software development practices?

It seems developers best practices they follow are all over the place.  Some good, some bad but most fall somewhere in the middle.  I think language and learning styles; a lot of the time has different developers arguing about the best way to do things but really they are talking about the same things.
Also we seem to be creatures of habit that don’t always take well to change or a different way of doing things.  I find this leads to a lot of animosity and people making snide remarks about others people work when in fact it’s just a case they don’t understand and it appears that is the popular mechanism to comfort ones self.
Past that, what I find as the more experience I gain and the more I rely on patterns, the principles I try to adhere to are "Loosely Coupled" and "High Cohesion".  (I have to throw a bone the way of Dino Espisto and his latest Architectul book listed in my book list for completely clearing this up for me.)
When you come up with your base principles everything is golden, right?  There is nothing that can stand in your way.  Wrong.  There is no such thing as a black and white flow chart that you can create to write "good code".  However, I feel that if you develop a couple of good sound principles and then start with them on your work and then analyze each situation when you may have to deviate, it gives you the best chance of success while also at the same time allowing you to get product out the door.  When you veer too far to the left, your productivity in the short term increases but at the expense of flexible code and a lot of times you pay the price down the road exponentially as the product grows.  If you veer too far to the right, then you can start suffering from paralysis by analysis and your productivity drops when you try to prepare for everything down the road.
Now that we have some ground work laid, lets start a topic that hopefully will spark a passionate discussion for all of us to benefit from.  I find myself most working with layered applications. (N-Tiered).
I remember when I started working on my first apps I would get a couple of ideas, and dive right in.  I would probably create my database, then build my endpoints to interface with the database and then I would call those functions directly from my application pages and as long as "things worked" I thought I was golden.  After all, getting things out the door as quickly as possible that worked is the goal right?
As you mature as a developer, or at least in my experience, just getting something out the door is just the beginning of the journey.  Things change, improvements are made, additional features are requested etc.  Please, a raise of hands out there who have been asked to work on an app, whether they designed it or inherited and add features or fixed problems.  The more you got into it and accessed what needed to change, the more you realized it would take less time to rewrite the entire app from scratch???  Come on don’t be shy.
The more I run into these situations the more determined it makes me to spend more time planning and trying to come up with "flexible" code with not only the goal of getting a great original product out the door.  But also a product that provides the most flexibility within the time given to finish the product.
So now the LOB (Line of Business) apps I create, whether I use WCF for the middle tier or not I try to follow a couple of patterns.  I usually try to do this no matter the size of the app because as the saying goes, most large apps started out as small ones.  (Or something like that.)  The only times I try to deviate is if I’m writing a throw away app.  Say something for a demo or something.
  • Of course there will be the UI layer. 
  •  If I need dynamic configurability, I usually add a configuration assembly utilizing ConfigurationSections. 
  • Next I always create a Business Layer.  Lately I label my classes as Providers.  I follow the provider module and implement a factory pattern to where I define an interface with all the functionality a provider should have.  Next I create a ProviderFactory and using generics and reflections, any code that needs to use the BLL goes through the ProviderFactory.CreateProvider method.  I define the provider that can be used in the appSettings of the config file.  I feel this gives me a way to change my providers to use any type of data interfacing technology I choose to use or change to down the road with minimal effort and in most cases no major code changes in the production environment.
  • Next there is the Data Access Layer.  My preference right now is to use ORM’s as they give me the functionality and performance I need and cut down on development time exponentially.  Plus I’m a fan of having strongly typed data objects for interfacing into the database.  I’m also a fan of separating development objects from database objects.  Or at least having the flexibility of doing so.  Presently I use LLBL Gen Pro.  I’m a fan of Linq to SQL but there are limitations I find with the product right now so I don’t use it in large applications right now.  But I do hope Linq or something like it does eventually take off.  I’m a proponent that developers exist to provide solutions to problems and our job is not just about sitting around trying to figure out every technology there is out there.  As much as I would love that to be my job it’s not the reality and I applaud technologies that give us great options to be productive and take more of our focus off of technology so we can focus more on the businesses needs write for.
  • Data Contracts – I’m not a fan of accessing my database objects directly.  There’s obvious reasons like you need to change the table names etc.  Other reasons though now I use ORM’s and LLBL Gen, I still want the flexibility change to any technology I need to with minimal effort.  Creating data contracts with translators to translate the DAL objects to your data contracts and use those in the layers above the BLL is my preference.  With the use of macros to generate code, it’s not that much more work.  The ability to change an ORM also ties into the ProviderFactory as I can create new providers that utilize different data access technologies and then plug the new assemblies into production code seamlessly.

I’m out of time for now.  I would love to hear thoughts and feedback from others on their best practices.

Categories: Software Development
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: