问:
Forgetting stuff I've done before and how do you fix this
I'm not sure if it's just me or if this is common in our field.

The past year has been a bit intense for me. I've been learning a few different technologies to get some tasks done and sometimes I've had to completely focus on that one new technology I'm learning.

What I noticed though when I go back to using everything together in the full project is that I forgot how to do things that I already knew how to do before I started focusing on learning that other new technology. Sometimes I find that I forget even simple things like the syntax for selecting a div in jquery, that I have to go back to old files to get a quick peek.

Sometimes I could be coding something that I recognize I did before in another project, but can't quite remember which project it was for, so I have to go through several projects and look through the code to try and remember where I did that.

What ways have you invented to prevent yourself from forgetting things you've done before, or to easily access code you've written in the past?

答:
Nah, it's not just you. I believe this to be common in almost anything theoretical which you don't use for any longer length of time. Think about all the stuff you've learned in school or uni which you don't remember anymore. I tend to forget stuff already 2 weeks after the final exam...

The only way to remedy this, that I know of, is to use it. Often. It's like TV commercials where you remember each and every line and scene. Why? Because you see them every day - a constant reminder which causes your brain to rearrange its synapses (or whatever it does) for you to remember it. Imagine if we could do the same for all knowledge we would like to remember - algorithms, methods, formulas, syntax, etc. (I think it's time that we protest and make the TV stations show this kind of useful stuff during program breaks instead of those tacky commercials.) But fortunately, almost everything you have once learned you can relearn in a shorter time.

If you happen to know when you're writing a piece of code that you'll want to look back at this some time in the future, copy it to a separate file and keep a library of useful code snippets. That way you don't have to search through entire projects. Also make sure to arrange these snippets after language and kind (What does the code do? Why did you save it?) for easy access.


问:
How can I explain the usefulness of Inheritance?
When trying to explain the concept of Inheritance in OOP, the common example is often the mammals example. IMHO, this is really a bad example, because it will lead the newbies to use this concept the wrong way. And moreover, it is not a common design that they will face in their day-to-day design job.

So, what will be a nice, simple and concrete problem that is solved using Inheritance ?

答:
My real-world example is the domain model of a simple HR application. I tell that we can create a base class called Employee, because of course, managers are employees too.

```<code>public class Employee
{
    public string FirstName { get; set; }

    public string LastName { get; set; }

    public int Code { get; set; }

    public string GetInsuranceHistory()
    {
        // Retrieving insurance history based on employee code.
    }
}
</code>```

Then I explain that developers are employees, testers are employees, project managers are employees. Thus they all can inherit from the employee class.

ContentLicense: CC BY-SA 3.0

Body:
My real-world example is the domain model of a simple HR application. I tell that we can create a base class called Employee, because of course, managers are employees too.

public class Employee
{
    public string FirstName { get; set; }

    public string LastName { get; set; }

    public int Code { get; set; }

    public string GetInsuranceHistory()
    {
        // Retrieving insurance history based on employee code.
    }
}

Then I explain that developers are employees, testers are employees, project managers are employees. Thus they all can inherit from the employee class.


问:
Coding dojos on regular basis
Do you find reasonable to practice coding dojos on a regular basis? I understand dojo may be a good starting point to introduce somebody to some approach but what is the point of making  similar dojos regularly?

So currently we have two teams which are working on real project written in TDD. One team wants to work on TDD-oriented dojos regularly and other prefers to practice it only on real tasks. Who is right?

答:
They both are. Teams should determine their own working rules and guidelines. If one wants to practice techniques (e.g. TDD) in real tasks, let them. If another prefers to practice in tasks that are designed to sharpen TDD skills, but aren't applicable to the project, let them.

If one team wanted to do daily stand-ups where they went around the room in clockwise fashion and the other wanted to use a token that got tossed to the next person to speak, would you try to make one team right and the other wrong?

Title: Coding dojos on regular basis


问:
The business and architecture challenge behind creating effective user stories
A friend of mine in another department had a problem and came to me with a question that I wasn't sure how to help him with.  He recently became promoted to architect and he was put in charge of design and leading a team of developers that are of questionable quality and little to no experience with following a project plan.  This team got in the habit of starting development as soon as possible before business needs were even evaluated, and then hacking the software to pieces when requirements finally became clear near the end of the deadline.  Because of this they have tried formulating design standards in the past but never bothered following them later in the project when the heat was turned up.

He aims to change this and asked me about the best way to handle these challenges.  My perspective is that the project is doomed before they start because management sets a tight deadline before the requirements are clearly known or understood.  Dithering from the client exacerbates the problem further. I told him that Agile was MADE for these kinds of problems, formulate user stories based on the customer requirements as you are aware of them now, and then as more user stories or as they change just add to the backlog and readjust your sprint plan accordingly.

But then I got thinking about what really is the best way to handle this?  The client has no way of knowing exactly what they want from the software now, but they know they want it and are willing to pay for it and they want at least some kind of working release by a specific date.  They are given a quote with a breakdown of what will be delivered (it is a guess for both vendor and client), price is agreed upon.

When formulating the quote a deadline of some kind must exist even though it is soft at this point.  User stories aren't even known and certainly not tasks and the ability to provide a reasonable estimation either.  How do you approach this challenge?

When this quote is taken and agreed upon is it normal to use the rough deliverables as outlined in the quote as a basis for formulating your user stories?

Further do you have any advice on how to "keep the design patterns and documents alive" throughout the project as requirements change drastically?

EDIT: It seems many people assume that the client involved should be the one to provide the user stories as if it were a given.  I don't have any personal experience with a client willing to put this kind of effort into being involved with the development process.  Due to this, it seems to make sense that because of their lack of input into the development process, they are not a very good stakeholder for the project itself.  The stakeholders at this point become the business analysts and application managers who are supposed to squeeze whatever trickle of information they can get from the client and turn it into usable information for the developers.  This is clearly not working though so perhaps the ONLY way that Agile or Kanban can work is to have direct client involvement in user stories or else the project is doomed to failure?

答:
Help your team; help with sales.

The tough part about this situation is someone who has the skills to be an architect may not be a good team leader. Unfortunately for your friend, solutions to this company's problems are going to require the skills of a team leader. Seems like they are inncapable of executing even the best of designs.

The first step is going to be with the team. Everything is easier with talented developers who get things done. Keep the good ones. Attempt to train the redeemable ones. Get rid of the rest. Everyone needs to know where they stand as soon as you can provide an evaluation.

Take control from the very beginning. It's easier to let up over time. Require that standards are followed. Failure to follow will have your code tossed out and eventual dismissal. This is part of the first step.

There's not point in building a functioning team only to have it torn down by poor senior management decisions. You'll eventually lose them. Get involved with the client meetings. Of course the client wants a fixed fee, schedule and requirements. That's what my wife wanted when we remodeled our kitchen. It didn't happen (Kitchen construction has been going on a lot longer than computer programming.). As an expert you can help make those decisions based on information. Be there to let them know what can possibly be built and by when, but only after you've done some preliminary work. Give a confident, "I'll get back to you." Nobody starts building a building without involving the architect.

Let them know what your expectations are of the client. They have to provide information. Identify who is going to be available for meetings, questions, review, testing, sign-off ect. Force them to get more skin in the game than just writing a check. When they find out that they will have a time crunch as well, the schedule relaxes. They want to just dedicate some time for a few weeks and then be done with the process for several months until you come back with the entire project. That doesn't work. Let them know that this is to insure they get what they are paying for. Be confident and act like this is the standard way of doing things. Ask a client if it is all right to create poor software that probably won't work just to meet a deadline. Nobody will agree to that at the beginning (Of course they panick when the end is near and put their head in the sand and pray.).

There will be resistence from the rest of the company. Investigate this company's past performance on client satisfaction, the amount of promises they broke. The poor quality of the code and inability to make what should be easy fixes and upgrades. Use this against them. Sales people like doing what's easy for them. They need to understand that your involvment with the process will keep them from having to bring the bad news to the client.

Building a quality team along with helping sales people manage client expectations attacks this problem from both ends. Your friend has his work cut out. I hope he can juggle both of these roles.


问:
Bogarting the Data Access Layer
Situation: The dba is an offsite contractor who keeps the entire DAL code checked out in TFS. It would be nice as the front end developer to be able to add columns, and tweak procs and whatnot, without having to rely on waiting for this dude to respond to your emails to do the work.

