问:
Low level programming - what's in it for me?
For years I have considered digging into what I consider "low level" languages. For me this means C and assembly. However I had no time for this yet, nor has it EVER been neccessary.

Now because I don't see any neccessity arising, I feel like I should either just schedule some point in time when I will study the subject or drop the plan forever.

My Position

For the past 4 years I have focused on "web technologies", which may change, and I am an application developer, which is unlikely to change.

In application development, I think usability is the most important thing. You write applications to be "consumed" by users. The more usable those applications are, the more value you have produced.

In order to achieve good usability, I believe the following things are viable

Good design: Well-thought-out features accessible through a well-thought-out user interface.

Correctness: The best design isn't worth anything, if not implemented correctly.

Flexibility: An application A should constantly evolve, so that its users need not switch to a different application B, that has new features, that A could implement. Applications addressing the same problem should not differ in features but in philosophy.

Performance: Performance contributes to a good user experience. An application is ideally always responsive and performs its tasks reasonably fast (based on their frequency). The value of performance optimization beyond the point where it is noticeable by the user is questionable.

I think low level programming is not going to help me with that, except for performance. But writing a whole app in a low level language for the sake of performance is premature optimization to me.

My Question

What could low level programming teach me, what other languages wouldn't teach me? Am I missing something, or is it just a skill, that is of very little use for application development? Please understand, that I am not questioning the value of C and assembly. It's just that in my everyday life, I am quite happy that all the intricacies of that world are abstracted away and managed for me (mostly by layers written in C/C++ and assembly themselves). I just don't see any concepts, that could be new to me, only details I would have to stuff my head with. So what's in it for me?

My Conclusion

Thanks to everyone for their answers. I must say, nobody really surprised me, but at least now I am quite sure I will drop this area of interest until any need for it arises.

To my understanding, writing assembly these days for processors as they are in use in today's CPUs is not only unneccesarily complicated, but risks to result in poorer runtime performance than a C counterpart. Optimizing by hand is nearly impossible due to OOE, while you do not get all kinds of optimizations a compiler can do automatically. Also, the code is either portable, because it uses a small subset of available commands, or it is optimized, but then it probably works on one architecture only.

Writing C is not nearly as neccessary anymore, as it was in the past. If I were to write an application in C, I would just as much use tested and established libraries and frameworks, that would spare me implementing string copy routines, sorting algorithms and other kind of stuff serving as exercise at university. My own code would execute faster at the cost of type safety. I am neither keen on reeinventing the wheel in the course of normal app development, nor trying to debug by looking at core dumps :D

I am currently experimenting with languages and interpreters, so if there is anything I would like to publish, I suppose I'd port a working concept to C, although C++ might just as well do the trick.

Again, thanks to everyone for your answers and your insight.

答: Every programming language changes a little bit about how you think about programming in general. A concrete example I can give you is when I started to learn haskell and all of a sudden the functional bits of javascript, ruby, and python just made a whole lot more sense. I had never used foldl in any of my code before but after haskell I pretty much see it everywhere I see arrays. So chances are high that if you learn some C you will become much more aware of the relative performance characteristics of various constructs in your favorite language. A few minutes ago I was listening to a talk about writing speedy and optimized javascript and the speaker said  "If it is hard to do in C then it will be really slow in javascript." His intent being that javascript is an interpreted language and the interpreter is either written in C or C++. This went right over my head because I have very little C experience and I have no idea what's hard or easy in C.</p>


问:
Comment system sorting madness
I have a website in which I'm loading all of the users' comments by the number of likes they have. This has caused me some troubles.

Let's say comment #1 has 5 likes, comment #2 has 2 likes, and the rest have 0 likes. We have the following comment id's:

```<code>1   2   3   4   5   6   7   8   9   10
</code>```

Now let's assume someone else "likes" comment #4. Now the id's ordered are:

```<code>1   2   4   3   5   6   7   8   9   10
</code>```

Let's assume I'm loading 3 comments at the same time. At scenario #1, I loaded comments:

```<code>{1, 2, 3}
</code>```

Now when I click "load more," I load:

```<code>{3, 5, 6}
</code>```

Loaded #3 twice! And comment #4 is never viewed. Problems also happen when a comment is deleted, but that's for later.

How can I work around that? I saw websites that order by "likes" or something similar and I almost never encounter duplicates and/or missing comments. Any tips?

Thanks.

答:
It sounds like you're using naive "LIMIT 3" and then "LIMIT 3,3" to return only those additional records required.  Doing so will, quite obviously, result in duplicates and missed comments if a "like" is recorded intra-session.

To resolve that issue, you may want to try one of the following approaches:

Rather than the OFFSET clause, send a JSON array of all comment ID's already shown to the user, and exclude them from the viable options via a WHERE IN(1,2,3) clause.

As above, but store the array of comment ID's shown server-side, in the user's current session or even a MySQL temporary table.

Don't send the entire "new comments" in a single request.  Instead,  have the page request an index of comment ID's and their sortable attributes, and then ask for "comment text" or "comment changes" via distinct requests.

Don't omit any comment from the list sent to the client.  Instead, include ALL comments in each request, and descide which ones to show client-side.

Be aware that none of the above are without potential performance issues, but one of the approaches will be required if you want to sort by any mutable property, "Likes" or what have you.

ContentLicense: CC BY-SA 3.0

Title: Comment system sorting madness


问:
How can I convince my client that the task was complex and the time I took is fair?
I am the single programmer working on a website handling both frontend and backend. Recently in my task list I have to provide a social news feed (activities among friends) which should summarize activities from different modules (at least 7 modules). It has taken at least 20-25 days for me to develop that. Remember in news feed every action can be performed right on the news feed + there must be some kind of aggregation which should aggregate similar activities e.g. User A, B and C liked your item.

How can I convince my client that the task was complex and the time I took is fair?

答:
You gave an estimate, your client agreed based on it, you got it wrong, you take the hit.
It's a harsh lesson, and you did have the option of attempting to renegotiate the cost and or scope, but you got into one more day mode, there's always a price for that.

Even if you succeeded in persuading your client to pay for your mistake, they are not going to be happy, and will be reluctant to do business with you again. Personally I'd visibly take this one on the chin and honestly and openly admit my error. You'll get regain some respect and get a reputation for integrity.

I know it's not what you want to hear, but put yourself in their shoes, what would persuade you to pay over 2.5 times what was originally agreed with some third party? It would have to be really convincing wouldn't it?


问:
Decision making process within a Scrum team
Two questions:

I assume that when Scrum coaches say "the team should decide" they mean there has to be a consensus decision process usually facilitated by the Scrum Master?

What if there is a disagreement between members of the Scrum team on the way to develop/design some feature and a consensus cannot be reached, who decides? The Scrum Master? The system architect? The funcional manager?

Thanks.

答:
These are my subjective views:

1: A team decision does not have to be consencus-based. It can in fact be a majority vote, the choice of an elected representative or something else. But the team should somehow agree, yes. Considering who should facilitate this leads us directly onto answer number...

2: I have on multiple occasions encountered situations where the inability to resolve disputes has proven problematic. In these cases, having someone there to resolve the dispute really helps, even if resolving it only involves making a random decision. In my experience it works well if the team lead or technical lead takes this role.

In theory you could probably just as well adopt some sort of "rock, paper, scissors" policy to resolve disputes, but this would require non-stubborn and quite open-minded team members. It might work if you're sitting on a group of experienced people or people who agree a lot.


问:
Is embedded programming closer to electrical engineering or software development?
I am being approached with a job for writing embedded C on micro controllers. At first I would have thought that embedding programming is too low on the software stack for me, but maybe I am thinking about it wrong.

Normally I would have shrugged off an opportunity to write embedded code, as I don't consider myself an electrical engineer. Is this a bad assumption? Am I able to write interesting and useful software for embedded systems, or will I kick myself for dropping too low on the software stack?

I went to school for computer science and really enjoyed writing a compiler, thinking about concurrent algorithms, designing data structures, and developing frameworks. However, I am currently employed as a web developer, which doesn't scream the interesting things I just described. (I currently deal with issues like: "this check box needs to be 4 pixels to the left" and "this date is formatted wrong".)

I appreciate everyone's input. I know I have to make the decision for myself, I just would like some clarification on what it means to be a embedded programmer, and if it fits what I find to be interesting.

答:
@tcrosley's answer is excellent.   You do not need to be an electrical engineer, but knowing the basics helps.

I don't think you need to fear being "too low on the software stack".  I've had to solve many very interesting problems as an embedded engineer.   You mention a list of tasks you enjoyed:

Concurrent algorithms - Dealing with asynchronous hardware level interrupts has as many interesting challenges as using an OS thread model.

Designing data structures - Check.  Design for compactness and efficient access.

Developing frameworks - Check.  On bare bones systems, you can end up designing a mini-OS.

Writing a compiler - maybe not, but you can end up doing low-level code optimization similar to the assembly generation step of a compiler.

I'd pick working on embedded systems over coding UI's any day.  You'll never forget the first time you watch a machine start moving the way you programmed it to.  It's way more satisfying than pushing pixels.

ContentLicense: CC BY-SA 2.5


问:
Should unit-tests be entirely self-contained?
As the title suggests my question is whether or not
unit-tests should be entirely self-contained or can
one rely on the results yielded by previous tests?

What I mean, in case that it isn't entirely clear,
is that if ones initial test sufficiently asserts
that a certain module A works in a certain way can,
or more appropriately, should one write subsequent
tests with the assumption that the aforementioned
module A is tested beforehand? This would imply that
the order that the unit-tests are executed matters.

