C/C++ Working Professionals

[sedawk]

Hi,

I am not working C/C++ as my main programming language but have, I guess below-medium level C/C++ skill with single components. If more complicated development then I need assistance. Besides, I am not working in a group.

Here is the question for the ones working on C++ daily in companies or teams:

What are the working experiences to organize or manage the programming processes? Especially when facing the situation a couple components are being developed at the same time. I am not meaning on coding style management.

I hope a lot of gurus here can share their experiences. If small example provided that will be very great.

Thanks

 

[LazyMe]

I don't think your question relates to C/C++; it is language independent what you're asking...

The same approach would be taken in C/C++ as well as VB, Java, .NET (need I go on?)...

Greetings,
Rick

 

[sedawk]

Rick,

Sure please kindly go on. You are right this is a question independent to C/C++. I just happened to use C/C++ at this moment.

I also want to make some supplement to my question: how is the partitioning of a whole project? I know these questions don't have standard answers but just working solutions. 'cause what I am thinking is how to prepare myself in the future integrate into a development team.

Thanks.

 

[PerFnurt]

Well, Im working with in fairly large C++ product (some 10.000 files). It is all divided into components and some 30 subsystems, each susbystem having someone responsible for it. Susbsystems are grouped into front-end (ie apps with a GUI) and back-end (apps without GUI).

Being part of the software architecture team we work on the over-all design issues, keeping it "together".

When it comes to parallell development it is mainly an task of doing things in the right order:
1) Design
2) Define interface(s)
3) Write tests
4) Implement

alternative

3) Implement just the interface if that helps work on the "other" component and then at a later time:
4) Write tests
5) Implement the rest

Not sure this is what you're asking about though...


/Per
_{Nerdy signatures are as lame as the inconsistent stardates of STTNG.}

 

[sedawk]

Per,

Thanks for your reply. What you told me is part of my questions. Let's zoom in a little bit:

Say your project needs to do an interface design, just a simple popup window with some simple toolbar. There are many ways to do that in textbooks, how do you justify which way is the best?

how you integrate all 10,000 files together is the thing I am eager to know. I simply don't see how the stuffs in textbook(ususally simplified version of real world, my personal view) connecting to the real projects.

Thanks,

 

[PerFnurt]

How to justify what way to pop up a message? Well, it depends on the over-all design, it could be good to do it in the same manner as you show other other messages.

The obvious key to it all is having a suitable design

Perhaps splitting it into subsystems that in turn is split into components that in turn is split into classes.

Then it is important to define a clear responsibility of the various components on each level, who-does-what, etc.
If you find yourself with a component doing "this-and-that" and/or has a name that ends with "Manager", "Mgr" or "Handler" chances is good it would benefit in being split up in smaller components with a more clear responsibility.

Given your example I'd let the susbsystem that is responsible for popping up messages do it, so the place to put it would be quite obvious. This implies that there should be one (and only one) subsystem that has the responibility of notifying the user with messages, that it is the "expert" of.

Guidelines is also a must. Design guidlines on the large scale and coding guidelines on the smaller scale. It would be unmanageble to have each developer using his/hers own favourite indentation, naming convention etc. What guidlines to use is up to each organization to decide, but should of course be based on the rule that "the best argument wins - whoever said it" (as with a lot of other things).

A guideline could be "One-class-per-filepair. Filenames shall be same as the class name". Perhaps that'd bring a lot of files but it helps in keeping it structured (even if there's a few exceptions).

"A class shall have one main responsibilty that it handles, and handles well." and "A function/method shall do one thing and do it well" is also ideas used to keep stuff manageble.

Anyway, it is not impossible to keep a big project together (not that I say it is easy), all you need to have a mindset like "think first - code later".




/Per
_{Nerdy signatures are as lame as the inconsistent stardates of STTNG.}

 

[sedawk]

Per,

I guess I need some time to digest what you said. The essence is to specilize functions, subsystem, or components to smaller parts, right?

As for guidelines, sometime I had this experience: I get used to one method to do one thing, but when look at others' codes, they had totally different approaches. It is kind of "what the textbook tells me to do this in this way, why you can do that way?" question. Probably is from experiences and practices.

Thanks

 

[benlinkknilneb]

sedawk,

It's all about experience and practice; I tend to disagree with textbooks. Heck, I even disagree with professors if I'm sure I know what I'm talking about.

My best advice to you is to *always* be open to a different approach. With programming, you'll find it's as much an art as it is a science, and your method may be totally different from mine. The key to making them work together is to design the application completely before beginning any sort of coding. Everyone who works on it has to know what direction it's going in. Then you break it up into parts that can be encapsulated; by that, I mean that (assuming I'm the project manager) I assign you a section to write, I tell you what gets passed into it and what gets passed out of it, and I don't worry about your programming style along the way. As long as we can agree that the code does what it's supposed to do accurately and efficiently, it's really comparing apples to oranges to say "you wrote it in this fashion; I'd have done it this other way".

As a programmer, it's important to know different ways to do the same thing; there are cases where one method is the best way to do something, and then there are cases where it's the worst way to do it.

In terms of project management, I'd say that it should NOT be organized on a line-by-line basis (e.g. I always put a tab when I go one level deeper into an "if" structure). The project should be organized based on functionality; like "this source file contains the database access functions, and this one over here contains the statistical calculations, and this third file contains the code that interacts directly with the user."


My $.02.
Ben

 

[PerFnurt]

>As long as we can agree that the code does what it's supposed to do accurately and efficiently,

By that I assume it should also be manageble, extensible and removeable? Issues that are so easy to neglect, specially if the work is 100% project-driven (ie "just do what you gotta do for this project, as fast as you can, no extras&quot

>it's really comparing apples to oranges to say "you wrote it in this fashion; I'd have done it this other way".

That is normally not for the project manager to say. His/hers job is to get the product (as defined by the market representatives) out to the market at the planned release date.

However, assuming that the product actually has a lifetime, and will get, if not bigger, at least altered with every version, you (or some sw-architect or similar) do need to think ahead and beyond the scope if the current project and might well say "if we write in in this fashoin we'll get into big trouble later, lets do it this other way instead even though it takes us 3 times longer" which may very well be in conflict the the project managers ideas of what need to be done.

>The project should be organized based on functionality

Maybe so, but the project/functionality isn't everything.



/Per
_{Nerdy signatures are as lame as the inconsistent stardates of STTNG.}

 

[benlinkknilneb]

You're right, Per;

I didn't clarify my response. I was assuming that the code was well-documented (which would make it more manageable; extensible and removable are covered by my comment about encapsulation). Part of making the decision about which is the best way to do something *is* determining how it affects the future of the application; I neglected to mention that (although it was implied in my statement that it's important to know different ways to do the same thing).

Overall, I'd have to say that there is no "right" method to the coding process; by that I mean a method that is correct 100% of the time. Textbooks can only give you direction and syntactic understanding. Whether method X is the appropriate way to do a specific task in a project is something that should be decided when the project is being designed, and all of these factors we've mentioned are taken into consideration.

The project's organization should also be part of the design; my statement that it should be based on functionalities was biased to my own personal approach. It's something that should be agreed upon by those in charge of the project.

 

[sedawk]

Hi Per & Ben,

Ok, it is nice to see your replies when I am back. Some key notes are worthy mentioning again:

>>A guideline could be "One-class-per-filepair. Filenames shall be same as the class name".

>>a mindset like "think first - code later"

>>As a programmer, it's important to know different ways to do the same thing

>>*always* be open to a different approach

>>do need to think ahead and beyond the scope

Thanks a lot.