Question: What would be a recommended solution/process that would allow for more rapid/agile development, while maintaining data integrity as well as peace love and happiness among the team?

答:
Martin Fowler and Pramod Sadalage have written an excellent article on this subject.

Every developer has his own database to which changes can be made. These changes are then communicated back (as a changeset) to the DBA who implements them in the master database, so he's still involved in the process, he probably knows best about the structures and needs of the database anyway. I think that's the best approach as it's satisfactory for all people involved in the process and it's also very agile.

You can change the DAL in a similar manner. Just make your changes and provide a changeset for the DBA when you think you're done, so he can review it and merge it into his master.

Title: Bogarting the Data Access Layer


答:
Wellll, when I'm doing the DBA thing, I have been known to lock everything up so the damn dirty programmers can't get their mits on it. Everybody thinks they know how to do it better, and they "tweak" things to make them easier for themselves, and it causes an unholy mess.

The other alternative is to throw it wide open, and let the programmers melee on it for a while, then jump in and impose order as things begin to wind to a close...This is certainly more "agile", but it can be a real nightmare depending on what has to be cut out or changed...DBAs often have a better understanding of the project as a whole, and some changes that seem innocuous can be problematical.

If he's going to be the sole gatekeeper, he needs to either have a fixed spec, or be able to "sell" his vision to the rest of the devs.

Title: Bogarting the Data Access Layer

Body:
Situation: The dba is an offsite contractor who keeps the entire DAL code checked out in TFS. It would be nice as the front end developer to be able to add columns, and tweak procs and whatnot, without having to rely on waiting for this dude to respond to your emails to do the work.

Question: What would be a recommended solution/process that would allow for more rapid/agile development, while maintaining data integrity as well as peace love and happiness among the team?


答:
Instead of horizontal layers, I prefer to work in silo's across layers.

That way no 1 person/team can block in this fashion.

It also means you're developers are multi-skilled and able to move around features much more easily.

Of course, there are sections (UI design, and DB design) that may need more speciality work, but you get the idea.

Title: Bogarting the Data Access Layer


问:
"Gödel, Escher, Bach" still valid today?
I have just completed a course on computability and logic which was an interesting course. The lecturer recommend a few books on his slides, which include "Gödel, Escher, Bach". I can see the book is quite famous, and looks very interesting. But I have a few questions to ask regarding its content.

Is the content still valid today? I guess most theoretical stuff doesn't change over night, but are there any major points which no longer hold today that I should be aware of?

I assume we actually HAVE made some progress in the last 30 years or so. Can any of you recommend a book on the subject which includes this progress (logic, AI, computability)?

Another question: Do I have to know about Escher and Bach?

答:
Is the content still valid today? I guess most theoretical stuff don't change over night, but is there some major points which does not hold today which I should be aware of?

The content is logic and math.  It doesn't change in any substantial way, not only over night.  It will be valid forever.

ContentLicense: CC BY-SA 2.5


答:
There is a major problem that supercedes any other problem:

Why does the contractor always have the code checked out?

Why is he allowed to do this? No one should have a file checked out unless they're actively making edits.  There should be a team policy about checkouts.

The contractor (whether they like it or not) works as part of a team, and sometimes other members of the team may need to make changes.  This is a communication issue.  There's no automated way to fix this communication issue, unfortunately.

Title: Bogarting the Data Access Layer


问:
Is it worth evaluating compiler optimization on trivial cases?
I'm currently testing Visual C++ 10 on some trivial pieces of code. For example, like this one (taken from here):

```<code>int main()
{
    int i;
    clrscr();
    for(i=0,i++,i<=5;i++,i<=2;i=0,i<=5,i+=3){
        printf("%d ",i);
    }
    return 0;
}
</code>```

For the code above the compiler emits machine code that in effect does this:

```<code>clrscr();
printf("%d ",2);
return 0;
</code>```

and this makes me happy. Sometimes the compiler emits really dumb code and then I file a Microsoft Connect feedback item.

I have the following concern. Is testing a compiler on trivial code worth it?

On one hand, we want real code to be compiled as good as possible, not some stupid sample snippets.

On the other hand, compiler optimization is recursive in sense that if code B follows code A and the compiler can see that code B does nothing it can eliminate code B and eliminate whatever connected A and B logically and thus optimize (and maybe eliminate) code A better. And if the compiler fails to optimize away code B it will likely not be able to optimize code A either. So every improvement of generated code matters - better code at some point can mean better code elsewhere and this is beneficial.

Is it worth testing compilers on trivial samples or are only tests on "real code" worthy?

答:
Is it worth testing compilers on trivial samples

No.

or are only tests on "real code" worthy?

Barely.  This is mostly a waste of your time, also.

Before wasting your time on compiler optimization, you have to answer three questions.

Does it actually work?

Is it the right algorithm and data structure?

Is there an actual performance problem that you need to actually solve?

"we want real code to be compiled as good as possible"

This is not a good goal.  You must have a specific performance guideline and you must stop wasting your time optimizing when you meet that goal.  "as good as possible" is too vague.


答:
Simple, If you don't already, you should have a 3 Environments:

Development Environment

QA Environment

Production Environment

The develoment environment should be administered by your developers.

You might also want to add an RC environment.

Another answer, If multiple environments isn't possible, you could develop against a mocked repository... This way you build your models and then your contractor is responsable for making your models match the DB. In a way this is better since it frees your developers from worrying about the database.

Title: Bogarting the Data Access Layer


答: I'd just show them a real-life example. For instance, in most UI frameworks you derive from some kind of a "Dialog" or "Window" or "Control" class to make your own.</p>

Title: How can I explain the usefulness of Inheritance?

Body:
When trying to explain the concept of Inheritance in OOP, the common example is often the mammals example. IMHO, this is really a bad example, because it will lead the newbies to use this concept the wrong way. And moreover, it is not a common design that they will face in their day-to-day design job.

So, what will be a nice, simple and concrete problem that is solved using Inheritance ?


答:
He aims to change this and asked me about the best way to handle these
  challenges. My perspective is that the project is doomed before they
  start because management sets a tight deadline before the requirements
  are clearly known or understood. Dithering from the client exacerbates
  the problem further. I told him that Agile was MADE for these kinds of
  problems, formulate user stories based on the customer requirements as
  you are aware of them now, and then as more user stories or as they
  change just add to the backlog and readjust your sprint plan
  accordingly.

The fact that management is setting deadlines and making commitments before the project is well understood is a problem, and agile methods can't solve that particular problem. Agile lets you deal with poorly understood requirements, highly volatile requirements, and improving visibility to all stakeholders. However, if you have deadlines, agile can't make you magically meet them.

This is going to have to be a negotiation process with management. Perhaps they don't understand the nature of software development, or they simply don't care about the process of developming software.

The client has no way of knowing exactly what they want from the
  software now, but they know they want it and are willing to pay for
  it...

Do they not know what they want, or can they not articulate what they want? I have a feeling that the customer knows that business objectives that they want to achieve, and creating a vision and scope and capturing these high level business objectives would help a great deal. This should be done as part of project planning, even before you begin your chosen project life cycle - it exists at a higher level, and understanding this information can help you choose an appropriate life cycle methodology for each project.

When formulating the quote a deadline of some kind must exist even
  though it is soft at this point. User stories aren't even known and
  certainly not tasks and the ability to provide a reasonable estimation
  either. How do you approach this challenge?

First, understand the difference between estimates, targets, and commitments/deadlines. Also consider the cone of uncertainty when providing this. Knowing high-level business requirements can allow you to begin to estimate. As you know more user stories that are required for completion, you can slowly estimate project duration. As you track velocity (or some other progress metric), you can determine how long it takes you to complete user stories of known size and difficulty, thereby allowing you to estimate what iteration each requirement or user story will be started in.

When this quote is taken and agreed upon is it normal to use the rough
  deliverables as outlined in the quote as a basis for formulating your
  user stories?

You can't formulate all of the user stories from rough deliverables or business objectives. User stories need to be driven by specific requirements that are elicited from the customer and users of the software. You can probably come up with some, but not nearly all of them. As you begin to add functionality, it's likely (almost certain) that more user stories will be created and prioritized.

Further do you have any advice on how to "keep the design patterns and
  documents alive" throughout the project as requirements change
  drastically?

A good process methodology and discipline. Keeping documents in an easy-to-edit format and versioned helps a lot, as well.