Or should each individual test be self-reliant
to the point that if one needs to know whether a
module B works, which can only be validated
if module A works, should one then test module A
within the same test as module B which
would imply that the separate unit-tests can be
executed in any order.

To give a concrete example, consider the "stack" datatype, which we won't delve too deeply into, specifically two fundamental properties we'd need to be able to reason about the datatype in any meaningful sense. Namely, isEmpty(stack) and Empty(). Now, if one wishes to test the validity of isEmpty which takes a stack and returns a True or False depending on whether or not the stack received as an argument is empty or not one would first need to create an empty stack using Empty().

Then we consider the scenario of doing the following: isEmpty(Empty()) and checking what kind of result we get. Either we get a True statement, so Empty() could have returned a non empty stack and isEmpty might view that as an empty stack which would be wrong. Or we get False, and we still don't know how the two actually interplay, nor how either works on their own (assuming we can't view the source). (There is a third option, we receive something that's neither True nor False, but that is beyond the scope of this discussion, this is solely a remark).

Finally, to tie this back to my question, if we create a test where we can be reasonably certain that isEmpty works in a satisfying manner can then all tests executed after it trust that it does indeed work? Or should they all try and incorporate this ambiguity into their own test logic (for instance, including an else statement to if neither True nor False was returned)

答:
Unit tests should be self-contained, but need not be order-independent. It should be possible a test in isolation from others, but a failure may then imply failure in a dependency, not in the test itself.

Take a simplistic example, a set of functions implementing a data type. Two of those functions are Parse() and Format(), converting from and to a string representation. It is a quite reasonable strategy to test the Format() function, and then use the Format() function in tests on the Parse() function. If the tests are run out of order then a fault in the Format() function could actually appear as a test failure in the Parse() function.

This is simplistic, but it is common to build up suites of increasingly complex tests based on the knowledge that prior tests have passed. In some cases mocking is a better strategy, but mock components themselves have to be tested, so even then you are depending on prior successful tests.


问:
Placing arguments on their own lines
This question applies to both parameters and arguments, since I've seen this style used in both.

I usually write parameters like this

```<code>someFunction(arg0, arg1, arg2)
</code>```

but I've recently noticed that many people write theirs like this

```<code>someFunction(
arg0,
arg1,
arg2
) // the bracket doesn't have to be on its own line
</code>```

I have a multi-faceted question here:

1) Is it standard practice, good practice, or negligible to put each argument on their own lines?

2) Are their exceptions to this style, like when there is only one argument?

3) What are the pros and cons of such a design?

答:
As with any code formatting questions, it is largely a matter of opinion and of context.

If you are passing a small number of parameters and the parameters are local variables rather than the result of some other method, having everything on one line tends to make code easier to read because it is appropriately compact.  If, on the other hand, you are passing a relatively large number of parameters and the parameters are the result of calling other methods, separate lines are often better from a readability standpoint because you're not trying to follow dozens of operations in a single line of code.

In other words, if I have something like

```<code>log( base => 2, exp => 8 )
</code>```

it's much easier to see on a single line.  On the other hand, if I have something like this where I'm instantiating one object and passing a value to a constructor, calling a method on another object, computing a value from one local variable, passing in another local variable, and using a constant, it would be very difficult to follow on a single line of code.  You'd need multiple lines just to be able to see everything at a glance.

```<code>someBusinessFunction( new SomeObject( "file_name.txt" ),
                      anotherObject.GetListOfAddresses(),
                      aLocalVariable,
                      (case when someLocalVariable then 'Y' else 'N' end),
                      ASYNC_MODE );
</code>```

Of course, ideally, you'd probably want method signatures that are simpler rather than signatures that are overly complex all else being equal.  But sometimes methods make more sense when they accept a few parameters.  You could, of course, also create multiple intermediate variables on multiple lines of code and then call the function on a single line of code.  That may or may not simplify the logic overall, though.  You'd still have at least as many lines of code but now you'd have a few additional local variables to keep track of.

Title: Placing arguments on their own lines

Body:
As with any code formatting questions, it is largely a matter of opinion and of context.

If you are passing a small number of parameters and the parameters are local variables rather than the result of some other method, having everything on one line tends to make code easier to read because it is appropriately compact.  If, on the other hand, you are passing a relatively large number of parameters and the parameters are the result of calling other methods, separate lines are often better from a readability standpoint because you're not trying to follow dozens of operations in a single line of code.

In other words, if I have something like

log( base => 2, exp => 8 )

it's much easier to see on a single line.  On the other hand, if I have something like this where I'm instantiating one object and passing a value to a constructor, calling a method on another object, computing a value from one local variable, passing in another local variable, and using a constant, it would be very difficult to follow on a single line of code.  You'd need multiple lines just to be able to see everything at a glance.

someBusinessFunction( new SomeObject( "file_name.txt" ),
                      anotherObject.GetListOfAddresses(),
                      aLocalVariable,
                      (case when someLocalVariable then 'Y' else 'N' end),
                      ASYNC_MODE );

Of course, ideally, you'd probably want method signatures that are simpler rather than signatures that are overly complex all else being equal.  But sometimes methods make more sense when they accept a few parameters.  You could, of course, also create multiple intermediate variables on multiple lines of code and then call the function on a single line of code.  That may or may not simplify the logic overall, though.  You'd still have at least as many lines of code but now you'd have a few additional local variables to keep track of.


答:
The goal of unit testing is to test all paths within a class. This means testing all possible inputs (or representative sample), but also all possible behaviors of dependencies, including dependency failures, i.e. how a method in module B handles all possible correct values returned by A, all possible exceptions thrown by A, and all possible incorrect return values from A, e.g. null. Testing module B by relying on a set of tests for A is valid so long as you recognize that it represents only a subset of behaviors of A (unless you can confirm that it is possible to exercise all paths in A using the range of inputs to B). To fully test B, you likely need to force the full range of potential return values/exceptions from A by mocking it. It doesn't matter from the perspective of B whether A is correct or not. What matters is how B handles any implementation of A, i.e. to protect against current or future buggy implementations of A (or A's dependencies). The goal is to prove that B always does the correct thing for correct inputs and correct dependency behaviors, and also does something sensible (not crash or corrupt anything, informs the caller of the problem, returns control gracefully) when it receives bad input or encounters faulty behavior by a dependency.

So my response is unit tests can use other unit tests to generate behavior of dependencies, but that a mockup of dependencies is likely needed to define a complete set of unit tests, e.g. to include dependency failures. The particular implementation of dependencies, and their correctness, are irrelevant, only their API matters.

To say it slightly differently, an exception thrown by A is a valid unit test of B in that it tests an error handling path in B, that is unreachable by varying input to B.

Title: Should unit-tests be entirely self-contained?

Body:
As the title suggests my question is whether or not
unit-tests should be entirely self-contained or can
one rely on the results yielded by previous tests?

What I mean, in case that it isn't entirely clear,
is that if ones initial test sufficiently asserts
that a certain module A works in a certain way can,
or more appropriately, should one write subsequent
tests with the assumption that the aforementioned
module A is tested beforehand? This would imply that
the order that the unit-tests are executed matters.

Or should each individual test be self-reliant
to the point that if one needs to know whether a
module B works, which can only be validated
if module A works, should one then test module A
within the same test as module B which
would imply that the separate unit-tests can be
executed in any order.

To give a concrete example, consider the "stack" datatype, which we won't delve too deeply into, specifically two fundamental properties we'd need to be able to reason about the datatype in any meaningful sense. Namely, isEmpty(stack) and Empty(). Now, if one wishes to test the validity of isEmpty which takes a stack and returns a True or False depending on whether or not the stack received as an argument is empty or not one would first need to create an empty stack using Empty().

Then we consider the scenario of doing the following: isEmpty(Empty()) and checking what kind of result we get. Either we get a True statement, so Empty() could have returned a non empty stack and isEmpty might view that as an empty stack which would be wrong. Or we get False, and we still don't know how the two actually interplay, nor how either works on their own (assuming we can't view the source). (There is a third option, we receive something that's neither True nor False, but that is beyond the scope of this discussion, this is solely a remark).

Finally, to tie this back to my question, if we create a test where we can be reasonably certain that isEmpty works in a satisfying manner can then all tests executed after it trust that it does indeed work? Or should they all try and incorporate this ambiguity into their own test logic (for instance, including an else statement to if neither True nor False was returned)


问:
Decouple GUI & Program logic
I have some windows c++ code (pure winapi c++, no MFC etc) that I would like to build a GUI for. My code does not know about windows GUI, it is completely decoupled from any type of UI.

The question: How could I build a UI around the existing code. Ideally, I am imagining something like this:

GUI <--> Mediator <--> MyExistingCode

For example,

MyExistingCode.showmsg(char* msg) would call Mediator.MessageBox(0, 0, msg, 0);

I'm stuck at how to design the Mediator class (If that is the correct way of going about this). Is the Mediator an Interface?, Abstract Class?, Other? Is an MVC model the best way to go?

答:
The solution that works best for me nowadays is to build my application like a library (lib or dll) and then build my console or GUI application on top of that. On Visual Studio, for example, this works by having (at least) two projects in the same solution. One project is your library and the other is the consumer of that library. You only have to provide a sensible interface, and not care who and how it uses your library. In this way, my console or GUI would use my code as any other regular 3rd party library.

See some opinions on this SO question: What do you think of developing for the command line first?

Title: Decouple GUI & Program logic


答:
There are actually three different ways for routine-header layout (Code Complete 2):no conscious layout, endline layout and standard indentation. The preferred  method being the standard indentation

No conscious layout

The parameters are laid out one after another, with no arrangement whatsoever

```<code>bool ReadData(string employeeName, int employeeAge, int yearsOnJobMarket, bool isOperationSuccesful)
</code>```

These routines are seen as purely utilitarian in that both computers and humans can read them, but they cause trouble for humans.

Endline layout

```<code>bool ReadData(string employeeName,
              int    employeeAge,
              int    yearsOnJobMarket,
              bool   isOperationSuccesful)
</code>```

This approach is neat and aesthetically appealing. The main problem is that it takes a lot of work to maintain, and that usually means it isn't maintained. For example, if the routine name changes to ReadNewData, your layout will look like this:

```<code>bool ReadNewData(string employeeName,
              int    employeeAge,
              int    yearsOnJobMarket,
              bool   isOperationSuccesful)
</code>```

so now you either have to manually change the indentation of all the other parameters, or just forget about it and leave it as it is.

Standard indentation

```<code>bool ReadData(
    string employeeName,
    int employeeAge,
    int yearsOnJobMarket,
    bool isOperationSuccesful
)
</code>```

Now, in this case, you don't have to change anything if your routine name changes, or you add/delete new parameters. It looks good for the eyes, it's readable and maintainable.

Again, these are not my ideas, but are taken from Code Complete 2 by Steve McConnell

Title: Placing arguments on their own lines

Body:
This question applies to both parameters and arguments, since I've seen this style used in both.

I usually write parameters like this

```<code>someFunction(arg0, arg1, arg2)
</code>```

but I've recently noticed that many people write theirs like this

```<code>someFunction(
arg0,
arg1,
arg2
) // the bracket doesn't have to be on its own line
</code>```

I have a multi-faceted question here:

1) Is it standard practice, good practice, or negligible to put each argument on their own lines?

