问:
Story points for bug fixing tasks: Is it suitable for Scrum?
I'm just wondering if we should assign story points to bug fixing tasks or not. JIRA, our issues-tracking software, does not have story point field for Bug type issues (it's only for Storys and Epics).

Should we add the Bug issue type to the applicable issue types of the Story Points field?  What are the pros and cons? Would it be suitable for Scrum?

答:
Instead of the focus on stories and bugs and chores and the points each has, I find it better to focus on delivering features for the customer.

Customers expect the software to work and only give real value to development, enhancements and new features as these drive the business forward.

Bug fixes, as important as they may be, do not drive the business forward into new areas and new customers (tangentially and eventually perhaps yes but not immediately which is what management is measuring).

So points are best viewed from the higher viewpoint of velocity and how many points per week have been done historically for similarly scored stories.

This can lead to a management by track record history rather than pushing the urgent need for this weeks stories to be complete and frequently finding that they are not.  However the loss of up-front control and increased trust that this requires will have some managers running for the door in horror.

I use Pivotal Tracker (I've just JIRA, Trak, Trello and others too) and Pivotal Tracker also does not do points for chores or bugs.  It's done for the same good reasons above that make it also true in JIRA as you are seeing yourself.


问:
Is there a good reason to avoid node.js for non-realtime web apps?
I've seen a lot of talk about how awesome Node.js is for realtime web apps -- things that need sockets, Comet, AJAX-heavy communications, and so forth. I know that its event-driven, asynchronous, thread-driven model is also good for concurrency with low overhead.

I've also seen Node.js tutorials for more simple, 'traditional', non-realtime apps (e.g., the standard blog example, which seems to be the standard 'Hello World' for people learning app development). And I also know that node-static allows you to serve static assets.

My question is: is there any good reason to avoid Node.js for traditional web apps, like classifieds, forums, the aforementioned blog example, or the sort of CRUD apps you build for internal business applications? Just because it excels at all the funky realtime stuff, does that contraindicate it for more staid uses?

The only thing I can think of, off the bat, is the lack of mature libraries (although that's changing).

(The reason I'm asking is that I'm considering ditching PHP for Node.js, mostly to get over the impedance mismatch of switching between languages, but also so I can reuse validation code and whatnot. My superego admonishes me to choose the best tool for the job; however, I don't have a lot of time to learn fifteen languages and all their userland libraries just to have a comprehensive arsenal. It's also reassuring that Node.js might give me an easier optimisation path than PHP/Apache in the future when I have to start thinking about heavy traffic.)

[EDIT] Thanks for the answers so far, folks; I just want to see if anyone else will weigh in before I choose an answer. The answer from @Raynos kinda confirms what I'm thinking, and the links from the commenters provided good food for thought, but I want to see if anyone else has any Node-specific answers, like 'DON'T USE NODE FOR PROBLEM X'. (Besides high-CPU tasks; I know that already :-)

答:
A good reason to have seconds thoughts about node are not technical - it's great and amazing at what it does.

They are business and specifically human capital, i.e. programmers who know it, how much they cost and their availability.  It's not that hard to learn, but as with any newer technology the number of people who know it well (or want to) is a subest of the larger pools of workers.

ContentLicense: CC BY-SA 3.0


问:
How does a garbage collector prevent the whole memory from being scanned on every collect?
Some (at least Mono's and .NET's) garbage collectors have a short term memory area which they scan often, and a secondary memory area which they scan less often. Mono calls this a nursery.

To find out which objects can be disposed of, they scan all objects starting from roots, the stack and the registers and dispose all objects that aren't being referenced anymore.

My question is how they prevent all in use memory from being scanned on every collect? In principle, the only way to find out what objects aren't in use anymore is to scan all objects and all their references. However, this would prevent the OS from swapping out memory even though it isn't in use by the application and feels like a huge amount of work that needs to be done, also for "Nursery Collection". It doesn't feel like they're winning much by using a nursery.

Am I missing something or is the garbage collector actually scanning every object and every reference every time it does a collection?

答:
The oldest and simplest generation of garbage collectors actually did scan all of memory, and had to stop all other processing while they did it.  Later algorithms improved on this in various ways - making the copy/scan incremental, or run in parallel.  Most modern garbage collectors segregate objects into generations, and carefully manage cross-generational pointers so newer generations can be collected without disturbing older ones.

The key point is that garbage collectors work in close collaboration with the compiler and with the rest of the runtime to maintain the illusion that it is watching all of memory.


问:
Git workflow / practices for a small project (flowchart in png)
I'm trying to come up with a personal workflow. I've put together a flowchart of the hypothetical lifespan of a release: one developer pushing to a public github repo + a friend helping with some feature and fixing a bug.

Is this a reasonable approach to version control?

The main idea is to keep the public repo tidy:

Each new release gets on its own branch until it's finally tagged in the master branch when it's finished.

All work is done on "feature" or "hotfix" branches, never on an actual release branch, to prevent anomalies.

Merges to higher-level branches are always rebased or squashed (to avoid clutter).

If it's overkill I don't mind because the whole point is for me is to learn skills I might need for a larger project. The only problem would be if I'm doing something flat out wrong or unnecessary.

edit 2: fixed bad idea in the original flowchart and made it a bit easier to navigate.

答:
What I see a lot in the git/github community is this

branches
master
develop

You and contributors work primarily in develop, but someone may have an idea or new feature, so you create a topic branch like git checkout -b user_comments.

Then as you progress through the development you push to master once you git a version you are happy with and tag that in the master branch as 1.0 or 1.1.2 etc ( look up semantic versioning )


问:
Reasonable test coverage requirements when dealing with a contractor?
We're outsourcing some work to an external developer, so I'm busy writing up a contract about what constitutes a deliverable.

So far I require that the code is shipped with automated tests.

But, what is a reasonable way to specify the detail of tests up-front in the contract in a measurable way?

I'm loathe to say "100% code coverage" because it's been established pretty often that 100% is pretty meaningless, and the diminishing returns above about 70-80% would probably just be pushing up our costs unnecessarily, and possibly even pushing up the complexity of certain things that might otherwise be very simple.

Internally we pretty much leave it up to our developers to decide on the level of tests needed, based on their intuition and experience. With a contractor however there is a fixed price that has to be agreed to up front and we need some way to enforce a certain level of quality.

Any suggestions or recommended reading matter would be appreciated!

答:
Testivus on Test Coverage -- From the Google Testing Blog:

Early one morning, a young programmer asked the great master:

“I am ready to write some unit tests. What code coverage should I aim for?”

The great master replied:

“Don’t worry about coverage, just write some good tests.”

The young programmer smiled, bowed, and left.

Later that day, a second programmer asked the same question.

The great master pointed at a pot of boiling water and said:

“How many grains of rice should put in that pot?”

The programmer, looking puzzled, replied:

“How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”

“Exactly,” said the great master.

The second programmer smiled, bowed, and left.

Toward the end of the day, a third programmer came and asked the same question about code coverage.

“Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table.

The third programmer smiled, bowed, and left.

After this last reply, a young apprentice approached the great master:

“Great master, today I overheard you answer the same question about code coverage with three different answers. Why?”

The great master stood up from his chair:

“Come get some fresh tea with me and let’s talk about it.”

After they filled their cups with smoking hot green tea, the great master began:

“The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.

The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”

“I see,” said the young apprentice, “but if there is no single simple answer, then why did you tell the third programmer ‘Eighty percent and no less’?”

The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down.

“The third programmer wants only simple answers – even when there are no simple answers … and then does not follow them anyway.”

The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.

ContentLicense: CC BY-SA 2.5


问:
Object Oriented Programming: getters/setters or logical names
I'm currently thinking about an interface to a class I'm writing. This class contains styles for a character, for example whether the character is bold, italic, underlined, etc. I've been debating with myself for two days whether I should use getters/setters or logical names for the methods which change the values to these styles. While I tend to prefer logical names, it does mean writing code that is not as efficient and not as logical. Let me give you an example.

I've got a class CharacterStyles which has member variables bold, italic, underline (and some others, but I'll leave them out to keep it simple). The easiest way to allow other parts of the program to access these variables, would be to write getter/setter methods, so that you can do styles.setBold(true) and styles.setItalic(false).

But I do not like this. Not only because a lot of people say that getters/setters break encapsulation (is it really that bad?), but mostly because it doesn't seem logical to me. I expect to style a character through one method, styles.format("bold", true) or something like that, but not through all these methods.

There is one problem though. Since you can't access an object member variable by the contents of a string in C++, I would either have to write a big if-statement/switch container for all styles, or I would have to store the styles in an associative array (map).

I can't figure out what the best way is. One moment I think I should write the getters/setters, and the next moment I lean towards the other way. My question is: what would you do? And why would you do that?

答:
I think you are over-thinking the issue.

styles.setBold(true)  and styles.setItalic(false) are OK


答:
After working with node for a few weeks, I'd say yes, its very cool.  But not necessarily something you'd want to use to replace your run-of-the-mill web apps with... nor, imo, is it intended to be.

Remember, node is its own server.  This introduces complexities if you want to run more than just your one node.js application.  ie, if you have more than one site/domain hosted on a machine.  Its not like a LAMP stack, where you can have a dozen PHP applications for a half dozen different domains running off the same server (on port 80, at least).  There are frameworks for node that probably make it possible, but thats adding complexity that you just dont need if you stuck to traditional web platforms.  (You can, of course, also set up proxies by putting a web server in front of node, but that sort of defeats the benefit of using node).

imo, Node is perfect for working in conjunction with a traditional web server.  The way I have things organized now is to serve up the static html/js/images via apache, and handle the 'real time' data needs by long polling to the node application.

Title: Is there a good reason to avoid node.js for non-realtime web apps?

Body:
I've seen a lot of talk about how awesome Node.js is for realtime web apps -- things that need sockets, Comet, AJAX-heavy communications, and so forth. I know that its event-driven, asynchronous, thread-driven model is also good for concurrency with low overhead.

I've also seen Node.js tutorials for more simple, 'traditional', non-realtime apps (e.g., the standard blog example, which seems to be the standard 'Hello World' for people learning app development). And I also know that node-static allows you to serve static assets.

My question is: is there any good reason to avoid Node.js for traditional web apps, like classifieds, forums, the aforementioned blog example, or the sort of CRUD apps you build for internal business applications? Just because it excels at all the funky realtime stuff, does that contraindicate it for more staid uses?

The only thing I can think of, off the bat, is the lack of mature libraries (although that's changing).

(The reason I'm asking is that I'm considering ditching PHP for Node.js, mostly to get over the impedance mismatch of switching between languages, but also so I can reuse validation code and whatnot. My superego admonishes me to choose the best tool for the job; however, I don't have a lot of time to learn fifteen languages and all their userland libraries just to have a comprehensive arsenal. It's also reassuring that Node.js might give me an easier optimisation path than PHP/Apache in the future when I have to start thinking about heavy traffic.)

[EDIT] Thanks for the answers so far, folks; I just want to see if anyone else will weigh in before I choose an answer. The answer from @Raynos kinda confirms what I'm thinking, and the links from the commenters provided good food for thought, but I want to see if anyone else has any Node-specific answers, like 'DON'T USE NODE FOR PROBLEM X'. (Besides high-CPU tasks; I know that already :-)


问:
Data Quality in Relational Database Regression Tests
I have been working on an open source Museum Collections Management web application that is to be used to keep track of a museum's accessioned, donated, loaned or otherwise acquired artefacts.

This involved designing and creating a rather large database (in relation to my previous experiences), which stores all kinds of varying information (artefact information, changing location information, personal contact information, pictures, etc), that needs to be flexible and easily extendible.

I am just finishing my university degree and I am not a professional when it comes to database design and so I am really wanting to create a thorough test suite to ensure that what I have in place "works".

I have read up on database testing and have come across a few articles that mention Regression Testing in regards to databases but I do not fully understand what this all involves. From reading this article at Dr.Dobbs I understand that one sort of testing that I will need to do is validate that the logic in the database is correct. So I would create tests that insert certain data into the database and then follow it up with a query to ensure that I get the correct data back from the database (ensuring that all the appropriate triggers or views are working).

The confusion comes in with the mention of testing for "Data Quality". In the article above the author makes mention that you want to validate the following with tests:

Column domain value rules

Column default value rules

Value existence rules

Row value rules

Size rules

What types of tests would this involve and how would they be implemented? Also this is my first time writing a test suite for a database, are there any good guidelines on how/where to begin or any processes that I could follow to guide my test development?

答:
A complete answer to this question would be very long. I will try to mention the main points.

To separate concerns, you may be looking at tests to:

A - Validate the database design.

B - Validate that the program(s) are interacting correctly with the database.

The database design validation should be performed by the person(s) who designed the database. The developers (while unit testing) should be concerned more with part (B). The primary difference I see between the two types of tests is the tools used. For (A), you'd use an environment independent of the project code, whereas on (B) you'd of course use the project's code. In the following text, I will mix both.

To answer your specif questions:

Column domain value rules

Each column has an associated data type. Each column must be validated against business rules to prove that it represents the correct data type. Problems may arrise if the column data type is not compatible with business requirements or if the code uses a data type different from how it is defined in the database.

For example:

If the column is defined as small int, you should not be able to store text in it. This is an important test specially when the columns are optional, since it could go unnoticed until someone actually enters some data in it.

Could you store a negative value in a column where the business requires that to happen?

Column default value rules

Some columns are associated with a default value specification in the DDL (Data Def. Language) where if during insert the insert does not provide a value, the database will assume the default value. This can be tested by not passing the value and observing the result value the database stores. This test may also include checking for Nullable columns. This rarely requires a test since it can be verified from DDL unless an unique index is built on the column.

Value existence rules

As I understand this, you verify that data inserted or updated shows as expected in the database.

Row value rules

I am not clear on what this one means exactly.

Size rules

Each column has a size in the database based on how it is defined in DDL. you want to make sure that any value that fits requirements(either entered form GUI or resulting as an output of a computation) would be stored correctly in the column. For example a Small Integer data type does not allow you to store a value of 5 billions. Also, a name defined as VARCHAR2(30) will not accommodate 40 characters, so business rules must be very clear here, specially when the column is used for aggregating data. You want to test what happens in such situations.

guidelines on how/where to begin

One way of doing this is to come up with a testing plan. You want to ensure you are using the correct version of specifications (such as requirements documents and Use Cases) and of the software. You also need to coordinate thes tests with tests done by Unit Testing (if any). You may find duplicate tests that you don't need to perform again. You want to take a copy of the database before testing so that you could repeat a specific test if you ever needed to. The DBA may help you with this. You also need to check with your team how do they document theses tests and verify the testing scope with them. You can break your database into logical parts and begin the testing of each logical part separately. The testing process could begin by studying the DDL of the database and verifying that the columns are defined correctly as required by the business. You should be using the application's software and not any other tool to perform the majority of the tests. For example question the following:

Is the column supposed to be of the defined type (no point in making a Name as Int).

Is the size compatible with business requirements?

Are all the columns in business requirements found in the database?

Are null columns really optional?

etc.

Next, you could design test cases to test the above. You could use the GUI to do most of the tests.

There are other important database tests that you have not mentioned. Those deal with:

1 - Testing that the primary keys are really unique from a business perspective.

2 - Testing that unique indexes (other than the PK) are really unique from business perspective.

3 - Testing Foreign Key constraints work.

4 - Testing what happens when a rows is deleted and its effect on related rows.

5 - Other tests regarding special database constructs such as CHEKC, Triggers if they exist.

6 - Correct table normalization and that normalized columns hold correct values.

The above is not a complete list but it should get you started.


问:
Carpool logical architecture
I'm designing a carpool system (drivers can publish their routes and passengers can subscribe to them) with WebServices(axis2) and Android clients (ksoap2).

I have been having problems with the logical architecture of the system and I wondered if this architecture is fine.

And another question: for that architecture (if it is ok), how would be the packages structure?

I suppose something like that:

(In android)

package org.carpool.presentation

*All the activities here (and maybe mvc pattern)

(In the server)

package org.carpool.services

*Public interfaces (for example: register(User user), publishRoute(Route route) )

package org.carpool.domain

*Pojos (for example: User.java, Route.java, etc)

package org.carpool.persistence

*Dao Interface and implementation (jdbc or hibernate)

答:
A carpool business is based on a good backend story. A few challenges that can surface are

A carpool backend system is the efficiency of the search. If the search is quick and efficient, the entire system proves to be useful. As the database grows the search can only become worse. The question is how do you keep your search efficient as your database grows.

What business model do you follow, is they key. If you are catering to a cab system, and not a carpool system then what will be the impact of this change on your design ? Will you need to change your entire backend too ? Very costly affair.

Competition, there is so much out there, but frankly not enough :). the carpool websites out there are left to grow under "God's grace". Website owners develop the website like a blog and "hope" people will just walk in.

Every website is offering a different solution, but just not able to meet up due to above challenges. That said, there is value in this business since there is so much opportunity.

We thought of this a few years back and developed a core engine that will enable businesses to just use our framework and build their car pooling website, mobile app. You only need to worry about your upper business layers. Think about it, instead of starting ground up, integrate our framework and use api calls like AddUser, AddVehicle, AddCarProvider, SearchCarProvider.

Title: Carpool logical architecture


答:
I think you are approaching this the wrong way.

Any database I know verifies data before inserting it into tables - it validates it against the definition of each column. You can't enter a 80 character string into a SMALLINT(3) column - the database will fail that attempt and let you know you've made an error. You don't need to test for that yourself by inserting the data and then retrieving it.

What you do want to have are validation / filtering rules on data before it is sent to the database.

Making sure the data fits the accepted types and range for each column, and filtering unwanted content

Making sure to properly escape it to avoid errors (and possible SQL injections if you have a public interface)

Those validation / filtering rules should run on the data in your actual application. You can then setup tests to make sure they are correct, by feeding it with correct and incorrect data to make sure it passes or fails validation accordingly.

As far as database design goes, you can't really verify it with tests - since many designs will work even if they are not ideal (and the definition of ideal changes between different people). Proper database design comes with experience and knowledge, not with automated tests.

Title: Data Quality in Relational Database Regression Tests

Body:
I have been working on an open source Museum Collections Management web application that is to be used to keep track of a museum's accessioned, donated, loaned or otherwise acquired artefacts.

This involved designing and creating a rather large database (in relation to my previous experiences), which stores all kinds of varying information (artefact information, changing location information, personal contact information, pictures, etc), that needs to be flexible and easily extendible.

I am just finishing my university degree and I am not a professional when it comes to database design and so I am really wanting to create a thorough test suite to ensure that what I have in place "works".

I have read up on database testing and have come across a few articles that mention Regression Testing in regards to databases but I do not fully understand what this all involves. From reading this article at Dr.Dobbs I understand that one sort of testing that I will need to do is validate that the logic in the database is correct. So I would create tests that insert certain data into the database and then follow it up with a query to ensure that I get the correct data back from the database (ensuring that all the appropriate triggers or views are working).

The confusion comes in with the mention of testing for "Data Quality". In the article above the author makes mention that you want to validate the following with tests:

Column domain value rules

Column default value rules

Value existence rules

Row value rules

Size rules

What types of tests would this involve and how would they be implemented? Also this is my first time writing a test suite for a database, are there any good guidelines on how/where to begin or any processes that I could follow to guide my test development?


问:
Rush to client-side in web development
In the past few months, I recognized a big excitement about client-side scripting in web development. But while server-side technologies are mature, stable and well accepted by backend-developers, client-side technologies are immature (i.e. compared to big server-side framework) and disliked by many long-established developers. Nevertheless everyone is doing client-side development these days. I personally expect those big server-side frameworks to disappear in like 2-5 years, watching the current trend.

Why is that so? How could the new and "diffuse" client-side developing in HTML5/JS possibly be superior to big and well thought server-side solutions?

答:
This is true:

Rush to client-side in web development

But it is not confined to client-side, it is a full stack movement.

I know this may be surprising.
Please, hear me out.

Why is that so? How could the new and "diffuse" client-side developing
  in HTML5/JS possibly be superior to big and well thought server-side
  solutions?

First of all, both are well thought out.

Secondly, Because it is better.

Good question.

But "better" is subjective, so the answer to your question is, what specifically is better?

Re-visit the question:

How could "diffuse" client-side developing
  in HTML5/JS possibly be superior to big server-side solutions?

```<code>Because small is nimble.
And big is clunky.
</code>```

It is flexibility.

Doesn't seem like a big deal. Does it? Flexibility.

However, flexibility underlies everything. One improvement in
  flexibility - improves everything.

Maintainability.
Extensibility.
Scalability.
Modularity.
Usability.
UX.

And it is faster to implement.
This is the reality.
Faster and Better.

```<code>This is why Windows 8 made JS a first-class citizen.
</code>```

HTML5 - JS, is not a fad and it will not go away. We are only seeing
  the seeds of a technology that will grow to provide computing content and
  interaction behavior to tablets. Tablets.

Smart phones were the fastest mass-media adoption since the TV in the 1950's.
Now, not only do we have smartphones - we have Tablets.

Already in development at Mozilla and Windows the OS that will run on future devices in their markets -> HTML/JS.

Many solutions and innovations remain.

A full stack of JS is emerging, based on flexibility.

I hope that helps.

Title: Rush to client-side in web development

Body:
This is true:

Rush to client-side in web development

But it is not confined to client-side, it is a full stack movement.

I know this may be surprising.
Please, hear me out.

Why is that so? How could the new and "diffuse" client-side developing
  in HTML5/JS possibly be superior to big and well thought server-side
  solutions?

First of all, both are well thought out.

Secondly, Because it is better.

Good question.

But "better" is subjective, so the answer to your question is, what specifically is better?

Re-visit the question:

How could "diffuse" client-side developing
  in HTML5/JS possibly be superior to big server-side solutions?

Because small is nimble.
And big is clunky.

It is flexibility.

Doesn't seem like a big deal. Does it? Flexibility.

However, flexibility underlies everything. One improvement in
  flexibility - improves everything.

Maintainability.
Extensibility.
Scalability.
Modularity.
Usability.
UX.

And it is faster to implement.
This is the reality.
Faster and Better.

This is why Windows 8 made JS a first-class citizen.

HTML5 - JS, is not a fad and it will not go away. We are only seeing
  the seeds of a technology that will grow to provide computing content and
  interaction behavior to tablets. Tablets.

Smart phones were the fastest mass-media adoption since the TV in the 1950's.
Now, not only do we have smartphones - we have Tablets.

Already in development at Mozilla and Windows the OS that will run on future devices in their markets -> HTML/JS.

Many solutions and innovations remain.

A full stack of JS is emerging, based on flexibility.

I hope that helps.


问:
In C and C++, what methods can prevent accidental use of the assignment(=) where equivalence(==) is needed?
In C and C++, it is very easy to write the following code with a serious error.

```<code>char responseChar = getchar();
int confirmExit = 'y' == tolower(responseChar);
if (confirmExit = 1)
{
    exit(0);
}
</code>```

The error is that the if statement should have been:

```<code>if (confirmExit == 1)
</code>```

As coded, it will exit every time, because the assignment of the confirmExit variable occurs, then confirmExit is used as the result of the expression.

Are there good ways to prevent this kind of error?

答:
A traditional way to prevent the incorrect use of assignments within expression is to place the constant on the left and the variable on the right.

```<code>if (confirmExit = 1)  // Unsafe

if (1=confirmExit)    // Safe and detected at compile time.
</code>```

The compiler will report an error for the illegal assignment to a constant similar to the following.

```<code>.\confirmExit\main.cpp:15: error: C2106: '=' : left operand must be l-value
</code>```

The revised if condition would be:

```<code>  if (1==confirmExit)
</code>```

As shown by comments below, this is considered by many to be an inappropriate method.

Body:
A traditional way to prevent the incorrect use of assignments within expression is to place the constant on the left and the variable on the right.

if (confirmExit = 1)  // Unsafe

if (1=confirmExit)    // Safe and detected at compile time.

The compiler will report an error for the illegal assignment to a constant similar to the following.

.\confirmExit\main.cpp:15: error: C2106: '=' : left operand must be l-value

The revised if condition would be:

  if (1==confirmExit)

As shown by comments below, this is considered by many to be an inappropriate method.


答:
The best technique is to increase the warning level of your compiler.
It will then warn you about potential assignment in the if conditional.

Make sure you compile your code with zero warnings (which you should be doing anyway). If you want to be pedantic then set your compiler to treat warnings as errors.

Using Yoda conditionals (putting the constant on the left hand side) was another technique that was popular about a decade ago. But they make the code harder to read (and thus maintain because of the unnatural way they read (unless you are Yoda)) and provide no greater benefit than increasing the warning level (which also has extra benefits of more warnings).

Warnings are really logical errors in the code and should be corrected.

Title: In C and C++, what methods can prevent accidental use of the assignment(=) where equivalence(==) is needed?

Body:
In C and C++, it is very easy to write the following code with a serious error.

```<code>char responseChar = getchar();
int confirmExit = 'y' == tolower(responseChar);
if (confirmExit = 1)
{
    exit(0);
}
</code>```

The error is that the if statement should have been:

```<code>if (confirmExit == 1)
</code>```

As coded, it will exit every time, because the assignment of the confirmExit variable occurs, then confirmExit is used as the result of the expression.

Are there good ways to prevent this kind of error?


问:
Comparing one's self to others during interviews
I'm often asked at some point during the interview process to compare myself to my peers.  For example, one of my first after-graduation jobs asked me to compare myself to my classmates.  A job I recently interviewed for asked me to compare myself to my coworkers.

I always play this down quite a bit.  I'm always worried that, "I'm miles above everyone around me," sounds too arrogant.  When push comes to shove though it is the truth.

I graduated at the top of my class.  I had a 3.99, the highest GPA of anyone else that year.  My fellow students bitched and moaned about things like having to use the console to write "javac xxx.java" and build programs instead of just hitting the build button in VS.  Most of them were utterly inept and I'd hate to see what happened to them in the real world.  Others were miles above these people.  There were like 3-5 of us that actually gave a damn, pursued our own education as if it mattered, and had whatever genes are necessary to think like a programmer or mathematician (the one guy I'd say was smarter than me was actually a math major--he graduated one year ahead of me or he would have taken my title).  Even among these few "big hitters" I was one of, if not the best (some was due to more experience though).