It seems many people assume that the client involved should be the one
  to provide the user stories as if it were a given. I don't have any
  personal experience with a client willing to put this kind of effort
  into being involved with the development process. Due to this, it
  seems to make sense that because of their lack of input into the
  development process, they are not a very good stakeholder for the
  project itself. The stakeholders at this point become the business
  analysts and application managers who are supposed to squeeze whatever
  trickle of information they can get from the client and turn it into
  usable information for the developers. This is clearly not working
  though so perhaps the ONLY way that Agile or Kanban can work is to
  have direct client involvement in user stories or else the project is
  doomed to failure?

Many clients don't see the need for involvement. However, you can try to get them involved by rapidly showing them working, potentially shippable deliverables, asking them if it meets their needs, and correcting or improving the software until it adds sufficient business value. Demonstrating the value of involvement is usually a pretty good and convincing argument.

Now, involvement doesn't mean that they are always present and walking with you. For example, you might only meet with the client after a handful of iterations. You do, however, need someone to represent the interests of the client and can communicate with them on a somewhat regular basis so that they can be informed of the state of the project and product.

Title: The business and architecture challenge behind creating effective user stories

Body:
A friend of mine in another department had a problem and came to me with a question that I wasn't sure how to help him with.  He recently became promoted to architect and he was put in charge of design and leading a team of developers that are of questionable quality and little to no experience with following a project plan.  This team got in the habit of starting development as soon as possible before business needs were even evaluated, and then hacking the software to pieces when requirements finally became clear near the end of the deadline.  Because of this they have tried formulating design standards in the past but never bothered following them later in the project when the heat was turned up.

He aims to change this and asked me about the best way to handle these challenges.  My perspective is that the project is doomed before they start because management sets a tight deadline before the requirements are clearly known or understood.  Dithering from the client exacerbates the problem further. I told him that Agile was MADE for these kinds of problems, formulate user stories based on the customer requirements as you are aware of them now, and then as more user stories or as they change just add to the backlog and readjust your sprint plan accordingly.

But then I got thinking about what really is the best way to handle this?  The client has no way of knowing exactly what they want from the software now, but they know they want it and are willing to pay for it and they want at least some kind of working release by a specific date.  They are given a quote with a breakdown of what will be delivered (it is a guess for both vendor and client), price is agreed upon.

When formulating the quote a deadline of some kind must exist even though it is soft at this point.  User stories aren't even known and certainly not tasks and the ability to provide a reasonable estimation either.  How do you approach this challenge?

When this quote is taken and agreed upon is it normal to use the rough deliverables as outlined in the quote as a basis for formulating your user stories?

Further do you have any advice on how to "keep the design patterns and documents alive" throughout the project as requirements change drastically?

EDIT: It seems many people assume that the client involved should be the one to provide the user stories as if it were a given.  I don't have any personal experience with a client willing to put this kind of effort into being involved with the development process.  Due to this, it seems to make sense that because of their lack of input into the development process, they are not a very good stakeholder for the project itself.  The stakeholders at this point become the business analysts and application managers who are supposed to squeeze whatever trickle of information they can get from the client and turn it into usable information for the developers.  This is clearly not working though so perhaps the ONLY way that Agile or Kanban can work is to have direct client involvement in user stories or else the project is doomed to failure?


答: I think this is most likely a waste of time. Worse, it may divert resources away from finding issues that are likely to affect real code. If this happens to hit on a problem that actually matters, it will only be by luck. You're much more likely to hit the target if you aim at it.</p>

Title: Is it worth evaluating compiler optimization on trivial cases?

Body:
I'm currently testing Visual C++ 10 on some trivial pieces of code. For example, like this one (taken from here):

```<code>int main()
{
    int i;
    clrscr();
    for(i=0,i++,i<=5;i++,i<=2;i=0,i<=5,i+=3){
        printf("%d ",i);
    }
    return 0;
}
</code>```

For the code above the compiler emits machine code that in effect does this:

```<code>clrscr();
printf("%d ",2);
return 0;
</code>```

and this makes me happy. Sometimes the compiler emits really dumb code and then I file a Microsoft Connect feedback item.

I have the following concern. Is testing a compiler on trivial code worth it?

On one hand, we want real code to be compiled as good as possible, not some stupid sample snippets.

On the other hand, compiler optimization is recursive in sense that if code B follows code A and the compiler can see that code B does nothing it can eliminate code B and eliminate whatever connected A and B logically and thus optimize (and maybe eliminate) code A better. And if the compiler fails to optimize away code B it will likely not be able to optimize code A either. So every improvement of generated code matters - better code at some point can mean better code elsewhere and this is beneficial.

Is it worth testing compilers on trivial samples or are only tests on "real code" worthy?


问:
Why are interfaces useful?
I have been studying and coding in C# for some time now. But still, I can't figure the usefulness of Interfaces. They bring too little to the table. Other than providing the signatures of function, they do nothing. If I can remember the names and signature of the functions which are needed to be implemented, there is no need for them. They are there just to make sure that the said functions(in the interface) are implemented in the inheriting class.

C# is a great language, but sometimes it gives you the feeling that first Microsoft creates the problem (not allowing multiple inheritance) and then provides the solution, which is rather a tedious one.

That's my understanding which is based on limited coding experience. What's your take on interfaces? How often you make uses of them and what makes you do so?

答:
They are mostly used for code reusability. If you code to the interface you can use a diffrent class that inherits from that interface and not break everything. </p>

<p>Also they are very usefull in webservices where you want to let the client know what a class does (so they can consume it) but dont want to give them the actual code. </p>

Title: Why are interfaces useful?

Body:
They are mostly used for code reusability. If you code to the interface you can use a diffrent class that inherits from that interface and not break everything.

Also they are very usefull in webservices where you want to let the client know what a class does (so they can consume it) but dont want to give them the actual code.


答:
You have probably used foreach and found it to be a pretty useful iteration tool.  Did you know that it requires an interface to function, IEnumerable?

That's certainly a concrete case speaking to the usefulness of an interface.

Title: Why are interfaces useful?

Body:
I have been studying and coding in C# for some time now. But still, I can't figure the usefulness of Interfaces. They bring too little to the table. Other than providing the signatures of function, they do nothing. If I can remember the names and signature of the functions which are needed to be implemented, there is no need for them. They are there just to make sure that the said functions(in the interface) are implemented in the inheriting class.

C# is a great language, but sometimes it gives you the feeling that first Microsoft creates the problem (not allowing multiple inheritance) and then provides the solution, which is rather a tedious one.

That's my understanding which is based on limited coding experience. What's your take on interfaces? How often you make uses of them and what makes you do so?


答:
have direct client involvement in user stories or else the project is doomed to failure

Correct.

That's excellent.  Stick with that.  It's perfect.


答:
There are 2 major reasons:

Lack of multiple inheritance. You can inherit from one base class and implement any number of interfaces. That's the only way to "do" multiple inheritance in .NET.

COM interoperability. Anything that will need to be used by "older" technologies will need to have interfaces defined.

Title: Why are interfaces useful?


答:
Interfaces are the backbone of (static) polymorphism! The interface is what matters. Inheritance would not work without interfaces, as subclasses basically inherit the already implemented interface of the parent.

How often you make uses of them and what makes you do so ??

Pretty often. Everything that needs to be pluggable is an interface in my applications. Often times you have otherwise unrelated classes that need to provide the same behaviour. You can't solve such problems with inheritance.

Need different algorithms to perform operations on the same data? Use an interface (see strategy pattern)!

Do you want to use different list implementations? Code against an interface and the caller does not need to worry about the implementation!

It's been considered a good practice (not only in OOP) to code against interfaces for ages, for one single reason: It's easy to change an implementation when you realize it does not fit your needs. It's pretty cumbersome if you try to achieve that only with multiple inheritance or it boils down to creating empty classes in order to provide the necessary interface.

Title: Why are interfaces useful?


答: You problem appears to me to be one of manpower. It is apropriate and necessary for all potential daatbase changes to be approved by a database specialist. If the current person cannot keep up with the work in a timely manner, you need more database specialists.</p>

Title: Bogarting the Data Access Layer


答:
Other than providing the signatures of function, they do nothing. If I can remember the names and signature of the functions which are needed to be implemented, there is no need for them

