问:
Why can people expect hardware/software requirements on software applications, but it's not for web applications?
Questions revolving around ways of getting customers to embrace new web technology / browsers so one can deliver better web software to the end user.

It's hard to manage expectations of customers. Expectations such as:

Websites should work on older browsers. (ambiguous).

Websites should not require specific hardware.

Giving system / computer specs for running a website is unacceptable.

Web development isn't as easy as many think. There's a lot that goes into creating a properly run web application (not just a website). Take a look at Google Docs or Microsoft Office online. These are more than just regular websites, and they force users to use newer browsers.

MS Office Online will not work with IE6, and they are trying very hard to push people to use IE8 (soon IE9). Google pushes as well, same with many other strong web entities.

You can do a lot on the internet, from playing games, watching movies, doing work, even coding and have the server you're connected to compile your code.

With everything the web can do, I find it amazing that people still want to put unrealistic expectations on web applications just because it will require someone to use a browser that is only... 2-3 years old.

I understand people don't like change. And we all know that many corporations will provide days/weeks of training to help their employees understand new internet browsers. There are also cases where people are forced to use old browsers because the archaic system they use for internal work only runs on that browser (ActiveX+IE6).

My Questions

How can you tell your end users that they will need to upgrade their browser to use the latest version of your website without a huge outcry?

Why does the expectation exist that it's ok for software to require people to upgrade Windows/Mac versions, but a website cannot require a new browser version?

答:
First of all, I don't really think people have any greater motivation "to upgrade Windows/Mac versions": Here are the usage share of web client operating systems (August 2010): Windows XP (48.32%), Windows 7 (19.81%), Windows Vista (18.43%), Mac OS X (6.42%), iOS (iPhone) (1.40%), Linux (1.34%). So nearly 50% are using an outdated OS (XP).

By contrast, here are the usage  share statistics for browsers: Overall- IE (31.1 %), FF (45.1%), Chrome (17.3%), Safari (3.7%), Opera (2.2%). Breaking down IE by version- IE9 (0.2%), IE8 (17.3%), IE 7 (8.0 %), IE6 (5.6%). And for Firefox- FF4 (0.8%), FF3.6 (35.3%), FF3.5 (5.6%), FF3.0 (2.9%). So over 50% use the latest stable (or beta) versions of these browsers.

As for your other question--"How can you tell your end users that they will need to upgrade their browser to use the latest version of your website without a huge outcry?"--you must understand (i) the factors motivating people to upgrade, and (ii) the factors inhibiting people from upgrading; then you must use these factors to bolster your appeal to your end-users.

Motivators

What rewards do end-users get by upgrading? Skimming Microsoft's IE8 marketing materials, these are the motivators they stressed most:

Appeals to Efficiency/Laziness:

Faster surfing (i.e., you will gain more free-time if you switch)

You can accomplish more work with fewer clicks, because of a more intuitive design. IE7 had put certain buttons in strange places, etc. (I.e., you will lose less effort [as measured in clicks] if you upgrade).

Appeals to Security/Fear:

SmartScreen protects you from malicious software (i.e., you will lose safety if you don't upgrade).

Compatibility View allows you to view older pages correctly just as the website’s designers intended (i.e., you won't lose anything if you upgrade).

So motivators boil down to what the end-user will gain by upgrading (or lose if they don't upgrade). These things must be important to the end-user: Time, effort, financial security, compatibility, etc.

Reinforcers

Reinforcers aren't rewards, but they help increase the rate of adopting the desired behavior. Here's an example: Your web site can detect old versions of browsers, and direct users to download and install the latest versions by providing links and motivators.

Inhibitors

Nuisance (cost in terms of time and effort) to upgrade

Nuisance of learning something new

New versions are inevitably buggy and suffer from incompatibilities that haven't yet been discovered

You must anticipate these arguments, and develop effective counter-arguments:

There is a risk/reward trade-off, and the rewards outweigh these risks.

New versions of browsers are fully supported, and bugs will be worked out. By contrast, older versions aren't well supported; and the oldest version have lost support entirely.


问:
Should we bind view to a model property or ViewModel should have it's own..?
I am starting a project with following technical environment :
.Net 4.0, Entity Framework 4.0, WPF with MVVM Architecture

I saw lots of examples on the net, some books with this environment. In some of the examples authors had this Idea :

Viemodel will have an instance of Model class (Entity Framework Entity e.g. Person)

Bind the WPF view controls to the properties of Model

While some authors did :

Viemodel will expose all the properties of the model.

Bind the WPF view controls to the properties of ViewModel rather than to the model
directly.

So is it a good idea to let the view bind properties from model rather than viewmodel exposing its own? Or which is more preferred?

答:
I think a lot of programmers first try to take the shortcut of binding directly to the model, but in my experience this has some major drawbacks.  The primary problem is that if your entity model is persisted by NHibernate or similar, then as soon as the View updates the model property, then NHibernate could persist those changes to the database.  That doesn't work well for edit-screens that have a Save/Cancel button.  In actual fact, it may choose to wait and persist everything as a batch, but the idea is that when you change the model, you're committing your change.

So, you could still get away with binding directly to model properties on read-only screens, but then you're going to have an inconsistency.

Additionally, most models don't implement INotifyPropertyChanged so they may not be suitable binding targets if the state of the screen changes after the initial display.

Given the ease of auto-properties, I suggest always binding the View to the ViewModel, not to the Model.  It's consistent, simple, and gives you the most flexibility to support changes in the future.

ContentLicense: CC BY-SA 3.0


问:
Managing UAT / Defect and Bug raising
I'm looking for assistance in figuring out the best approach to managing User Acceptance Testing (UAT) and how users raise defects/bugs - I've been in the situation before of having to deal with a free for all in that every small error is raised as a bug which takes valuable time from actual bug fix whilst I sift through lots of invalid defects/bugs.

Don't get me wrong, i'm not trying to short shift users by saying "not a defect" but trying to make the process smoother so that things get fixed.

答:
A change control board (CCB) would be helpful to shield the developers from the user requests. A CCB is a group (although it could be an individual) that meets on a regular basis to review the latest submitted defects, determine their impact, prioritize them, and in some cases, assign them to a member of the development team.

The CCB would review all of the defects and feature requests submitted since the last meeting. For each one, they would determine if it's a valid request. If it's not, it would get closed with a reason why. If it is valid, it would be assigned a criticality and perhaps a milestone for incorporation or deadline date. The development lead at the CCB might even assign the task to a specific developer, depending on the process you are using.

Developers only need to care about the defects and feature requests approved by the CCB, and not all defects submitted by the user. The CCB would also be responsible for transforming user requests into the expected input to the development team such as a formal bug report, a prioritizied user story, or an updated requirements specification.

Depending on your situation, it might not be possible to provide your users/customers with access to your issue tracking tool. In such an instance, you would want another standardized method for everyone to submit reports with all of the information the CCB would need to turn it into a bug report or feature request in the issue tracking tool of your choice. Quality assurance would most likely still be submitting right into the issue tracking tool that you are using, but they would be reviewed, prioritized, and assigned by the CCB before a developer starts working on it.

Title: Managing UAT / Defect and Bug raising


答:
First of all, if you aren't yet using an issue tracker tool, get one and make it accessible to users. This way they can enter their bugs into it, rather than pestering you directly via emails or phone calls. You should of course train them to use the tool correctly - this may be a significant initial investment, but it will quickly pay off.

Let users freely report anything they consider a bug, but have them assign severity and/or priority to each bug. This allows you to focus on the most important / urgent ones, but still keep track of all. All decent bug trackers have built in support for these properties, and allow you to query / filter / order bugs according to them. In case the severity or priority of a bug is incorrect, you can discuss this with the user and modify it. If some users often report issues which aren't real bugs, or aren't reproduceable, you (or your management) may need to discuss this with them, and/or - again - educate them on how to document items to make them usable in the development process.

Title: Managing UAT / Defect and Bug raising

Body:
I'm looking for assistance in figuring out the best approach to managing User Acceptance Testing (UAT) and how users raise defects/bugs - I've been in the situation before of having to deal with a free for all in that every small error is raised as a bug which takes valuable time from actual bug fix whilst I sift through lots of invalid defects/bugs.

Don't get me wrong, i'm not trying to short shift users by saying "not a defect" but trying to make the process smoother so that things get fixed.


问:
How do you explain refactoring to a non-technical person?
How do you go about explaining refactoring (and technical debt) to a non-technical person (typically a PHB or customer)? ("What, it's going to cost me a month of your work with no visible difference?!")

UPDATE Thanks for all the answers so far, I think this list will provide several useful analogies to which we can point the appropriate people (though editing out references to PHBs may be wise!)

答:
I thought of another example, which apparently no-one here has mentioned: refactoring is pretty much exactly the same as rearranging an equation in maths (though that might fall outside the scope of 'non-technical person, I guess).

When you rearrange an equation, you just 'move stuff around' to make it more readable and more usable, without changing the meaning.


问:
What hurts maintainability?
For someone who doesn't have much real world experience yet, the notion of maintainable code is a bit vague, even though it follows from typical good practice rules. Intuitively I can tell that code can be well written, but not maintainable if for example it hard-wires information that is subject to constant change, but I still have a hard time looking at code and deciding if it's maintainable or not.

So the question is: what hurts maintainability? What should I look for?

答:
The better approach for maintainability from my experience is to have as little code as possible and shove the work to others (i.e. the software vendors) who do the maintenance for you.

I prefer to have as little custom source as possible and push as much as possible to Excel sheets, XML or property files that represent the business data and provide simple readers or use an ETL tool to do the conversion to application code.

I also try to find something that is standard based (i.e. no single vendor) if possible.  However, there are some things we cannot avoid e.g. Spring for dependency injection before JEE6 and Hibernate for ORM before JEE5, log4j/commons-logging/slf4j before Java 1.4.  By choosing something standard based, there is a higher possibility of switching providers especially if one becomes defunct or prohibitively expensive and you avoid classpath hassles.

Of course if you're the vendor that is providing the software that's another matter.  However, if you are dealing with real life situations sometimes it's better to throw money into the problem rather than skill and time.

Title: What hurts maintainability?


问:
Dominant team members in a Scrum team
What would you do in a situation where a team member tries to take responsibilities are not initially assigned to him but to the Scrum Master?</p>

答:
Propose that he becomes the Scrum Master for the following sprint.

People willing to take on responsibilities is not a problem (as long as they don't want monopoly over them), it's precisely what we're looking to achieve with self-organization.

Teams with a rotating scrum master role aren't uncommon, by the way.

OwnerDisplayName: anon

LastEditorDisplayName: anon

Title: Dominant team members in a Scrum team


答:
Give them a simple math equation.  For example:

Which is simpler?

```<code>y = x + x
</code>```

or

```<code>y = 2x
</code>```

Refactoring is a similar concept except instead of simple math equations, you put in algorithms.  The main idea is that you can swap between two ways of doing things because they will yield the same result.

The simplest refactoring that can be done is renaming.

```<code>doX() { ... }
{
   doX()
}
</code>```

Now because we don't really want things to be called doX because we don't really know what it means, we rename it to something else that is more self explanatory and replace anywhere we have used it.

```<code>doBusinessTransaction() { ... }
{
   doBusinessTransaction()
}
</code>```

This will save you money later on when there is a problem or enhancement because it reduces the time for people to understand and fix your application.  To further save money, there are free tools that do this work for you automatically depending on what language you are using.  These tools are also licensed such that it is not restrictive and would require you to do anything special aside from acknowledging it if you use it directly.

Title: How do you explain refactoring to a non-technical person?

Body:
How do you go about explaining refactoring (and technical debt) to a non-technical person (typically a PHB or customer)? ("What, it's going to cost me a month of your work with no visible difference?!")

UPDATE Thanks for all the answers so far, I think this list will provide several useful analogies to which we can point the appropriate people (though editing out references to PHBs may be wise!)

Body:
Give them a simple math equation.  For example:

Which is simpler?

y = x + x

or

y = 2x

Refactoring is a similar concept except instead of simple math equations, you put in algorithms.  The main idea is that you can swap between two ways of doing things because they will yield the same result.

The simplest refactoring that can be done is renaming.

doX() { ... }
{
   doX()
}

Now because we don't really want things to be called doX because we don't really know what it means, we rename it to something else that is more self explanatory and replace anywhere we have used it.

doBusinessTransaction() { ... }
{
   doBusinessTransaction()
}

This will save you money later on when there is a problem or enhancement because it reduces the time for people to understand and fix your application.  To further save money, there are free tools that do this work for you automatically depending on what language you are using.  These tools are also licensed such that it is not restrictive and would require you to do anything special aside from acknowledging it if you use it directly.


问:
Does EF mean you might never have to use SQL or design database tables again?
Does Entity Framework mean you might never have to use SQL or design database tables again?

Is this what "persistence ignorance" means?

I am new to EF and ORMs in general, and I would like to understand how much of it is hype and how much is reality.

答:
EntityFramework is a great tool, but like any great tool you would do yourself a great disservice to not understand the inner workings of how it translates a data model into a database schema, and also how it translates its own queries into SQL.

Everything works great until something goes wrong, then you are looking in log files trying to decipher the generated SQL to figure out where the bug is.  Good luck with that if you do not have an understanding of the schema or SQL.

The term "Persistence Ignorance" is heralded as a good thing, but only in terms of creating loose coupling from your data access layer.  Your business logic and presentation layers should be "Persistence Ignorant", not the developer!

Only in the US is Ignorance celebrated as a good thing ;)


问:
What is the difference between the "lib" and "vendor" folders?
Regarding source folder hierarchy, there are always some common features, such as the src, doc or test folders, which have rather easy-to-understand contents.

However, I realized that big projects have both a lib and vendor folders, while I had always thought they were the same, as their names hint at including “third-party libraries from external vendors”. Though, seeing both in the same project means there is a difference.

I couldn't find any information nor on Google nor on sources such as the Filesystem Hierarchy Standard, even though this is actually a somehow common practice.

Here is a more detailed example with Symfony: once you create a project, you get a lib folder at the root of your project. In this folder, the following structure is found:

```<code>lib
+--filter
+--form
+--…
+--vendor
    +--simpletest
    +--symfony
</code>```

Here, the symfony folder contains all Symfony's core.

答: In the case of something like Symfony, lib is the application code (i.e. written by the developers) and vendor is third-party code.  Think of it like lib is what the src folder normally is, and vendor is lib.  I normally see that style in PHP because you separate out the html templates from the actual classes.


问:
What is the possible disadvantage of putting declarations in inner blocks, instead of at beginning of function?
At the place where I work, there are explicit guidelines for placement of declarations of variables. According to that, it is required to put them at the global level and / or at the beginning of functions, and not in inner blocks (such as a for loop). Since they've been specified by persons more experienced than I am, I'm sure that there must be a good reason for it, but I cannot figure out what that might be. It would be nice to know if there are any compile time / run time advantages at having them declared at a bigger scope.</p>

答:
Not sure if you can call this a best-practice. When I set up guidelines for a new C project I always state that it is better to declare the variables close to where they are used. For two reasons, it makes it easier to refactor the code later on (i.e. when extracting a method). It also helps the compiler to do better optimization.

I'm not alone with this opinion. Here's a question that tackles the same problem:
https://softwareengineering.stackexchange.com/questions/56585/where-do-you-declare-variables-the-top-of-a-method-or-when-you-need-them
The answer here is to declare them where you use them. The same practice is described in the book 'Clean Code' by Robert C. Martin.

However, if you use an older C-standard (C-89), you must define local variables at the top of the function. So maybe the guideline is a remnant from the time when C-89 was used? It is probably better to ask the person that wrote the guidelines why the rule is still in there.


答:
Actually no.  The basic database concepts will apply and you have to know some basic rules of what databases can do or else you'd face significant performance issues.

Entity Frameworks are useful to handle the conversion of mapping data from database records into objects.  This allows developers to not have to deal with creating data access objects because the framework does it for you already.

So this will do quite a bit for developers especially when persisting data.

Looking up data can be performed with entity frameworks as well, but lookups are not always best done with just entity frameworks alone because if done improperly you will have memory issues when someone decides to load up the entire database into memory.  Or I/O issues if someone decides to do queries inside another query.  (Those two are the common performance issues I see when I review other people's code).

Sometimes it may be that you need raw SQL, stored procedure or a database view in order to get the best performance/maintainability ratio.

As such a good DBA is a valued resource.  Although I try to relegate the database to be just a data store, they still need to perform tuning so the proper indices and storage allocation is done correctly.

One thing that entity frameworks allow me to do is to talk about objects and tables with the DBA in logical terms rather than physical terms.  It allows application development and database to form a contract in the form of an Object Relational diagram that they agree to reduce the chances of defects (or at the very least quickly assign the blame).

UPDATE:
Three other things I would like to add...

Views.  ORMs may be able to read views, but it still takes a relatively skilled DBA to make a very complex one so it will optimize queries for other parts of the application.

Data migration. As your project grows so would your schema.  You'd need a skilled enough DBA to know how to migrate your data from one version of your application to another.

Data archival. As your project keeps on going, eventually you'd have a large dataset and you'd have to figure out how to partition and archive the old data so it will not impact the performance.

Title: Does EF mean you might never have to use SQL or design database tables again?

Body:
Does Entity Framework mean you might never have to use SQL or design database tables again?

Is this what "persistence ignorance" means?

I am new to EF and ORMs in general, and I would like to understand how much of it is hype and how much is reality.


答: +1 to maple_shaft.  I would add that even when you are using the (much balyhooed) EF Code First you are still modelling tables.  It's been more than 20 years that people have used modelling and CASE tools that put an abstraction layer between themselves and the DDL script that builds their tables.  That doesn't change the fact that they need to know how to design tables properly.</p>


答:
Anything that is not simple to understand.

The most destructive force for any kind of code is maintenance. Unfortunately, maintenance is also absolutely necessary. If the maintainer does not quickly understand the code they will either route around it which is just as destructive or almost certainly break it.

To misquote Einstein: Make it as simple as possible - but no simpler.

Title: What hurts maintainability?

Body:
For someone who doesn't have much real world experience yet, the notion of maintainable code is a bit vague, even though it follows from typical good practice rules. Intuitively I can tell that code can be well written, but not maintainable if for example it hard-wires information that is subject to constant change, but I still have a hard time looking at code and deciding if it's maintainable or not.

So the question is: what hurts maintainability? What should I look for?


答:
Too many features.

Features themselves by nature hurt maintainability because you need to write extra code to implement them, but an application without features is pointless, so we add features. However, by leaving out unnecessary features you can keep your code more maintainable.

Title: What hurts maintainability?


问:
How do you determine velocity when the previous sprint was half User Stories and half Defects?
The following scenario often happens with my team at the office. Let's say we decided to plan our Sprint this way:

50% new features

50% bug fixing (they are high priority AND unestimated as the fixes are easy, the hard and time-consuming bit is the investigation)

The Sprint goes well and we finish all the features, say X story points, and quite a few unestimated bugs.

Two questions come to mind:

What is our Sprint velocity? Is it X?

Assuming it is X; how do we plan the next Sprint using "yesterday's weather" (X story points) if we now want to do an 100% new features Sprint?

答: Add the time spent on fixing bugs in a story to the time spent developing the story (because actually the total time you spent on developing the story includes fixing the bugs: the story was not acceptable to the product owner in the buggy state). Now that is an indication of your velocity.


问:
Inheritance vs mixins in dynamic languages?
When should you prefer inheritance patterns over mixins in dynamic languages?

By mixins, I mean actual proper mixing in, as in inserting functions and data members into an object in runtime.

When would you use, for example, prototypal inheritance instead of mixins? To illustrate more clearly what I mean by mixin, some pseudocode:

```<code>asCircle(obj) {
  obj.radius = 0
  obj.area = function() {
    return this.radius * this.radius * 3.14
  }

myObject = {}
asCircle(myObject)
myObject.area() // -> 0
</code>```

答:
My horse sense tells me this:

If something is useful across multiple objects or class hierarchies -- make it a mixin

If something is only useful along a single hierarchy -- use inheritance

Related Notes:

The word "useful" should be taken metaphorically

For those languages that don't have multiple inheritance, mixins are a good alternative

PHP 5.4 introduces traits that have goodness from both mixins and multiple inheritance worlds


答:
Prototypical inheritance is simple. It has a single advantage over mixins.

That is that it's a live link. if you change the prototype everything that inherits it is changed.

Example using pd

```<code>var Circle = {
  constructor: function _constructor() {
    this.radius = 0;
    return this;
  },
  area: function _area() {
    return this.radius * this.radius * Circle.PI
  },
  PI: 3.14
};

var mixedIn = pd.extend({}, Circle).constructor();
var inherited = pd.make(Circle, {}).constructor();

Circle.perimeter = perimeter;

inherited.perimeter(); // wins
mixedIn.perimeter(); // fails

function perimeter() {
  return 2 * this.radius;
}
</code>```

So basically, if you want changes to the "interface" Circle to reflect at run-time to all objects that "use" it's functionality, then inherit from it.

If you do not want changes to reflect then mix it in.

Note that mixins have more purpose than that as well. Mixins are your mechanism for multiple "inheritance".

If you want an object to implement multiple "interfaces" then you will have to mix some in. The one you use for prototypical inheritance is the one you want changes to reflect for at run-time, the others will be mixed in.

Title: Inheritance vs mixins in dynamic languages?

Body:
When should you prefer inheritance patterns over mixins in dynamic languages?

By mixins, I mean actual proper mixing in, as in inserting functions and data members into an object in runtime.

When would you use, for example, prototypal inheritance instead of mixins? To illustrate more clearly what I mean by mixin, some pseudocode:

```<code>asCircle(obj) {
  obj.radius = 0
  obj.area = function() {
    return this.radius * this.radius * 3.14
  }

myObject = {}
asCircle(myObject)
myObject.area() // -> 0
</code>```

Body:
Prototypical inheritance is simple. It has a single advantage over mixins.

That is that it's a live link. if you change the prototype everything that inherits it is changed.

Example using pd

var Circle = {
  constructor: function _constructor() {
    this.radius = 0;
    return this;
  },
  area: function _area() {
    return this.radius * this.radius * Circle.PI
  },
  PI: 3.14
};

var mixedIn = pd.extend({}, Circle).constructor();
var inherited = pd.make(Circle, {}).constructor();

Circle.perimeter = perimeter;

inherited.perimeter(); // wins
mixedIn.perimeter(); // fails

function perimeter() {
  return 2 * this.radius;
}

So basically, if you want changes to the "interface" Circle to reflect at run-time to all objects that "use" it's functionality, then inherit from it.

If you do not want changes to reflect then mix it in.

Note that mixins have more purpose than that as well. Mixins are your mechanism for multiple "inheritance".

If you want an object to implement multiple "interfaces" then you will have to mix some in. The one you use for prototypical inheritance is the one you want changes to reflect for at run-time, the others will be mixed in.


答:
Velocity is X because velocity measures how much story points (= business value) you delivered in the last sprint. But you have second value available - capacity. Capacity is number of hours / man days you have available for the sprint. So if you now doubled the capacity you can assume that your velocity will increase. It is up to team to judge if doubling the capacity will double expected velocity. Of course not every increase in capacity will lead to increase in velocity. For example adding team member will definitely not have immediate effect of velocity increase (the reverse is usually true for few sprints).

If your capacity change frequently by large amount of hours / man days it will affect average velocity value and its meaning for forecasting will be much worse.

Btw. 50% time spend on bug fixing should raise some questions about the way how you deal with quality of your product = how you create your automated test suite.

Title: How do you determine velocity when the previous sprint was half User Stories and half Defects?

Body:
The following scenario often happens with my team at the office. Let's say we decided to plan our Sprint this way:

50% new features

50% bug fixing (they are high priority AND unestimated as the fixes are easy, the hard and time-consuming bit is the investigation)

The Sprint goes well and we finish all the features, say X story points, and quite a few unestimated bugs.

Two questions come to mind:

What is our Sprint velocity? Is it X?

Assuming it is X; how do we plan the next Sprint using "yesterday's weather" (X story points) if we now want to do an 100% new features Sprint?


问:
Giving away sensitive information about previous employers during interview
When you are being interviewed by potential future employers, it is of course of benefit to both parties to discuss what your previous job entailed (ie, what you have been doing for the last few years).  What if the technology (and the ideas behind the technology) that you have been working on is sensitive and confidential?

I'm working on some really cool stuff at the moment, things that would impress an interviewer, that could demonstrate my passion and understanding, but at the same time I can't just come out and explain the nature of it without disclosing too much about my current employer.  On the other hand, if I keep it vague without explaining the subtleties, it just seems as though I am working on fairly basic applications.  The key is in the middle ground- the way the applications are constructed- which makes what I currently do both special and difficult. But even acknowledging this middle ground gives away vital information about how my employer competes.

Hope that made some sense.  What should I do in an interview? Is there like a 2-way NDA for interviews so I can just launch into an in-depth explanation of my past experience, or do I need to be deliberately vague and apologise for not being able to go into detail?

答: Just tell your new employer just what you wrote in your question.</p>


答:
What makes maintainance necessary is that requirements are a moving target.
I like to see code where future possible changes have been anticipated, and thought put into how to handle them if they should arise.

I have a measure of maintainability.
Suppose a new requirement comes along, or a change in an existing requirement.
Then the changes to the source code are implemented, along with fixing any related bugs, until the implementation is complete and correct.
Now run a diff between the code base after and the code base before.
If that includes documentation changes, include those in the code base.
From the diff you can get a count N of how many insertions, deletions, and replacements of code were necessary to accomplish the change.

The smaller N is, as a rough average over past and future requirements changes, the more maintainable the code is.
The reason is, programmers are noisy channels. They make mistakes.
The more changes they have to make, the more mistakes they make, which all become bugs, and every bug is harder to find and fix than it is to make in the first place.

So I'm agreeing with the answers that say follow Don't Repeat Yourself (DRY) or what's called cookie-cutter-code.

I'm also agreeing with the movement toward domain-specific-languages (DSLs) provided they reduce N.
Sometimes people assume the purpose of a DSL is to be "coder-friendly" by dealing in "high-level abstractions".
That doesn't necessarily reduce N.
The way to reduce N is to get into a language (which may be just things defined on top of an existing language) that map more closely onto the concepts of the problem domain.

Maintainability doesn't necessarily mean any programmer can just dive right in.
The example I use from my own experience is Differential Execution.
The price is a significant learning curve.
The reward is an order of magnitude reduction in source code for user interface dialogs, especially those that have dynamically changing elements.
Simple changes have N around 2 or 3.
More complex changes have N around 5 or 6.
When N is small like that, the likelihood of introducing bugs is much reduced, and it gives the impression that it "just works".

At the other extreme, I've seen code where N was typically in the range of 20-30.

Title: What hurts maintainability?


答:
Definitely no because EF is heavily dependent on correct database design. It usually fails expectation where used with legacy or incorrectly designed databases. Also full power of EF can be unleashed only when combining with direct SQL.

Each abstraction shields you from some implementation. ORM is abstraction of data access but only coding monkeys are shielded from these details as well. Developers must understand concepts running under the hood of abstraction to know how to use them correctly.


答:
I don't think you need be vague:- you can be very specific up-front about what you are -and are not- prepared to discuss. A good (prospective) employer will appreciate your honesty.

Remember that if you're applying for a job with a direct competitor you have a more compelling moral and legal problem if you get the job: You can't 'unlearn' your past experience, and your new employer may well be recruiting you partly for the inside knowledge you can bring. Check you contract of employment carefully, and consult a lawyer if needs be.

I've always wanted to say:-

I can tell you, but then I'll have to kill you

...in an interview...

Title: Giving away sensitive information about previous employers during interview

Body:
When you are being interviewed by potential future employers, it is of course of benefit to both parties to discuss what your previous job entailed (ie, what you have been doing for the last few years).  What if the technology (and the ideas behind the technology) that you have been working on is sensitive and confidential?

I'm working on some really cool stuff at the moment, things that would impress an interviewer, that could demonstrate my passion and understanding, but at the same time I can't just come out and explain the nature of it without disclosing too much about my current employer.  On the other hand, if I keep it vague without explaining the subtleties, it just seems as though I am working on fairly basic applications.  The key is in the middle ground- the way the applications are constructed- which makes what I currently do both special and difficult. But even acknowledging this middle ground gives away vital information about how my employer competes.

Hope that made some sense.  What should I do in an interview? Is there like a 2-way NDA for interviews so I can just launch into an in-depth explanation of my past experience, or do I need to be deliberately vague and apologise for not being able to go into detail?


答: I've frequently had to use phases such as "I can't go into any more detail due to {security/confidentiality/NDA}" at an interview. For every project that I'm working on, I know exactly what is classified, what is competition sensitive, what is covered by an NDA, and what can be shared and who it can be shared with. If a piece of information comes across my desk, and it's not clear what category it is, I always ask the sender or a project manager to confirm, even if I'm not interviewing. It keeps everyone on the same page, and lets me know exactly what I can share with colleagues in a given situation.</p>


答:
There are two things you should consider. One is legal, the other is ethical.

Legally speaking, you need to be careful you don't break any confidentiality agreement signed when you took on the first job.

Ethically speaking, you shouldn't say anything that might reveal sensitive data that could potentially hurt the company you work for, regardless of whether you signed or not a confidentiality agreement with them.

Keep in mind that a recruiting company is not going to be looking at your skills alone. They look for much more than that. If you come out talking too much about sensitive data, they'll most likely feel that in the future, you might do the same to them, and regard you as not trustworthy.

Only you can know how much to say, without saying too much. Unless you don't mind telling us everything so we can then tell you what you should say :P


答:
While you can't say what a particular feature, product, book, or whatnot is, you can say why it excites you. Does it make the software faster than ever before? Does it delight the end users? Does it combine two things that could never be combined before?

As an interviewer, the WHY is always more important than the what. "What are you most excited about on your current project and why?" "I'm adding a feature to our flagship product and while I can't describe the feature, I can tell you why I fought to have it added to the design. ". Or ", I can tell you why I was thrilled to be the one chosen to implement it." When you talk about the benefits of the feature, or the product or whatever, about its place in the overall ecosystem of users and developers, or even about the flat out fun of working in a new language or pushing the machine to new things, you tell me about yourself and tell me why I want to hire you. And that's the whole point of the interview.

It will probably take a little practice to do this without revealing what you shouldn't reveal. Go ahead and practice out loud.


问:
Is it misguided to label mobile web applications as cross platform?
Yes, you can access the mobile web site from a range different mobile devices, but the platform, I suppose, is still the web server and the client browser (the latter ideally being the "same" on any device).

When talking mobile and cross platform I am thinking frameworks such as PhoneGap and Appcelerator Titanium, but still with a reluctance to call it cross platform as the deployed products are not the same. I guess I am hung up on the idea that it has to be directly equivalent to the Java virtual machine to call anything cross platform, but maybe I am the one who is misguided.

What is the general opinion?

答:
I do not think it is useful to say that a web application is cross-platform. In the phrase "our web application is cross-platform" you haven't actually provided any more information than if you said "we have a web application". In both statements we still do not know if the web application adheres to standards and can work with many different browsers, which is really what is important with a web application.

Generally cross-platform refers to an application that actually executes on the client.


答: As an interviewer, I probably wouldn't want to hire someone who freely gives away his previous employers intellectual property, so it's good to think about this and be open about it during an interview. On the other hand, you should have some work experience that you can talk about: Maybe a debugging war story (like that one time when you found the dangling pointer in Bill's code that caused the system to slow down on Wednesdays) or a piece of OO architecture that's very elegant, but not very sensitive, IP-wise. In the end, most interviewers aren't interested in stealing from your former employers but in your ability to solve problems.


答: The only time that cross-platform is relevant to a web application is in dealing with the different idiosyncrasies of each browser and tuning the user experience to work just as well on each.  The host platform of the browser is somewhat less relevant, but may be a factor, especially with differing plugin (flash, etc) support.</p>

Title: Is it misguided to label mobile web applications as cross platform?

Body:
Yes, you can access the mobile web site from a range different mobile devices, but the platform, I suppose, is still the web server and the client browser (the latter ideally being the "same" on any device).

When talking mobile and cross platform I am thinking frameworks such as PhoneGap and Appcelerator Titanium, but still with a reluctance to call it cross platform as the deployed products are not the same. I guess I am hung up on the idea that it has to be directly equivalent to the Java virtual machine to call anything cross platform, but maybe I am the one who is misguided.

What is the general opinion?


问:
Are COM objects a form of IPC?
In Pro C# 2008 it is stated

Using constructs such as AppIDs, stubs, proxies, and the COM runtime
  environment, programmers can avoid the need to work with raw sockets,
  RPC calls, and other low-level details.

It then demonstrates a VB6 call where a COM object is instantiated by passing in the AppId.  Then, a method call is performed on said object.

Does this mean COM allows IPC directly with objects?  Is this secure?  Why does .NET disallow this behavior?

答:
Yes, COM is a form of IPC.  It is even listed on the IPC page you linked.

.NET does not prohibit IPC.  In fact, it provides several mechanisms to do IPC.  I think the intention, as outlined in your quoted block, is that the .Net mechanisms are provided at a higher level (COM, Enterprise Services, Remoting) rather than doing low level activities such as socket programming, shared memory, remote procedure calls, etc.

Title: Are COM objects a form of IPC?


问:
Programming paradigms and the maintenance developer
I was reading, Facts and Fallacies of Software Engineering, which has a section of maintenance. Since, I'm have been a maintenance developer for years now, I was very interesting facts presented. Here's three.

Fact 41: Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.

Fact 42: Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.

Fact 45: Better software engineering development leads to more maintenance, not less.

This one was counter-intuitive, turns out that good software has more maintenance, because it's easy to change. Hence, it stays in use longer, leading to, yes, more changes.

Which paradigm (such as functional, object-oriented, procedural) has the best maintainability, and is there any research to back this up?

答:
I think you will find that paradigms such as functional, OO, and procedural probably don't corellate with software maintainability in a meaningful way.

What you might find the following corellates much more clearly with software maintainability:

Level of requirements gathering and requirements engineering

Good development practices: (Loose coupling, High Cohesion, Unit testing, YAGNI...)

Skilled and qualified software engineers (They are worth 10 times as much as a moron)

Qualified and organized technical QA team

Good project management led by competent project managers (Even harder to find than skilled software developers IMHO)

Good Product Owners or application managers, strong leadership, good long-term direction, good feedback to the project teams, overall vision.


答: If you're seeing a lot of friction trying to go from Model -> ViewModel, try something like AutoMapper.  It removes the tedium associated with copying properties manually.</p>

Title: Should we bind view to a model property or ViewModel should have it's own..?

Body:
I am starting a project with following technical environment :
.Net 4.0, Entity Framework 4.0, WPF with MVVM Architecture

I saw lots of examples on the net, some books with this environment. In some of the examples authors had this Idea :

Viemodel will have an instance of Model class (Entity Framework Entity e.g. Person)

Bind the WPF view controls to the properties of Model

While some authors did :

Viemodel will expose all the properties of the model.

Bind the WPF view controls to the properties of ViewModel rather than to the model
directly.

So is it a good idea to let the view bind properties from model rather than viewmodel exposing its own? Or which is more preferred?


问:
Is there a mature, easy-to-use CQRS framework that is not Azure-specific, not outdated, or not well adopted?
I've been doing research on .net implementations with CQRS. Either everything I've seen so far is do-it-yourself, azure-specific, outdated (i think), or not well adopted

Problems:

Scritchy - is not well adopted

NCQRS - appears to be a bit older? it also requires a DIY-ish setup - meaning, you need to create several projects yourself (not all that terrible though).

https://github.com/gregoryyoung/m-r - more of a theoretical demo than a production framework

LOKAD.CQRS - mostly azure specific

https://github.com/MarkNijhof/Fohjin - again, more of a demo than framework

I'm working on a new project. It will be hosted in AppHarbor. I would like to use a CQRS approach. I would prefer to use an awesome framework rather than write/copy it myself.

答:
(Disclaimer: I am the author of Scritchy)

I can not talk for the other frameworks, but in my case, Scritchy merely exists because I wanted to provide a quick and easy to use tool for writing CQRS apps, also taking away some of the burden of writing similar command handlers over and over...

As the experts are saying: CQRS in it's most basic representation is quite simple, so it does not really require a framework.

However, since I personally use the CQRS approach a lot and I hated writing the same boilerplate code over and over, I decided to write an opinionated framework for it (think RoR for CQRS).

Scritchy is a very pragmatic and opinionated approach to CQRS (preferring convention over configuration), but it has been designed in a way that every component should easily be replaceable by some other component... (i.e. an easy to replace base class for your ARs is the only dependency).

As Scritchy has been in development for only a short time - even though it functions perfectly for my needs -, it is not as adopted as most of the other frameworks.

One framework a lot of the people in the community seem to approve, is Jonathan Oliver's event store, which is not a specific CQRS framework per sé, but he does offer some CommonDomain objects you can use in your CQRS apps.

My suggestion: pick one, setup basic infrastructure and get started. The hardest part in CQRS is usually not in the infrastructure, but in the domain (or at least, it should be ;) )


问:
How to encourage creative user interface design?
When I picture a really well functioning software team in my mind, one of the visions I have is of a developer showing off to a small group of devs some cool, clever UI that they just came up with based on something that they were just playing with.

I'm afraid that while we're doing great at being creative writing expressive, well architected, high quality code - we aren't pushing any creative boundaries when it comes to effective user interface.

What's an effective strategy for encouraging developers to push their boundaries with user interface?

Edit:

I'm looking for something "lab oriented", like for instance pair programming sessions focused on some problem or other.

答:
As strange as it sounds, there are methodical ways to foster creativity.  I highly recommend Strategies for Creative Problem Solving by Scott Fogler and Steven LeBlanc.  It's one of the few books from college that's dog eared and earned a permanent place on my bookshelf at work.  The book is geared toward engineering, but can be applied toward any creative endeavor.

First we need to define the real problem.  Often we jump right into generating solutions without knowing if we're solving the right problem.  A methodical technique for defining the real problem is using Duncker diagrams to illustrate the present state - desired state technique.

For user interfaces, you really need a non-programmer to help, because we have the bad habit of thinking things like markdown are intuitive UI.  It doesn't necessarily need to be formal.  I call this the "wife test."  I open the software and give her a task to accomplish, like "comment on a photo," without any further instructions, and watch where she gets hung up.  This step is crucial to change your problem definition from something impossible to solve like "the UI feels clunky" to lists of easy to solve design issues like "it isn't clear that you must log in before commenting on a photo."

Only after we know the real problem can we move on to generating solutions.  Techniques for this range from recognizing your mental blocks, to brainstorming, to less known techniques like random stimulation or fishbone diagrams.


答:
I think the way to answer this question, is to take a step back, and define what is your development process. If you are using Scrum, or some other agile development methodology which has a defined release schedule, and a process for determining what goes in each release, you can push off dealing with the bugs until the next release planning session. (Of course, any "show stopper" bugs have to be fixed immediately.)  The release planning session should be about prioritizing the bugs, together with any new feature requests, and deciding what gets in, what gets left out.  If you are doing fairly quick release cycles (like every 1-2 weeks), users will get the confidence that the important stuff is getting fixed quickly.

What Peter said above, about having an Issue Tracking system, which allows users to capture the bugs, and set priorities, is critical. However, that is only the first step, since the bug fix won't get into a release unless the "team" agrees on it.

This is actually a great question, with no simple answer. Whatever solution you use needs to fit your organization.

You might find this link interesting reading, as a starting point for more investigation on what methodology would work best for you.

Coping with Bugs on an Agile/Scrum Project

Title: Managing UAT / Defect and Bug raising


答:
Use the "Is-a" test.

Inheritance is limited to the case when you can say "Subclass IS A Superclass".  They are the same kind of thing.  "Cheese is a Dairy Product".

Mixins are for everything else.  "Cheese can be used in a sandwich".  Cheese isn't a sandwich, but it participates in sandwiching.

PS.  This has nothing to do with dynamic languages.  Any multiple inheritance language with static compilation (i.e., C++) has the same decision point.


答:
This one was counter-intuitive, turns out that good software has more
  maintenance, because it's easy to change. Hence, it stays in use
  longer, leading to, yes, more changes.

You seem to be viewing this from the amount of maintenance and not the percentage of cost. Good software that has more features added is just a larger amount of software. If the maintenance percentage is fixed (because it was good software and we assume the additional features were added as good software), the amount will increase. It's just a larger piece of pie with the same number of slices.

Based on what your asking, it matters whether the "good" software was written in: functional, OOP, or procedural code. Will giving someone a laser-guided power saw save on wood if the person doesn't know how to measure?

Title: Programming paradigms and the maintenance developer

Body:
I was reading, Facts and Fallacies of Software Engineering, which has a section of maintenance. Since, I'm have been a maintenance developer for years now, I was very interesting facts presented. Here's three.

Fact 41: Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.

Fact 42: Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.

Fact 45: Better software engineering development leads to more maintenance, not less.

This one was counter-intuitive, turns out that good software has more maintenance, because it's easy to change. Hence, it stays in use longer, leading to, yes, more changes.

Which paradigm (such as functional, object-oriented, procedural) has the best maintainability, and is there any research to back this up?


问:
Stuff every programmer needs while working
I've been tasked with creating a fun and relaxing environment, one thing I know that I want is ergonomic mice and keyboards, others have suggested exercise balls and bands.

What is it that every programmer needs while working? What might not be necessary but would be nice to have anyway?

Note: this question was asked previously, but has been recommended to be posted here. See this link for the previous responses: https://stackoverflow.com/questions/3911911/stuff-every-programmer-needs-while-working-closed

答: For me a gym.  I'm a physical guy and I know a lot of programmers are not, but I need to go and work out or i'm just not as productive.  It doesn't have to be much but a place where you can do pull ups or sit ups a chin up bar and a punching bag.  however I would do this after you have 2 monitors and a place where ideas are debated but those have already been mentioned.</p>

ContentLicense: CC BY-SA 2.5


答:
This isn't really an answer so much as a long comment (Because these answers have already been presented).

I've found that striving religiously for two factors--clean, usable interfaces and no repetition have made my code much better and over time have made me a much better programmer.

Sometimes eliminating redundant code is HARD, it forces you to come up with some tricky patterns.

I usually analyze what MUST change then make that my goal.  For instance, if you are doing a GUI on a client to update a database--what do you need to add "Another" one (another control linked to the DB?)  You need to add a row to the DB, and you need the position of the component, that's it.

So if that is your bare minimum, I don't see ANY code in that--you SHOULD be able to do it without touching your codebase.  This is amazingly hard to attain, a few toolkits will do it (usually poorly), but it's a goal.  How hard is it to get close?  Not terribly.  I can do it and have done it with zero code in a couple ways, one is by tagging new GUI components with the name of the table in the DB, another by creating an XML file--the XML file (or YAML if you hate XML) can be really useful because you can link validators and special actions to the field, making the pattern extremely flexible.

Also, it doesn't take more time to implement solutions correctly--by the time you've shipped most projects it's actually cheaper.

I can point out that if you rely heavily on Setters & Getters ("Bean Patterns"), Generics & Anonymous inner classes you probably AREN'T coding generically like this.  In the above examples, trying to force in any of these will really screw you up.  Setters & Getters force you to use code for new attributes, Generics force you to instantiate classes (which requires code) & Anonymous inner classes tend not to be easy to re-use elsewhere.  If you are really coding generically, these language constructs aren't bad, but they can make it hard to visualize a pattern.  For a totally nonsensical example:

```<code>user.setFirstName(screen.getFirstName());
user.setLastName(screen.getLastName());
</code>```

Looks fine--not really redundant at all--at least not in a way you can fix, right?  But it causes you to add a line when you want to add a "Middle Name", so it is "Redundant code"

```<code>user.getNameAttributesFrom(screen);
</code>```

Does not need new code for this task--it simply requires that some attributes in "screen" are tagged with a "Name" attribute, but now we can't copy address, how about this:

```<code>user.getAttributesFrom(screen, NAME_FIELDS, ADDRESS_FIELDS);
</code>```

Nicer, a var-args lets you include a group of attributes (from an enum) to gather from the screen--still you have to edit code to modify the types of attributes you want.  Note that "NAME_FIELDS" is a simple enum instance--fields in "screen" are tagged with this enum when designed to put them in the correct categorie(s)--there is no conversion table.

```<code>Attribute[] attrs=new Attributes[]{NAME_FIELDS, ADDRESS_FIELDS, FRIENDS_FIELDS};
user.getAttributesFrom(screen, attrs);
</code>```

Now you've got it to where  you are just changing "Data".  This is where I usually leave it--with the data in the code--because it's "Good enough".  The next step is to externalize the data if that is ever needed, so that you can read it from a text file, but it rarely is.  Refactorings "Roll up" like this a lot once you get into the habit, and what I just did there^ created a new enum and pattern that will end up rolling in many other refactorings.

Finally, note that good generic solutions to problems like this are NOT language-dependent.  I've implemented a no-code-per-loc solution to parsing a text GUI from the command line of a router, updating it on the screen and writing it back to the device--in VB 3.  It just takes dedication to the principle of don't write redundant code, ever--even if you have to write twice as much code to do so!

The Clean Interface (Fully Factored & doesn't allow illegal stuff to pass through) is important too.  When you factor an interface between two units of code correctly, it allows you to manipulate code on either side of the interface with impunity and allows new users to implement to the interfaces cleanly.

Title: What hurts maintainability?

Body:
This isn't really an answer so much as a long comment (Because these answers have already been presented).

I've found that striving religiously for two factors--clean, usable interfaces and no repetition have made my code much better and over time have made me a much better programmer.

Sometimes eliminating redundant code is HARD, it forces you to come up with some tricky patterns.

I usually analyze what MUST change then make that my goal.  For instance, if you are doing a GUI on a client to update a database--what do you need to add "Another" one (another control linked to the DB?)  You need to add a row to the DB, and you need the position of the component, that's it.

So if that is your bare minimum, I don't see ANY code in that--you SHOULD be able to do it without touching your codebase.  This is amazingly hard to attain, a few toolkits will do it (usually poorly), but it's a goal.  How hard is it to get close?  Not terribly.  I can do it and have done it with zero code in a couple ways, one is by tagging new GUI components with the name of the table in the DB, another by creating an XML file--the XML file (or YAML if you hate XML) can be really useful because you can link validators and special actions to the field, making the pattern extremely flexible.

Also, it doesn't take more time to implement solutions correctly--by the time you've shipped most projects it's actually cheaper.

I can point out that if you rely heavily on Setters & Getters ("Bean Patterns"), Generics & Anonymous inner classes you probably AREN'T coding generically like this.  In the above examples, trying to force in any of these will really screw you up.  Setters & Getters force you to use code for new attributes, Generics force you to instantiate classes (which requires code) & Anonymous inner classes tend not to be easy to re-use elsewhere.  If you are really coding generically, these language constructs aren't bad, but they can make it hard to visualize a pattern.  For a totally nonsensical example:

user.setFirstName(screen.getFirstName());
user.setLastName(screen.getLastName());

Looks fine--not really redundant at all--at least not in a way you can fix, right?  But it causes you to add a line when you want to add a "Middle Name", so it is "Redundant code"

user.getNameAttributesFrom(screen);

Does not need new code for this task--it simply requires that some attributes in "screen" are tagged with a "Name" attribute, but now we can't copy address, how about this:

user.getAttributesFrom(screen, NAME_FIELDS, ADDRESS_FIELDS);

Nicer, a var-args lets you include a group of attributes (from an enum) to gather from the screen--still you have to edit code to modify the types of attributes you want.  Note that "NAME_FIELDS" is a simple enum instance--fields in "screen" are tagged with this enum when designed to put them in the correct categorie(s)--there is no conversion table.

Attribute[] attrs=new Attributes[]{NAME_FIELDS, ADDRESS_FIELDS, FRIENDS_FIELDS};
user.getAttributesFrom(screen, attrs);

Now you've got it to where  you are just changing "Data".  This is where I usually leave it--with the data in the code--because it's "Good enough".  The next step is to externalize the data if that is ever needed, so that you can read it from a text file, but it rarely is.  Refactorings "Roll up" like this a lot once you get into the habit, and what I just did there^ created a new enum and pattern that will end up rolling in many other refactorings.

Finally, note that good generic solutions to problems like this are NOT language-dependent.  I've implemented a no-code-per-loc solution to parsing a text GUI from the command line of a router, updating it on the screen and writing it back to the device--in VB 3.  It just takes dedication to the principle of don't write redundant code, ever--even if you have to write twice as much code to do so!

The Clean Interface (Fully Factored & doesn't allow illegal stuff to pass through) is important too.  When you factor an interface between two units of code correctly, it allows you to manipulate code on either side of the interface with impunity and allows new users to implement to the interfaces cleanly.


问:
What did Bill Gosper mean by saying a data structure is just a stupid programming language?
There's a quotation by Ralph William Gosper, Jr that says:

A data structure is just a stupid programming language.

What did he mean by this?  Alas, all I can find in Google about it is relentless copy/pastes of the quotation itself, without any context.

答:
Consider Javascript, where all data is code.
Consider LISP, where all data is code and all code is data.

In the beginning, end, and everywhere in between, data is just bits. That we attempt to ontologize bits with text and symbols to make them easily human-readable and human-transformable is a layer of abstraction that requires a) You learn the definition language and b) you learn the leakiness of the abstraction.

For example, in C#, learning the difference between a struct and class requires you learn the difference in equality comparison between value-types and reference-types. Every data ontology requires its own set of rules you must learn and adhere to. And, like any language, it allows you to quickly get to the general idea, but the closer you want to approach the actual truth of the matter, the more you should just look at the binary yourself.

Finally, when one considers a B-tree or similar data structure, navigating the structure of the tree and performing other kinds of operations on it requires a specialized kind of syntax that's not necessarily transferable across trees, structures, or languages.


问:
Should code review be performed before or after unit tests
I am debating with my colleague on when to perform code review - before or after unit tests.  What is the best practice?

Some factors we might need to take into account (there may be more):

Size of code change - a big change means more changes will result from the code review. If these changes are big than, if UT was before code review, you'll need to repeat most of your UTs again.

Time required to perform unit test

Is it new functionality or a bug fix

答:
Code Reviews are for when the code is "done".

In my organisation our definition of "done" includes unit tests (as we aim for TDD) so code reviews are of complete code - and complete code includes tests.

Also, tests need reviewing and refactoring so it make sense that they are part of the code review.

OwnerDisplayName: idimba

OwnerDisplayName: Neil Thompson


答:
Well,

This depends on what you mean by "Unit Test"...

If it was a TDD style Unit Test it is meaningless because you write
  test while you write your code. There is no after-later case.In this
  case you improve code quality continously: Refactoring...

AND

If it was classic "unit test" [ whatever it means i do not know, but i
  mean test after you write the codes and done by usually other guys]
  then the main criteria is what you expect from codereview and nature
  of unit tests: if you want fast feedback-make review and take action
  and have no automated unit test,you will have to wait unit test. If you
  want to identify mature problems with code review, and incrementally
  apply solution for next iterations, you may do it before unit test...

But after all personally, for codereview, after or later unit test is not a real criteria for me...

Why we do codereview? For code quality...Instead of a "quality control" gate, inject quality into your software developement process-enviroment...

Title: Should code review be performed before or after unit tests

Body:
I am debating with my colleague on when to perform code review - before or after unit tests.  What is the best practice?

Some factors we might need to take into account (there may be more):

Size of code change - a big change means more changes will result from the code review. If these changes are big than, if UT was before code review, you'll need to repeat most of your UTs again.

Time required to perform unit test

Is it new functionality or a bug fix


答:
You should always unit test before doing the code review and here's why

If your code is broken in a way that would be caught by unit tests you will be wasting the other developer's time by getting them involved in the red/green/refactor cycle.

Tests show other developers the intended use of the code which makes it easier to review.

Tests should be reviewed along with the code that is tested in case you are missing test cases or your tests don't work properly.

Tests and code review tend to catch different issues with only a little overlap in issues found. Unit tests don't get annoyed at having to retest code when the reviewer finds issues, developers do get annoyed and probably won't do as well the second time through.

There are probably other reasons but those are the ones I've personally seen and experienced having implemented code review practices within 3 different teams/companies.

Edit
Of course the above is for times when code review is a step in your software development process (whether waterfall or agile). If you're working on a particularly large or difficult section of code feel free to get another pair of eyes on it at any point.

OwnerDisplayName: Bryan Anderson


答:
I'd tend to say, let's be "agile"... don't wait for the code to be finished to make some quick, informal code review: there are developers with whom and subjects with which you can indeed wait for the entire code + test phasis to be finished... but

when it comes to really new subjects (whole new feature, near-research, something totally new to the team), code review early, don't loose time: have a coworker get a look from time to time: isolation is an important factor of failure in this case.

if the developer is new to the team, as well, review code early and maybe often.

and by the way, unit tests as well need code review.

OwnerDisplayName: armel


答:
Tests should be considered part of the code to review. Therefore it makes sense to review after tests are done.

Ensure the tests are reviewed as well. This is critical for those who are new to unit tests.

Make sure your team underetsnds dependency injection, isolation frameworks, mocks vs stubs, seams, interaction vs state based tests, and integration vs unit tests.

You don't need to implement the aforementioned topics, but you should understand them.


答:
All the tasks which are completed should be assigned some type of estimate. These estimates can be in time, user stories, or some other unit.

Upon completion of the sprint, you'll know which tasks were complete and which weren't. Even if some of the tasks were to fix defects, that is still considered tasks that were completed.

You can use this information to gather your slope. From here, you'll be able to apply this to a burn-down chart and get a percentage as to when you'll be down with the project at hand.

Finally, bugs created during a sprint should be fixed before the end of the iteration. A task should not be considered done if it had outstanding bugs in a sprint.


问:
Using bug-tracking / issue-tracking software to discuss design questions, new tools etc
Does anybody have experience with using a bug-tracking / issue-tracking software like bugzilla, mantis or JIRA not only for bugs or tasks, but to initiate and maintain discussions that in the end lead to a decision?

For example, a developer thinks that all protected fields should be abolished and changed to private fields with protected methods that access them. It is not his call, and he would like to discuss it. Normally he brings up the point in the next developer meeting at the end of which a decision is made. Instead, my idea was for him to open an issue of a certain type "decision" and describe his intent like normally one would describe a bug or task.

Other developers can make their comments if they feel like it, and in the end, the issue is closed as "accepted" or "denied".

The advantages I see in this:

Asynchronous communication: no one is forced to voice his opinion in a meeting when they didn't have time yet to oversee all ramifications of said decision.

Written log of considerations that lead to a decision. If one later raises that question again he can be referred to it.

Relations to other issues can be made, e.g. a task can be followed back to a decision.

Integration with version control software, e.g. a commit can be traced back to a decision.

Disadvantages:

Heavy smell of a golden hammer: issue tracking software normally is used to track actionable items

Organizational overhead may be disproportionate: instead of a small informal talk one has to communicate his ideas in written form

答:
FogBugz is the way to go. It's not free. The newest features make implementing an agile methodology even easier.

A simpler, free way to go would be Asana.

No matter what tool you use, team communication is the most important to facilitate a successful project.


问:
Linking a modular option to a program without creating a dependence
I would like to make my programs much less of a hassle to extend or create, I am imagining a scenario where the end user has a variety of check box options that affect how the program interacts. Something like in a word processor where you say underline, or bold, or to a game where you say, include this feature exclude that one. Just options in general.

How does one create dynamic options that modify the programs behavior without making the program dependent on that feature should one decide to remove that option completely? And what is this type of programming called?

Does one use global variables, (despite some languages suggesting otherwise)

I guess maybe an alternative (metaphorical) way to form this question would be: How do I make my code look more like lego blocks and less like one of those wooden three dimensional puzzles?

Example you can use: Deck of cards, options to remove all the jacks, or all the kings.

答:
It's called a plugin/hook architecture.  It's very common for content management systems, bug trackers, and version control software.  Basically, instead of making direct dependencies, you let plugins register callbacks that get called at certain points, called hooks.

For example, a lot of source control software lets you register pre-commit hooks.  Whenever someone is about to make a commit, the source control software calls all the registered callbacks for the pre-commit hook.  It passes things like the commit message as arguments.  If any of the callback functions return false, it won't allow the commit.  This lets a customer write a plugin that requires certain information in the commit message without having to change the core software.


问:
What are some FizzBuzz-type questions for web or SQL developers?
After a while, we are hiring again, and I'm reviewing tests for programmers; some of them are a bit out of date. What are some of the FizzBuzz-type questions for web developers and SQL? That is, not too trivial, but still solvable in five to ten minutes with pen and paper and without Google?

I typically eliminate about two thirds or more of the candidates based on CV, and then all but a few really good candidates in a one-hour interview (which can be over the phone). At this point the candidate is writing a personality test and has a chance to write a bit of FizzBuzz-like code. So, I'm not trying to eliminate a bunch of candidates, but I am trying to validate my initial assessment that candidate is hireable and able to code.

答:
I find that people tend to have a lot of trouble working with time for some reason, so that may be a good place to put a small test.

Something like this:

Part 1: Create a function that will calculate the Nth or last weekday in a given month - ie; the first, third, last Tuesday in next month.

Part 2 (if desired): Design table(s) to hold temporal expressions for recurring schedules.  The schedules could be any of "the Nth weekday of one or more months" or "the Nth day of one or more months" or "every N days from date".

Example, the 15 of every month, the last Wednesday of every March, the last day of every month, every 17 days from December 2nd, 2008, etc.


答: In terms of what developers can do, designing the project so that one can swap out UIs easily without secondary effects or significant trouble will help a lot. Even better is if you can setup the project to support multiple UIs in parallel so you can get truly experimental without downside risk.</p>

Title: How to encourage creative user interface design?

Body:
When I picture a really well functioning software team in my mind, one of the visions I have is of a developer showing off to a small group of devs some cool, clever UI that they just came up with based on something that they were just playing with.

I'm afraid that while we're doing great at being creative writing expressive, well architected, high quality code - we aren't pushing any creative boundaries when it comes to effective user interface.

What's an effective strategy for encouraging developers to push their boundaries with user interface?

Edit:

I'm looking for something "lab oriented", like for instance pair programming sessions focused on some problem or other.


答:
Well, it seems like the heart of the statement is:

A data structure is just a ... programming language

Which is quite true if you think about it. After all, compilers rely on this transitivity all the time; they take a programming language, convert it into a data structure, do some transformations on that data, and then turn the result into another programming language.

In fact, if you wanted to you could even make something crazy like a C data structure, that lets you write C code by calling its various methods - for instance (in kinda C#, because that's what I'm using right now):

```
var C = new HorribleCObject();
C.Function<int>("main", typeof(char[][]), typeof(int))
  .Variable("i", typeof(int), 0)
  .While("i", Func(i) => i < 10))
     .Call("printf", "%d", "i")
     .PostIncrement("i")
  .EndWhile();
  .Return(0)
 .EndFunction();
```

Now, as to the full quote: why would something like that be stupid compared to (say) writing in C itself? It should be pretty obvious that this is verbose and not nearly as legible as its equivalent in C (and, in practice, might not support the full scope of what C can do - typedefs would be tricky); hence, this data structure is just a "stupid" programming language, embedded in a "real" programming language. That same logic can be generalized to any data structure you can think of; linked lists are just a "stupid" version of Lisp, and hash maps are just a "stupid" version of some theoretical Hash Programming Language (Hasp?).

The thing is, though, that we don't always want to write Hasp in order to interact with our hash maps. It's the problem all domain specific languages have - on the one hand, a well-implemented DSL is powerful enough to express everything the underlying model can do; on the other hand, you have to implement the DSL in the first place, and then other people have to learn it. That takes time and effort that they probably don't want to spend; after all, I just want to put things in my hash map and then check other things are in there, I don't want to learn all the intricacies of Hash Oriented Programming.

So, pretty much without thinking about it, we take these theoretical highly specific and very smart programming languages and distill them down to the few, stupid operations embodied in a data structure. A linked list has one small collection of simple methods; a hash map has some others. We ignore the other, more powerful operations you could potentially perform over the data structure (most LinkedList implementations don't have a .Map or .ForEach function, for instance, and I can't even imagine what you would do in Hasp), in favor of implementing them explicitly in the parent programming language - which is what most programmers are going to be familiar with.

Data structures are, essentially, a stupid extension of their parent language into the problem space that they conceptually represent. A sufficiently smart extension would require a new, specific programming language, and most people aren't going to want to learn that.

Title: What did Bill Gosper mean by saying a data structure is just a stupid programming language?

Body:
There's a quotation by Ralph William Gosper, Jr that says:

A data structure is just a stupid programming language.

What did he mean by this?  Alas, all I can find in Google about it is relentless copy/pastes of the quotation itself, without any context.

Body:
Well, it seems like the heart of the statement is:

A data structure is just a ... programming language

Which is quite true if you think about it. After all, compilers rely on this transitivity all the time; they take a programming language, convert it into a data structure, do some transformations on that data, and then turn the result into another programming language.

In fact, if you wanted to you could even make something crazy like a C data structure, that lets you write C code by calling its various methods - for instance (in kinda C#, because that's what I'm using right now):

var C = new HorribleCObject();
C.Function<int>("main", typeof(char[][]), typeof(int))
  .Variable("i", typeof(int), 0)
  .While("i", Func(i) => i < 10))
     .Call("printf", "%d", "i")
     .PostIncrement("i")
  .EndWhile();
  .Return(0)
 .EndFunction();

Now, as to the full quote: why would something like that be stupid compared to (say) writing in C itself? It should be pretty obvious that this is verbose and not nearly as legible as its equivalent in C (and, in practice, might not support the full scope of what C can do - typedefs would be tricky); hence, this data structure is just a "stupid" programming language, embedded in a "real" programming language. That same logic can be generalized to any data structure you can think of; linked lists are just a "stupid" version of Lisp, and hash maps are just a "stupid" version of some theoretical Hash Programming Language (Hasp?).

The thing is, though, that we don't always want to write Hasp in order to interact with our hash maps. It's the problem all domain specific languages have - on the one hand, a well-implemented DSL is powerful enough to express everything the underlying model can do; on the other hand, you have to implement the DSL in the first place, and then other people have to learn it. That takes time and effort that they probably don't want to spend; after all, I just want to put things in my hash map and then check other things are in there, I don't want to learn all the intricacies of Hash Oriented Programming.

So, pretty much without thinking about it, we take these theoretical highly specific and very smart programming languages and distill them down to the few, stupid operations embodied in a data structure. A linked list has one small collection of simple methods; a hash map has some others. We ignore the other, more powerful operations you could potentially perform over the data structure (most LinkedList implementations don't have a .Map or .ForEach function, for instance, and I can't even imagine what you would do in Hasp), in favor of implementing them explicitly in the parent programming language - which is what most programmers are going to be familiar with.

Data structures are, essentially, a stupid extension of their parent language into the problem space that they conceptually represent. A sufficiently smart extension would require a new, specific programming language, and most people aren't going to want to learn that.


答:
I see FizzBuzz as a test to see if people actually know what they claim to know on their Resume. I wouldn't use it as anything other than a question to weed out candidates that don't know what they're talking about.

A suitable SQL replacement would be to just ask the candidate to write a SQL statement such as selecting the Name fields of two joined table that begin with A. It's simple and demonstrates that the candidate actually does have some knowledge of SQL.

```<code>SELECT Table1.Name, Table2.Name
FROM Table1
INNER JOIN Table2 ON Table1.Id = Table2.Id
WHERE Table1.Name LIKE 'A%' OR Table2.Name LIKE 'A%'
</code>```

For a web developer I would just ask them FizzBuzz. Just because you're programming for the web doesn't mean you should lack the ability to do basic programming logic

If you're looking for actual interview questions, there are plenty of good ones online that you can find with a quick search. I found more than I care to list by taking 10 seconds with Google.

Title: What are some FizzBuzz-type questions for web or SQL developers?

Body:
After a while, we are hiring again, and I'm reviewing tests for programmers; some of them are a bit out of date. What are some of the FizzBuzz-type questions for web developers and SQL? That is, not too trivial, but still solvable in five to ten minutes with pen and paper and without Google?

I typically eliminate about two thirds or more of the candidates based on CV, and then all but a few really good candidates in a one-hour interview (which can be over the phone). At this point the candidate is writing a personality test and has a chance to write a bit of FizzBuzz-like code. So, I'm not trying to eliminate a bunch of candidates, but I am trying to validate my initial assessment that candidate is hireable and able to code.

Body:
I see FizzBuzz as a test to see if people actually know what they claim to know on their Resume. I wouldn't use it as anything other than a question to weed out candidates that don't know what they're talking about.

A suitable SQL replacement would be to just ask the candidate to write a SQL statement such as selecting the Name fields of two joined table that begin with A. It's simple and demonstrates that the candidate actually does have some knowledge of SQL.

SELECT Table1.Name, Table2.Name
FROM Table1
INNER JOIN Table2 ON Table1.Id = Table2.Id
WHERE Table1.Name LIKE 'A%' OR Table2.Name LIKE 'A%'

For a web developer I would just ask them FizzBuzz. Just because you're programming for the web doesn't mean you should lack the ability to do basic programming logic

If you're looking for actual interview questions, there are plenty of good ones online that you can find with a quick search. I found more than I care to list by taking 10 seconds with Google.


问:
Mask oAuth API key and token for pure client-side technologies
If I were to build a Twitter or Facebook application using pure client-side technologies like HTML and javascript, how would I mask/hide my API keys?

For example, for Twitter I have consumer key and consumer secret. In order for me to call Twitter's API I'll have to pass these keys to authenticate my app. If I am using pure client side technologies, I leave myself exposed. Therefore, the API keys are up for grab and anyone can authenticate as my app. How can I prevent this? Can I prevent this at all?

This question is very similar to this thread, however, it's not a desktop application.

答:
The nature of HTML and Javascript is such that the client has access to all the code.

What you are trying to do is like trying to build an HTML website while securing the HTML code from theft.

This simply can't be done.


答:
Here is an answer I gave to a very similar (possibly duplicate) question that was closed on this site.

Extremely Easy Level:
Given an employees table with the columns EmpID, FirstName, Lastname, HireDate, and TerminationDate:
Write a query to return all employees still working for the company with last names starting with "Smith" sorted by last name then first name.

Easy Level
Given the Employee table above, plus a new table "AnnualReviews" with the columns EmpID, and ReviewDate:
Write a query to return all employees who have never had a review sorted by HireDate.

Medium Level

Given the employee table above, write a query to calculate the difference (in days) between the most and least tenured employee still working for the company?

Hard Level
Given the employee table above, write a query to calculate the longest period (in days) that the company has gone without a hiring or firing anyone.

Harder Level

Again using the same tables, write a query that returns each employee and for each row/employee include the greatest number of employees that worked for the company at any time during their tenure and the first date that maximum was reached. Extra points for not using cursors.


问:
Does simplicity always improve Readability?
Recently, I was developing a set of coding standards for our company.  (We're a new team branching out into a new language for the company.)

On my first draft, I set the purpose of our coding standards as improving Readability, Maintainability, Reliability, and Performance.  (I ignored writability, portability, cost, compatibility with previous standards, etc.)

One of my goals while writing this document was to push through the idea of simplicity of code. The idea was that there should be only one function call or operation per line.  My hope was that this would increase readability.  It's an idea that I carried over from our previous language.

However, I've questioned the assumption behind this push:

Does simplicity always improve readability?

Is there a case where writing simpler code decreases readability?

It should be obvious, but by "simpler", I don't mean "easier to write", but less stuff going on per line.

答: Not necessarily.  If you've got a complex operation, that complexity has to go somewhere.  Reducing the number of "stuff" that goes on one line just means it will take up more lines, which can actually be detrimental to code readability if it makes your routine too "tall" to fit on one screen.</p>


问:
Is `catch(...) { throw; }` a bad practice?
While I agree that catching ... without rethrowing is indeed wrong, I however believe that using constructs like this:

```<code>try
{
  // Stuff
}
catch (...)
{
  // Some cleanup
  throw;
}
</code>```

Is acceptable in cases where RAII is not applicable. (Please, don't ask... not everybody in my company likes object-oriented programming and RAII is often seen as "useless school stuff"...)

My coworkers says that you should always know what exceptions are to be thrown and that you can always use constructs like:

```<code>try
{
  // Stuff
}
catch (exception_type1&)
{
  // Some cleanup
  throw;
}
catch (exception_type2&)
{
  // Some cleanup
  throw;
}
catch (exception_type3&)
{
  // Some cleanup
  throw;
}
</code>```

Is there a well admited good practice regarding these situations?

答:
My coworkers says that you should always know what exceptions are to be thrown [...]

Your coworker, I'd hate to say it, has obviously never worked on general-purpose libraries.

How in the world can a class like std::vector even pretend to know what the copy constructors will throw, while still guaranteeing exception safety?

If you always knew what the callee would do at compile-time, then polymorphism would be useless! Sometimes the entire goal is to abstract away what happens at a lower level, so you specifically don't want to know what's going on!

OwnerDisplayName: ereOn

OwnerDisplayName: Mehrdad


答:
Two comments, really.  The first is that while in an ideal world, you
should always know what exceptions might be thrown, in practice, if
you're dealing with third party libraries, or compiling with a Microsoft
compiler, you don't.  More to the point, however; even if you do know
exactly all of the possible exceptions, is that relevant here?  catch
(...) expresses the intent far better than catch ( std::exception
const& ), even supposing that all possible exceptions derive from
std::exception (which would be the case in an ideal world).  As for
using several catch blocks, if there is no common base for all
exceptions: that is downright obfuscation, and a maintenance nightmare.
How do you recognize that all of the behaviors are identical?  And that
that was the intent?  And what happens if you have to change the
behavior (bug fix, for example)?  It's all too easy to miss one.

Title: Is `catch(...) { throw; }` a bad practice?

Body:
While I agree that catching ... without rethrowing is indeed wrong, I however believe that using constructs like this:

```<code>try
{
  // Stuff
}
catch (...)
{
  // Some cleanup
  throw;
}
</code>```

Is acceptable in cases where RAII is not applicable. (Please, don't ask... not everybody in my company likes object-oriented programming and RAII is often seen as "useless school stuff"...)

My coworkers says that you should always know what exceptions are to be thrown and that you can always use constructs like:

```<code>try
{
  // Stuff
}
catch (exception_type1&)
{
  // Some cleanup
  throw;
}
catch (exception_type2&)
{
  // Some cleanup
  throw;
}
catch (exception_type3&)
{
  // Some cleanup
  throw;
}
</code>```

Is there a well admited good practice regarding these situations?

OwnerDisplayName: James Kanze


答:
Any answer of yes or no should be accompanied by a rationale of why this is so.

Saying that it is wrong simply because I've been taught that way is just blind fanaticism.

Writing the same //Some cleanup; throw several times, as in your example is wrong because is code duplication and that is a maintenance burden. Writing it just once is better.

Writing a catch(...) to silence all the exceptions is wrong because you should only handle exceptions you know how to handle, and with that wildcard you can cath more than you expect, and doing so can silence important errors.

But if you rethrow after a catch(...), then the latter rationale no longer applies, as you are not actually handling the exception, so there is no reason why this should be discouraged.

Actually I've been done this for logging in sensitive functions without any problem whatsoever:

```<code>void DoSomethingImportant()
{
    try
    {
        Log("Going to do something important");
        DoIt();
    }
    catch (std::exception &e)
    {
        Log("Error doing something important: %s", e.what());
        throw;
    }
    catch (...)
    {
        Log("Unexpected error doing something important");
        throw;
    }
    Log("Success doing something important");
}
</code>```

Body:
Any answer of yes or no should be accompanied by a rationale of why this is so.

Saying that it is wrong simply because I've been taught that way is just blind fanaticism.

Writing the same //Some cleanup; throw several times, as in your example is wrong because is code duplication and that is a maintenance burden. Writing it just once is better.

Writing a catch(...) to silence all the exceptions is wrong because you should only handle exceptions you know how to handle, and with that wildcard you can cath more than you expect, and doing so can silence important errors.

But if you rethrow after a catch(...), then the latter rationale no longer applies, as you are not actually handling the exception, so there is no reason why this should be discouraged.

Actually I've been done this for logging in sensitive functions without any problem whatsoever:

void DoSomethingImportant()
{
    try
    {
        Log("Going to do something important");
        DoIt();
    }
    catch (std::exception &e)
    {
        Log("Error doing something important: %s", e.what());
        throw;
    }
    catch (...)
    {
        Log("Unexpected error doing something important");
        throw;
    }
    Log("Success doing something important");
}

OwnerDisplayName: rodrigo


问:
Is programming a SubCulture?
I was going through this article:

http://en.wikipedia.org/wiki/Subculture

Which got mee thinking is programming a subculture?

After the a while I started thinking it really hard, and if you go really in depth this is a very complex and interesting question to ask.

YOu can even ask yourself if (heavy) internet (social) users are an subculture and programmers a culture within.

I think it might be an interesting discussion, hope you like it!

NOTE:

I linked the wiki article because it might be a good baseline, maybe you can base you answer  on Ken Gelder´s proposal to distinguish subcultures. But it should be based on a little bit more that intuition.

Thanks in advance!

Trufa

答:
Well, it's almost 11pm on Friday. An I'm answering your question...

I think it's a subculture with a lot of members. Similar to the hippy/counter-culture movement in the late 60's.

Title: Is programming a SubCulture?


答:
I think your co-worker has mixed up some good advice - you should only handle known exceptions in a catch block when you don't re-throw them.

This means:

```<code>try
{
  // Stuff
}
catch (...)
{
  // General stuff
}
</code>```

Is bad because it will silently hide any error.

However:

```<code>try
{
  // Stuff
}
catch (exception_type_we_can_handle&)
{
  // Deal with the known exception
}
</code>```

Is fine - we know what we're dealing with and don't need to expose it to the calling code.

Likewise:

```<code>try
{
  // Stuff
}
catch (...)
{
  // Rollback transactions, log errors, etc
  throw;
}
</code>```

Is fine, best practice even, the code to deal with general errors should be with the code that causes them. It's better than relying on the callee to know that a transaction needs rolling back or whatever.

Body:
I think your co-worker has mixed up some good advice - you should only handle known exceptions in a catch block when you don't re-throw them.

This means:

try
{
  // Stuff
}
catch (...)
{
  // General stuff
}

Is bad because it will silently hide any error.

However:

try
{
  // Stuff
}
catch (exception_type_we_can_handle&)
{
  // Deal with the known exception
}

Is fine - we know what we're dealing with and don't need to expose it to the calling code.

Likewise:

try
{
  // Stuff
}
catch (...)
{
  // Rollback transactions, log errors, etc
  throw;
}

Is fine, best practice even, the code to deal with general errors should be with the code that causes them. It's better than relying on the callee to know that a transaction needs rolling back or whatever.

OwnerDisplayName: Keith