For about 90% of the other students though I see this not as me being so good, but them being really that f'n bad.  I was often dumbfounded not just by their ignorance, but by their unwillingness to do what it took to loose it.  My peers in college were lazy, bemoaning, irresponsible, sacks of stupidity that would rather run around puking from so much booze than put out the least amount of effort in learning anything.  Then they blamed their ineptitude on the professors.

As I entered the workforce I found that this trend continued.  When I'm on the internet, talking to a worldwide populace of brilliant people I'm rather mediocre.  I'm smart, excited, etc...I'm still very good but I'm much more able to see myself as a smaller fish in a larger ocean.  Locally though, in personal real life experience....what I find easy others find hard even among what I'd call some of the best developers I've worked with.  I know more about design, general development, and the specific language I use more than anyone else I know.  Part of this is, I know full well, the kind of places I've learned in and where I've worked (who doesn't have the money to pay me what I'm worth).  Still though, if I were to fairly compare myself to my coworkers, and in years past my co-students...don't I come off as more than a little arrogant?

Others see me this way too though.  It actually took me a while to recognize that there's actually something significantly special about the way I approach my programming (I really care), work ethic, and additionally my lucky roll in the gene game.  I have seen it get to my head from time to time, and I try to avoid it, but in all honesty I'm just better than most.