The point of interfaces is not to help you remember what method to implement, it is here to define a contract. In foreach P.Brian.Mackey example (which turns out to be wrong, but we don't care), IEnumerable defines a contract between foreach and any enumerable thing. It says : "Whoever you are, as long as you stick to the contract (implement IEnumerable), I promise you I'll iterate over all your elements". And, that is great (for a non dynamic language).

Thanks to interfaces you can achieve very low coupling between two classes.

Title: Why are interfaces useful?


问:
Should Professional Development occur on company time?
As a first-time part-time software developer at a small consulting company, I'm struggling to organise time to further my own software development knowledge - whether that's reading a book, keeping up with the popular questions on StackOverflow, researching a technology we're using in-depth, or following the front page of Hacker News. I can see results borne from my self-allocated study time, but listing and demonstrating the skills and knowledge gained through Professional Development is difficult.

The company does not have any defined PD policy, and there's a lot of pressure to get something deliverable done now! when working for consultants. I've checked what my coworkers do, and they don't appear to allocate any time to self-improvement; they just work at the problems they're given, looking up specific MSDN references, code samples, and the like as they need them.

I realise that PD policy is going to vary across companies of different size and culture, and a company like my own is probably a bit of an edge case. I'd love to hear views and experiences from more seasoned developers; especially those who have to make the PD policy choices in their team or company.

I'd also like to learn about the more radical approaches to PD, even if they're completely out there; it's always interesting to see what other people are trying.

Not quite a summary, but what I'm trying to ask:

Is it common or recommended for companies to allocate PD time?

Whose responsibility is it to ensure a developer's knowledge and skills are up to date?

Should a part-time work schedule inspire a lower ratio of PD time : work?

How can a developer show non-developer coworkers that reading blogs and books is net productive?

Is reading blogs and books actually net productive? (references welcomed)

Is writing blogs effective as a way of PD? (a recent theme on Hacker News)

This is sort of a broad question because I don't know exactly which questions I need to ask here, so any thoughts on relevant issues I haven't addressed are very welcome.

答:
I don't think I'd like my company to schedule this kind of thing for me, I prefer to learn when I am "in the mood" so to speak:

clear mind

no stray thought (current project, something personal, etc..)

At the moment, I simply take advantage of compile-time / unittest-time to relax and browse SO / technical blogs / Google Talks / etc...

The short things I do at work in this "spare" time. The longer I prefer to do at home, calmly.

I imagine of course that not having children to care for help a lot regarding the personal time I can allocate for this.


答:
I personally love the abstract class and use it more than an interface. The main difference comes with integrating with .NET interfaces such as IDisposable, IEnumerable and so on... and with COM interop. Also, the interface is a little less effort to write than an abstract class, and a class can implement more than one interface while it can only inherit from one class.

That said, I find that most things I would use an interface for are better served by an abstract class. Pure virtual functions--abstract functions-- allow you to force an implementer to define a function similar to the way an interface forces an implementer to define all of its members.

However, you typically use an interface when you do not want to impose a certain design upon the super class, while you would use an abstract class to have a reusable design that is already mostly implemented.

I have used interfaces extensively with writing plugin environments using the System.ComponentModel namespace. They come quite in handy.

Title: Why are interfaces useful?


答:
My real world example is a vehicle:

```<code>public class Vehicle
{
    public Vehicle(int doors, int wheels)
    {
        // I describe things that should be
        // established and "unchangeable"
        // when the class is first "made"
        NumberOfDoors = doors;
        NumberOfWheels = wheels;
    }

    public void RollWindowsUp()
    {
        WindowsUp = true;
    }

    // I cover modifiers on properties to show
    // how to protect certain things from being
    // overridden
    public int NumberOfDoors { get; private set; }
    public int NumberOfWheels { get; private set; }

    public string Color { get; set; }
    public bool WindowsUp { get; set; }
    public int Speed { get; set; }
}

public class Car : Vehicle
{
    public Car : base(4, 4)
    {

    }
}

public class SemiTruck : Vehicle
{
    public SemiTruck : base(2, 18)
    {

    }
}
</code>```

This example can get as detailed as you like, and there are all kinds of properties attached to vehicles to explain the use of any modifiers you might want to teach.

Body:
My real world example is a vehicle:

public class Vehicle
{
    public Vehicle(int doors, int wheels)
    {
        // I describe things that should be
        // established and "unchangeable"
        // when the class is first "made"
        NumberOfDoors = doors;
        NumberOfWheels = wheels;
    }

    public void RollWindowsUp()
    {
        WindowsUp = true;
    }

    // I cover modifiers on properties to show
    // how to protect certain things from being
    // overridden
    public int NumberOfDoors { get; private set; }
    public int NumberOfWheels { get; private set; }

    public string Color { get; set; }
    public bool WindowsUp { get; set; }
    public int Speed { get; set; }
}

public class Car : Vehicle
{
    public Car : base(4, 4)
    {

    }
}

public class SemiTruck : Vehicle
{
    public SemiTruck : base(2, 18)
    {

    }
}

This example can get as detailed as you like, and there are all kinds of properties attached to vehicles to explain the use of any modifiers you might want to teach.


答: Use of interfaces helps a system stay decoupled and thus easier to refactor, change, and redeploy.  It is a very core concept to object-oriented orthodoxy and I first learned about it when C++ gurus made "pure abstract classes" which are quite equivalent to interfaces.</p>

Title: Why are interfaces useful?


答:
It's difficult for me to imagine clean, object-oriented C# code without the use of interfaces.  You use them whenever you wish to enforce the availability of certain functionality without forcing classes to inherit from a specific base class, and this allows your code to have the relevant level of (low) coupling.

I don't agree that multiple inheritence is better than having interfaces, even before we get to arguing that multiple inheritence comes with it's own set of pains.  Interfaces are a basic tool for enabling polymorphism and code reuse, what more does one need?

Title: Why are interfaces useful?


问:
How should I communicate the specifics of cloud computing (as compared to other)
A meeting today went well where I explained that cloud computing which one of the persons recognized was something else than a traditional RDBMS and I said that cloud computing is that everthing is software. It didn't seem like "Aha!" when I said it so I wonder what I should say. I thought the main specifics of cloud computing are integrated services, no traditional RDBMS and resources are allocated as software and payment model is pay per usage instead of pay per hardware. And/or should I stress the concept of PaaS i.e. that it is a platform?

Wikipedia says the distinction is between products and services but that we said about web services 15 years ago.

Thanks in advance for you answers

答:
Although you can host your own cloud, for most businesses it means this:

You pay another company to "take care" of some or all your data.

Your data lives on their computers, where their employees take care of

your data (in the sense of keeping it alive, not in the sense of keeping it up to date),

privileged access to your data (at least some parts of "privileged access"),

the software that manages your data, and

the computers that run the software that manages your data.

Their employees take care of upgrades to the software and to the computers. Depending on the contract, their employees might take care of disaster recovery, too.

Now, if that all sounds too good to be true . . .


答:
Interfaces are the best way to maintain well decoupled constructs.

When writing tests, you will find that concrete classes will not work in your test environment.

Example: You want to test a class that depends on a Data Access Service class.  If that class is talking to a web service, or database -- your unit test will not run in your test environment ( plus it has turned into an integration test ).

Solution?  Use an Interface for your Data Access Service and Mock that interface so you can test your class as a unit.

On the other hand, WPF  & Silverlight do not play at all with Interfaces when it comes to binding.  This is a pretty nasty wrinkle.

Title: Why are interfaces useful?


问:
Are developers more productive at night?
I personally stay awake late at night, coding and enjoying working on personal projects. My other colleagues also feel the same and like coding at night. However, it's not about being passionate about personal hobbies, rather, I really feel that I'm more productive at night.

I think that there is something about night, maybe its darkness, maybe its silence, maybe another attribute that makes developers become more productive.

Is there some truth to this? Why do some developers believe that they are more productive at night? Is there any scientific proof to justify this proposition? Maybe something like "in night, monitor light is less harmful" or "the natural air in night has more oxygen, thus is more suitable for thinking process", or anything like that.

Moderator Note:

The question is asking for scientific proof and otherwise cited information on this subject. Answers that do not provide supporting references will be removed. This is not a poll where you should share when you wake up and what parts of the day you personally are productive.

答:
I used to think this about myself, but the cause and effect are mixed up. I find that I am more productive at night, but I now attribute this to the reasons I stay up late coding in the first place. I only stay up late when I am "in the zone" and am already being more productive than normal.

I do not deny that there are other factors involved, such as a lack of distractions and fatigue, but I haven't found these to be as significant as the original reason I'm up late.

That being said, I also have pretty serious ADHD, so my productivity has a higher day to day variance than most.


问:
When is a version control commit too large?
I've heard in several places "Don't make large commits" but I've never actually understood whats a "large" commit. Is it large if you work on a bunch of files even if there related? How many parts of a project should you be working on at once?

To me, I have trouble trying to make "small commits" since I forget or create something that creates something else that creates something else. You then end up with stuff like this:

```
Made custom outgoing queue

Bot
-New field msgQueue which is nothing more than a SingleThreadExecutor
-sendMsg blocks until message is sent, and adds wait between when messages get
sent
-adminExist calls updated (see controller)
-Removed calles to sendMessage

Controller
-New field msgWait denotes time to wait between messages
-Starting of service plugins moved to reloadPlugins
-adminExists moved from Server because of Global admins. Checks at the channel,
server, and global level

Admin
-New methods getServer and getChannel that get the appropiate object Admin
belongs to

BotEvent
-toString() also show's extra and extra1

Channel
-channel field renamed to name
-Fixed typo in channel(int)

Server
-Moved adminExists to Controller

PluginExecutor
-Minor testing added, will be removed later

JS Plugins
-Updated to framework changes
-Replaced InstanceTracker.getController() with Controller.instance
-VLC talk now in own file

Various NB project updates and changes

---

Affected files
Modify  /trunk/Quackbot-Core/dist/Quackbot-Core.jar
Modify  /trunk/Quackbot-Core/dist/README.TXT
Modify  /trunk/Quackbot-Core/nbproject/private/private.properties
Modify  /trunk/Quackbot-Core/nbproject/private/private.xml
Modify  /trunk/Quackbot-Core/src/Quackbot/Bot.java
Modify  /trunk/Quackbot-Core/src/Quackbot/Controller.java
Modify  /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java
Modify  /trunk/Quackbot-Core/src/Quackbot/info/Admin.java
Modify  /trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java
Modify  /trunk/Quackbot-Core/src/Quackbot/info/Channel.java
Modify  /trunk/Quackbot-Core/src/Quackbot/info/Server.java
Modify  /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
Modify  /trunk/Quackbot-GUI/dist/README.TXT
Modify  /trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar
Modify  /trunk/Quackbot-GUI/nbproject/private/private.properties
Modify  /trunk/Quackbot-GUI/nbproject/private/private.xml
Modify  /trunk/Quackbot-GUI/src/Quackbot/GUI.java
Modify  /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java
Delete  /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java
Modify  /trunk/Quackbot-Impl/dist/Quackbot-Impl.jar
Modify  /trunk/Quackbot-Impl/dist/README.TXT
Modify  /trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar
Modify  /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
Modify  /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
Modify  /trunk/Quackbot-Impl/lib/javarebel.stats
Add /trunk/Quackbot-Impl/lib/jrebel.info
Modify  /trunk/Quackbot-Impl/nbproject/private/private.properties
Modify  /trunk/Quackbot-Impl/nbproject/private/private.xml
Modify  /trunk/Quackbot-Impl/nbproject/project.properties
Modify  /trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js
Add /trunk/Quackbot-Impl/plugins/CMDs/Operator/hostBan
Modify  /trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js
Modify  /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js
Modify  /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js
Modify  /trunk/Quackbot-Impl/plugins/listeners/onJoin.js
Modify  /trunk/Quackbot-Impl/plugins/listeners/onQuit.js
Modify  /trunk/Quackbot-Impl/plugins/testCase.js
Add /trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js
Modify  /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java
Add /trunk/Quackbot-Impl/vlc_http
Add /trunk/Quackbot-Impl/vlc_http/current.html
Modify  /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
Modify  /trunk/Quackbot-Plugins/dist/README.TXT
Modify  /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
Modify  /trunk/Quackbot-Plugins/nbproject/private/private.properties
Modify  /trunk/Quackbot-Plugins/nbproject/private/private.xml
Modify  /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java
Add /trunk/Quackbot-Plugins/vlc_http
Add /trunk/global-lib/jrebel.jar
```

Yea....

So for questions:

What are some factors for when a commit becomes too large (non-obvious stuff)?

How can you prevent such commits? Please give specifics

What about when your in semi-early stages of development when things are moving quickly? Are huge commits still okay?

答:
The thing to grasp here is that "Large" in this context is about the number distinct changes not the physical size of the commit (although generally the two will go hand in hand).

Its not so a question of "don't make large commits" as do make small commits - the ideal being to commit small self contained changes.

Its clear from the changelog that you've got a series of things that could have been committed separately (and safely) and therefore its fairly self evident that its too large.

The reason that this can be a problem is that your last commit is your reference point for the changes you're currently making and if, for example, you get the first bit right and then get the next bit wrong you've no easy way to roll your work back to the point where you started making mistakes (BTDTGTTS).

Of course sometimes changes just are big - large scale refactoring - and as is suggested by others this is where you need to branch, that way although your individual commits might notionally break things they are separated from the main development trunk so that isn't a problem and you get to continue to commit early and often.

One more thing - if something comes along in the midst of your work that requires more immediate attention you need to change it separately (ideally in a completely distinct set of folders) and commit it separately.

The real challenge in all of this is not the mechanics its the mindset - that a commit is not just a backup copy that you make every now and then but that each commit is an inch-pebble along the way and that there's nothing wrong with lots of small commits and that munging different things together in a mob commit is as bad a munging vaguely related bits of functionality together in a lump of code.


问:
What core skills does a new Computer Science Graduate need to be employable?
A computer science degree (like any undergraduate degree) does not prepare you to be productive immediately. And my sense is that employers are less and less willing to provide that initial training. (Or at least if you DO have those core skills*, you have a broader selection of "first jobs" to choose from).

What skills should a senior focus on to make him/her self more employable?
And how might you get those skills?

*EDIT: I'm not talking about experience/mastery of technology. I'm talking about core skills like Source Control (not mastery of a particular SC, but just being able to use one an understanding the concepts) and Unit Testing (having written Unit Tests using at least some famework), etc.

答: Practical experience always helps, even if it's something as simple as contributing to a open source project just to get something on the C.V. (and of course to help OSS). Get some code you're proud of on something like github so they can see your work, that way they know whether you'll fit in terms of code style.</p>


答:
The best way to get a job is to do well in the interview.  I found that my CS skills were of little use in interviews.  Most of the questions are boilerplate trivia, easily found via Google "%my programming language% interview questions".

You should spend research time seeing what kind of positions are available in your area.  Then decide what interests you.  If it's C#, then buy a C# book for beginners and read it cover to cover.  Do the examples, write a lot of code.

Keep writing tons of code.  Offer your code and programs as a portfolio in interviews.

Title: What core skills does a new Computer Science Graduate need to be employable?

Body:
A computer science degree (like any undergraduate degree) does not prepare you to be productive immediately. And my sense is that employers are less and less willing to provide that initial training. (Or at least if you DO have those core skills*, you have a broader selection of "first jobs" to choose from).

What skills should a senior focus on to make him/her self more employable?
And how might you get those skills?

*EDIT: I'm not talking about experience/mastery of technology. I'm talking about core skills like Source Control (not mastery of a particular SC, but just being able to use one an understanding the concepts) and Unit Testing (having written Unit Tests using at least some famework), etc.


答:
Programming. Knowledge of a specific technology and know it well. If you work with .NET know all parts of the framework, how it works and what it can offer.

Test Driven Development seems to be a big thing with building high quality clean code the sets you a cut above those who dont develop in such a way.

Examples of work showing fundamental pillars of OOP and some use of design patterns, make sure not to use patterns so heavily that it actually makes your coding seem worse, they are there as a guide not as a rule.

A lot of employer are concerned abotu theory though and if you know how to program well in one language picking up a second or fifth can take a very short time to a CS graduate with proven skills down any avenue.


答:
I do not expect a CS grad to know anything that directly applies to an industry for an entry level position. I expect them to be smart and to be able to learn quickly.

That said here are some basic things I look for:

Do they know C and/or some OO superset of C (i.e. C++, objective-C)?
Do they know basic CS mathematics. Algorithm Analysis, Matrix operations, vector spaces, Big-O and so on?
Do they know how a computer actually works w.r.t programs? (i.e. Compilers, Linkers, Assembly instructions)?

I also test to see if they can use both recursion and pointer arithmetic.

However I am not a corporate recruiter, I am a developer who wants competent programmers. Corporate recruiters typically want a load of buzzwords on your resume like, C#, Java, MySQL, SQLSERVER, or whatever the latest craze is these days.

To someone who knows what they are looking for, all of that stuff is irrelevant. If you are a good programmer, you can become competent in a new language in a couple weeks. What a good software company usually wants to see is that you  are smart, know computers, love programming, and work hard. The rest is easy.


问:
In agile (scrum), how do you go about breaking down a user story?
In agile (scrum), how should one ideally break down things into a user story.

The team size is about 6 developers if that makes a difference, and iterations are 3 weeks.

Is breaking a user story with points and hours considered agile, or is it ONLY user points for a given user story?

Should we break a user story into tasks also?

In the actual workflow for a user story, you have things like:

requirement gathering

review of the user story by managers etc.

qa related tasks in the user workflow

How are these things handled in a agile environment?

答:
It is Agile, in that it conforms to the Agile manifesto.

It is not Scrum, in that Scrum suggests you should use complexity points to estimate everything.

But neither of these things are that important. In fact, I argue that strict adherence to Scrum, despite all evidence that you shouldn't be, is not Agile.

Here's the question you should be asking: is it useful to you?

How does it improve the process of getting the job done? What does it offer in terms of visibility? How does it help your users get the product they want? What does it offer to quality?

If you can't answer those questions then don't bother doing it. If you're not sure then try it, measure, adjust accordingly.


答: The most important "skills" are the ability to complete tasks, and the ability to learn. Everything else falls into place after those two. Both are demonstrated through previous projects, so find a project to work on (eg. a smaller open-source project in an area that interests you).</p>


答:
They are there just to make sure that the said functions (in the interface) are implemented in the inheriting class.

Correct. That's a sufficiently awesome benefit to justify the feature. As others have said, an interface is a contractual obligation to implement certain methods, properties and events. The compelling benefit of a statically typed language is that the compiler can verify that a contract which your code relies upon is actually met.

That said, interfaces are a fairly weak way to represent contractual obligations. If you want a stronger and more flexible way to represent contractual obligations, look into the Code Contracts feature that shipped with the last version of Visual Studio.

C# is a great language, but sometime it gives you the feeling that first Microsoft creates the problem(not allowing multiple inheritance) and then provides the solution, which is rather a tedious one.

Well I'm glad you like it.

All complex software designs are a result of weighing conflicting features against each other, and trying to find the "sweet spot" that gives large benefits for small costs. We've learned through painful experience that languages that permit multiple inheritance for the purposes of implementation sharing have relatively small benefits and relatively large costs. Permitting multiple inheritance only on interfaces, which do not share implementation details, gives many of the benefits of multiple inheritance without most of the costs.

Title: Why are interfaces useful?


答:
A user story is typically created from a need expressed by the client or potential user of the system. It's often of the format "As a {role}, I want {goal} so that {benefits}". The collective set of user stories capture the functionality desired in the system that is being built. The customer or customer representative prioritizes each user story, typically based on the value added by having the functionality specified in the story.

Once written, user stories are sized and estimated. There are a number of techniques to do this. The most common method of estimation that I've seen is the amount of effort needed to complete the task, in arbitrary values. There's a base unit that everyone can agree on, and use this as a common framework for providing estimates as to the effort required. I've seen these as being unitless values called "story points", but I don't see why you couldn't also estimate the user story in hours. The key is to be consistent across all user stories.

For the first iteration, the team estimates how many story points they can complete in a given iteration and move up to that number of points into the backlog for an iteration. If you are estimating in hours, then you can determine how many hours your development team will dedicate to the project during the iteration and pull down that many hours worth of work. After the iteration, you determine how many points or hours that you actually completed and pull down that amount of work for the next iteration.

During the entire process, your overall backlog of stories is changing. Features might be removed, new features can be added, or the priority can be changed. However, none of this affects the work that was pulled down for the current iteration. Only between iterations should you adjust what you are working on. You will typically either have an on-site customer representative or someone who can act as voice of the customer and is in contact with the appropriate people from the customer's organization. They are continually refining the requirements and acceptance criteria throughout the project.

How you further break down user stories into tasks is up to you. It might be an undocumented preference of the engineer, or there might be a detailed analysis of exactly what each user story entails. That's something that needs to be specified by tailoring the process to meet the needs of your organization, team, and project.

You should have a definition of done, which can be used to determine when a particular user story is shippable. This defines everything from design, implementation, testing, quality assurance, acceptance criteria, and documentation. You can specify what tools and methods you use to ensure that a given feature as specified by a user story is done. Once a user story is done and integrated, the product should be in a potentially-shippable state, meaning that packaging it and delivering it to the customer would add some value to their operations or meet some of their needs.

Ultimately, you need to tailor the processes to work for your organization, team, and project. Doing anything "by the book" is usually a recipe for problems. Just because something has been documented and works well for certain teams working on certain projects doesn't mean that it fits everything that you need it to do.

You might be interested in this InfoQ article on user story estimation as well as Scott Ambler's Introduction to User Stories.

Title: In agile (scrum), how do you go about breaking down a user story?

Body:
In agile (scrum), how should one ideally break down things into a user story.

The team size is about 6 developers if that makes a difference, and iterations are 3 weeks.

Is breaking a user story with points and hours considered agile, or is it ONLY user points for a given user story?

Should we break a user story into tasks also?

In the actual workflow for a user story, you have things like:

requirement gathering

review of the user story by managers etc.

qa related tasks in the user workflow

How are these things handled in a agile environment?

ContentLicense: CC BY-SA 4.0


答:
Actually, many employers hire new grads. A few reasons are:

New grads are cheaper in salary and for billing to clients

New grads are a clean slate that can be trained the way the company wants

New grads can have more relevant training with newer languages

So, don't go knocking your new grad status. You are in a pretty good position actually. Many companies actually have postings just for new grads.

Now, a better question would be "how do I look more appealing than other new grads?" As you're already in your senior year, I can only hope that your marks are good. Good marks are a good indication that you pick up new concepts well, that you can meet deadlines, and that you are self motivated to study. Most employers will ask to see your transcript for this reason.

Next, some programming experience out side of school. Do you have a pet project that you're working on in your spare time? Have you made any contributions to open source projects? If not, think about doing something like that. If you really don't have time, make sure you know your final project inside out. Maybe create a blog where you outline your process for your final project and provide code samples (after it's submitted of course). Potential employers like to see that you can code, as they won't expect to have to teach you how to do that.

Source control, and ticket tracking. It is pretty much a given you will use these two things at your new job. Make sure you have the basics of each.

Make sure you're resume is the best it can possibly be. See if your school has resume reviewing and writing services. You need a good resume to stand out from everyone else.

Show your passion for programming, and your understanding of basic concepts in the interview, and you should be fine.

Good luck.


答:
While it clearly is a treat for the programmer (at first, at least) to have multiple inheritance, this is an almost trivial omission, and you should (in most cases) not rely on multiple inheritance. The reasons for this are complex, but if you really want to learn about it, consider the experience from the two most famous (by TIOBE index) programming languages that support it: C++ and Python (3rd and 8th respectably).

In Python, multiple inheritance is supported, yet is almost universally misunderstood by programmers and to state that you know how it works, means to read and understand this paper on the topic: Method Resolution Order. Something else, that happend in Python, is that interfaces sort-of-got into the language - Zope.Interfaces.

For C++, google "diamond hierarchy C++" and behold the ugliness that is about to cover you. C++ pros know how to use multiple inheritance. Everybody else is usually just playing around without knowing what the results will be. Another thing that shows how useful are interfaces is the fact, that in many cases a class might need to override completely its parent's behavior. In such cases, the parent implementation is unnecessary and only burdens the child class with the memory for the parent's private variables, which might not matter in the C# age, but matters when you do embedded programming. If you use an interface, that problem is nonexistent.

In conclusion, interfaces are, in my opinion, an essential part of OOP, because they enforce a contract. Multiple inheritance is useful in limited cases, and usually only to guys who know how to use it. So, if you are a beginner, you are the one who is treated by the lack of multiple inheritance - this gives you a better chance to not make a mistake.

Also, historically, the idea for an interface is rooted far earlier than Microsoft's C# design specs. Most people consider C# to be an upgrade over Java (in most senses), and guess where C# got its interfaces from - Java. Protocol is an older word for the same concept, and it is way older than .NET.

Update: Now I see I might have answered a different question - why interfaces instead multiple inheritance, but this seemed like the answer you were looking. Besides an OO language should have at least one of the two, and the other answers have covered your original question.

Title: Why are interfaces useful?


问:
Documentation often ommits to specify which flavour of regular expression to use, so is there a default flavour that we should all be familiar with?
Often I come across documentation that says "use a regular expression here" I have to spend quite some time digging around trying to work out which regular expression format they are expecting.

As far as I can tell, there are many types of regular expression.

But, at my last place of work I was made to feel stupid when I suggested adding some text to our User Documentation to specify the type of regular expression to be used.

When someone says "a regular expression" what is the regular expression syntax most people expect and where is it documented?

Update: I was prompted to single-out some examples - but no disrespect to these great projects:

eregi docs page is not particularly helpful in explaining expected syntax.

Nor can I easily work out the syntax expected here if i just land on the page from a search.

No explicit mention of the regular expression pattern expected by PatternExpectation() on the SimpleTest page.

etc. etc.

here is a highly voted SO answer that seems to assume there is only one flavour of regular expressions.

答: I usually go with the flavor found in books dealing with Perl. Rarely fails.</p>


答:
This is a management issue as much as a technical one.

There are certainly valid reasons for a DBA (regardless of whether onsite or off, contractor or employee) to keep developers away from making any type of database changes.

However the main issue you defined is one of availability.  Does your manager know that time/money is wasted waiting on this person?  If not, you might want to bring it up how everyone is sitting around.

Title: Bogarting the Data Access Layer


答:
I'd say there are a couple of big buckets that would be my suggestion:

Networking skills - Who knows you?  Who knows what kind of work you want to do?  This is an important skill as sometimes it may be through friends or family that you hear about a job and get hired at a company.  A couple of other terms here would be communication or relationship skills as this is about using language and getting things done through indirect means.

Problem solving skills - How well can you take a question or problem someone has and resolve it?  How well can you figure out what is the root cause and really fix it?  How well can you figure it out without pissing off the person who wants it fixed ASAP?


答:
You might want to consider changing your mindset from:

"What skills should a senior focus on to make him/her self more employable?"

to

"What skills should a senior focus on to make sure he/she gets the job he/she WANTS?"

I've spent the last week interviewing applicants and one thing that stood out during the period was how LITTLE of them knew what they wanted. Most just wanted to get a programming job ASAP and ANY type of programming job would do.........

None of them stood out except for the very few ( 1.5 out of 12 ) and non coincidentally, they were the ones that knew EXACTLY what they wanted to do.

It's really hard not to be impressed by someone who knows what he wants to do (hopefully it's in line with what your company is doing) because the resume reflects that clarity.

He made it clear that he:

Only wanted to do Web development. No winforms.

He wanted to use the Microsoft "stack". C#, some JQuery, Ajax and a bit of Javascript/HTML/CSS. No PHP, No Java, etc on his resume.

Had done 3 projects, all with the same stack of tools/languages.

Did we have winform apps? Sure we did. Did we have PHP stuff? Java stuff? Sure.

BUT our main focus was on the Microsoft stack (Customer requirements but that's another story for another day...) and we knew he would fit in quickly.

The last thing I wanted to see was another applicant with 5 different/diverse languages that would/could/wanted to do EVERYTHING and ANYTHING. I swear nothing scares us more than those cos then its really nothing but roulette with human bouncing balls.

At the end of the day, I want to hire someone that really WANTS to do the stuff that he'll be doing, in an industry where turnover is thru the roof, their happiness translates to a longer lasting relationship.

Sure, you won't be very flexible. You also won't appeal to the companies who are from the other camp.

But if its not something you want to do anyway, whats the loss? :P

Aim to get the job you WANT and focus your attention on those specific areas. It will be more enjoyable for both you and the company that you end up with.


问:
What made jQuery so popular? What is offers that other JavaScript libraries don't?
According to W3Tech, this link, this link, this link, and many other sources, jQuery is really becoming what IE experienced in the world of web browsers (gaining more than 80% of the market for a period).

I don't have the knowledge of any other JavaScript library like MooTools, YUI, etc. because when I started web development, jQuery was already ahead and I chose it.

Are other libraries really that awful, or do they lack something jQuery exclusively has? What is the reason(s) behind this huge market share?

答:
jQuery was adopted by large organizations. But what made them adopt this new library? My main reason for falling in love with jQuery was because it fixed all the browser quirks when I found other libraries were buggy at times.

Other pros was it was super easy to pick and use, great documentation and huge amount of free plugins available. It was so easy to find what you need someone in the community had already built a plugin that does what you need using the jQuery library.

It just boils down to ease of use, quick to pick up, thorough documentation, fixes browser quirks, big community base, loads of plugins available and open source of course!


问:
what are your web application server side layering design rules and the best practices you like to apply?
A web application is often designed to be layered. Typically there would be a Repository (Dao) layer, a Service layer and a Control (web handling) layer. The Control layer uses the Service layer which in turn uses the Repository layer. Often you'll see the Control layer using the Repository layer directly.

Also quite prevalent is Services using other Services. Quite often all Services inherit from a base service class which will contain all references to all Repository components.

So my question is really how and why do you design your serverside application (in terms of layers) and what rules do you apply to them?

What are the generally accepted justifications for these layers and these rules?

What rules do you see that should be considered 'bad practice'?

What rules do you considered essential?

Have you tried anything new in this area that worked?

答:
Warning long, rambling answer follows and I'm not really using 1/2 of the formal terminology that I should be (but that's OK, because someone will correct me!):

No Golden Bullet

I'll start by saying that I think each software architecture should be designed for the problem at hand.  There is no golden bullet, silver hammer or one solution that fits all cases.

Overall strategy

Is to:

Decouple your components

Code to interfaces

Generally think about the separation of concerns

Think about who is calling your code for what purpose

Why are there patterns?

Design patterns (and therefore frameworks around them) emerge because they solve certain common problems.

However, a mistake that I think many Java developers are guilty of is to over engineer architectures, applying patterns left right and centre. They think about all sorts of exotic "What If?" scenarios.  My advice is that although there are common patterns out there, don't just blindly apply them, make sure you've got solid reasoning for doing so.

Examples

1.) People have used MVC for years because it gives you flexibility to change either the model, view or controller without impacting each other (unless you want them to).  So for example if I want to:

Change my View technology from JSP to JSF I shouldn't have to change my 'Dog' Model

Add a legs field to my Dog Model, I don't automatically have to add that legs field to my list of Dogs View, or change my Controller in order for a user to travel from list of Dogs View to a detailed View of one Dog.

2.) One of the reasons why Services have become popular because of the rise of multiple clients.  So for example if I want to have a Java Swing client and a JSP client that both list the big Dogs in the system they can both call the same DogShelterService method List<Dog> getBigDogs();

Conclusion

There are lots more examples of patterns and why they came about (I suspect someone will give better examples than I did).  I find using a BDD, TDD/ATDD approach (at least in terms of your thinking) helps clarify the design and where you might want to go for a formal design patterns and where simple code will do just nicely.


答:
What skills should a senior focus on to make him/her self more employable? And how might you get those skills?

Technical skills are not the only ones that you will need in order to succeed in the business world. Social/business skills are very important in order to survive. In another thread, I posted a list of books that I think that folks new to the corporate life would benefit by reading.

Over the long run, maintaining your technical skills will be crucial to a long career in development. Hobby projects at home, reading blogs, reading technical books are all helpful. I frequently pick some certification exams in order to put a structure on some studies.


问:
Is programming a profession not for a person with speech impairment?
My friend has 15 years of programming experience and Ph.D. in mathematics. He has also cerebral palsy with speech impairment. Because of his handicap, he chose to being a software developer after his Ph.D. As far as I can see, he is still an excellent c# developer.