2) Are their exceptions to this style, like when there is only one argument?

3) What are the pros and cons of such a design?

Body:
There are actually three different ways for routine-header layout (Code Complete 2):no conscious layout, endline layout and standard indentation. The preferred  method being the standard indentation

No conscious layout

The parameters are laid out one after another, with no arrangement whatsoever

bool ReadData(string employeeName, int employeeAge, int yearsOnJobMarket, bool isOperationSuccesful)

These routines are seen as purely utilitarian in that both computers and humans can read them, but they cause trouble for humans.

Endline layout

bool ReadData(string employeeName,
              int    employeeAge,
              int    yearsOnJobMarket,
              bool   isOperationSuccesful)

This approach is neat and aesthetically appealing. The main problem is that it takes a lot of work to maintain, and that usually means it isn't maintained. For example, if the routine name changes to ReadNewData, your layout will look like this:

bool ReadNewData(string employeeName,
              int    employeeAge,
              int    yearsOnJobMarket,
              bool   isOperationSuccesful)

so now you either have to manually change the indentation of all the other parameters, or just forget about it and leave it as it is.

Standard indentation

bool ReadData(
    string employeeName,
    int employeeAge,
    int yearsOnJobMarket,
    bool isOperationSuccesful
)

Now, in this case, you don't have to change anything if your routine name changes, or you add/delete new parameters. It looks good for the eyes, it's readable and maintainable.

Again, these are not my ideas, but are taken from Code Complete 2 by Steve McConnell


问:
Building a distributed system on Amazon Web Services
Would simply using AWS to build an application make this application a distributed system?

For example if someone uses

RDS for the database server,

EC2 for the application itself and

S3 for hosting user uploaded media,

does that make it a distributed system?

If not, then what should it be called and what is this application lacking for it to be distributed?

Update

Here is my take on the application to clarify my approach to building the system:

The application I'm building is a social game for Facebook.

I developed the application locally on a LAMP stack using Symfony2.

For production I used an a single EC2 Micro instance for hosting the app itself, RDS for hosting my database, S3 for the user uploaded files and CloudFront for hosting static content.

I know this may sound like a naive approach, so don't be shy to express your ideas.

答:
There are (at least) two lines of thoughts regarding distributed systems, and depending on your environment your system may or may not qualify as such:

Computer Science - in this case, a distributed system solves an algorithmic problem such that each node does part of the processing, in some instances even without a controller coordinating the task. Usually the goal is to find a distributed algorithm to solve a problem more efficiently.

Information Systems - in this case, a distributed system is one which distributes presentation, application and database among multiple autonomous entities that communicate via a network (by passing messages among each-other).

(Note that on an a sincerely abstract level that's the same definition -- any computational problem is in fact an algorithmic problem, but let's save this argument for a different discussion).

So yes, you can consider yours a distributed system, and we can argue so given the definition as found in Wikipedia:

```<code>1. There are several autonomous computational entities, each of which has its own local memory.[7]

2. The entities communicate with each other by message passing.[8]
</code>```

In your case, the web server along with your application code, the database server and the image server are all autonomous computational entities with their own local memory, and they communicate by message passing (that is, sending messages back and forth via the network).

The same Wikipedia article also lists several architectures for building distributed systems, one of which is the n-tier Architecture:

In software engineering, multi-tier architecture (often referred to as
  n-tier architecture) is a client–server architecture in which
  presentation, application processing, and data management functions
  are logically separated.

Further, your system clearly has multiple tiers (the application, the database and the image store). It probably also has multiple layers, that is if you followed Symfony's MVC model. MVC by definition seperates presentation and application logic, and since (at least part of) the presentation layer is most certainly run by a web browser, this is in fact a 3-tier architecture:

Three tier systems move the client intelligence to a middle tier so
  that stateless clients can be used. This simplifies application
  deployment. Most web applications are 3-Tier.

Body:
There are (at least) two lines of thoughts regarding distributed systems, and depending on your environment your system may or may not qualify as such:

Computer Science - in this case, a distributed system solves an algorithmic problem such that each node does part of the processing, in some instances even without a controller coordinating the task. Usually the goal is to find a distributed algorithm to solve a problem more efficiently.

Information Systems - in this case, a distributed system is one which distributes presentation, application and database among multiple autonomous entities that communicate via a network (by passing messages among each-other).

(Note that on an a sincerely abstract level that's the same definition -- any computational problem is in fact an algorithmic problem, but let's save this argument for a different discussion).

So yes, you can consider yours a distributed system, and we can argue so given the definition as found in Wikipedia:

1. There are several autonomous computational entities, each of which has its own local memory.[7]

2. The entities communicate with each other by message passing.[8]

In your case, the web server along with your application code, the database server and the image server are all autonomous computational entities with their own local memory, and they communicate by message passing (that is, sending messages back and forth via the network).

The same Wikipedia article also lists several architectures for building distributed systems, one of which is the n-tier Architecture:

In software engineering, multi-tier architecture (often referred to as
  n-tier architecture) is a client–server architecture in which
  presentation, application processing, and data management functions
  are logically separated.

Further, your system clearly has multiple tiers (the application, the database and the image store). It probably also has multiple layers, that is if you followed Symfony's MVC model. MVC by definition seperates presentation and application logic, and since (at least part of) the presentation layer is most certainly run by a web browser, this is in fact a 3-tier architecture:

Three tier systems move the client intelligence to a middle tier so
  that stateless clients can be used. This simplifies application
  deployment. Most web applications are 3-Tier.


问:
difference between exponential and logarithmic growth
Why

for(k=1;k<=n;k*=2) grows logarathmically = O(logn)
but I feel it grows exponentially, as the seq look like 1,2,4,8....

and for fibonacci series people say it grows exponentially.
which for me doesnt look like  0,1,1,2,3,5...
but for tis they tell O(2^n).

PLease explain

答:
The asymptotic growth is not about how the numbers in the sequence grow - it's about how long it takes to calculate the sequence for a given n.

In for(k=1;k<=n;k*=2)'s case, it only takes a single extra iteration to calculate for n*2 compared to n, so assuming the iteration's execution time is O(1), the growth is logarithmic.

In Fibonacci's case, if you use the naive recursive algorithm, it takes twice as long to calculate for n+1 compared to n, so the growth is exponential.


答:
You're misunderstanding the meaning. They are probably talking about the complexity of an algorithm, which got nothing to do with the resulting sequence of numbers (which you seem to talk about).

Just look at some snippets.

Compare for example for(k=1;k<=5000;k*=2) with for(k=1;k<=10000;k*=2). You'll see that the second will only take 1 more iteration. In fact doubling n will always take only one step more.

Now lets look at the algorithm for the fibonacci sequence that was probably being talked about:

```<code>int fibonacci(int n)  {
    if(n <= 1) return n;
    else return fibonacci(n - 1) + fibonacci(n - 2);
}
</code>```

Now lets look at how often the function gets executed for several values for n:

```<code>n = 0:  1    function call
n = 1:  1   function call
n = 2:  3   function calls
n = 3:  5   function calls
n = 4:  9   function calls
n = 5:  15  function calls
n = 6:  25  function calls
n = 7:  41  function calls
n = 8:  67  function calls
n = 9:  109 function calls
n = 10: 177 function calls
</code>```

In fact you got the one function call you make when calling fibonacci(n) + the amount of function calls being made in fibonacci(n-1) + the amount of function calls in fibonacci(n-2).

Therefore increasing n just slightly would make an huge increase in the number of function calls actually being made.

Title: difference between exponential and logarithmic growth

Body:
Why

for(k=1;k<=n;k*=2) grows logarathmically = O(logn)
but I feel it grows exponentially, as the seq look like 1,2,4,8....

and for fibonacci series people say it grows exponentially.
which for me doesnt look like  0,1,1,2,3,5...
but for tis they tell O(2^n).

PLease explain

Body:
You're misunderstanding the meaning. They are probably talking about the complexity of an algorithm, which got nothing to do with the resulting sequence of numbers (which you seem to talk about).

Just look at some snippets.

Compare for example for(k=1;k<=5000;k*=2) with for(k=1;k<=10000;k*=2). You'll see that the second will only take 1 more iteration. In fact doubling n will always take only one step more.