One thing that seems to differentiate me more than anything really is the fact that I continue to pursue greater knowledge at home, off hours.  I'm one of the best because I want to be and it shows significantly.  I've found that this is actually fairly rare in the real world, though many Internet people have me beat here as well.

Knowing that there's certainly many more people like this out there, in fact I know of many people on SE that are much smarter than I am, how do you approach this question?  Do you answer honestly?  "I'm a fucking God that has do dumb down everything thing they do for the little people!  The only way I can drag the rest along is by saying everything 20 times in 5 different ways."  Or do you downplay yourself to make sure you don't come off as someone so damn arrogant they can't work with others?

Edit: Yes, I make grammatical mistakes and additionally many more.  I also suck at welding even though I tried very hard to get it.  I also have a very hard time keeping my house plants alive.  Some people are simply better at it.  I'm simply better at programming.

答:
Silly goose, it's not always about you.

Companies are always looking for influential smart people, because they know if the person is not only smart but also raises the average level of skill/smarts of your other employees then it's a big win.

Every good  programmer gets to a point where he realises that perfection is subjective. Critique and bad news is always free, but good news needs to be searched for or created.

Bias is something better left at home. When interviewers have asked me how I compared to my co-workers, I told them that an efficient team specialises in different areas and our goal was to grow as a team and improve collectively.

