Develop design and coding standards, OOP 2

[SharkTooth]

I tried this discussion on the OOP forum but didn't get anywhere. I don’t know a better place to put it on tek-tips, so here goes...

I have just been tasked with developing and executing a plan to move the developers to an OOP design and development process. There are 4 developers including myself and I am the only one with any OOP experience. I am the new guy on the block so I have to be careful. We are a Microsoft shop and will be using .Net (looks like my boss wants VB.Net I work on that). Most of the new activity will be web applications (ASP.Net).

Any ideas, suggestions or books would be great. I have a great opportunity to get this off the ground the right way and don’t want to screw it up.

My manager’s expectations (they are still evolving):
1.) Just about all new development in VB.NET (I'll get him to go C# soon) mostly web based.
2.) Create a development process that is easy to follow for use in an environment where smaller applications are the norm.
3.) Create and document code libraries.
4.) Create coding standards.
5.) Create a peer review process.
6.) Implement a 3-tear architecture. (Presentation, Business Rules, Data Sources)

Right off the top I know I have to:
1.) Get an understanding of the existing processes (we really don’t have one)
2.) Get input for the other developers; get them involved in the decision-making.
3.) Get advise from people that have had this experience (you guys).
4.) Get the team some .net and oop training.

I would like to hear:
1.) Suggestions for a design methodology (books too).
2.) Suggestions for building the foundation of the libraries.
3.) Possibly some architecture suggestions

Actually any ideas or suggestions you have to offer would be great. I have a great opportunity to get this off the ground the right way and don’t want to screw it up.

Thanks for your ideas.

 

[chiph]

Two suggestions:

1) Go to

http://www.pragmaticprogrammer.com

and buy their starter series of books. You'll have info on best practices for version control, unit testing, and automating your tools. Can't recommend it enough.

2) For coding standards, Microsoft published a whitepaper that's now available via MSDN. Unfortunately, they've redesigned their site and now it's worthless (no tree-view anymore), so I can't find a link to give you.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[Zech]

There is one thing that you may need to remember as you are helping transitioning your colleagues to OOP:

OOP is just one approach to programming. OOP is not necessarily better than the linear programming approach nor is linear programming better than OOP. There are many fine, time-tested software, such as Unix system and even the core of Windows OS, that were written in C using linear approach (although Microsoft later builds some wrappers around it to facilitate later OOP development on Windows). What matter most is about formulating the best and most efficient solution in solving the problems, and not whether it is OOP or not. So when you are 'preaching' the OOP ideas to your colleagues, keep an open mind and try to convey OOP as another route that they can take to solve their programming problems. In some situations OOP solves problems more efficiently than linear, in other situation linear may be better than OOP. So being flexible and knowing both approaches do make programmer's life a lot easier (Plus, it's a worthwhile investment for their career as well).

About creating reusable libraries, there are many books and references about pattern-based programming. Theoretically, by sticking to these common design patterns, you will be able to create well-designed libraries that are effective and can be easily extended (MFC is a fine example of pattern-based programming). In practice, however, implementing these designs is never easy although they do help.

Also, I am not sure how difficult it is to transition from VB.Net to C# but I had one disastrous experience in trying to convert my colleagues (well-versed VB programmers) to C++. Since I started off my early career as a C/C++ programmer, I was (still am) more familiar with C/C++ than other programming languages. So, at that time, I felt that moving to C++, with its OOP support, flexibility, and greater control over software performance, was a logical move if the team was to create a high-quality software. Although my colleagues were initially enthusiastic about learning C++, they apparently didn't expect the level of difficulty that they were about to face in learning C++ (Well, actually it was not difficult, it's just that they need to manually take care of things that were done automatically by VB). So, in the end, they revert back to VB - leaving me and one other guy coding in C++ making COM objects so that our C++ and VB codes can work together. So you may want to make a good preparation before getting them to C#.