Now lets look at the algorithm for the fibonacci sequence that was probably being talked about:

int fibonacci(int n)  {
    if(n <= 1) return n;
    else return fibonacci(n - 1) + fibonacci(n - 2);
}

Now lets look at how often the function gets executed for several values for n:

n = 0:  1    function call
n = 1:  1   function call
n = 2:  3   function calls
n = 3:  5   function calls
n = 4:  9   function calls
n = 5:  15  function calls
n = 6:  25  function calls
n = 7:  41  function calls
n = 8:  67  function calls
n = 9:  109 function calls
n = 10: 177 function calls

In fact you got the one function call you make when calling fibonacci(n) + the amount of function calls being made in fibonacci(n-1) + the amount of function calls in fibonacci(n-2).

Therefore increasing n just slightly would make an huge increase in the number of function calls actually being made.


答:
For the first snippet, you are correct, the sequence is 1, 2, 4, 8, but you miss the point. Make a table, n and the number of steps to take.
Sample:

n / sequence length

```<code>1 / 1
2 / 2
4 / 3
8 / 4
16 / 5
</code>```

As you can see, you get O(log n).

For Fibonacci, you have f(n) = f(n-1) + f(n-2). For every n step, you calculate 2 more steps. For every n-1 steps you also have to calculate 2 steps. You stop at n = 1 or n = 2, the last one with 2 more steps being n = 3.
For nth step, you have, more or less:

```<code>2^3 + 2^4 + .. + 2^(n-1) = 2^n - 2^0 - 2^1 - 2^2 = O(2^n)
</code>```

Body:
For the first snippet, you are correct, the sequence is 1, 2, 4, 8, but you miss the point. Make a table, n and the number of steps to take.
Sample:

n / sequence length

1 / 1
2 / 2
4 / 3
8 / 4
16 / 5

As you can see, you get O(log n).

For Fibonacci, you have f(n) = f(n-1) + f(n-2). For every n step, you calculate 2 more steps. For every n-1 steps you also have to calculate 2 steps. You stop at n = 1 or n = 2, the last one with 2 more steps being n = 3.
For nth step, you have, more or less:

2^3 + 2^4 + .. + 2^(n-1) = 2^n - 2^0 - 2^1 - 2^2 = O(2^n)


答:
Just an observation regarding the complexity of calculating the Fibonacci numbers. As others have pointed out, the naive implementation

```<code>int fibonacci(int n)
{
    if (n <= 1)
        return n;
    else
        return fibonacci(n - 1) + fibonacci(n - 2);
}
</code>```

is exponential. On the other hand, the following implementation is linear:

```<code>int fibonacci_helper(int f0, int f1, int p, int n)
{
    if (p == n)
        return f0 + f1;
    else
        return fibonacci_helper(f1, f0 + f1, p + 1, n);
}

int fibonacci(int n)
{
    if (n <= 1)
        return n;
    else
        return fibonacci_helper(0, 1, 2, n);
}
</code>```

Body:
Just an observation regarding the complexity of calculating the Fibonacci numbers. As others have pointed out, the naive implementation

int fibonacci(int n)
{
    if (n <= 1)
        return n;
    else
        return fibonacci(n - 1) + fibonacci(n - 2);
}

is exponential. On the other hand, the following implementation is linear:

int fibonacci_helper(int f0, int f1, int p, int n)
{
    if (p == n)
        return f0 + f1;
    else
        return fibonacci_helper(f1, f0 + f1, p + 1, n);
}

int fibonacci(int n)
{
    if (n <= 1)
        return n;
    else
        return fibonacci_helper(0, 1, 2, n);
}


问:
In Scrum, who verifies "Done"?
I am a QA/Test manager in my organization and until today I verified the quality of the software (tests written and executed and bugs fixed). Who will verify this in Scrum? How do I know that the team wrote and executed all the right tests? On the other hand I'm afraid that if I continue to do the verification the team will not feel empowered enough. But I need some verification process that "Done" is indeed "Done". What do you suggest?</p>

答:
One major idea in Scrum is that the team should agree on a "definition of done". Ideally, this is something like a set of objective criteria that anyone can verify by going through a checklist.

But to reduce the chance of something slipping through, it makes perfect sense to have a rule that verifying "done" most be performed by someone other than the person who implemented an item - or a designated QA guy like you (but that risks making you a bottleneck).

If in doubt, discuss is with the team and the Scrum Master and decide together.

Title: In Scrum, who verifies "Done"?


答:
I think there is an implicit assumption in the question. There is a difference between "accepted", when a Product Owner declares a backlog item or task has satisfied the Product Owner, and "done" meaning all work associated with the backlog item is complete.

However, there is regularly more to a task than that visible to the Product Owner, usually someone semi-technical at best, including (automated and manual) testing, documentation and review. The Product Owner is rarely in a position to know the technical aspects, let alone whether they are completed.

Therefore, it is ultimately up the team to determine what "done" means. The organization may have standards and different stakeholders will have their own requirements. The scrum master or relevant managers usually are responsible for collating and enforcing the list.

In your example, as the QA/Test manager, you are the one who says whether tests are complete. However, you may not be the best person to say whether the code has been reviewed, security requirements are met, the product is internationalized, documentation is complete or whatever else constitutes "done".

Title: In Scrum, who verifies "Done"?

Body: I am a QA/Test manager in my organization and until today I verified the quality of the software (tests written and executed and bugs fixed). Who will verify this in Scrum? How do I know that the team wrote and executed all the right tests? On the other hand I'm afraid that if I continue to do the verification the team will not feel empowered enough. But I need some verification process that "Done" is indeed "Done". What do you suggest?</p>


问:
Implementation of deque in C++ with an array
How is the end() function implemented in deque-STL of C++ with array?

As per my knowledge it returns past-the-end element. But when a loop is run like, for(i=deq.begin();i!=deq.end();i++) and the whole array is full (suppose size=4), then I think end() will point to the position where begin() is pointing, in this way it won't go in the for loop.

How to resolve this problem?

答:
You seem to be confusing a deque (double ended queue) with a circular buffer.

In a circular buffer you are right that when the buffer is full, the 'one past the last' element coincides with the first element. When implementing iterators for a circular buffer, this needs to be taken into account to avoid confusing an empty buffer with a completely filled one.

A deque can best be visualised as a row of elements where you can add elements at either end. This should also make it clear that there is no way for end() to equal begin() except for an empty queue, because there is no point where the two ends come together again.


问:
Learning Scala, feeling discouraged
I'm coming from a Java background and trying to learn Scala. At the moment I'm feeling pretty overwhelmed, there seems to be so much more to learn with Scala, so many different ways of doing the same thing.

I was wondering if anyone has any advice on where to start, and how long it took them to feel reasonably competent in the language?

Even little things like for loop comprehensions seem really powerful but it's just another piece of syntax you need to remember!

答:
Scala is a very different way of thinking to Java, so don't be discouraged! I'd probably start with Functional Programming for Java developers so that you can get into the functional way of thinking.

Is there a Java and/or Scala user group near by?  It's always easier to learn a new language with a colleague.

Best of luck and keep persevering at it!.

Title: Learning Scala, feeling discouraged


问:
How important is an SSL certificate for a internal website?
I know many people have asked the same question but I think it really depends on the type of the website. So that's why I am asking the question about my website.

I am developing a PHP web application for an insurance company. the application contains all information about the customers but this app is only used by the admins and salesman of the company. The admin creates a user then that user can add customers or renew their insurance. the address will be something like example.com/manage/ and the login is only for the users that admin person has created. Of course I will be using validation, salt, encryption, etc. But do I need SSL certificate?

答:
Yes, whenever traffic is transported across an untrusted network.

Using HTTPS encrypts the traffic. Otherwise, an attacker could read customer information or internal documents in the clear whenever they are transmitted. And if a password or other keys are ever transmitted as clear text, then an attacker could use those to get even better access.

SSL certficates can authenticate a server to a user which makes man in the middle-attacks more difficult. Otherwise, an attacker could set up a proxy between the user and the real server, and record all communications even when they're encrypted.

Consider the following attack scenarios:

A sales rep connects to your website while sitting in a coffee-shop. The Wi-Fi has been compromised, and all network traffic is recorded by a malicious hacker. If you do not verify the identity of the server and encrypt all traffic, the attacker can record and misuse confidential information or sensitive customer data, e.g. by selling the data to a competitor.

The physical internet connection of your office is compromised. Your website is hosted outside of the office. All requests to the server are intercepted and redirected to a proxy which records all information. The same chaos as above ensues.

This is not of an issue when the server is only accessible via an Intranet which is already sufficiently secured and encrypted (e.g. via a VPN). Note that in some jurisdictions there are strong privacy requirements when handling customer data. Should you be breached without having secured the data properly, you could face legal action there.


问:
What should you leave behind for your successors?
Assume that you're a sole developer leaving a job. What kind of information/material, outside of the code itself, should you create and leave behind for your replacement?

An obvious answer is "whatever you would want at a new job" for sure, but it's been a while since I started a new job, and I forget what the most important things that I needed were back then.

I'm thinking:

accounts/passwords

location of equipment, backups, software CDs

What else?

答:
I think what I would love to see in documentations besides the usual would be what features were left out. Like why certain ideas were NOT implemented or a certain platform or method NOT used (which was otherwise an obvious choice).

This makes sure that the successor always knows what not to do or if he is more capable then maybe he can come up with a work around and make certain features work.

This is especially applicable to open source projects. Can save a lot of time and brain power!


问:
Naming convention of getters and setters
Given a string variable variable, for example, the convention to expose it is:

public class SomeClass {

```<code>public String variable = "";
public String getVariable() {return variable;}
public void setVariable(String variable) {this.variable = variable;}
</code>```

}

Which looks like:

class.getVariable(); // Gets "variable"

class.setVariable("Hello"); // Sets "variable"

Is the following convention considered bad style?:

public class SomeClass {

```<code>public String variable = "";
public String variable() {return variable;}
public void variable(String variable) {this.variable = variable;}
</code>```

}

Which looks like:

class.variable(); // Gets "variable"

class.variable("Hello"); // Sets "variable"

Keep in mind that the established design pattern of fluent interface seems to suggest that one create objects using something like:

public class SomeClass {

```<code>public String variable = "";

public SomeClass(String variable) {this.variable = variable;}

public String variable() {return variable;}
public SomeClass variable(String variable) {return SomeClass(variable);}
</code>```

}

Which looks like:

SomeClass sc = new SomeClass().variable("Hello"); // Instantiates a new SomeClass object with variable equal to "Hello".

Evidently, the word "set" is implied in the fluent interface pattern.
(Yes, technically, the fluent interface returns the class instead of void when setting. This is not important.)

答:
The first is fine getXXX, setXXX
The second won't work as you can't have three members all with the same name.

As mentioned in the comments it all depends on the language. Stick with the general style guide of the language if there exists any.

AFAIK in

Java you have get_/set_ prefix while the field storing the value is private.

in C# you use uppercase Xxx for getter and setter and xxx for the backing field (if you have any)

in Go you have Xxx for getter and SetXxx for setter.
The backing field is named xxx because lowercase makes it private.

in Dart you have to use _ to indicate that a field is private, this results in xxx for getter and setter and _xxx for the backing field.

These are just the few languages I used recently and they have all different conventions.


问:
Creating a large quantity of types VS using mostly the ones provided by the language
There are several times where you're coding a method which has two parameters with the same type, lets say, integers, NumberOfUnitA and NumberOfUnitB. Given that we're coding in a language that doesn't support named parameters, why is that we don't see people creating types closer to the domain logic, in this case, UnitA and UnitB, but just raw integers? It seems much more expressive to me.

And even in other situations, many times, we have to pass a bunch of flags, and they are just integers (even in cases where perfomance is not an issue), why we do this? Does it create unnecessary complications?

What are the problems of this approach of creating many types?

答:
This depends a lot of the language you use.

I Go which has type aliases you can easily create aliases for ints without any notable drawbacks.
Other languages don't allow deriving elementar types like int or string at all,  (like Dart) because they are strongly optimized for performance and dynamic method dispatch as it's used for polymorphism would decrease performance a lot (but Dart has named parameters though)


答:
The reason I am not doing it as much as I would like to: not enough compiler support.

In Delphi I can create type aliases such as:

```<code>type
  TAmount = type Integer;
  THouseNumber = type Integer;
  TCreditAmount = type Currency;
  TDebitAmount = type Currency;
</code>```

These would make method signatures so much more self dosumenting. Unfortunately, the compiler doesn't force me to use the proper alias as long as the types are assignment compatible. Only if a parameter is a var parameter (passed by reference) does the compiler enforce exact type equality.

Which means that I can forget to use the proper types and won't be alerted. Which means that the code base may slowly start not using TCreditAmount where it should and that detracts from the usefulness of declaring it in the first place.

Title: Creating a large quantity of types VS using mostly the ones provided by the language

Body:
There are several times where you're coding a method which has two parameters with the same type, lets say, integers, NumberOfUnitA and NumberOfUnitB. Given that we're coding in a language that doesn't support named parameters, why is that we don't see people creating types closer to the domain logic, in this case, UnitA and UnitB, but just raw integers? It seems much more expressive to me.

And even in other situations, many times, we have to pass a bunch of flags, and they are just integers (even in cases where perfomance is not an issue), why we do this? Does it create unnecessary complications?

What are the problems of this approach of creating many types?

Body:
The reason I am not doing it as much as I would like to: not enough compiler support.

In Delphi I can create type aliases such as:

type
  TAmount = type Integer;
  THouseNumber = type Integer;
  TCreditAmount = type Currency;
  TDebitAmount = type Currency;

These would make method signatures so much more self dosumenting. Unfortunately, the compiler doesn't force me to use the proper alias as long as the types are assignment compatible. Only if a parameter is a var parameter (passed by reference) does the compiler enforce exact type equality.

Which means that I can forget to use the proper types and won't be alerted. Which means that the code base may slowly start not using TCreditAmount where it should and that detracts from the usefulness of declaring it in the first place.


问:
What's the idea behind defining rectangles with two points?
It's not that this doesn't make sense, but it just works out awkward 99% of the time.

Often in 2D graphics rectangles are initialized, stored and manipulated as a pair of points.  In no particular language,

```<code>class Rect:
   p1, p2: point
</code>```

It makes more sense to define a rectangle as two x values and two y values, like this:

```<code>class Rect
   xleft, xright: int
   ytop, ybottom: int
</code>```

With two points, if at some place in the source code you want to make use of the y value of the top, you'd have to say rect.p1.y  (hmmm, stop and think, is it p1 or p2) but with the four values as plain data members, it's clear and direct:  rect.ytop (no thinking required!)     The use of two points means that in dealing with the vertical, you have to tangle the horizontal; there's an extraneous relation between indepenent elements.

How did this two-point idea come about and why does it persists?  Does it have some benefit over bare x and y coordinates?

ADDED NOTE: This question is in the context of X-Y aligned rectangles, such as in windows managers and GUI toolkits, not in the context of arbitrary shapes in drawing and painting app.

答:
Well p1: Point and p2: Point are each going to have two int coordinates in them anyway, so doesn't your class amount to the same thing?

And if you store those two points as first-class Point objects, don't you get a little more utility from them?  In most graphical coordinate systems that I know of, points are subclassed in this way to create a hierarchy of objects: point -> circle -> ellipse and so on.

So if you make an object  that doesn't use the Point class, you have divorced that object from the rest of the class hierarchy.


问:
Is it okay to make coding style changes on an open source project that doesn't follow best practices?
Recently, I came across a number of open source Ruby (or majority of it was Ruby) projects on GitHub that when checked with a code analyzing tool like Rubocop, create a lot of offenses.

Now, most of these offenses include using double quotation marks instead of single quotes (when not interpolation), not following the 2 spaces per level rule, exceeding the 80 character line length rule, or using { and } for multi-line blocks.

[The] Ruby style guide recommends best practices so that real-world
  Ruby programmers can write code that can be maintained by other
  real-world Ruby programmers. ~ Source: Ruby Style Guide

Although they are small and easy to fix, is it appropriate to change the coding style of an open source project by fixing the offenses and making a Pull Request? I acknowledge that some projects, like Rails, do not accept cosmetic changes and some are just too large to "fix" all at once (Rails for example generates over 80,000 offenses when Rubocop is run - regardless, they have their own small set of coding conventions to follow when contributing). After all, the Ruby Style Guide is there for a reason together with tools like Rubocop.

People appreciate consistency so making these kinds of changes is kind of doing a good thing for the Ruby community in general, right?

[The author(s) of the Ruby Style Guide] didn't come up with all the
  rules out of nowhere - they are mostly based on my extensive career as
  a professional software engineer, feedback and suggestions from
  members of the Ruby community and various highly regarded Ruby
  programming resources, such as "Programming Ruby 1.9" and "The Ruby
  Programming Language". ~ Source: Ruby Style Guide

Isn't not following community coding style conventions and best practices basically encouraging bad practices?

答:
Ask the maintainers.

Coding style is a quite subjective discussion, and rules like maximum line length of 80 characters are fairly subjective - while general agreement should be that shorter lines are better to read, 80 might be too restrictive for some with today's screen sizes and IDE's.

Other rules can be ignored on purpose, too. For instance, a developer might consider global use of double quotes better for him and be willing to accept the "risk" of accidental interpolation and an extremely small increase on parsing time.

Many maintainers also don't like large coding style changes as they are boring to review and there is a chance that it might introduce errors. For example, a string could be switched to single quote, even though it contained a deliberate interpolation and should have been using double quotes. Maintainers prefer to do style cleanups while working on that actual code so they can verify style changes don't introduce new bugs.


答:
The only concept of "done" is whether or not a story as a whole is completed. The team should have created a definition of done that says when they feel a story is finished or not. This will typically include things such as "code has been reviewed", "nightly tests have been run", "all acceptance criteria have been met", etc. When these things have been accomplished, the team can feel confident they've done everything expected of them to finish a story.

During a sprint, if you're trying to determine if one of those items in the definition of done has been accomplished, just ask. Scrum and agile is all about open communication. If you are part of the team, ask your teammates if anyone has written the tests, or run them, or created the nightly job, etc. If you are a stakeholder, ask the scrum master.

If you sit outside the team but still must review the tests, have the team add "tests must be reviewed by user user3251930" as part of the definition of done. If that's what it takes for a story to be done, be honest about it and make it part of the process. The whole point of the "definition of done" is so that the team can know with certainty that they have done what is required to deliver quality software. If part of that is an external review, so be it.

Ultimately, it is the product owner who signs off on a particular story, so at the end of the day he or she has the final decision as to whether a story as a whole is done or not.

Title: In Scrum, who verifies "Done"?


答:
You can pull these changes only if there is an open issue to fix the formatting. Otherwise start your own branch, and if the author sees that more people use your branch simply because it's more readable. They'll merge in the branch on their own, but be prepared to maintain your branch by merging in updates and constantly fixing the formatting.

If the project isn't important enough to you to keep maintaining your own branch, then it wasn't worth cleaning up in the first place.