Because that was true, but I have had also to state that I was working on 80% of the projects alone because my fellow team members were lazy and didn't have the driving force to improve given opportunity and my help.

Now I realize the latter scenario is somewhat my fault (you should NEVER critique someones' code unless you are doing a code review or have been appointed such). As long as we as programmers can be teachable, there is hope for us yet!


问:
Maintenance model for external artifacts
When we think about maintaining a software solution holistically, we have to think about things like non-code change control and configuration management, in addition to the actual source code. For example, for maintaining a large web application, tracing:

"Make the following (manual) configuration change to the farm, as part of deploying this specific xx.yy.zz version of the solution package."

I've implemented a fairly good model for this, but now I'm tackling the next largest problem - how do we manage changes in other systems we don't own? Let's take a simple example:

We have an ASP.NET application owned by a solution team (let's call them the PLM Team). Their next release includes a change that requires the SAP team (which is under a different maintenance umbrella) to also deploy a change to one of their BAPI endpoints.

Of course the actual coordination of the deployment at release time is simple human interaction & coordination, but in terms of the total SDLC:

How does our example "PLM Team" package & trace this dependency as an artifact, both as an upcoming change and, post-deployment, a managed dependency with requirements they own but an implementation they do not directly control?

What is the right information to capture about it? How should it be treated differently than non-code configuration items they do control?

答:
If two teams communicate constantly, it's rather about human interaction and coordination, not about business processes. You just agree how the interface used by both projects will change, you implement the change, and you deploy both products at the same time. By the same time, I mean you disconnect a machine from a farm, you stop both apps, then updates are applied to both apps, and then they start running again and the machine can get back to the farm.

If two teams cannot communicate very well (either because they are located in different cities geographically or because they hate one another, or whatsoever), there is really nothing you can do from business process perspective to update both applications at the same time.

In this second case, you're in a role of a large API provider who released a new version of the API, but has lots of customers who are still using the old version. If the next version does not extend¹ the first one, but changes² it, you should keep running both versions.

This means that you will have both:

```<code>http://api.example.com/products/get/5
</code>```

and:

```<code>http://api.example.com/v2/d6w9UbnZ50/products/get/5
                       ↑       ↑
                    version  token
</code>```

and while the new clients will be able to benefit from the RESTfull API by using the second version, the older clients who rely on sessions will still be able to use the API.

Since your project is used by only one other project, both developing and maintaining two versions of the same project is cost-prohibitive. This means that once the second version developed and tested, you should try whatever you can to force the other team to start using the second version as soon as possible. This also means that if they open a ticket telling that there is a bug in your first version, this ticket must be immediately closed as "won't solve" with a note that the first version is not maintained any longer.

¹ Extending: adding an optional argument to en existent method or adding an overload or a new method doesn't break the current API.

² Changing: renaming methods to make them more explicit or removing an argument or adding a mandatory one will break the current API.

Body:
If two teams communicate constantly, it's rather about human interaction and coordination, not about business processes. You just agree how the interface used by both projects will change, you implement the change, and you deploy both products at the same time. By the same time, I mean you disconnect a machine from a farm, you stop both apps, then updates are applied to both apps, and then they start running again and the machine can get back to the farm.

If two teams cannot communicate very well (either because they are located in different cities geographically or because they hate one another, or whatsoever), there is really nothing you can do from business process perspective to update both applications at the same time.

In this second case, you're in a role of a large API provider who released a new version of the API, but has lots of customers who are still using the old version. If the next version does not extend¹ the first one, but changes² it, you should keep running both versions.

This means that you will have both:

http://api.example.com/products/get/5

and:

http://api.example.com/v2/d6w9UbnZ50/products/get/5
                       ↑       ↑
                    version  token

and while the new clients will be able to benefit from the RESTfull API by using the second version, the older clients who rely on sessions will still be able to use the API.

Since your project is used by only one other project, both developing and maintaining two versions of the same project is cost-prohibitive. This means that once the second version developed and tested, you should try whatever you can to force the other team to start using the second version as soon as possible. This also means that if they open a ticket telling that there is a bug in your first version, this ticket must be immediately closed as "won't solve" with a note that the first version is not maintained any longer.

¹ Extending: adding an optional argument to en existent method or adding an overload or a new method doesn't break the current API.

² Changing: renaming methods to make them more explicit or removing an argument or adding a mandatory one will break the current API.


问:
How to use the unit of work and repository patterns in a service oriented enviroment
I've created an application framework using the unit of work and repository patterns for it's data layer. Data consumer layers such as presentation depend on the data layer design. For example a CRUD abstract form has a dependency to a repository (IRepository).

This architecture works like a charm in client/server environments (Ex. a WPF application and a SQL Server). But I'm looking for a good pattern to change or reuse this architecture for a service oriented environment.

Of course I have some ideas:

Idea 1: The "Adapter" design pattern

Keep the current architecture and create a new unit of work and repository implementation which can work with a service instead of the ORM. Data layer consumers are loosely coupled to the data layer so it's possible but the problem is about the unit of work; I have to create a context which tracks the objects state at the client side and sends the changes to the server side on calling the "Commit" (Something that I think the RIA has done for Silverlight). Here the diagram:

```<code>----------- CLIENT----------- | ------------------ SERVER ----------------------

[ UI ] -> [ UoW/Repository ] ---> [ Web Services ] -> [ UoW/Repository ] -> [DB]
</code>```

Idea 2: Add another layer

Add another layer (let say "local services" or "data provider"), then put it between the data layer (unit of work and repository) and the data consumer layers (like UI). Then I have to rewrite the consumer classes (CRUD and other classes which are dependent to IRepository) to depend on another interface.

And the diagram:

```<code>----------------- CLIENT ------------------ | ------------------- SERVER ---------------------

[ UI ] -> [ Local Services/Data Provider ] ---> [ Web Services ] -> [ UoW/Repository ] -> [DB]
</code>```

Please note that I have the local services layer on the current architecture but it doesn't expose the data layer functionality. In another word the UI layer can communicate with both of the data and local services layers whereas the local services layer also uses the data layer.

```<code>|    |      |                 |      |      |
|    | ---> |  Local Services | ---> |      |
| UI |      |                 |      | Data |
|    |                               |      |
|    | ----------------------------> |      |
</code>```

答:
You can add idea 1 on top of idea 2. So I would start with idea 2.

I would avoid having lengthy conversation stored locally at the client end. It will result in synchronization complexity and the client may end up being very chatty (and thus slow).

Try looking at your web service as a facade. Try sticking to a single call - complete operation pattern.

Ask yourself why do I need a client side unit of work.


问:
TDD with SQL and data manipulation functions
While I'm a professional programmer, I've never been formally trained in software engineering. As I'm frequently visiting here and SO, I've noticed a trend for writing unit tests whenever possible and, as my software gets more complex and sophisticated, I see automated testing as a good idea in aiding debugging.

However, most of my work involves writing complex SQL and then processing the output in some way. How would you write a test to ensure your SQL was returning the correct data, for example? Then, say if the data wasn't under your control (e.g., that of a 3rd party system), how can you efficiently test your processing routines without having to hand write reams of dummy data?

The best solution I can think of is making views of the data that, together, cover most cases. I can then join those views with my SQL to see if it's returning the correct records and manually process the views to see if my functions, etc. are doing what they're supposed to. Still, it seems excessive and flakey; particularly finding data to test against...

答:
An important rule to test everything that is database related is to completely isolate it from the rest of your application.

The ports and adapters architecture is a really good example. The database is regarded as an external plugin through an adapter to your application. The same goes with all the 3rd party subsystems.
For testing how your app would behave and interpret the responses of 3rd party subsystems the only way I know how to test that is to stub the responses of this individual subsystem. I does not necessarily mean that you would have to manually write all the data objects. You can easily take the approach of using data driven testing.

In regard to testing how your application interacts with your database you can fake out the database adapters to use an in-memory database for example.

Now testing your database queries. First of all all the complex queries should be decomposed in more easy, simple and predictable queries. The same you would do for a fat class or for a fat function. There are tools that can help you testing your database like Dbunit. A simple approach I sometimes take is to use the concept of characterization tests. So I would put the database in a know state, run all the queries I have to write save the output in a place(file, memory) and consider this output to be the correct one. The next runs would compare their output with this one, so that would definitely offer me the regression testing i need. Indeed the first output is not guaranteed to be correct but the regression problem can be solved this way.
If you have your queries well decomposed you can test them individually towards the database that is in a known state.


答:
That is an interesting question because the database is usually the part that is faked during application unit testing.  Hopefully the logic of the database engine itself is well tested by the provider but of course the queries, schema, and stored procedures are code that needs to be tested and protected against regression. This is often left to integration testing which is not TDD.

Views would likely be a difficult way to do it because they don't really lend to the test first red-light, green-light automatic testing of one aspect per test that is preferred in TDD.  Also with views you can't write the test first before the code. A better approach would be to write stored procedures where you can add "assert" logic in the procedure (e.g. using "if" statements) to test the output for failure. You need to test just one thing in each unit test to isolate the unit, and the SP method would be better suited for that.  Also, with SP's you could run the whole suite of them as scripts as you develop the initial code and later on when testing for regressions when refactoring.

Also, be mindful that the tests must be repeatable and you will need some scripts to initialize and tear-down the database state to ensure that the state is the same for each unit test.

For your question about data that is not under your control, that is a difficult area.  I think you are better off mocking it with fake data and testing the exception and edge conditions as much as possible for unit tests. Otherwise it will fall more into the category of integration testing (which is also a good thing to do). For integration testing you can run your tests against the 3rd-party data and let it generate an initial output and for subsequent tests (e.g. after refactoring) make sure those outputs repeat the initial known output.

Title: TDD with SQL and data manipulation functions

Body:
While I'm a professional programmer, I've never been formally trained in software engineering. As I'm frequently visiting here and SO, I've noticed a trend for writing unit tests whenever possible and, as my software gets more complex and sophisticated, I see automated testing as a good idea in aiding debugging.

However, most of my work involves writing complex SQL and then processing the output in some way. How would you write a test to ensure your SQL was returning the correct data, for example? Then, say if the data wasn't under your control (e.g., that of a 3rd party system), how can you efficiently test your processing routines without having to hand write reams of dummy data?

The best solution I can think of is making views of the data that, together, cover most cases. I can then join those views with my SQL to see if it's returning the correct records and manually process the views to see if my functions, etc. are doing what they're supposed to. Still, it seems excessive and flakey; particularly finding data to test against...


问:
Using empty subclasses to add to the semantics of a class hierarchy?
I was wondering whether using (almost) empty derived classes to give additional semantics to a class hierarchy was a good idea (or practice) ?

Because a (not so short) example is always better than a long speech, let's assume we're writing a class hierarchy for SQL generation. You want to represent a data manipulation command (INSERT, UPDATE or DELETE), so you have two alternatives :

First version, with switch statement

```<code>enum CommandType {
    Insert,
    Update,
    Delete
}

class SqlCommand {
    String TableName { get; }
    String SchemaName { get; }
    CommandType CommandType { get; }
    IEnumerable<string> Columns { get; }
    // ... and so on
}

class SqlGenerator  {
    string GenerateSQLFor(SqlCommand command)
    {
        switch (command.CommandType)
        {
            case CommandType.Insert:
                return generateInsertCommand(command);
            case CommandType.Update:
                return generateUpdateCommand(command);
            case CommandType.Delete:
                return generateDeleteCommand(command);
            default:
                throw new NotSupportedException();
        }
    }
}
</code>```

Second version with VisitorPattern (Note that the question is NOT about whether the Visitor pattern should be used or adding new operations)

```<code>abstract class SqlCommand {
    String TableName { get; }
    String SchemaName { get; }
    IEnumerable<string> Columns { get; }
    // ... and so on
    abstract void Accept(SqlCommandVisitor visitor);
}

class InsertCommand : SqlCommand
{
    overrides void Accept(SqlCommandVisitor visitor)
    {
        visitor.VisitInsertCommand(this);
    }
}

class DeleteCommand : SqlCommand
{
    overrides void Accept(SqlCommandVisitor visitor)
    {
        visitor.VisitDeleteCommand(this);
    }
}

class SqlCommandVisitor  {
    void InitStringBuffer() { ... }
    string GetStringBuffer() { ... }

    string GenerateSQLFor(SqlCommand command)
    {
        InitStringBuffer();
        command.Accept(this);
        return GetStringBuffer();
    }

    void Visit(SqlCommand command) { ... }
    void VisitInsertCommand(InsertCommand command) { ... }
    void VisitDeleteCommand(DeleteCommand command) { ... }
    void VisitUpdateCommand(UpdateCommand command) { ... }
}
</code>```

With both examples we achieve the same result, but :

In the first version, my code feels more DRY, even though polymorphism is generally preferable over a switch statement.

In the second version, I feel like I'm needlessly deriving SqlCommand just so that the code carries more meaning.

Another similar case is deriving a class from a generic class, just to give additionnal meaning to the collection, eg :

```<code>class CustomerList : List<Customer> { }
</code>```

I'm left off wondering whether this is a good idea. Are there any pitfalls to doing so ?

I personally prefer the second version exactly because it adds meaning to the code, and helps me when I read my code later... But I clearly lack the experience to see any downside to this pattern.

答:
Your second example has the benefit of no case statement, and no CommandType.  This means you can a new statement type without having to modify a case statement.  A case statement ought to cause an OOP programmer to pause a moment and consider whether the design should be changed to get rid of the case statement.  A variable denoting a thing's type ought to cause the programmer to pause a long while.

However, the visitor pattern doesn't seem to be needed here.  Simpler would be to use a class hierarchy, as you did, but then put the SQL generation inside that hierarchy rather than having it be a separate class:

```<code>class SqlCommand {
  abstract String sql;
}

class InsertCommand : SqlCommand {
  overrides String sql {...};
}

class DeleteCommand : SqlCommand {
  overrides String sql {...};
}
</code>```

The code inside the sql functions will probably turn out to have shared behavior, or enough complexity, that moving the shared behavior and complexity into a separate SqlBuilder class would be good:

```<code>class InsertCommand : SqlCommand {
  overrides String sql {
    builder = SqlBuilder.new
    builder.add("insert into")
    builder.add_identifier(table_name)
    buidler.add("values")
    builder.add_value_list(column_names)
    ...
    return builder.sql
  };
}
</code>```

The SqlCommand drives the process of creating the sql, pushing its details into the SqlBuilder.  This keeps the SqlCommand and SqlBuilder decoupled, since the SqlCommands do not have to expose their entire state for the builder to use.  This has the benefits of your second example, but without the complexity of the visitor pattern.

If it turns out that sometimes you need the sql built one way and sometimes another (perhaps you want to support more than one SQL back end), then you abstract the SqlBuilder class, like so:

```<code>class SqlBuilder {
  abstract void add(String s);
  abstract void add_identifier(String identifier);
  abstract void add_value_list(String[] value_list);
  ...
}

class PostgresSqlBuilder : SqlBuilder {
  void add(String s) {...}
  void add_identifier(String identifier) {...}
  void add_value_list(String[] value_list) {...}
  ...
}

class MysqlSqlBuilder : SqlBuilder {
  void add(String s) {...}
  void add_identifier(String identifier) {...}
  void add_value_list(String[] value_list) {...}
  ...
}
</code>```

Then the sql functions use the builder passed into them, rather than creating one:

```<code>class InsertCommand : SqlCommand {
  overrides String sql (SqlBuilder builder) {
    builder.add("insert into")
    builder.add_identifier(table_name)
    buidler.add("values")
    builder.add_value_list(column_names)
    ...
    return builder.sql
  };
}
</code>```

Body:
Your second example has the benefit of no case statement, and no CommandType.  This means you can a new statement type without having to modify a case statement.  A case statement ought to cause an OOP programmer to pause a moment and consider whether the design should be changed to get rid of the case statement.  A variable denoting a thing's type ought to cause the programmer to pause a long while.

However, the visitor pattern doesn't seem to be needed here.  Simpler would be to use a class hierarchy, as you did, but then put the SQL generation inside that hierarchy rather than having it be a separate class:

class SqlCommand {
  abstract String sql;
}

class InsertCommand : SqlCommand {
  overrides String sql {...};
}

class DeleteCommand : SqlCommand {
  overrides String sql {...};
}

The code inside the sql functions will probably turn out to have shared behavior, or enough complexity, that moving the shared behavior and complexity into a separate SqlBuilder class would be good:

class InsertCommand : SqlCommand {
  overrides String sql {
    builder = SqlBuilder.new
    builder.add("insert into")
    builder.add_identifier(table_name)
    buidler.add("values")
    builder.add_value_list(column_names)
    ...
    return builder.sql
  };
}

The SqlCommand drives the process of creating the sql, pushing its details into the SqlBuilder.  This keeps the SqlCommand and SqlBuilder decoupled, since the SqlCommands do not have to expose their entire state for the builder to use.  This has the benefits of your second example, but without the complexity of the visitor pattern.

If it turns out that sometimes you need the sql built one way and sometimes another (perhaps you want to support more than one SQL back end), then you abstract the SqlBuilder class, like so:

class SqlBuilder {
  abstract void add(String s);
  abstract void add_identifier(String identifier);
  abstract void add_value_list(String[] value_list);
  ...
}

class PostgresSqlBuilder : SqlBuilder {
  void add(String s) {...}
  void add_identifier(String identifier) {...}
  void add_value_list(String[] value_list) {...}
  ...
}

class MysqlSqlBuilder : SqlBuilder {
  void add(String s) {...}
  void add_identifier(String identifier) {...}
  void add_value_list(String[] value_list) {...}
  ...
}

Then the sql functions use the builder passed into them, rather than creating one:

class InsertCommand : SqlCommand {
  overrides String sql (SqlBuilder builder) {
    builder.add("insert into")
    builder.add_identifier(table_name)
    buidler.add("values")
    builder.add_value_list(column_names)
    ...
    return builder.sql
  };
}


答: Using the type system (in a statically type language) to express semantics is exactly what it is meant for. Consider a type for database IDs that you subclass for each table, say a CustomerId, an OrderId and so on. The benefit is that you never mistake a CustomerId for an OrderId. But they are clearly empty subclasses. See the Google IO talk on GWT by Ray Ryan at around 7:00 for an example. </p>

Title: Using empty subclasses to add to the semantics of a class hierarchy?

Body:
I was wondering whether using (almost) empty derived classes to give additional semantics to a class hierarchy was a good idea (or practice) ?

Because a (not so short) example is always better than a long speech, let's assume we're writing a class hierarchy for SQL generation. You want to represent a data manipulation command (INSERT, UPDATE or DELETE), so you have two alternatives :

First version, with switch statement

```<code>enum CommandType {
    Insert,
    Update,
    Delete
}

class SqlCommand {
    String TableName { get; }
    String SchemaName { get; }
    CommandType CommandType { get; }
    IEnumerable<string> Columns { get; }
    // ... and so on
}

class SqlGenerator  {
    string GenerateSQLFor(SqlCommand command)
    {
        switch (command.CommandType)
        {
            case CommandType.Insert:
                return generateInsertCommand(command);
            case CommandType.Update:
                return generateUpdateCommand(command);
            case CommandType.Delete:
                return generateDeleteCommand(command);
            default:
                throw new NotSupportedException();
        }
    }
}
</code>```

Second version with VisitorPattern (Note that the question is NOT about whether the Visitor pattern should be used or adding new operations)

```<code>abstract class SqlCommand {
    String TableName { get; }
    String SchemaName { get; }
    IEnumerable<string> Columns { get; }
    // ... and so on
    abstract void Accept(SqlCommandVisitor visitor);
}

class InsertCommand : SqlCommand
{
    overrides void Accept(SqlCommandVisitor visitor)
    {
        visitor.VisitInsertCommand(this);
    }
}

class DeleteCommand : SqlCommand
{
    overrides void Accept(SqlCommandVisitor visitor)
    {
        visitor.VisitDeleteCommand(this);
    }
}

class SqlCommandVisitor  {
    void InitStringBuffer() { ... }
    string GetStringBuffer() { ... }

    string GenerateSQLFor(SqlCommand command)
    {
        InitStringBuffer();
        command.Accept(this);
        return GetStringBuffer();
    }

    void Visit(SqlCommand command) { ... }
    void VisitInsertCommand(InsertCommand command) { ... }
    void VisitDeleteCommand(DeleteCommand command) { ... }
    void VisitUpdateCommand(UpdateCommand command) { ... }
}
</code>```

With both examples we achieve the same result, but :

In the first version, my code feels more DRY, even though polymorphism is generally preferable over a switch statement.

In the second version, I feel like I'm needlessly deriving SqlCommand just so that the code carries more meaning.

Another similar case is deriving a class from a generic class, just to give additionnal meaning to the collection, eg :

```<code>class CustomerList : List<Customer> { }
</code>```

I'm left off wondering whether this is a good idea. Are there any pitfalls to doing so ?

I personally prefer the second version exactly because it adds meaning to the code, and helps me when I read my code later... But I clearly lack the experience to see any downside to this pattern.


问:
How would a new language look if it was designed from scratch to be easy to TDD?
With the some most common languages (Java, C#, Java, etc) it sometimes seems that you are working at odds with the language when you want to fully TDD your code.

For example, in Java and C# you will want to mock any dependencies of your classes and most mocking frameworks will recommend that you mock interfaces not classes. This often means that you have many interfaces with a single implementation (this effect is even more noticeable because TDD will force you to write a larger number of smaller classes). Solutions that let you mock concrete classes properly do things like alter the compiler or override class loaders etc, which is pretty nasty.

So what would a language look like if it was designed from scratch to be great to TDD with? Possibly some way language level way of describing dependencies (rather than passing interfaces to a constructor) and being able to separate the interface of a class without doing so explicitly?

答:
Well, dynamically typed languages do not require explicit interfaces. See Ruby or PHP, etc.

On the other hand, statically typed languages like Java and C# or C++ enforces types and forces you to write those interfaces.

What I do not understand is what is your problem with them. Interfaces are a key element of design and they are a used all over the design patterns and in respecting the SOLID principles. I am, for example, frequently using interfaces in PHP because they make design explicit and they also enforce design. On the other hand in Ruby you have no way to enforce a type, it is a duck typed language. But still, you have to imagine the interface there and you have to abstract the design in you mind in order to correctly implement it.

So, though your question may sound interesting, it implies that you have problems with understanding or applying dependency injection techniques.

And to directly answer your question, Ruby and PHP have great mocking infrastructure both built in their unit testing frameworks and delivered separately (see Mockery for PHP). In some cases, these frameworks even allow you to do what you are suggesting, things like mocking static calls or object initializations without injecting a dependency explicitly.


问:
What is an “implementation plan”?
I was recently given the task of creating an implementation plan document. When I asked for an example of one that I could look at, I was told to look at the Project Plan that had already been created an use that as a base. I'm still a bit confused on what I should be creating.

Can anyone point me to a good example out there or to something that explains what this is and more importantly the details about what it should contain.

答:
Implementation is about construction and planning is how will you go about doing that construction.

Your implementation plan should include:

what things or parts will be implemented

identify a way of knowing when you have completed the things to be implemented

time estimate and schedule of the implementation effort

the number of people in the team that will work in the implementation

whenever applicable, the order in which things will be implemented (what parts should be implemented first)

figuring/deciding on a way of monitoring and tracking progress or problems

identifying quality acceptance criteria and goals

test stages and testing iterations

what [corrective] actions will be taken when and if things don't go according to plan

Since implementation is part of the whole project development effort, some of these things may already be mentioned as part of the project plan.

This link points to a simple 'implementation roadmap' document from Construx Software http://www.construx.com/File.ashx?cid=1951

From Construx Software here is a useful check list of tasks for a construction lead:
http://www.construx.com/File.ashx?cid=1935

Title: What is an “implementation plan”?


问:
How can I ensure a portion of my project's code remains in all derivative works?
I had an idea for a website. After much coding and thinking out the idea, I've got it to a decent stage.

If I were someone else, potentially a more commercially-minded person, I might want to sell it, or slather it with ads. However, I've fallen somewhat in love with open-source, and I'd like to host the project on GitHub and give it a nice open-source license.

However, the project seems to be getting better all the time and, in fact, I think that it'll quickly grow to be fairly popular. So I want to put ads on it that benefit charity.

How can I ensure that one small text advertisement benefiting charity remains in all derivative works? Are there any licenses that would let me do this?

p.s. My other requirement for a license is that it gives me attribution (in the same form as the MIT license would be fine)

[EDIT]
I've decided to just let it be Apache licensed. I'm hoping that people will just leave charity-benefiting ads in.

答:
I think there is no prewritten license to fulfill your requirements. However, noone stops you write your own license and attach it to the original work.

On the other hand, if you have something successful and open-source you may want to consider a business model where users are not required to pay but may be encouraged to donate or support the project.

Open-source, by definition implies that the code is completely open, and no one person should be limited to modify it. GPL, MIT, CreativeCommons and other standard licenses guarantee attribution.

So, go open-source and be open, or make parts of the project closed source. You could make that module that contains the advertisement closed and make the rest of the project depend on it. This will, in some degree protect you, but may also be discouraging for developers to be required to depend on something secret from you.

Other business options would be to open only parts of your project and give them for free, but retain other parts of the project and keep the whole as a paid service.


问:
Why are there proxy processes between clients and logic processes in C/S application?
In real world networking software  following c/s model, there are always proxy server processes between clients and server processes dealing with business logic, why we need proxy to isolate the logic part and clients? What's the benifit of this architecture?</p>

答:
Clients became plugins to the business logic. The server offers an API and the clients use it. Clients can change and evolve and be swapped with other clients, the server and the business logic will never know or care about this.

Dependency is inverted, clients depend on server and server with it's business logic does not depend on the clients. A proxy, is a good way to offer an abstract interface, an API on which any client can rely.

Control still flows from business logic towards external clients.

Imagine Twitter, if it would not have implemented such a design, there would have been only one single (or only a few) clients to twitter and all would be dependent on the server and vice versa.


问:
Linux OS developers : do they unit test their code?
Linux OS developers : do they unit test their code ?

If yes :

since this OS is coded in C, how do they manage to write effectively unit tests in this language ?

what are the "zones" in OS where unit testing is easier to write ? where is it harder ? where is it valuable ?

答:
In general I would say that kernel code is not unit tested (I'm sure there are some exceptions).  There are a few things that make kernel code difficult to unit test

Kernel code generally interfaces with hardware.

Kernel code does not link to the standard c library, it uses kernel specific headers etc.

You could decouple all of your functions that do not interface with the kernel API or hardware, but that has not been my experience of what actually happens.

I think most kernel code is tested using "integration tests" where command line apps are written to exercise the userspace interface to the kernel code.

Finally, C code itself can be unit tested.  I write C code almost everyday and it gets unit tested.


答:
So what would a language look like if it was designed from scratch to
  be great to TDD with?

'works well with TDD' surely isn't sufficient to describe a language, so it could "look" like anything. Lisp, Prolog, C++, Ruby, Python... take your pick.

Furthermore, it's not clear that supporting TDD is something that's best handled by the language itself. Sure, you could create a language where every function or method has an associated test, and you could build in support for discovering and executing those tests. But unit testing frameworks already handle the discovery and execution part nicely, and it's hard to see how to add the requirement of a test for every function cleanly. Do tests also need tests? Or are there two classes of functions -- normal ones which need tests and test functions which don't need them? That doesn't seem very elegant.

Maybe it's better to support TDD with tools and frameworks. Build it into the IDE. Create a development process which encourages it.

Also, if you're designing a language, it's good to think long-term. Remember that TDD is just one methodology, and not everyone's preferred way of working. It may be difficult to imagine, but it's possible that even better ways are coming. As a language designer, do you want people to have to abandon your language when that happens?

All you can really say to answer the question is that such a language would be conducive to testing. I know that doesn't help much, but I think the problem is with the question.

Title: How would a new language look if it was designed from scratch to be easy to TDD?

Body:
With the some most common languages (Java, C#, Java, etc) it sometimes seems that you are working at odds with the language when you want to fully TDD your code.

For example, in Java and C# you will want to mock any dependencies of your classes and most mocking frameworks will recommend that you mock interfaces not classes. This often means that you have many interfaces with a single implementation (this effect is even more noticeable because TDD will force you to write a larger number of smaller classes). Solutions that let you mock concrete classes properly do things like alter the compiler or override class loaders etc, which is pretty nasty.

So what would a language look like if it was designed from scratch to be great to TDD with? Possibly some way language level way of describing dependencies (rather than passing interfaces to a constructor) and being able to separate the interface of a class without doing so explicitly?


答:
Many years ago I threw together a prototype that addressed a similar question; here's a screenshot:

The idea was that the assertions are inline with the code itself, and all tests run basically at each keystroke.  So as soon as you make the test pass, you see the method turn green.


答:
It would be dynamically rather than statically typed.  Duck typing would then do the same job that interfaces do in statically typed languages.  Also, its classes would be modifiable at runtime so that a test framework could easily stub or mock methods on existing classes.  Ruby is one such language; rspec is its premier test framework for TDD.

How dynamic typing aids testing

With dynamic typing, you can create mock objects by simply creating a class that has the same interface (method signatures) the collaborator object you need to mock.  For example, suppose you had some class that sent messages:

```<code>class MessageSender
  def send
    # Do something with a side effect
  end
end
</code>```

Let's say that we have a MessageSenderUser that uses an instance of MessageSender:

```<code>class MessageSenderUser

  def initialize(message_sender)
    @message_sender = message_sender
  end

  def do_stuff
    ...
    @message_sender.send
    ...
    @message_sender.send
    ...
  end

end
</code>```

Note the use here of dependency injection, a staple of unit testing.  We'll come back to that.

You wish to test that MessageSenderUser#do_stuff calls send twice.  Just as you would in a statically typed language, you can create a mock MessageSender that counts how many times send was called.  But unlike a statically typed language, you need no interface class.  You just go ahead and create it:

```<code>class MockMessageSender

  attr_accessor :send_count

  def initialize
    @send_count = 0
  end

  def send
    @send_count += 1
  end

end
</code>```

And use it in your test:

```<code>mock_sender = MockMessageSender.new
MessageSenderUser.new(mock_sender).do_stuff
assert_equal(mock_sender.send_count, 2)
</code>```

By itself, the "duck typing" of a dynamically typed language doesn't add that much to testing compared to a statically typed language.  But what if classes aren't closed, but can be modified at runtime?  That's a game changer.  Let's see how.

What if you didn't have to use dependency injection to make a class testable?

Suppose that MessageSenderUser will only ever use MessageSender to send messages, and you have no need to allow the substitution of MessageSender with some other class.  Within a single program this is often the case.  Let's rewrite MessageSenderUser so that it simply creates and uses a MessageSender, with no dependency injection.

```<code>class MessageSenderUser

  def initialize
    @message_sender = MessageSender.new
  end

  def do_stuff
    ...
    @message_sender.send
    ...
    @message_sender.send
    ...
  end

end
</code>```

MessageSenderUser is now a simpler to use: Nobody creating it needs to create a MessageSender for it to use.  It doesn't look like a big improvement in this simple example, but now imagine that MessageSenderUser is created in more than once place, or that it has three dependencies.  Now the system has a whole lot of passing instances around just to make the unit tests happy, not because it necessarily improves the design at all.

Open classes let you test without dependency injection

A test framework in a language with dynamic typing and open classes can make TDD quite nice.  Here's a code snippet from an rspec test for MessageSenderUser:

```<code>mock_message_sender = mock MessageSender
MessageSender.should_receive(:new).and_return(mock_message_sender)
mock_message_sender.should_receive(:send).twice.with(no_arguments)
MessageSenderUser.new.do_stuff
</code>```

That's the whole test. If MessageSenderUser#do_stuff does not invoke MessageSender#send exactly twice, this test fails.  The real MessageSender class is never invoked: We told the test that whenever someone tries to create a MessageSender, they should get our mock MessageSender instead.  No dependency injection necessary.

It's nice to do so much in such a simpler test.  It's ever nicer not to have to use dependency injection unless it actually makes sense for your design.

But what does this have to do with open classes?  Note the call to MessageSender.should_receive.  We didn't define #should_receive when we wrote MessageSender, so who did?  The answer is that the test framework, making some careful modifications of system classes, is able to make it appear as through #should_receive is defined on every object.  If you think that modifying system classes like that requires some caution, you're right.  But it's the perfect thing for what the test library is doing here, and open classes make it possible.

Body:
It would be dynamically rather than statically typed.  Duck typing would then do the same job that interfaces do in statically typed languages.  Also, its classes would be modifiable at runtime so that a test framework could easily stub or mock methods on existing classes.  Ruby is one such language; rspec is its premier test framework for TDD.

How dynamic typing aids testing

With dynamic typing, you can create mock objects by simply creating a class that has the same interface (method signatures) the collaborator object you need to mock.  For example, suppose you had some class that sent messages:

class MessageSender
  def send
    # Do something with a side effect
  end
end

Let's say that we have a MessageSenderUser that uses an instance of MessageSender:

class MessageSenderUser

  def initialize(message_sender)
    @message_sender = message_sender
  end

  def do_stuff
    ...
    @message_sender.send
    ...
    @message_sender.send
    ...
  end

end

Note the use here of dependency injection, a staple of unit testing.  We'll come back to that.

You wish to test that MessageSenderUser#do_stuff calls send twice.  Just as you would in a statically typed language, you can create a mock MessageSender that counts how many times send was called.  But unlike a statically typed language, you need no interface class.  You just go ahead and create it:

class MockMessageSender

  attr_accessor :send_count

  def initialize
    @send_count = 0
  end

  def send
    @send_count += 1
  end

end

And use it in your test:

mock_sender = MockMessageSender.new
MessageSenderUser.new(mock_sender).do_stuff
assert_equal(mock_sender.send_count, 2)

By itself, the "duck typing" of a dynamically typed language doesn't add that much to testing compared to a statically typed language.  But what if classes aren't closed, but can be modified at runtime?  That's a game changer.  Let's see how.

What if you didn't have to use dependency injection to make a class testable?

Suppose that MessageSenderUser will only ever use MessageSender to send messages, and you have no need to allow the substitution of MessageSender with some other class.  Within a single program this is often the case.  Let's rewrite MessageSenderUser so that it simply creates and uses a MessageSender, with no dependency injection.

class MessageSenderUser

  def initialize
    @message_sender = MessageSender.new
  end

  def do_stuff
    ...
    @message_sender.send
    ...
    @message_sender.send
    ...
  end

end

MessageSenderUser is now a simpler to use: Nobody creating it needs to create a MessageSender for it to use.  It doesn't look like a big improvement in this simple example, but now imagine that MessageSenderUser is created in more than once place, or that it has three dependencies.  Now the system has a whole lot of passing instances around just to make the unit tests happy, not because it necessarily improves the design at all.

Open classes let you test without dependency injection

A test framework in a language with dynamic typing and open classes can make TDD quite nice.  Here's a code snippet from an rspec test for MessageSenderUser:

mock_message_sender = mock MessageSender
MessageSender.should_receive(:new).and_return(mock_message_sender)
mock_message_sender.should_receive(:send).twice.with(no_arguments)
MessageSenderUser.new.do_stuff

That's the whole test. If MessageSenderUser#do_stuff does not invoke MessageSender#send exactly twice, this test fails.  The real MessageSender class is never invoked: We told the test that whenever someone tries to create a MessageSender, they should get our mock MessageSender instead.  No dependency injection necessary.

It's nice to do so much in such a simpler test.  It's ever nicer not to have to use dependency injection unless it actually makes sense for your design.

But what does this have to do with open classes?  Note the call to MessageSender.should_receive.  We didn't define #should_receive when we wrote MessageSender, so who did?  The answer is that the test framework, making some careful modifications of system classes, is able to make it appear as through #should_receive is defined on every object.  If you think that modifying system classes like that requires some caution, you're right.  But it's the perfect thing for what the test library is doing here, and open classes make it possible.


答: You could always do something radical like testing your software.  I don't even mean automated unit tests, just the tests every single experienced developer does out of habit by running his new code twice, once confirming the exit and once not.  That's the reason most programmers consider it a non-issue.</p>


答:
I like Patkos' answer, but I'd like to throw in a few other things.

First off, I would assume you could modify the GPL, or another similar license, as they require attribution and you simply add the stipulation that the original advertisements must remain.

However, by doing this you are somewhat defying the concept of open source software, as the source is no longer (completely) open.

There is nothing preventing someone else from starting an open source project to duplicate your webapp, as long as they don't use your code. And given the choice, which do you think people will pick?

Personally, I believe you either have to embrace open source or not. Straddling the line will only alienate the public.

Title: How can I ensure a portion of my project's code remains in all derivative works?

Body:
I had an idea for a website. After much coding and thinking out the idea, I've got it to a decent stage.

If I were someone else, potentially a more commercially-minded person, I might want to sell it, or slather it with ads. However, I've fallen somewhat in love with open-source, and I'd like to host the project on GitHub and give it a nice open-source license.

However, the project seems to be getting better all the time and, in fact, I think that it'll quickly grow to be fairly popular. So I want to put ads on it that benefit charity.

How can I ensure that one small text advertisement benefiting charity remains in all derivative works? Are there any licenses that would let me do this?

p.s. My other requirement for a license is that it gives me attribution (in the same form as the MIT license would be fine)

[EDIT]
I've decided to just let it be Apache licensed. I'm hoping that people will just leave charity-benefiting ads in.


问:
How to manage a developer who has poor communication skills
I manage a small team of developers on an application which is in the mid-point of its lifecycle, within a big firm. This unfortunately means there is commonly a 30/70 split of Programming tasks to "other technical work". This work includes:

Working with DBA / Unix / Network / Loadbalancer teams on various tasks

Placing and managing orders for hardware or infrastructure in different regions

Running tests that have not yet been migrated to CI

Analysis

Support / Investigation

Its fair to say that the Developers would all prefer to be coding, rather than doing these more mundane tasks, so I try to hand out the fun programming jobs evenly amongst the team.

Most of the team was hired because, though they may not have the elite programming skills to write their own compiler / game engine / high-frequency trading system etc., they are good communicators who "can get stuff done", work with other teams, and somewhat navigate the complex bureaucracy here. They are good developers, but they are also good all-round technical staff.

However, one member of the team probably has above-average coding skills, but below-average communication skills. Traditionally, the previous Development Manager tended to give him the Programming tasks and not the more mundane tasks listed above. However, I don't feel that this is fair to the rest of the team, who have shown an aptitude for developing a well-rounded skillset that is commonly required in a big-business IT department.

What should I do in this situation? If I continue to give him more programming work, I know that it will be done faster (and conversely, I would expect him to complete the other work slower). But it goes against my principles, and promotes the idea that you can carve out a "comfortable niche" for yourself simply by being bad at the tasks you don't like.

I want to clarify that I'm not trying to address this issue due to a grudge, or that I have a "chip on my shoulder" as was mentioned. I'm looking for advice on how to keep a well-rounded team, which is happy and motivated. By observing the variety of answers to this question, it seems like there are a lot of different opinions on how to achieve this.

答:
It's not clear from your original post what exactly is lacking about this dev's communication skills.  A lack of interest in going to meetings or doing planning/coordination type work (for example) doesn't necessarily indicate poor communication skills.  Maybe the dev simply feels that this type of work is manager work and cuts into his productivity as a dev?  Or maybe he feels that there is too much organizational overhead and this is a form of protest against what he feels is just overall wasted time?  After all, the opposite problem where people talk all day and never get anything done is also pretty common in the office.

It's important that you speak with this dev in a non-confrontational way and try to figure out why he avoids the non-programming tasks.  It's probably not a single reason, he may have as many different reasons as there are different types of tasks.  Make sure he understands that the purpose of the conversation is so that you can learn how to effectively improve team productivity and job satisfaction for all team members (you're not out to get him).  This is a time for you to listen, and not to argue or try to address his concerns with knee-jerk reactions.  You should probably also meet with the other team members, maybe they are totally fine with letting this guy do the heavy dev work while they focus on the chattier side of the profession.

After this meeting, spend some time thinking about the conversations you had and try to consider this employee's perspective with an open mind.  Maybe your initial feelings were correct and he is lacking some important skills which you should push him to develop. Or maybe he made some valid challenges to your assumptions.  Maybe you can work with other teams to formalize some processes and reduce the need for redundant communication.  Maybe other teams aren't pulling their weight and you need to have a friendly chat with their management.  There are many possibilities you may not be considering.

Finally, and most importantly, have follow-up conversation with individuals, or a team meeting if it is appropriate.  If you've identified real organizational problems which are within your power to affect, tell your employees about the actions you are going to take to improve their work situation.  If you still believe that the individual employee is in the wrong, sit down with him and explain what changes you need from him and why.  Devs do tend to respond well to logical/practical explanations. "It's not fair to your peers to give you all the fun work.  We'd like for all of you to be pure devs but that's not the reality of the situation so we need to share the burden of the crappy work."

Of course, if this guy is just a grumpy jerk, refuses to tell you why he is unhappy, will not respond to reason, and is not well respected by his peers...well...it's time for the Performance Improvement Plan.


问:
Teaching myself, as a physicist, to become a better programmer
I've always liked physics, and I've always liked coding, so when I got the offer for a PhD position doing numerical physics (details are not relevant, it's mostly parallel programming for a cluster) at a university, it was a no-brainer for me.

However, as most physicists, I'm self taught. I don't have broad background knowledge about how to code in an object oriented way, or the name of that specific algorithm that optimizes the search in some kD tree.

Since all my work so far has been more concerned about the physics and the scientific results, I undoubtedly have some bad habits - more so because my coding is my own, and not really teamwork. I have mostly used C since it is very straightforward and "what you write is what you get" - no need for fancy abstractions. However, I have recently switched to C++ since I'd like to learn more about the power that comes with abstraction, and it's pretty C-like (syntax-wise at least).

How do I teach myself to code in a good, abstract way like a graduate in computer science?

I know my code is efficient, but I want it to be elegant as well, and readable. Keep in mind that I don't have time to read several 1000-page tomes about abstract programming. I need to spend time on actual, physics related research (my supervisor would laugh at me if he knew I spent time thinking about how to program elegantly). How do I assess if my work is also good from a programmer's perspective?

答:
Your programs will be completely different from commercial source code, therefore many good practices and approaches won't apply in your day-to-day source code development. But there is a good way to learn a few tips and tricks.

Let some good software developer review your code and optimize it together. It will give you much more experience and will teach you good practices. Also review source code written by other people. Search for open source projects on sourceforge or github and read their source code.

But most of all, think whether you actually need to learn anything new in order to accomplish your goals. Doing unnecessary stuff just to make the code look prettier won't add any value to your applications.


答:
First,"elegant" is a relative term. Abstraction might seem elegant to you but to another C aficionado, it might seem unnecessary. Anyways,to answer your question, you should try posting your code for review on http://codereview.stackexchange.com.<br>
Digressing from the main point, some unsolicited advice based on my own experience. If you can get all your work done with just C, then why do you want to code it in an abstract way? By this, do you want to enable others to resuse your code? If you really have a solid reason to switch to C++, go for the abstraction and learning C++ and OO concepts. Otherwise drop the idea. In my humble opinion, should n t you aim at your code being more readable and your scientific results reproducible than giving it OO abstractions? I myself had this kind of obsession to learn OOPS and code "elegant"ly. But C++ will take time to master.You will have to learn memory management since garbage collection is not automatic in C++. Take my advice since i worked for a research lab myself and lost lots of time learning C++ and OO, instead of concentrating on the main work at hand. </p>

Title: Teaching myself, as a physicist, to become a better programmer

Body:
I've always liked physics, and I've always liked coding, so when I got the offer for a PhD position doing numerical physics (details are not relevant, it's mostly parallel programming for a cluster) at a university, it was a no-brainer for me.

However, as most physicists, I'm self taught. I don't have broad background knowledge about how to code in an object oriented way, or the name of that specific algorithm that optimizes the search in some kD tree.

Since all my work so far has been more concerned about the physics and the scientific results, I undoubtedly have some bad habits - more so because my coding is my own, and not really teamwork. I have mostly used C since it is very straightforward and "what you write is what you get" - no need for fancy abstractions. However, I have recently switched to C++ since I'd like to learn more about the power that comes with abstraction, and it's pretty C-like (syntax-wise at least).

How do I teach myself to code in a good, abstract way like a graduate in computer science?

I know my code is efficient, but I want it to be elegant as well, and readable. Keep in mind that I don't have time to read several 1000-page tomes about abstract programming. I need to spend time on actual, physics related research (my supervisor would laugh at me if he knew I spent time thinking about how to program elegantly). How do I assess if my work is also good from a programmer's perspective?

Body:
First,"elegant" is a relative term. Abstraction might seem elegant to you but to another C aficionado, it might seem unnecessary. Anyways,to answer your question, you should try posting your code for review on http://codereview.stackexchange.com.

Digressing from the main point, some unsolicited advice based on my own experience. If you can get all your work done with just C, then why do you want to code it in an abstract way? By this, do you want to enable others to resuse your code? If you really have a solid reason to switch to C++, go for the abstraction and learning C++ and OO concepts. Otherwise drop the idea. In my humble opinion, should n t you aim at your code being more readable and your scientific results reproducible than giving it OO abstractions? I myself had this kind of obsession to learn OOPS and code "elegant"ly. But C++ will take time to master.You will have to learn memory management since garbage collection is not automatic in C++. Take my advice since i worked for a research lab myself and lost lots of time learning C++ and OO, instead of concentrating on the main work at hand.