Nowadays, however, he has hard time to find a job for himself because most of developer jobs require good communication skills. Looking at him struggling so much, do I have to advise him software industry is not suitable for him any more? It will be extremely difficult for me to do that to the friend but I think it would be better than making him wasting his time.

What do you think?

Update: Thanks a lot for your excellent answers. I can see most answers recommend against my advice and I really really hope you guys are right. In reality, however, he has been rejected in 100 or so phone interviews. That's where I want to be a potential bad adviser rather than a politically right friend.

答:
My friend has 15 years of programming experience and Ph.D. in
  mathematics.

With that much experience and a Ph.D., I could imagine some companies wondering, "Geeesh, how expensive will this guy be?" which may prevent him for getting some opportunities.  Has he considered going back into academia?  Another point is whether he is looking to work as an employee or a contractor?  The latter may be preferable in terms of using that experience to show, "Hey, I got stuff done in the past and I still do it well," in a sense.


答:
Where I work we have a couple of different conditions that will cause a story to be broken down into multiple stories:

The poker points for it are too high or the story seems too vague to even try to estimate.  If the story has more than X points, then it is too big to treat as one story to get done in a sprint.  This prevents the team from being overly committed as sometimes a big story can be hard to estimate how many hours it'll take and how fast can it really get done.  "As a site visitor, I want to buy products so that I can have those products at my home," would be the type of story that is just too vague.  Amazon.com wasn't built in a 2 week sprint.