Pull requests can be taken personally by the author. It's not a mechanism to offering criticism, and reformatting all the code could be taken as criticism.

If you don't want to maintain your own branch, but you want to contribute to a project. Open a new issue and describe why the current format is causing you issues, then offer to resolve the issue for the author. If the author agrees, then they'll assign the issue to you and you now have permission to make a pull request.

You've touched on a subject that I also agree is a rampant problem on GitHub. Formatting aside, there are a number of projects that incorrectly use annotations and that cause havoc with many IDEs. I can think of three largely popular projects that use deprecated flags incorrectly that propagate warning messages in my IDE. I've sent pull requests to fix them, but the authors don't use the same IDE, thus the pull requests are ignored.

Branching, merging and fixing seem to be the only solution.

Title: Is it okay to make coding style changes on an open source project that doesn't follow best practices?

Body:
Recently, I came across a number of open source Ruby (or majority of it was Ruby) projects on GitHub that when checked with a code analyzing tool like Rubocop, create a lot of offenses.

Now, most of these offenses include using double quotation marks instead of single quotes (when not interpolation), not following the 2 spaces per level rule, exceeding the 80 character line length rule, or using { and } for multi-line blocks.

[The] Ruby style guide recommends best practices so that real-world
  Ruby programmers can write code that can be maintained by other
  real-world Ruby programmers. ~ Source: Ruby Style Guide

Although they are small and easy to fix, is it appropriate to change the coding style of an open source project by fixing the offenses and making a Pull Request? I acknowledge that some projects, like Rails, do not accept cosmetic changes and some are just too large to "fix" all at once (Rails for example generates over 80,000 offenses when Rubocop is run - regardless, they have their own small set of coding conventions to follow when contributing). After all, the Ruby Style Guide is there for a reason together with tools like Rubocop.

People appreciate consistency so making these kinds of changes is kind of doing a good thing for the Ruby community in general, right?

[The author(s) of the Ruby Style Guide] didn't come up with all the
  rules out of nowhere - they are mostly based on my extensive career as
  a professional software engineer, feedback and suggestions from
  members of the Ruby community and various highly regarded Ruby
  programming resources, such as "Programming Ruby 1.9" and "The Ruby
  Programming Language". ~ Source: Ruby Style Guide

Isn't not following community coding style conventions and best practices basically encouraging bad practices?


答:
Agree that this is something the development/test team needs to define, depending on your own practices. Some projects run so agile that they're willing to risk releasing bugs to their alpha stream; some consider any bug which gets outside the development group a process failure.

The project I'm working on requires peer review of code changes, and requires that whoever wrote the code either provide/update regression tests or explain why it isn't possible to do so. (They and their reviewer(s) also have to certify that they've checked for known bad practices. We're generally Much Happier if they can show that they ran the full test suite and have gotten a clean result (or clean modulo known open issues, at least)  The code then has to survive intensive automated unit and functional testing on multiple platforms to demonstrate that it doesn't cause any regressions against those, and it gets further checked for common antipatterns by an automated code analysis system. Only then do we accept it into the main development stream and mark the work item complete. Note that completing one work item may only be one step toward completing a larger-scale task or story.

That obviously doesn't guarantee that nobody finds a new way to fail, but it reduces the risk to an acceptable level without greatly impeding speed of development.

Title: In Scrum, who verifies "Done"?


答:
The team decides. I use a checklist, for what's considered 'Done'. What's 'Done' per story, per sprint, per release.

As others have mentioned, ultimately the decision lies with the product owner.

Title: In Scrum, who verifies "Done"?


问:
Does late have any meaning in Agile methodologies?
This came out of some of the answers and comments on another question (this one).

I've worked primarily with waterfall projects and while I've worked on ad-hoc projects that have taken on agile behaviours and have read a fair bit about agile, I'd say I've never worked on a "proper" agile project.

My question is does the concept of "late" have any meaning in agile, if so then what?

My reasoning is that with agile you have no upfront plan and you have no detailed requirements at the outset.  You may have a high level goal in mind and a notional date attached to it but both may change (potentially massively) and neither are certain.

So if you don't know exactly what you're going to deliver basically until you deliver it and the user accepts it, and if you don't have a schedule beyond the next sprint, how could you ever be late in any way that actually has meaning?

(Obviously I understand that a sprint might overrun but I'm talking about beyond that.)

Just to be clear I'm (personally) happy with the assumption that on time waterfall projects (even relatively large ones) are possible based on the fact I've seen them and been involved in them - they're not easy or common even but they are possible.

This isn't about knocking agile, it's about me understanding it.  I've always seen the benefit of agile as nothing to do with deadlines or budgets (or rather only indirectly), it's to do with scope - agile delivers closer to what is really important rather than what the project team think is important before they've seen anything.

答:
"late" in an agile methodology means the same thing it means in a waterfall methodology: the estimates were wrong, the scope was too big for the allotted time, unexpected difficulties appeared, the customer wasn't responsive enough, the programmers got lazy, the machines crashed, your dog ate my bytecode, etc.

you learn from it and adjust for the next iteration

the difference is that this can happen every 2-4 weeks, so the lessons get learned and the process gets adjusted rapidly


问:
Should I use automatic properties?
I'm new to C# coming from a Java background. I'm working on a take home assignment for a coding interview. I normally write my code as following(Java):

```<code>public class Test {

   //fields

   private string fieldA;
   private int fieldB;

   public Test () {
      //.....
   }

   public String getFieldA() {
      return fieldA;
   }

   //ETC.
}
</code>```

The point is that I use getters/setters like above. Now, I have a coding assignment to do for a job interview, and using C# I have stumbled across automatic properties. I was initially slightly confused about it but understand what it does now and have used it.

So for fields I would write

```<code>public string fieldA {get; set;}
</code>```

It feels weird declaring fields public like that and doesn't it violate some OOP encapsulation principles ?

My question is, should I just go ahead and use automatic properties to show interviewers that I know what it is? In case I want to prevent setting a field I could just use:

```<code>public string fieldA {get; private set;}
</code>```

But would it appear like I don't follow encapsulation "rules", I obviously wouldn't want to risk that. I could write it out as I do in Java.

In general what is your view on using automatic properties ?

答:
If you can, use them. Behind the scenes the compiler does more than just making a field public. The field is still private.

The automatic property

```<code>public string MyField { get; private set; }
</code>```

would be converted into something like this (the long version)

```<code>private string _myfield;

public string MyField
{
  get
  {
    return _myfield;
  }
  private set
  {
    _myfield = value;
  }
}
</code>```

Internally the compiler will generate getter and setter methods like you know them from Java. So, there's no violation of any OOP principles.

Title: Should I use automatic properties?

Body:
If you can, use them. Behind the scenes the compiler does more than just making a field public. The field is still private.

The automatic property

public string MyField { get; private set; }

would be converted into something like this (the long version)

private string _myfield;

public string MyField
{
  get
  {
    return _myfield;
  }
  private set
  {
    _myfield = value;
  }
}

Internally the compiler will generate getter and setter methods like you know them from Java. So, there's no violation of any OOP principles.


答:
At a first glance, these two lines may look the same:

```<code>public string A;
public string B {get; set;}
</code>```

but they're not the same at all. As you'll know, if you use a public field and in the future you need to add some logic when getting or setting the value, you can't (unless you break the interface that you're providing to others). You can't, because the value isn't encapsulated.

With an automatic property, instead, you can add more logic whenever you want, without the need to change the interface that your class provides. Just replace the automatic property with a standard one. Or, vice-versa, you can replace the standard property with an automatic one. To an external user, nothing changes.

So no, you're not even remotely breaking encapsulation. You're just using an handy syntactic sugar.

Title: Should I use automatic properties?

Body:
I'm new to C# coming from a Java background. I'm working on a take home assignment for a coding interview. I normally write my code as following(Java):

```<code>public class Test {

   //fields

   private string fieldA;
   private int fieldB;

   public Test () {
      //.....
   }

   public String getFieldA() {
      return fieldA;
   }

   //ETC.
}
</code>```

The point is that I use getters/setters like above. Now, I have a coding assignment to do for a job interview, and using C# I have stumbled across automatic properties. I was initially slightly confused about it but understand what it does now and have used it.

So for fields I would write

```<code>public string fieldA {get; set;}
</code>```

It feels weird declaring fields public like that and doesn't it violate some OOP encapsulation principles ?

My question is, should I just go ahead and use automatic properties to show interviewers that I know what it is? In case I want to prevent setting a field I could just use:

```<code>public string fieldA {get; private set;}
</code>```

But would it appear like I don't follow encapsulation "rules", I obviously wouldn't want to risk that. I could write it out as I do in Java.

In general what is your view on using automatic properties ?

Body:
At a first glance, these two lines may look the same:

public string A;
public string B {get; set;}

but they're not the same at all. As you'll know, if you use a public field and in the future you need to add some logic when getting or setting the value, you can't (unless you break the interface that you're providing to others). You can't, because the value isn't encapsulated.

With an automatic property, instead, you can add more logic whenever you want, without the need to change the interface that your class provides. Just replace the automatic property with a standard one. Or, vice-versa, you can replace the standard property with an automatic one. To an external user, nothing changes.

So no, you're not even remotely breaking encapsulation. You're just using an handy syntactic sugar.


答:
You seem to be motivated largely by respect for the authority of the rubocop tool and the Ruby Style Guide, which the maintainers may not share.  They already have their own style, and are used to it, so any change would affect everyone working on the project, and that's a lot of work, especially if the project is large.

Consider the motivations of the maintainers.  They (probably) want new people to join them by submitting bugfixes, bug reports, working code, and well-written documentation.  If you show up and say "You have offences in rubocop" they aren't going to think "Oh good, someone new to help share the load", they're going to think "Who is this guy?  Why is he telling us what to do?".

Open source projects tend to be meritocracies: you get respect based on the quality of your work.  If you show up and do great things and then bring up your style concerns, they are more likely to listen, although they still might say no.  There is a open source saying "Talk is cheap, show me the code".


问:
Naming of type parameters in java
We all know that it is good to use descriptive identifier names. However, the convention in java is to use a single letter for a type parameter identifier. The default most people go to is T, but if you are dealing with elements in a collection, you often see E. Now I can see how it makes sense to use single letter identifiers for unbounded type parameters, since they can really be anything, so you have no information to be represented by the identifier.

But suppose you had two bounded type parameters, say T extends Iterable<Integer> and S extends Consumer<Integer>, wouldn't it make more sense to use more descriptive identifiers than T or S so you don't confuse them? You might be able to get away with using, say, I and C, but people would never (in my ideal world) be so terse with variable identifiers. So why are people so terse with type parameter identifiers? Or is the convention of single character type parameter identifiers not as pervasive as I imagine?

答:
There is some merit to single-letter type parameters

They're short which is fortunate as type params crop up in many places when writing generic code.

They are effectively in a different namespace from actual classes.

Of course, my first point is moot as Java doesn't care much about conciseness. But the second point avoids a real problem. Consider this piece of code:

```<code>Entry<Key, Value> e = new Entry<>(...);
</code>```

I would start searching for the interfaces or classes Entry, Key, and Value which would lead nowhere as a few hundred lines before, all of these have been declared as type parameters. But no Java programmer would ever expected E<K, V> to refer to actual classes.

If we do not want to use the single-uppercase-letter naming convention, then we either have to surrender the discernability of actual types and type parameters, or we can switch to another convention e.g. using Hungarian Notation. Then, IFoo, CFoo, and PFoo would clearly refer to different kinds of types.

This is not a usable solution as the builtin Java types do not follow such a convention. For the sake of uniformity it is probably better to stick with a suboptimal but widespread solution rather than inventing your own.

The importance of naming type parameters can also be overemphasized, and it is quite possible to understand their meaning given some context, and sufficient documentation.

Title: Naming of type parameters in java

Body:
There is some merit to single-letter type parameters

They're short which is fortunate as type params crop up in many places when writing generic code.

They are effectively in a different namespace from actual classes.

Of course, my first point is moot as Java doesn't care much about conciseness. But the second point avoids a real problem. Consider this piece of code:

Entry<Key, Value> e = new Entry<>(...);

I would start searching for the interfaces or classes Entry, Key, and Value which would lead nowhere as a few hundred lines before, all of these have been declared as type parameters. But no Java programmer would ever expected E<K, V> to refer to actual classes.

If we do not want to use the single-uppercase-letter naming convention, then we either have to surrender the discernability of actual types and type parameters, or we can switch to another convention e.g. using Hungarian Notation. Then, IFoo, CFoo, and PFoo would clearly refer to different kinds of types.

This is not a usable solution as the builtin Java types do not follow such a convention. For the sake of uniformity it is probably better to stick with a suboptimal but widespread solution rather than inventing your own.

The importance of naming type parameters can also be overemphasized, and it is quite possible to understand their meaning given some context, and sufficient documentation.


问:
Why should passwords be encrypted if they are being stored in a secure database?
I have a web service. Right now, I have passwords stored in plain text in a MySQL table on my server. I know this isn't the best practice, and that is why I am working on it.

Why should passwords be encrypted if they are being stored in a secure database? I realize that if someone hacks in to my database they will get everyone's password. But I have other problems if someone gets in my database, for example, deleting data.

The scenario I can think of is that you are hacked. You restore a database from a couple of hours ago and everything is well. However, if your passwords are plaintext... The thief has all the passwords and you have to reset them all. Hassle to your users.

If the passwords were encrypted, you could just restore to previous database. Is this correct thinking?

答:
Well, it's surprising no one has mentioned this, yet, but what about PHYSICAL security of your database?