Getting the story done in a sprint doesn't seem likely and there is an easy way to split the story into multiple parts.  For example, a first part may be to investigate and design a solution.  Another part is to implement that solution.  Each part can be done in a sprint but it doesn't seem likely to get both done in the same sprint.

Sometimes it may be in seeing the task list that goes with a story that will show that it falls into that second case or that there will be so much QA required as some major piece of functionality gets rebuilt that the story has to be subdivided.


问:
Are there advantages to using a DVCS for a solo developer?
Right now, I use visual svn on my server, and have ankhsvn/tortoise on my personal machine. It works fine enough, and I don't have to change, but if I can see some benefits of using a DVCS, then I might give it a go.

However, if there's no point or difference using it without other people, then I won't bother.

So again, I ask, are there any benefits to using a DVCS when you're the only developer?

答:
Well, the default answer would be, "If (whatever you're using now) works for you, why would you change?".

But, yes, even if there is no reason for a change, I find using DVCS somewhat easier than the "older models". The following goes for Mercurial, which I use the most, so your mileage may vary, depending on which system you're going to use.

really easy to use - I figured out all the commands I need in an hour or so

everything is local (you don't need the remote server to be online)

very easy branching / merging - you don't even think about those things anymore

easy cloning (also, a type of branching) - and generally, a much more user friendly interface (I found it more enjoyable than git's on windows; also some concepts are simpler; i.e. don't require thinking on my side, therefore leading to less fiddling with VS and more work done)

works nice with svn

Jumping gate to an intro to Mercurial and a blog (pretty colours ;-) with useful tips.


答:
I suspect Documentation does not specify which flavour of regular expression to use, because it's rarely a choice. The choice is usually specified by the language that has been chosen (unless the language implements more than one flavour, in which case it might be valid to specifiy a preference for one of them in the docs, to keep things consistent), or by other constraints of the programming environment.

As a handy reference, here's a web page comparing regex flavours: http://www.regular-expressions.info/refflavors.html

Title: Documentation often ommits to specify which flavour of regular expression to use, so is there a default flavour that we should all be familiar with?

Body:
Often I come across documentation that says "use a regular expression here" I have to spend quite some time digging around trying to work out which regular expression format they are expecting.

As far as I can tell, there are many types of regular expression.

But, at my last place of work I was made to feel stupid when I suggested adding some text to our User Documentation to specify the type of regular expression to be used.

When someone says "a regular expression" what is the regular expression syntax most people expect and where is it documented?

Update: I was prompted to single-out some examples - but no disrespect to these great projects:

eregi docs page is not particularly helpful in explaining expected syntax.

Nor can I easily work out the syntax expected here if i just land on the page from a search.

No explicit mention of the regular expression pattern expected by PatternExpectation() on the SimpleTest page.

etc. etc.

here is a highly voted SO answer that seems to assume there is only one flavour of regular expressions.


答:
how ... do you design your serverside application (in terms of layers) and what rules do you apply to them?

We use Apache, Django and MySQL.  That defines the layers.

What are the generally accepted justifications for these layers and these rules?

The justification is "That's the way Apache, Django and MySQL work."

What rules do you see that should be considered 'bad practice'?

Unthinking dogmatism is a bad practice.

Effort spent trying to "codify" or "reduce" architecture to a few rules is a bad practice.

What rules do you considered essential?

Architecture is hard.

Follow the simplest path that fits most closely with the framework.

Title: what are your web application server side layering design rules and the best practices you like to apply?

Body:
A web application is often designed to be layered. Typically there would be a Repository (Dao) layer, a Service layer and a Control (web handling) layer. The Control layer uses the Service layer which in turn uses the Repository layer. Often you'll see the Control layer using the Repository layer directly.

Also quite prevalent is Services using other Services. Quite often all Services inherit from a base service class which will contain all references to all Repository components.

So my question is really how and why do you design your serverside application (in terms of layers) and what rules do you apply to them?

What are the generally accepted justifications for these layers and these rules?

What rules do you see that should be considered 'bad practice'?

What rules do you considered essential?

Have you tried anything new in this area that worked?


答:
Most of the time the layers and rules used are driven by the idiomatic usage of the base libraries and technologies you've chosen.  The choice of base technology to use was hopefully made with some analysis and forethought.  Occasionally you have to subvert the idiomatic usage, or even the base technology to get the job done.  Those occasions should be rare because non-idiomatic usage is generally more costly to maintain.

Rules:

Write the simplest code to implement the best solution you can in the most timely manner possible.

Remove practices and techniques that make implementation slower, more buggy, and more complicated.

Add practices and techniques that make implementation faster, more maintainable and easier.

These rules are often the justification for using certain architectures, technologies, or practices.  The problem is that there are no practices that are applicable in all programming contexts.

Bad Rules:

Treating any practice as sacrosanct.

No practice has value in and of itself.  It only has value in it's ability to make you work "better".  People often forget that and that's when you get dogmatic adherence regardless of cost or benefit.


问:
Java developing server-client solutions
I am trying to get a job as Java developer.

I have been developing web pages with Java for a while, but now trying to go to another path and develop server-client solutions.

In this specific company they are using these technologies for web developing: Spring, Hibernate, Ant, Velocity etc. All of the hot techs for Java.

Now before applying for job as server-client developer, which technologies should I get familiar with. Which would be adequate technologies?

答:
You should get familiar with the languages, technologies, and techniques that you need right now to get the job done or that are called out in a job posting. There's no one, ultimate technology stack that you should learn to, in your case, develop client/server applications in Java. You should also learn the underlying concepts of developing distributed systems that are applicable across languages, frameworks, and technologies.

You should never tie yourself to a particular technology. Those change all the time. Instead, focus on learning, continuous improvement and development, and problem solving techniques that can be applied to any situation or job. The act of learning new technology is, by itself, an improvement, even if it's not immediately relevant. I've found that by learning something, I get better at learning in general and can more rapidly pick up and use new technologies.

The easiest way to learn something new is to read, practice, and do. First, read the documentation and find out where to go for information. Then, practice with the tutorials or simple problems to get your feet wet. Finally, do something of a meaningful scale, such as implement (or reimplement) a personal project or contribute to an open-source project. Ask questions along the way and never take anything for granted.

Title: Java developing server-client solutions


问:
How can I explain the usefulness of Inheritance?
When trying to explain the concept of Inheritance in OOP, the common example is often the mammals example. IMHO, this is really a bad example, because it will lead the newbies to use this concept the wrong way. And moreover, it is not a common design that they will face in their day-to-day design job.

So, what will be a nice, simple and concrete problem that is solved using Inheritance ?

答: I am working with cameras at work. We have devices that connect to different models, so we have an abstract "camera class" and every model inherits from this class to support specific functionality of that camera. It's a real world example and not difficult to understand. </p>


问:
With agile, what do when a user story doesn't get completed in an iteration?
Do you just move the story to a new iteration, or delay the next iteration?

It gets a bit tricky when you use something like Jira when you have to copy or move around stories between iterations as it effects calculations of velocity/points etc.

Is there a best-practice?

答:
We tend to try to brake up stories so that it can easily fit into a sprint, and that it can easily be removed. It takes a certain mindset to brake up the story into deliverable pieces during the sprint planning meeting.

The thing I also found is that if the stories brake up into deliverable pieces (which can be visible or not, or even switched off for a couple of sprints), my team can do all the work on the trunk, and not hassle with doing work on a branch, and then rebase/merge the work later which is always a pain, so that's a bonus.

OwnerDisplayName: codecompleting