You may have the best IT security in the world set up, but that doesn't stop anyone who can gain physical access to your storage media.  What happens when your team wins the Superbowl this afternoon, and a small riot erupts in your city's downtown area where your office / hosting provider is?  (Given that it's Seattle vs. Denver, two large IT areas in the US, I don't think that's unreasonable).  The mob smashes in to your building and while the authorities are overwhelmed, someone grabs some of your hardware with a DB on it that contains clear-text passwords?

What happens when the Feds show up and seize your equipment because some high-level exec was using his position in the company to execute illegal stock trades?  Then the Feds use those passwords to investigate your customers, although they did nothing wrong. Then they realize it was YOU that left them vulnerable.

What happens when your IT department forgets to wipe the old RAID drives that held your DB when they do scheduled replacements before "handing out" the old drives to interns, and then their dorm roommates find what was left behind, and figure out they can "sell" it and never have it traced back to them?

What happens when your DB Server blows a motherboard, IT restores an image to your new server, and the "carcass" of the old server gets thrown in the recycling heap?  Those drives are still good, and that data is still there.

Any decent architect knows that security isn't something you "bolt on" later with firewalls and operations policies.  Security has to be a fundamental part of the design from the very beginning, and that means passwords are one-way hashed, NEVER transmitted with out encryption (even inside your own datacenters), and never recoverable.  Anything that can be retrieved can be compromised.


问:
When to store Date/DateTime?
I'm working on a social network website and I'm not quite sure when I should store the date/datetime. The service includes some of the following events:

Register/Login

Follow

"Like" (images & comments)

Post a comment

Post an image

In my eyes, I would use DateTime for all of them... Although I'm not sure if that's professional or maybe it's just a waste of space.

When should I store the time of an event? Thanks in advance.

答:
For all the things that you have mentioned I would store a date/time because they are things that actually took place at a certain time and you can easily capture that time automatically.

Capturing the time allows you more flexibility than just capturing a date does. For instance, you could show the user the Time for things which happened in the last 0-48 hours as well as adjust the time for their local timezone. For things that happened a longer time ago you could then choose to show them the date even though you are storing the entire time. For things like login, I would probably never show the user the Time they registered, but there's no compelling reason not to have that piece of data.

I tend to store Dates for things which time is not necessary and/or users have to enter manually because entering times manually takes longer and half the time you will have guesses anyway.

Title: When to store Date/DateTime?


问:
Benefits of a leaderless team in Scrum
Scrum advocates assume that a team without a designated team leader (as it is in Scrum) is more effective than a team with a designated leader (as in traditional hierarchy). Although I can understand this point of view, I am not entirely certain that's the case.

In Scrum teams leaders always emerge. Power vacuums get filled. So if the organization already recognizes certain people as talented leaders, why not assign them an official leadership role in the first place?

答:
I think you might be conflating "leader" with "hierarchy."  They're not the same thing.  In traditional hierarchical organizations, I would argue that you don't have scrum, or at least, not an effective organization to do scrum-like things (unless the organization also has "working teams").

I also think you're having it both ways in terms of a "designated leader." By your own admission, leaders can emerge.  That's not a designated leader, it's a defacto leader.

Regardless, I think you can choose a leader in a scrum team without necessarily characterizing that team as "hierarchical."  And if you don't have a leader so chosen, there's always some leadership somewhere.  Were that not the case, there would be no need for software requirements.

Title: Benefits of a leaderless team in Scrum


问:
What is wrong with Java's generics?
I have seen several times on this site posts that decry Java's implementation of generics. Now, I can honestly say that I have not had any issues with using them. However, I have not attempted to make a generic class myself. So, what are your issues with Java's generic support?</p>

答: Java's generic implementation uses type erasure. This means that your strongly typed generic collections are actually of type Object at runtime. This has some performance considerations as it means primitive types must be boxed when added to a generic collection. Of course the benefits of compile time type correctness outweigh the general silliness of type erasure and obsessive focus on backwards compatibility.

Title: What is wrong with Java's generics?


答:
I would not necessarily store a Datetime for all of those. However in most cases it seems to be a good idea. Here's my logic:

Register/Login: It's a no-brainer to store it, here. Just think of support-tickets concerning hacked accounts or the case when you block someones account? You'll want to be able to tell a customer when it happened.

Following, Likes: To me there is no good reason that would make it necessary to store this. These fields are personal interest based and unless you're planning statistics on these fields that take time into account, you can let it go, here. I would go as far as saying that these are just metainformation. Follows being metainformation for an account and likes metainformation for a post.

Posting Comments/Images however are real information. The perspective the user has towards this information will change over time. No user comments a "It's my birthday, today" post half a year later wishing them a nice birthday. While after this long a timespan the exact time of the most might not matter anymore for this post, might, for other posts. So logically storing a Datetime seems important to me, here.

Title: When to store Date/DateTime?

Body:
I'm working on a social network website and I'm not quite sure when I should store the date/datetime. The service includes some of the following events:

Register/Login

Follow

"Like" (images & comments)

Post a comment

Post an image

In my eyes, I would use DateTime for all of them... Although I'm not sure if that's professional or maybe it's just a waste of space.

When should I store the time of an event? Thanks in advance.


答:
Pragmatism over Dogma, always. Coding style guides are an especially insidious form of evil that draw attention away from architectural concerns towards frivolous nonsense like single/double quoting. Ask yourself: Does it really make a difference?

They can be good up to a point, but the second you treat them with an almost religious fervor, you've gone too far. They're guidelines, suggestions, opinions, NOT facts.

Should they just be ignored then? No, there is merit to using the tools to get a general idea of what needs to be looked at, but no more.

It's a wonder how often junior types confuse opinion for fact.


问:
How can I convince my client that the task was complex and the time I took is fair?
I am the single programmer working on a website handling both frontend and backend. Recently in my task list I have to provide a social news feed (activities among friends) which should summarize activities from different modules (at least 7 modules). It has taken at least 20-25 days for me to develop that. Remember in news feed every action can be performed right on the news feed + there must be some kind of aggregation which should aggregate similar activities e.g. User A, B and C liked your item.

How can I convince my client that the task was complex and the time I took is fair?

答:
TL;DR: Establish a rapport.  Do regular status updates and offer options that save money, or meet their needs better.

So accurate estimation is good.  What's even better is timely communication as soon as you know that your estimation is off, as well as regular status updates on progress including challenges.  You should also strive to make these updates a 2 way conversation.  Explain when things start taking a long time, offer options that may takes less time.  Feel free to offer options that take more time as well, but may provide the value the customer if really looking for.


答:
In Scrum there is no designated leader in a management-hierarchical sense within the team. That means, there is no single person telling you to do Task X and to do it in Time Y. These things are decided upon by the team as a group. This way every developer is responsible, himself for his work. He estimated the time it will take, himself, he is responsible for completion, himself. Of course that also means that he takes the blame, himself if things go wrong.

In tradition models that would not be the case. There would be a team, with a designated leader who is responsible for every aspect of decision making. He would tell developers to do tasks, and he would tell them how to do it and within what time. However he would also be the one who takes the blame for everyone on the team.

This does not mean, however that teams can't have leaders in Scrum. You still need somebody with merging privileges and who has an overview of the whole project. Basically somebody who has the last say about architectural changes that could possibly affect the big picture and so on. That guy usually is the team lead. Very often, officially so.

In fact I've never worked in a Scrum environment where there was no official Team Lead. Looking at it from a pragmatic point of view, I'd actually have some issues with working in such an environment: My Team Lead is the guy who merges, he's the go-to guy for architectural problems. If there is to be an API change, we discuss things and he makes the decision.

Without a team lead, what if there's two guys not agreeing. Who is right?

If there are meetings concerning future developments or pretty much anything, he's the one who goes, keeping my back free to do my actual work. If decisions that were made in such a meeting seem strange, or not good, there's still Daily/Retro/Task Planning where you can raise your concerns.

If there is no Team Lead, then who is going?

Title: Benefits of a leaderless team in Scrum

Body:
Scrum advocates assume that a team without a designated team leader (as it is in Scrum) is more effective than a team with a designated leader (as in traditional hierarchy). Although I can understand this point of view, I am not entirely certain that's the case.

In Scrum teams leaders always emerge. Power vacuums get filled. So if the organization already recognizes certain people as talented leaders, why not assign them an official leadership role in the first place?


问:
Why is it a good idea for "lower" application layers not to be aware of "higher" ones?
In a typical (well-designed) MVC web app, the database is not aware of the model code, the model code is not aware of the controller code, and the controller code is not aware of the view code. (I imagine you could even start as far down as the hardware, or perhaps even further, and the pattern might be the same.)

Going the other direction, you can go just one layer down. The view can be aware of the controller but not the model; the controller can be aware of the model but not the database; the model can be aware of the database but not the OS. (Anything deeper is probably irrelevant.)

I can intuitively grasp why this is a good idea but I can't articulate it. Why is this unidirectional style of layering a good idea?

答:
Another reason I would like to see explicitly mentioned here is code reusability. We've already had the example of the RS232 media that gets replaced, so lets go one step further...

Imagine you're developing drivers. Its your job and you write quite a bunch. Protocols might probably start repeating at some point, as might physical media.

So what you'll start doing - unless you're a great fan of doing the same thing over and over again - is to write reusable layers for these things.

Say you have to write 5 drivers for Modbus devices. One of them uses Modbus TCP, two use Modbus on RS485 and the rest go over RS232. You're not going to reimplement Modbus 5 times, because you're writing 5 drivers. Also you're not going to reimplement Modbus 3 times, because you have 3 different Physical layers below you.

What you do is, you write a TCP Media Access, an RS485 Media Access and Possibly an RS232 Media Access. Is it smart to know that there's going to be a modbus layer above, at this point? Probably not. Next driver you're going to implement might also use Ethernet but use HTTP-REST. It would be a shame if you had to reimplement the Ethernet Media Access in order to communicate via HTTP.

One layer above, you're going to implement Modbus just once. That Modbus layer once again, will not know of the drivers, that are one layer up. These drivers, of course will have to know that they're supposed to talk modbus, and they're supposed to know that they're use Ethernet. Howevever implemented the way I just described it, you could not only just rip out a layer and replace it. you could of course - and that to me is the biggest benefit of all, go ahead and reuse that existing Ethernet layer for something absolutely unrelated to the project that originally caused its creation.

This is something, we probably see every day as developers and that saves us tons of time. There are countless Libraries for all sorts of protocols and other things. These exist because of principles like the dependency direction following the command direction, which allows us to build reusable layers of software.


答: Isnt that exactly the same thing as 2 points?  How is this awkward... most drawing routines require points, not separate x/y components.</p>

Title: What's the idea behind defining rectangles with two points?

Body:
It's not that this doesn't make sense, but it just works out awkward 99% of the time.

Often in 2D graphics rectangles are initialized, stored and manipulated as a pair of points.  In no particular language,

```<code>class Rect:
   p1, p2: point
</code>```

It makes more sense to define a rectangle as two x values and two y values, like this:

```<code>class Rect
   xleft, xright: int
   ytop, ybottom: int
</code>```

With two points, if at some place in the source code you want to make use of the y value of the top, you'd have to say rect.p1.y  (hmmm, stop and think, is it p1 or p2) but with the four values as plain data members, it's clear and direct:  rect.ytop (no thinking required!)     The use of two points means that in dealing with the vertical, you have to tangle the horizontal; there's an extraneous relation between indepenent elements.

How did this two-point idea come about and why does it persists?  Does it have some benefit over bare x and y coordinates?

ADDED NOTE: This question is in the context of X-Y aligned rectangles, such as in windows managers and GUI toolkits, not in the context of arbitrary shapes in drawing and painting app.


答:
I know that XAML based technology (WPF, Windows Phone) won't accept public fields like

```<code>public string a;
</code>```

... for data-binding in XAML.

You must instead use public properties like:

```<code>public string a { get; set; }
</code>```

Even though they look like the same. So yes, it does make difference.

Title: Should I use automatic properties?

Body:
I know that XAML based technology (WPF, Windows Phone) won't accept public fields like

public string a;

... for data-binding in XAML.

You must instead use public properties like:

public string a { get; set; }

Even though they look like the same. So yes, it does make difference.


答:
You are recording the moment in time when some user action occurred.  This is commonly called a timestamp.  Unfortunately, storing timestamps in databases is more complicated than most people realize, and the correct solution depends on the particular database implementation you are using.

You want to record the moment an event occurred, in this case some user action. There are two common ways to represent a moment in time: as a local time together with a timezone offset from Greenwich Mean Time, or as a number of seconds (or milliseconds or nanoseconds) since some moment in the past (start of epoch).  Unfortunately, no generally support SQL type does either of these.  The DATE and DATETIME types do not record a timezone, and few databases have any type that is represented as "time since start of epoch". The SQL standard defines a type 'TIMESTAMP WITH TIMEZONE' but it is few popular databases support it.

Most developers compromise by using DATETIME with some implied timezone.  If you do this, you will have to be careful to record all times in the same timezone.  The only one that makes sense is to record all times in GMT.  Set the default server timezone to GMT and set the database timezone to GMT if applicable.  You must be very careful to correctly convert application data types to the proper timezone before recording them in the database.

Alternatively, you can record timestamps as a numeric offset since some point in the past.  The Unix system and it's derivatives, and the Java runtime represent time as seconds since 1970-01-01 00:00 GMT.  If you do this you may want to define views that convert these to some readable representation.

Title: When to store Date/DateTime?


问:
In Scrum, who verifies "Done"?
I am a QA/Test manager in my organization and until today I verified the quality of the software (tests written and executed and bugs fixed). Who will verify this in Scrum? How do I know that the team wrote and executed all the right tests? On the other hand I'm afraid that if I continue to do the verification the team will not feel empowered enough. But I need some verification process that "Done" is indeed "Done". What do you suggest?</p>

答:
First Question you should ask yourself

Are you the Scrum Master?
if yes.

In scrum processes are controlled and managed by the Scrum Master.

How do you do it:

In the requirement phase you can use the user stories for each there is a test that needs to be verified.

In each Sprint The work items are pulled from the product backlog and directed by the product owner.each of them will have verification criteria as well.

Now in Scrum requirements dont change after the sprint has started .At the end of the Sprint you can analyze the verification according to the criteria for each item done.

If its done can only be found by the response of the Product owner.

Remember in Agile you "Embrace the change" even late into the development phase

Title: In Scrum, who verifies "Done"?


问:
Decouple GUI & Program logic
I have some windows c++ code (pure winapi c++, no MFC etc) that I would like to build a GUI for. My code does not know about windows GUI, it is completely decoupled from any type of UI.

The question: How could I build a UI around the existing code. Ideally, I am imagining something like this:

GUI <--> Mediator <--> MyExistingCode

For example,

MyExistingCode.showmsg(char* msg) would call Mediator.MessageBox(0, 0, msg, 0);

I'm stuck at how to design the Mediator class (If that is the correct way of going about this). Is the Mediator an Interface?, Abstract Class?, Other? Is an MVC model the best way to go?

答: Start with one of the MVC, MVP or MVVM patterns. All of these are proven and have their own advantages and disadvantages. There's plenty of literature out there and even here on SO/SE.</p>

Title: Decouple GUI & Program logic