问:
What is the difference between 'layer of abstraction' and 'level of indirection'?
I am not sure if both terms can be used interchangeably. Maybe there is some academic distinction in computer science which is not relevant for day-to-day programming? Or can I use both term interchangeably without being wrong? Maybe it depends on the context in which I use both terms?

Edit: On reason why I find both terms possibly interchangeable is a Wikipedia entry about Abstraction layer. There you can find David Wheelers quote 'All problems in computer science can be solved by another level of indirection.'

答:
Layer of Abstraction and Level of Indirection are distinct concepts. Abstraction is the aggregation and meaningful naming of a number of elements such as pieces of data or program instructions, for instance the concept of a file or method call, whereas indirection is the decoupling of entities to facilitate the postponement of the realisation of their relationship, for example, the use of JNDI to separate the identification of a resource within a program from the actual resource which may eventually be provided by an application container.

Frequently the concepts go hand in hand and which one applies to a particular construct depends on what exercise or discussion is in progress.  For instance, the abstract nature of an interface is important when learning or documenting an API; its property of indirection is important when adding extensibility to or creating tests for an application.

A layer of abstraction is the aggregation of abstractions and giving them a conceptual integrity and consistency of usage.  CreateProcess is the win32 API name for a bunch of code that builds and executes a process.  The "name" is significant to this context because if we called the function something like DoAllocMemThenMakeEnvThenFindEntryPoint... it really would not be very abstract.  A layer such as the Win32 API provides a barrier across which a programmer may be advised not to venture.  It removes complexity from the caller's viewpoint at the cost of reduced power (flexibility, performance etc).  This trade-off is highlighted by frequent discussion of leaky abstractions: we may still need to make direct SQL calls when using Hibernate or make Win32 calls when using .NET.

Regarding indirection, most non-trivial programs operate with some form of user coded indirection, witness COBOL's INPUT-OUTPUT section from before the ark.  When accessing a resource such as a database we may see the embedding of a JDBC connection string in the code as Level 0 indirection, a JNDI connection (which delegates the choice of resource to an application container) as Level 1 and some Spring construct that maps the application JNDI identifier to one of many container resources as Level 2.  Multiple levels allow a number of parties external to the relationship (in this case a relationship between executing code and a database) to manipulate that relationship.  This applies equally to internal program components such as interfaces and events.

We see that, no matter what their other qualities, abstraction reduces complexity whereas indirection increases it.  Abstraction reduces power whereas indirection increases it.  Indirection can be used to restore the power of abstraction by allowing default behaviour to be overridden by custom callbacks.


问:
Is the agile approach too much of a convenient excuse for cowboys
I believe that an agile approach is best for projects where the requirements are fuzzy and a lot of interaction is required to help shape the end user's ideas.

However... In my professional work, I keep ending up at companies where an "agile" approach is used as an excuse as to why no effort was put into an up front design; when the requirements are well understood.

I can't help but thinking that if the agile approach wasn't around, I'd be sitting here with a nice high-level specification and not having to revisit the same screen and functionality every second day when something else crops up or so and so hadn't thought of that.

Are the benefits of agile methodologies really enough to outweigh the excuse for being lame it gives to cowboy technical leads?

Update: Ironically I'm now a certified Scrum Master. One of the papers presented on the Scrum course observed that the best development process was one where there was a single expert or guru making the design decisions, however that has obvious weaknesses. Scrum shifts the responsibility for producing quality software to the "Team" which means a sub-standard team can get away with churning out spaghetti which I guess is no different to other Agile and non-Agile development processes.

答: I will not say that I am a fan of Waterfall, since I too deal with ever-frustrating scope-creep, but I have always seen Agile as a concession to the problem, not an effective way to combat it. A good design, with early iterative testing and lots of paper prototypes seems to be much more effective.</p>

ContentLicense: CC BY-SA 3.0

ContentLicense: CC BY-SA 2.5


问:
Why is the formal definition of Big O notation formulated as such?
Consider the formal definition:

f(n) = O(g(n))

Why is it not:

f(n) = O(f(n))

or

f(n) = O(c*f(n))

since for the Big O analysis, f(n)=2n and g(n)=n are identical?

I am confused by the function f(n) using another function.

Update

Why isn' t the definition as follows:

f(n) <= c*abs(g(n))

What does the formal O(g(x)) add to the definition? It seems like it overcomplicates things.

答:
The Big-Oh notation is used to relate two functions, f and g. Therefore, there must be two functions in the definition.

When we write

```<code>f(n)=O(g(n))
</code>```

we do not define the function f (that is already known) and the = doesn't mean "equals". You may read the notation either as "f(n) is (in some sense) less-than-or-equal than g(n)" or, if you like sets, as "f(n) belongs to the set O(g(n))".

That said:

```<code>f(n) = O(f(n))
f(n) = O(n*f(n))
</code>```

are both always true.

Body:
The Big-Oh notation is used to relate two functions, f and g. Therefore, there must be two functions in the definition.

When we write

f(n)=O(g(n))

we do not define the function f (that is already known) and the = doesn't mean "equals". You may read the notation either as "f(n) is (in some sense) less-than-or-equal than g(n)" or, if you like sets, as "f(n) belongs to the set O(g(n))".

That said:

f(n) = O(f(n))
f(n) = O(n*f(n))

are both always true.


答:
I am confused on defining the function f(n) using another function

Don't be confused, it's actually pretty simple. The big O notation is an inequation. That means that we can find multiple upper bounds for f(n) and still be correct, hence, although we can write f(n) = O(f(n)) and be correct it's, depending on f(n), often not what we are intending to express.

It's a measure of growth rates. f(n) = 2n does not grow faster than f(n) = n. Both growths are linear.

f(n) = O(n*f(n))

I'll assume you meant the second n to be a constant c.

By definition of Big O, this constant is already in the inequation. So when you write the usual f(n) equals Big O(g(n)) you're actually writing abs(f(n)) <= c * abs(g(n)). If you can find a constant factor you needn't mention it, because the definition of Big O, the inequation, already takes care of that and g(n) is then considered an upper bound of f(n).

Maybe the common wording can help you: f(n) = O(g(n)) means the function f does not grow faster than g, except maybe for a constant factor c.

Title: Why is the formal definition of Big O notation formulated as such?

Body:
Consider the formal definition:

f(n) = O(g(n))

Why is it not:

f(n) = O(f(n))

or

f(n) = O(c*f(n))

since for the Big O analysis, f(n)=2n and g(n)=n are identical?

I am confused by the function f(n) using another function.

Update

Why isn' t the definition as follows:

f(n) <= c*abs(g(n))

What does the formal O(g(x)) add to the definition? It seems like it overcomplicates things.


答:
Wikipedia has a formal definition of the big O notation. That is:

```<code>f(x) = O(g(x))
</code>```

if and only if there exists a positive real number M and a real number x0 such that

```<code>|f(x)| <= M * |g(x)|  for all x > x0
</code>```

Body:
Wikipedia has a formal definition of the big O notation. That is:

f(x) = O(g(x))

if and only if there exists a positive real number M and a real number x0 such that

|f(x)| <= M * |g(x)|  for all x > x0


问:
How can I compensate for having gone to a JavaSchool?
In an earlier question, I asked for career advice for new software engineers who did well before and during college.  But what about people who weren't fortunate enough to go to MIT or Yale, for whatever reason?  What if you went to what Joel Spolsky calls a JavaSchool?

What can/should JavaSchool alumni do to develop their skills and make up for the things they missed in college?  (Or, was Joel wrong about those schools being disadvantageous?)

答:
Best thing I can think of is to go and (re)learn programming in a completely different paradigm, in order to break free of the object-oriented way of thinking.

I'd suggest at a minimum:

Assembly language, to get a real appreciation for how the machine works

Haskell, for a very pure view on functional programming

Lisp, for impure functional programming and metaprogramming (Clojure would be my first choice, but Scheme or Common Lisp are also great)


问:
Should you write good documentation and clean code to increase the "Bus Factor"?
One of the main goals of software development companies is to increase their Bus factor This is also advocated in a talk that was organized by Google.

That means that you should code and document everything in a way that if you're run over by bus tomorrow, the project can still continue. In other words, you should make yourself easily replaceable by another programmer with a similar skill set to yours.

Being replacable, isn't that against the interest of a developer? In the book, 48 laws of power Rule 11 states that you should try to keep people dependent on you, in order to gain power, which then translates into monetary rewards.

Apart from the scenario, where you need some documentation for yourself in order to continue a project after 6 months of pause, there seems to be a clear conflict of interest here between the developer and the software company.

So as a programmer, should you really write excellent documentation and easily readable code for everyone; or should you write code and documentation in a way that it does the job and you yourself can understand it, but another person may have trouble understanding it?

答:
I'll address this question from a different perspective, since there are already several excellent answers.

Consider what happens when you play petty games by trying to make yourself "irreplaceable" though preventing other people from learning how your code works. You stay in the same job maintaining your very own messes for as long as the company tolerates you. And that's the best case scenario, the worst case scenario is that other, more talented and more ethical engineers and managers in your company see the hindrance your poor practices imposes on the company and they decide to do something about it: by firing you and rewriting everything from scratch. It's been done. In fact, it's a fairly common thing to happen.

Now consider what happens when you write good code and good documentation. You create a component or a system that works well, that after a while in operation working out the bugs works smoothly and hardly needs to be looked at. It takes little effort to maintain it. You can then move on to bigger and better projects, with a solid victory under your belt. People will recognize you for having done good work and will start to respect your opinion. You'll have the ability to move up in the foodchain and make more meaningful decisions, or do more important and impactfull work, or manage projects at a higher level. Your career will improve, you'll get promoted, you'll make more money, you'll gain recognition and approval by your peers, you'll add more and more successes of more and more important projects to your track record.

Which route would you prefer?


答:
See the formal definition of Big oh states f(n)=O(g(n))  means there are positive constants c and k such that 0<=f(n)<=cg(n) where n>=k.

It means value of f(n) for any n>=k is less than or equal to value of g(n) multiplied by some constant. Its covering both cases.

What we want to say by this definition is that there exists some function g(n) which is always greater than or equal to f(n) for any particular n. We know then that f(n) has some particular limit which it cannot cross which is essential need of Big Oh notation as it tells us that some particular program cannot take more time than its Big oh notation.

As jpalecek said, f(n)=O(g(n)) notation is like sets meaning f(n) belongs to set O(g(n)). There can be more functions which belong to the set O(g(n)). Thats why we require two functions for Big Oh analysis.


问:
How do I evaluate if writing a book, article, or presenting at conference is worth it?
I'm trying to understand how I should evaluate writing a book, article, or conference presentation.

Writing a book is a lot of work. Same for writing an article in a magazine or presenting in a conference. They need time and you may even make a mistake here and there that back fires (bad reviews, people calling you an idiot..) Also you do it for free (at least for magazine articles and conference presentations. For books you get something like a $5K deposit and you rarely get any additional sales royalties after that).

So how should I evaluate the benefits? I would appreciate answers that call out if you have done this before. I may not write a book because it's way beyond what I'd like to commit time-wise, but should I bother giving conference presentations or writing shorter articles in magazines?

答:
I suggest that you do not write a book, because nowhere in your posting do I see anything even close to saying "I really want to write a book", nor is there anything like "I'm excited about topic X and I'd like to tell people about it".  Those are the two reasons to write a book.

Writing a book is a labor of love.  I spent three years working on my book about job hunting, and I wrote it because I felt strongly that it was information that techies needed to hear.  I sure didn't do it for the money.  Sure, I cashed my sixth quarterly royalty check the other day, and it's gratifying to get that, but that's not what gets you through the process.

If you do feel like writing a book is seriously something that you'd be interested in, I suggest you practice to see if it's for you.  Go and start a blog on whatever topic it is that you'd like to write a book about.  Say you want to write a book about Ruby.  Go start a blog on blogspot.com or wordpress.com and write blog articles about Ruby.  Write at least three long articles every week, without fail.  Is that fun?  Then maybe you can write a book.  (And besides, you're going to need a blog to support your book and build interest in it, so you might as well start now.)

I see from your posting history that you asked the other day about presenting at conferences, and I told you about some of the process.  I'm getting the feeling that you're at a point where you're flailing around in your career.  Am I right in thinking that you feel like something's missing in your career, and you don't know what it is?  If that's the situation you're faced with, definitely do not go to write a book.  You write a book or give presentations because you have information that you need to get out.


答:
The answer to your question is "yes". Yes you should write good documentation and clean code. Deliberately doing otherwise displays a lack of integrity, which, while increasingly prevalent in the business world isn't somehow suddenly a "good" thing. </p>

<p>No one is irreplaceable. People who manufacture a situation whereby they think they are tend to find out the hard way that they are not. Manufacturing a co-dependency for yourself is counterproductive as it also limits you, not just your employer. </p>

Title: Should you write good documentation and clean code to increase the "Bus Factor"?

Body:
One of the main goals of software development companies is to increase their Bus factor This is also advocated in a talk that was organized by Google.

That means that you should code and document everything in a way that if you're run over by bus tomorrow, the project can still continue. In other words, you should make yourself easily replaceable by another programmer with a similar skill set to yours.

Being replacable, isn't that against the interest of a developer? In the book, 48 laws of power Rule 11 states that you should try to keep people dependent on you, in order to gain power, which then translates into monetary rewards.

Apart from the scenario, where you need some documentation for yourself in order to continue a project after 6 months of pause, there seems to be a clear conflict of interest here between the developer and the software company.

So as a programmer, should you really write excellent documentation and easily readable code for everyone; or should you write code and documentation in a way that it does the job and you yourself can understand it, but another person may have trouble understanding it?

Body:
The answer to your question is "yes". Yes you should write good documentation and clean code. Deliberately doing otherwise displays a lack of integrity, which, while increasingly prevalent in the business world isn't somehow suddenly a "good" thing.

No one is irreplaceable. People who manufacture a situation whereby they think they are tend to find out the hard way that they are not. Manufacturing a co-dependency for yourself is counterproductive as it also limits you, not just your employer.


问:
What are the deciding factors in choosing to expose a web service as a SOAP or REST service?
As far as I can see consuming SOAP requires a SOAP stack, so it is harder for your clients to consume i.e. they need to ensure that they have a SOAP stack in place that formats the POST data and the headers correctly and then gives you back some data structure, whereas with REST you just make an HTTP GET request with the arguments in the query string and get back some text that I guess is probably XML.

So what does the extra overhead / complexity of SOAP give you, when do you need it and when could you and should you do without it?

答:
REST uses post as well. In-fact when using REST the http verbs tell you what operation is going on.

REST and SOAP are just different standards of passing data over the internet.

Having used both I would generally recommend using REST rather than SOAP unless you know the people who are going to consume your web service are using .net and Visual Studio. Its generally much easier to consume a REST web service except with .net VS which does most of the work for you when your using SOAP.


问:
Is Object Oriented Programming a solution to complexity?
Do you think Object Oriented Programming is a solution to complexity. Why? This topic may be a bit controversial but my intentions to know the answer of Why from the experts here !</p>

答:
Object Orientation (as conventionally used) is a useful tool in many circumstances, but it isn't a sufficient solution to complexity.

In particular, it often adds a lot of "incidental complexity". Examples are the complexity surrounding implementation inheritance, the need to provide lots of "standard functionality" suach as equals() and hashCode() etc. A nice presentation by Stuart Halloway on this topic: "Simplicity Ain't Easy"

Objects in most languages also tend to encapsulate a lot of mutable state - which in a concurrent world is increasingly starting to look like a poor design decision. Again an interesting video by Rich Hickey looks at the distinction between object identity and state, and how it might be a mistake to conflate the two.


问:
Reason behind multi-line declaration style?
I'm a little curious about the reason behind the Windows header file declaration styles.

When I read them, I see multi-line declarations such as the following:

```<code>WINBASEAPI
HANDLE
WINAPI
GetStdHandle(
    IN DWORD nStdHandle
    );
</code>```

What is the primary reason why they're not written as something like:

```<code>WINBASEAPI HANDLE WINAPI GetStdHandle(IN DWORD nStdHandle);
</code>```

i.e. in a single line?

答:
Personally I prefer reading the multiline declarations, no matter the language.

For example, I'm working with a partner on an AI project and we're writing in C.  He does alot of his code like your first example, and rarely uses empty newlines to separate loops and statement blocks.  Drives me crazy reading his code!


答:
This is an extremely weird definition and is actually new to me. The symbols, as defined by Bachmann and Landau, are not defined like that.

Unfortunately, the German wikipedia is the only source, I can find exactly this, as of now, but I suppose you can see without much translation, that  is defined as .

(Please note: the french wikipedia has the following similar definition , which I suppose basically states the same, although I think it is incorrect, given that f(n) is something completely different than f).

As I explained in response to a different question, O means "the order of", and thus O(g) is actually the set of all functions, that have the same order as g. It makes only sense to say:

f is the same order as g (or more explicitely: the order of f is the order of g), which is O(f) = O(g)

f is in the order of g, which translates to f ∈ O(g)

So for the sake of nitpicking (which is the fun part in formalization), one can say the definition you criticize is indeed wrong.


答: One thing I would mention is interoperability - if you're going to call your service from an app written in .NET and the server is written in Java (or any other combination) then go for REST. I've seen too many slight incompatibilities between SOAP implementations to bother considering it any more.</p>

Title: What are the deciding factors in choosing to expose a web service as a SOAP or REST service?

Body:
As far as I can see consuming SOAP requires a SOAP stack, so it is harder for your clients to consume i.e. they need to ensure that they have a SOAP stack in place that formats the POST data and the headers correctly and then gives you back some data structure, whereas with REST you just make an HTTP GET request with the arguments in the query string and get back some text that I guess is probably XML.

So what does the extra overhead / complexity of SOAP give you, when do you need it and when could you and should you do without it?


答:
Agile is no more to blame for poor development practices than BDUF. The problem lies with the discipline, or lack thereof, in applying the practices. The purpose of BDUF practices is to identify the direction of the project and determine risks beforehand. The purpose of agile practices is to keep the state of the development flexible enough to quickly change direction. An agile project could prepare highly-detailed user stories so the team is aware of future directions and still only select 2 or 3 per iteration to fully implement. The problem remains the same whichever methodology is used: management is letting cowboys run amuck.

[BDUF: Big Design Up Front]

Title: Is the agile approach too much of a convenient excuse for cowboys

Body:
I believe that an agile approach is best for projects where the requirements are fuzzy and a lot of interaction is required to help shape the end user's ideas.

However... In my professional work, I keep ending up at companies where an "agile" approach is used as an excuse as to why no effort was put into an up front design; when the requirements are well understood.

I can't help but thinking that if the agile approach wasn't around, I'd be sitting here with a nice high-level specification and not having to revisit the same screen and functionality every second day when something else crops up or so and so hadn't thought of that.

Are the benefits of agile methodologies really enough to outweigh the excuse for being lame it gives to cowboy technical leads?

Update: Ironically I'm now a certified Scrum Master. One of the papers presented on the Scrum course observed that the best development process was one where there was a single expert or guru making the design decisions, however that has obvious weaknesses. Scrum shifts the responsibility for producing quality software to the "Team" which means a sub-standard team can get away with churning out spaghetti which I guess is no different to other Agile and non-Agile development processes.


问:
Which is a better practice - helper methods as instance or static?
This question is subjective but I was just curious how most programmers approach this. The sample below is in pseudo-C# but this should apply to Java, C++, and other OOP languages as well.

Anyway, when writing helper methods in my classes, I tend to declare them as static and just pass the fields if the helper method needs them. For example, given the code below, I prefer to use Method Call #2.

```<code>class Foo
{
  Bar _bar;

  public void DoSomethingWithBar()
  {
    // Method Call #1.
    DoSomethingWithBarImpl();

    // Method Call #2.
    DoSomethingWithBarImpl(_bar);
  }

  private void DoSomethingWithBarImpl()
  {
    _bar.DoSomething();
  }

  private static void DoSomethingWithBarImpl(Bar bar)
  {
    bar.DoSomething();
  }
}
</code>```

My reason for doing this is that it makes it clear (to my eyes at least) that the helper method has a possible side-effect on other objects - even without reading its implementation. I find that I can quickly grok methods that use this practice and thus help me in debugging things.

Which do you prefer to do in your own code and what are your reasons for doing so?

答:
It is a well known idiom to declare methods of utility classes static, so such classes need never be instantiated. Following this idiom makes your code easier to understand, which is a good thing.

There is a serious limitation to this approach though: such methods / classes can't be easily mocked (although AFAIK at least for C# there are mocking frameworks which can achieve even this, but they aren't commonplace and at least some of them are commercial). So if a helper method has any external dependency (e.g. a DB) which makes it - thus its callers - hard to unit test, it is better to declare it non-static. This allows dependency injection, thus making the method's callers easier to unit test.

Update

Clarification: the above talks about utility classes, which contain only low level helper methods and (typically) no state. Helper methods inside stateful non-utility classes are a different issue; apologies for misinterpreting the OP.

In this case, I sense a code smell: a method of class A which operates primarily on an instance of class B may actually have a better place in class B. But if I decide to keep it where it is, I prefer option 1, as it is simpler and easier to read.


答:
If you REALLY want to be irreplaceable (which you might want to reconsider after reading all the answers...) - why stop with not documenting the code?

There's a truly brilliant guide about how to write unmaintainable code you should definitely read: http://thc.org/root/phun/unmaintain.html

Enjoy! (I most certainly did...)


答:
Which do you prefer to do in your own code

I prefer #1 (this->DoSomethingWithBarImpl();), unless of course the helper method does not need access to the instance's data/implementation static t_image OpenDefaultImage().

and what are your reasons for doing so?

public interface and private implementation and members are separate. programs would be far more difficult to read if i opted for #2. with #1, i always have the members and instance available. compared to many OO based implementations, i tend to use a lot of encapsualtion, and very few members per class. as far as side effects - i am ok with that, there is often state validation which extends the dependencies (e.g. arguments one would need to pass).

#1 is much simpler to read, maintain, and has good performance traits. of course, there will be cases where you can share an implementation:

```<code>static void ValidateImage(const t_image& image);
void validateImages() const {
    ValidateImage(this->innerImage());
    ValidateImage(this->outerImage());
}
</code>```

If #2 were a good common solution (e.g. the default) in a codebase, I would be concerned about the structure of the design: are the classes doing too much? is there not enough encapsulation or not enough reuse? is the abstraction level high enough?

lastly, #2 seems redundant if you are using OO languages where mutation is supported (e.g. a const method).

Title: Which is a better practice - helper methods as instance or static?

Body:
This question is subjective but I was just curious how most programmers approach this. The sample below is in pseudo-C# but this should apply to Java, C++, and other OOP languages as well.

Anyway, when writing helper methods in my classes, I tend to declare them as static and just pass the fields if the helper method needs them. For example, given the code below, I prefer to use Method Call #2.

```<code>class Foo
{
  Bar _bar;

  public void DoSomethingWithBar()
  {
    // Method Call #1.
    DoSomethingWithBarImpl();

    // Method Call #2.
    DoSomethingWithBarImpl(_bar);
  }

  private void DoSomethingWithBarImpl()
  {
    _bar.DoSomething();
  }

  private static void DoSomethingWithBarImpl(Bar bar)
  {
    bar.DoSomething();
  }
}
</code>```

My reason for doing this is that it makes it clear (to my eyes at least) that the helper method has a possible side-effect on other objects - even without reading its implementation. I find that I can quickly grok methods that use this practice and thus help me in debugging things.

Which do you prefer to do in your own code and what are your reasons for doing so?

Body:
Which do you prefer to do in your own code

I prefer #1 (this->DoSomethingWithBarImpl();), unless of course the helper method does not need access to the instance's data/implementation static t_image OpenDefaultImage().

and what are your reasons for doing so?

public interface and private implementation and members are separate. programs would be far more difficult to read if i opted for #2. with #1, i always have the members and instance available. compared to many OO based implementations, i tend to use a lot of encapsualtion, and very few members per class. as far as side effects - i am ok with that, there is often state validation which extends the dependencies (e.g. arguments one would need to pass).

#1 is much simpler to read, maintain, and has good performance traits. of course, there will be cases where you can share an implementation:

static void ValidateImage(const t_image& image);
void validateImages() const {
    ValidateImage(this->innerImage());
    ValidateImage(this->outerImage());
}

If #2 were a good common solution (e.g. the default) in a codebase, I would be concerned about the structure of the design: are the classes doing too much? is there not enough encapsulation or not enough reuse? is the abstraction level high enough?

lastly, #2 seems redundant if you are using OO languages where mutation is supported (e.g. a const method).


答:
This really depends. If the values your helpers operate on are primitives, then static methods are a good choice, as Péter pointed out.

If they are complex, then SOLID applies, more specifically the S, the I and the D.

Example:

```<code>class CookieJar {
      function takeCookies(count:Int):Array<Cookie> { ... }
      function countCookies():Int { ... }
      function ressuplyCookies(cookies:Array<Cookie>
      ... // lot of stuff we don't care about now
}

class CookieFan {
      function getHunger():Float;
      function eatCookies(cookies:Array<Cookie>):Smile { ... }
}

class OurHouse {
      var jake:CookieFan;
      var jane:CookieFan;
      var cookies:CookieJar;
      function makeEveryBodyAsHappyAsPossible():Void {
           //perform a lot of operations on jake, jane and the cookies
      }
      public function cookieTime():Void {
           makeEveryBodyAsHappyAsPossible();
      }
}
</code>```

This would be about your problem. You can make makeEveryBodyAsHappyAsPossible a static method, that will take in the necessary parameters. Another option is:

```<code>interface CookieDistributor {
    function distributeCookies(to:Array<CookieFan>):Array<Smile>;
}
class HappynessMaximizingDistributor implements CookieDistributor {
    var jar:CookieJar;
    function distributeCookies(to:Array<CookieFan>):Array<Smile> {
         //put the logic of makeEveryBodyAsHappyAsPossible here
    }
}
//and make a change here
class OurHouse {
      var jake:CookieFan;
      var jane:CookieFan;
      var cookies:CookieDistributor;

      public function cookieTime():Void {
           cookies.distributeCookies([jake, jane]);
      }
}
</code>```

Now OurHouse need not know about the intricacies of cookie distribution rules. It must only now an object, which implements a rule. The implementation is abstracted away into an object, who's sole responsibility is to apply the rule. This object can be tested in isolation. OurHouse can be tested with using a mere mock of the CookieDistributor. And you can easily decide to change cookie distribution rules.

However, take care that you don't overdo it. For example having a complex system of 30 classes act as the implementation of CookieDistributor, where each class merely fulfills a tiny task, doesn't really make sense. My interpretation of the SRP is that it doesn't only dictate that each class may only have one responsibility, but also that a single responsibility should be carried out by a single class.

In the case of primitives or objects you use like primitives (for example objects representing points in space, matrices or something), static helper classes make a lot of sense. If you have the choice, and it really makes sense, then you might actually consider adding a method to the class representing the data, e.g. it's sensible for a Point to have an add method. Again, don't overdo it.

So depending on your problem, there are different ways to go about it.

Body:
This really depends. If the values your helpers operate on are primitives, then static methods are a good choice, as Péter pointed out.

If they are complex, then SOLID applies, more specifically the S, the I and the D.

Example:

class CookieJar {
      function takeCookies(count:Int):Array<Cookie> { ... }
      function countCookies():Int { ... }
      function ressuplyCookies(cookies:Array<Cookie>
      ... // lot of stuff we don't care about now
}

class CookieFan {
      function getHunger():Float;
      function eatCookies(cookies:Array<Cookie>):Smile { ... }
}

class OurHouse {
      var jake:CookieFan;
      var jane:CookieFan;
      var cookies:CookieJar;
      function makeEveryBodyAsHappyAsPossible():Void {
           //perform a lot of operations on jake, jane and the cookies
      }
      public function cookieTime():Void {
           makeEveryBodyAsHappyAsPossible();
      }
}

This would be about your problem. You can make makeEveryBodyAsHappyAsPossible a static method, that will take in the necessary parameters. Another option is:

interface CookieDistributor {
    function distributeCookies(to:Array<CookieFan>):Array<Smile>;
}
class HappynessMaximizingDistributor implements CookieDistributor {
    var jar:CookieJar;
    function distributeCookies(to:Array<CookieFan>):Array<Smile> {
         //put the logic of makeEveryBodyAsHappyAsPossible here
    }
}
//and make a change here
class OurHouse {
      var jake:CookieFan;
      var jane:CookieFan;
      var cookies:CookieDistributor;

      public function cookieTime():Void {
           cookies.distributeCookies([jake, jane]);
      }
}

Now OurHouse need not know about the intricacies of cookie distribution rules. It must only now an object, which implements a rule. The implementation is abstracted away into an object, who's sole responsibility is to apply the rule. This object can be tested in isolation. OurHouse can be tested with using a mere mock of the CookieDistributor. And you can easily decide to change cookie distribution rules.

However, take care that you don't overdo it. For example having a complex system of 30 classes act as the implementation of CookieDistributor, where each class merely fulfills a tiny task, doesn't really make sense. My interpretation of the SRP is that it doesn't only dictate that each class may only have one responsibility, but also that a single responsibility should be carried out by a single class.

In the case of primitives or objects you use like primitives (for example objects representing points in space, matrices or something), static helper classes make a lot of sense. If you have the choice, and it really makes sense, then you might actually consider adding a method to the class representing the data, e.g. it's sensible for a Point to have an add method. Again, don't overdo it.

So depending on your problem, there are different ways to go about it.


答:
One of the main goals of software development companies is to increase
  their Bus factor

False premise. The main goals of a software development company (every one that I've worked at, anyway) are to produce the best software they can and to make money, not necessarily in that order. Reducing the "bus factor" is just one way to avoid losing money.

Law 11 Learn to keep people dependent on you.

What does that mean to you?

Do you want people to depend on you because you've undermined them in such a way that they can only move forward with your help? Or do you want people to depend on you because you're smart and insightful, reliable, trustworthy, and able to help others do their jobs better too? Do you want to make your colleagues look bad without your help, or do you want them to appreciate you for making them look good?

It's your call.


答: You've fundamentally misunderstood the game.  The game is not to keep doing the same old things that you've done before, being responsible for all the code you've written because no one else gets it.  The game is to complete a project and move onto the next one, leaving behind code that someone else can easily understand and work with in your absence so that you can do new things and take on more and different responsibilities.  Your premise only works if you're happy to be stuck doing the same thing over and over with no chance to learn or improve.</p>


答:
I have implemented a REST API before and I really liked it. In general when you implement REST over SOAP, your client/server is more orthogonal meaning that you can a lot more freely change the server without affecting your client(s). This orthogonality is due to using a more abstract and already well defined communication via HTTP verbs. Also, the use of hyperlinks embedded in your REST responses make it easier to extend and grow your API relatively pain free. Clients are supposed to follow these embedded links to get to new resources like a human would follow links on a webpage to 'drill down' for more information.

With that said, I had some coworkers who were told they had to use SOAP and they complained about it all the time. So I went into researching the two a bit more in detail.

In general what I found is that REST is well suited for highly distributed applications, when you have hundreds, thousands or millions of clients. One reason is the above mentioned orthogonality, another is caching that you get for free since you are using HTTP.

SOAP might be the quicker way to go when you need a smaller API for a client or two quickly and you are not too worried about scalability. It might also fit you better if you do not have an architecture that is structured around resources, because it might take you some time to restructure your app to even be able to implement REST.


答: I believe if you're using Agile development as an excuse for cowboy-style programming, then you're not really following Agile development. Cowboys will always be cowboys, no matter what process you give them.


问:
How to draw a (UML) class diagram when the classes are dispersed across a distributed system?
Basically how to denote that class foo is from a different server than class bar ? </p>

答:
A class diagram only shows the relationships between classes, along with the methods and attributes of those classes. There's no inherent method to show what physical devices a class fits on, although you might be able to use notes attached to packages and classes.

If you are modeling a distributed system, consider using a deployment diagram to show the nodes in the network along with what modules exist on each node. At a much higher level, you might also consider using component diagrams to show the high level relationships between modules.


问:
Is having trouble with data structures common for beginners?
I'm taking my second course on Java. We are getting into data structures. I have done an assignment on a linked list, and now a stack. I had a hard time with the linked list. The stack gave me a little trouble, but was much easier.

Should I be worried about having a hard time with these algorithms and data structures? I just feel like I didn't really grasp it.

答: I wouldn't say that you "should be worried" about it, but the simple fact that you acknowledge your weak points shows that you know exactly where to study harder.  I think you will be well served by that attitude and will be OK in the long run.</p>


答:
There are bound to be some areas of software development you find harder than others. Whether it's certain algorithms, or certain design patterns or certain procedures will vary from person to person. I find that I have to use something on a real program before I fully understand it.

I'd be more worried if someone claimed to know it all and had never experienced problems learning something.

Personally I never seemed to have problems with linked lists, but then I worked on a program for 8 years that used them everywhere so I was working with them on a daily basis. As long as you know where to find the information you need to refresh your memory and know the areas where you have "trouble" you should be OK.

Title: Is having trouble with data structures common for beginners?

Body:
I'm taking my second course on Java. We are getting into data structures. I have done an assignment on a linked list, and now a stack. I had a hard time with the linked list. The stack gave me a little trouble, but was much easier.

Should I be worried about having a hard time with these algorithms and data structures? I just feel like I didn't really grasp it.


答: Very good points in other answers, just one note to add: IMO linked lists may be more difficult than e.g. stacks for a lot of people because they build on indirection (expressed via references / pointers). And these underlying concepts may be hard to grasp.


问:
Objective-C Categories and Sprawling Classes
The generally accepted programming practices I've come across tend to advise against big, sprawling classes.

Does using Objective-C categories change the conventional wisdom somehow?  Is it more acceptable to have bigger classes if each "subclass" or set of tasks is in its own category?  In my own experience, I've found that where I might've in the past tried to split classes, I now sometimes find it easier and rather maintainable to just split categories, but am I setting myself up for future maintenance hell (or other kinds of hell) by doing this?

答:
The first versions of my classes where filled with sprawling methods and definitions for anything that class implemented. Maintaining it was hell. All of my methods were getting lost. They were organized by #pragma marks, but the .m file was just to big. A lot of my methods would be half commented out with new functionality I would think of adding at one point but change my mind halfway through. It was way too much mental overhead.

I rewrote the code to have a view subclass that did the basic layout and management of my subviews (some of which were also custom views.) I kept the functionality really small and started subclassing my custom view for additional functionalities. I ended up with stuff like MenuedCustomView, OverlayCustomView, GradientCustomView. This was a huge improvement.

First, I could go back to the base sub class and really refine it's respoinsibilities and make it super tightly architected. Second, testing out new functionality was easy and clean. I would make a subclass add the functionality, then change a #define symbol in my controller to, say, TestCustomView or back to GradientCustomView or whatever. This Class swapping was a tiny bit unwieldy, but certainly worked better than when I was just working in the same class definition, adding functionality, trying them, reverting them, all in the same .m file. I have subclasses that have stubs of additional functionality I would like to add in the future, I'm just not including them in my Controller class. When I feel like working no them it's super easy to add to my project.

A little bit after I started subclassing everything I learned that this maybe isn't always the best practice in Objective-C and cocoa. I switched to adding categories for a lot of additional functionality I wanted to add to a class. Of course categories only add methods and not properties, so some of the functionality I was adding was only possible in a subclass. Now, I've now got a mixture of subclasses and categories to define my objects in a mostly manageable and easy to read/maintain file/class hierarchy.

I've wondered how Apple maintains a class like NSString. Is it one large .m file? Do they have a bunch of ProtoString classes that each add separate functionality and then they inherit them into the one NSString class? Or is it a base set of functions and then a bunch of categories?

I've still got a bunch to learn on the high level architecture of a good cocoa app, just thought I'd share my progression.


答:
I think, you must not accept not understanding these things, because they are really fundamental. That being said, your not understanding them is nothing to feel bad about.
You can explain a linked list to a child. So if your teacher failed to explain them to you, it is as much their fault. So you shouldn't spend time worrying, but rather try to find people, who can explain it to you. Often a fellow student is a far better teacher than a full-time academic.

Think of Trains

Imagine, you have a set of railway carriages, where each carriage has enough capacity, to contain one piece of data. Each carriage has some sort of hook at it's end, which can be attached to another carriage's front.

This in fact gives you a linked list:

the empty list: the train containing no carriages (and therefore carrying no data)

adding an element: add a new carriage containing the element in front of the train and hook it to the rest of the train

removing an element: find the carriage containing the element. Remove it (you might need a crane here :)), hook the carriage before with the carriage after.

replacing an element: find the carriage containing the old element. Exchange the old element with the new element.

inserting an element right after another: find the carriage containing the element after which you want to insert. Insert a new carriage after it, which is hooked accordingly (we don't want the train to fall apart) and put the the new element into it.

In contrast to that, you could think of an array as a train with a given number of carriages, that cannot be rearranged in any way. All you can do is to change the data within them. This model also explains a lot of the problems arrays have:

If you want to insert one element before another, you will have to move all the following elements to the next carriage.

If you want to remove one element, you will need to move all the following elements one carriage to the front.

If you need a train with more carriages, you will have to construct a new one, because you can't just prepend a carriage.
On the other hand, finding carriages in an array is much easier, because you can simply number them permanently (their order will never change).

As for the stack: A "stack" is less a data structure, than an idea. The idea of the stack is, that it acts much like a stack of books. You can only put books on top of the stack and you can only ever take the top book off the stack (at least if the books are sufficiently heavy).

That being said, a linked list can be used as a stack, if you think of the data in the carriages as books, and the book in the first most carriage as the top of the stack.

So I hope this helped you. Maybe it didn't. Maybe you're more of a visual type. In that case, I suggest you find somebody, who's good at giving visual explanations and explain it to you. It won't take long, but it will absolutely be worth it.

It's ok to struggle with this now. But merely accepting it, is not an option in the long run.


答: f(n) = O(f(n)) is a trivial statement. It's basically x = x and you gain no information from f(n) = O(f(n)). The whole point of Big-O notation is to compare some complicated function to a much simpler one to gain better understanding of its long term behavior.</p>


问:
Do simple accessors and mutators benefit from commented block headers?
Short Question

Is it necessary to add the function header comments for simple accessors and mutators?

Example

```<code>u8   OBJ_get_state_x(void) {return obj.state_x;}
void OBJ_set_state_x(u8 x) {obj.state_x = x;}
</code>```

Addition Thoughts

The object (OBJ) overall contains very minimal logic (if any).  Its sole purpose is to maintain the state of a system.  Additional modules (such as IO, COMM, DISPLAY, etc...) all know what the object is and contain all of the business logic required to drive the states in OBJ.

I would like to keep all of the accessors / mutators on a single line to make  the file a bit more readable and just put a generic block header above all of them.  I just don't know if this is a common (or good) practice.

Note that all of the ranges are the bound by their type.  If there is a special state that has a range of 0 to 3, I create an typedef'ed enum to use as the type (thus forcing the range and making the code more readable IMO).

答:
Maybe

A comment could be useful, but someone has to write it.  Generated comments are detrimental; they take up space and programmer time but say nothing.  Your inclination to keep all the accessors to a single line is correct.  I would be tempted to eliminate them entirely by making the data members public.


答:
Data Structures was the first "hard" class I took; we used Fortran 77 instead of Java, but the concepts are largely the same.

It took me a week longer than my classmates to grok the concept of a linked list; I biffed the assignment, but after a couple of slightly frustrating sessions with my professor, it finally clicked (literally; I heard a "click" in my head when I finally understood).

Everyone has trouble somewhere in their CS curriculum (unless they're freaks).  If you understand where your weaknesses are and how to address them, you really have nothing to worry about.


答: Only if logic is performed. Its possible to have getters / setters that don't map to specific class variables, so, in this case, yes, if its just returning a class variable then no, why would this be necessary? (except for in a class teaching programming or something)</p>

Title: Do simple accessors and mutators benefit from commented block headers?

Body:
Short Question

Is it necessary to add the function header comments for simple accessors and mutators?

Example

```<code>u8   OBJ_get_state_x(void) {return obj.state_x;}
void OBJ_set_state_x(u8 x) {obj.state_x = x;}
</code>```

Addition Thoughts

The object (OBJ) overall contains very minimal logic (if any).  Its sole purpose is to maintain the state of a system.  Additional modules (such as IO, COMM, DISPLAY, etc...) all know what the object is and contain all of the business logic required to drive the states in OBJ.

I would like to keep all of the accessors / mutators on a single line to make  the file a bit more readable and just put a generic block header above all of them.  I just don't know if this is a common (or good) practice.

Note that all of the ranges are the bound by their type.  If there is a special state that has a range of 0 to 3, I create an typedef'ed enum to use as the type (thus forcing the range and making the code more readable IMO).


问:
What's a good book to help non-technical management understand software development?
If you have some non-technical people managing your software development team, is there a book you'd want them to read to understand the process better?

For example, in most work, you can pretty well estimate how long a task will take. But in development, the whole point is that you have to figure out the problem, which takes unknown time. This is hard to communicate.

Anything you know of that explains this well?

答:
Get Facts and Fallacies of Software Engineering.

EDIT

This book is easy to read, and easy to snipe paragraphs from for management. It focuses on the issues of software development from the distance of knowing nothing about it. At the time, I had similar issues to OP, and working with my manager and this book, I manage to convince him that I need more time and resources to complete my tasks.

However, I've recently seen a lot of stuff in that book contradicted. As ever, I wouldn't recommend anyone reading anything in the social studies anyway. It's all too wishy washy and changes from day to day.


答:
So what does the extra overhead / complexity of SOAP give you, when do
  you need it and when could you and should you do without it?

The biggest difference between the two is that REST is suppose to be stateless, where-as SOAP is not.  In practice many REST implementation actually do implement some state in the session through something like OAuth.

Another difference is REST is very "resource" or noun oriented.  You interact with resources through CRUD operations.  Anything that doesn't fit this paradigm becomes cumbersome and awkward.

SOAP on the other hand is just an RPC (remote procedure call) protocol.  It doesn't come with a paradigm, it's just the transport layer.


答:
For software process and project management, I have to recommend Steve McConnell's Rapid Development: Taming Wild Software Schedules and Software Project Survival Guide. These books discuss topics ranging from classic mistakes in managing software projects to managing risks to explanations of best practices and when how to appropriately apply them.

Jim McCarthy's Dynamics of Software Development also provides some interesting insights into how software teams work and provides tips and tricks for optimizing software projects, based on real-world cases.

Title: What's a good book to help non-technical management understand software development?

Body:
If you have some non-technical people managing your software development team, is there a book you'd want them to read to understand the process better?

For example, in most work, you can pretty well estimate how long a task will take. But in development, the whole point is that you have to figure out the problem, which takes unknown time. This is hard to communicate.

Anything you know of that explains this well?


答:
It might be a minor point, but REST is entirely based on HTTP.

SOAP does not require HTTP, and you are free to use whatever transport you like.

SOAP messages can be routed asynchronously and reliably whereas REST is pretty much a synchronous paradigm.

REST does not tell you anything about what the data you are sending and receiving should look like. There is WADL, but mostly you rely on documentation of the API being correct. SOAP has circus of XML technologies to make data description less error prone. WSDL, Schema...

At the end of the day REST  basically gets you a file system based on HTTP. If your system can fit into that paradigm - then it might be a good choice.


答: I would say that they are written like this due to the 80 character line-width limit imposed by some code standards, and text mode editors.</p>

Title: Reason behind multi-line declaration style?

Body:
I'm a little curious about the reason behind the Windows header file declaration styles.

When I read them, I see multi-line declarations such as the following:

```<code>WINBASEAPI
HANDLE
WINAPI
GetStdHandle(
    IN DWORD nStdHandle
    );
</code>```

What is the primary reason why they're not written as something like:

```<code>WINBASEAPI HANDLE WINAPI GetStdHandle(IN DWORD nStdHandle);
</code>```

i.e. in a single line?


问:
One-week release cycle: how do I make this feasible?
At my company (3-yr-old web industry startup), we have frequent problems with the product team saying "aaaah this is a crisis patch it now!" (doesn't everybody?)

This has an impact on the productivity (and morale) of engineering staff, self included.  Management has spent some time thinking about how to reduce the frequency of these same-day requests and has come up with the solution that we are going to have a release every week.  (Previously we'd been doing one every two weeks, which usually slipped by a couple of days or so.)

There are 13 developers and 6 local / 9 offshore testers; the theory is that only 4 developers (and all testers) will work on even-numbered releases, unless a piece of work comes up that really requires some specific expertise from one of the other devs.  Each cycle will contain two days of dev work and two days of QA work (plus 1 day of scoping / triage / ...).

My questions are:

(a) Does anyone have experience with this length of release cycle?

(b) Has anyone heard of this length of release cycle even being attempted?

(c) If (a) or (b), how on Earth do you make it work?  (Any pitfalls to avoid, etc., are also appreciated.)

(d) How can we minimize the damage if this effort fails?

答:
Management has spent some time thinking about how to reduce the frequency of these "crisis jobs" and has come up with the solution that we are going to have a release every week.

Looks like your managament are world champions... why not invest in your team spirit intead ? You will see the problems will disapear by themselve.

(a) + (b) IMHO, according the size of your team it should be two weeks max. One week will work for one man shows or very tiny teams (like 2 or 3).

(c) + (d) But regardless the size of your team or project, one of the first thing I do, is automatize the build & deployment. I save days if not weeks of work by doing that in the early days of a project.

Your deployments must be done with one click. From source to staging, then from staging to production. There are a lot of tools to make this possible. From ant/nant to super heavy stuff like Automated Build Studio.

Everything can be automated from files deployments to database upgrade, including backups, notifications, reporting, ...


答:
Did you have trouble understanding the linked list, or just trouble with your implementation?

It's not unusual for a new programmer to have difficulty there, because it may be the first time you have to think about what it really means when you write:

```<code>list.head = null;
Element e = new Element(...);
e.next = list.head;
list.head = e;
</code>```

I got all twisted up in ALGOL/W on the same exercise, because I didn't quite understand the language semantics.  A year later, I could barely remember why I had difficulty.

Body:
Did you have trouble understanding the linked list, or just trouble with your implementation?

It's not unusual for a new programmer to have difficulty there, because it may be the first time you have to think about what it really means when you write:

list.head = null;
Element e = new Element(...);
e.next = list.head;
list.head = e;

I got all twisted up in ALGOL/W on the same exercise, because I didn't quite understand the language semantics.  A year later, I could barely remember why I had difficulty.


答:
Agile, like anything, can be used to cover a bad behavior or to try to solve a problem that the team think they are not responsible of.

However, the magic in some Agile methodologies like Scrum is that they will provide lot visibility on problems within the organization. Including problems within the team!

You will be then given the opportunity to solve them as they arise.

If the problem lies to the cowboys, this will be very visible after the first iteration. If the problem is elsewhere, you will see it very soon too.


问:
Small Basic vs Microsoft Small Basic
Are Small Basic (SB) and Microsoft Small Basic (MSB) related or is this a confusion based upon similar names?

I have read that SB is written in C and is GPL. The oldest date on SourceForge is 2004 but the facebook group states its over 10years old. MSB is written in .NET 3.5 by Microsoft DevLabs. Wikipedia states it originated in 2008. They seem completely unrelated. Is this another Microsoft "Embrace, Extend, and Extinguish" tactic?

I have read that MSB does not allow distribution:

The license is presented when you install the software.  Small Basic
  includes a command line compiler that can be used as part of the
  product.  You may install and use any number of copies of the software
  on your premises to test how it runs with your programs, distribution
  is not allowed.  Please review the license terms for additional use
  rights/restrictions.  Thank you.

-MSB Forums

答:
Are Java and Javascript related? No, they are not. It's highly unlikely these two are related though they could be. I don't think Microsoft is trying to steal what little market share Small Basic has. They already have a huge chunk via the VB.NET set.

To answer the second part of the question, it doesn't allow distribution of the interpreter. Any code you write doesn't automatically become Microsoft's.

Title: Small Basic vs Microsoft Small Basic


问:
Developing BlackBerry app with 3rd party content
I'm working on a BlackBerry app, however I'm loading data from various 3rd party websites around the web. (E.g, posts from stackoverflow or currency rates off Yahoo.com) I'd like to know if this could cause any trouble, would it be allowed?

Thank you!

答:
How are you pulling data from these sites?  Are you signing up to use there tools available to developers?  Have you even investigated if these sites offer any tools.

Get clarification from each site

Each site should have a contact email if you look hard enough, and direct your question there.  It is better to ask now, then to find out that you have a lawsuit on your hands...

My comments should not be be taken as legal advice.


问:
Can you write an unambiguous specification in a natural language like English?
It seems to me that you cannot possibly write a software specification in English that is completely free of ambiguities, simply due to the informal nature of natural language - and therefore that a truly unambiguous specification must include code written in a formally specified language.

Is this a known result or am I missing something?

答:
I believe the correct answer is negative. It's necessary to distinguish the following questions:

Is it possible to write a software specification in a natural language that does not contain ambiguities?

Is it possible to write software in a natural language that does not contain ambiguities?

The difference between the first and second question concerns the level of detail involved, the amount of interpretation required, and the rules imposed on the construction of sentences in the natural language for the purposes of writing the software or software specification.

The answer to the second question is affirmative. Given a suitably constrained subset of a natural language with agreed-upon rules for sentence construction and meaning, code can be written in grammatical English sentences. For instance, the following language unambiguously permits writing assignment statements:

```<code>Variables: x,y,z,...
Constants: 1,2,3,...
Rules: (1) if x is a variable and n a constant, then
           "The variable x contains the number n" is a sentence.
       (2) if x is a variable and n a constant, then
           "Assign the number n to the variable x" is a sentence.
</code>```

That is, we can systematically translate code written in formal programming languages into natural languages by describing each procedure. On the other hand, a software specification often requires interpretation. Thus, whether a software specification can be given unambiguously depends on the level of detail involved in the specification. However, given a selected domain over which the specification ranges, with particular operations on this domain selected, a similar translation process can be carried out. For instance:

```<code>Over the domain D supporting operations f,g,h over elements a,b,c in relations
P,R,Q with properties φ,ψ,θ, design a program that does X,Y,Z.
</code>```

where the statements X,Y,Z contain only those items mentioned in the specification's preface and are written in a suitably formal and agreed-upon subset of a natural language. The ambiguities will then concern how to implement the specification - but this will be expected.

Body:
I believe the correct answer is negative. It's necessary to distinguish the following questions:

Is it possible to write a software specification in a natural language that does not contain ambiguities?

Is it possible to write software in a natural language that does not contain ambiguities?

The difference between the first and second question concerns the level of detail involved, the amount of interpretation required, and the rules imposed on the construction of sentences in the natural language for the purposes of writing the software or software specification.

The answer to the second question is affirmative. Given a suitably constrained subset of a natural language with agreed-upon rules for sentence construction and meaning, code can be written in grammatical English sentences. For instance, the following language unambiguously permits writing assignment statements:

Variables: x,y,z,...
Constants: 1,2,3,...
Rules: (1) if x is a variable and n a constant, then
           "The variable x contains the number n" is a sentence.
       (2) if x is a variable and n a constant, then
           "Assign the number n to the variable x" is a sentence.

That is, we can systematically translate code written in formal programming languages into natural languages by describing each procedure. On the other hand, a software specification often requires interpretation. Thus, whether a software specification can be given unambiguously depends on the level of detail involved in the specification. However, given a selected domain over which the specification ranges, with particular operations on this domain selected, a similar translation process can be carried out. For instance:

Over the domain D supporting operations f,g,h over elements a,b,c in relations
P,R,Q with properties φ,ψ,θ, design a program that does X,Y,Z.

where the statements X,Y,Z contain only those items mentioned in the specification's preface and are written in a suitably formal and agreed-upon subset of a natural language. The ambiguities will then concern how to implement the specification - but this will be expected.


答:
To quote my fav CSCI teacher:

```<code>"Panic, but panic early."
</code>```

Data Structures sounds hard, right? To me it does, it sounds abstract and a bit complex and most of all... important!

Data Structures is a vital course. And it's common to struggle, but keep going! As long as you eat your Wheaties and keep at it, you will reach the rainbow with a bag filled with generic items  underneath.

Body:
To quote my fav CSCI teacher:

"Panic, but panic early."

Data Structures sounds hard, right? To me it does, it sounds abstract and a bit complex and most of all... important!

Data Structures is a vital course. And it's common to struggle, but keep going! As long as you eat your Wheaties and keep at it, you will reach the rainbow with a bag filled with generic items  underneath.


问:
How do I convince my employer to hire an additional developer without selling myself short?
I'm the only developer at a small company. I've slowly moved into development here; until ~4 months ago 50-75% of my time was spent on operations. Now, 50-75% of my time is spent on development, with the rest split between operations and various IT stuff. I regularly end up working 50+ hours a week.

I inherited some rather poorly-written applications (they were previously maintained by two people) that much of the business relies upon. Keeping these up and running, working on new, smaller applications, and my other responsibilities already take up all my time.

In order to be scalable, the existing software needs significant refactoring and additional functionality. I haven't had the pleasure to work on properly written or architected software before. The complexity of this task is well beyond anything I've done before (this is my first job out of college.) I know there's a feverish devotion to self-learning/learning by doing among many here, but this is so beyond my expertise that I wouldn't be doing my employer or myself any favors trying to tackle it alone.

I've been very direct about my inexperience, and in the past have mentioned that hiring another, more experienced developer will probably be necessary...if anything, just for the amount of time required for anyone to do the work as we grow and have more software to develop and maintain. I know that I would greatly benefit from hiring another developer; having someone to learn from and bounce ideas off of would be great. StackOverflow is great for determining approaches to individual coding problems or concepts, but is no replacement for discussions on a wider or more significant scale specific to a certain business domain. When mentioning hiring another developer in casual conversation recently, they didn't seem to think it was that important or necessary.

tl;dr: Current patch jobs and other responsibilities already take up all my time at work, work on existing applications that needs to be done is beyond my skillset, little chance of me having any time to work on new products that are being planned. Employer initially seems reluctant about hiring another developer.

How can I "sell" hiring another developer without sounding like I'm lazy or incompetent (I'd like to think I'm neither!)?

edit: Just wanted to clarify that I'm in no way interested in taking any kind of hostile action to prove a point (i.e. taking a vacation to show them they'd be screwed if I wasn't around.) I'm pretty content working here and consider myself to be fairly compensated, even figuring in the overtime, which is why I'm nowhere near considering a new job yet. That said, I accepted the 'no more overtime' answer - even if I don't mind working over too much I'm not doing anyone any favors by doing so (prone to more errors, wear myself out) and it's not really tenable in the short term much less the long term. I'll be stressing this when discussing the matter with my supervisor, and will probably suggest hiring a contractor part-time as an initial approach that's more financially palatable. Thanks for all the great answers.

答: Get something to compare your situation too whether its talking to friends at other companies, going on interviews and asking questions about their dev team, etc and then lay it out there that you think the workload is unreasonable and that the company is not set up success with just one developer. I did this with a past boss, ended up quitting anyways for a better job, but basically I said things about how having a testing team becomes a necessity with the more code that is written, due to regressions, etc (not necessarily related to what you are asking but having testers on hand helps with the deve process too) and that you know you are working more than the average developer, etc. It sounds like you may want to look for a new job if he doesn't agree, he should already know that you are overloaded and if he's that clueless to not know then that it may become an untenable situation for you at some point.</p>


问:
How can I make refactoring a priority for my team?
The codebase I work with daily has no automated tests, inconsistent naming and tons of comments like "Why is this here?", "Not sure if this is needed" or "This method isn't named right" and the code is littered with "Changelogs" despite the fact we use source control. Suffice it to say, our codebase could use refactoring.

We always have tasks to fix bugs or add new features, so no time is put aside to refactor code to be better and more modular, and it doesn't seem to be a high priority.

How can I demonstrate the value of refactoring such that it gets added to our task lists? Is it worth it to just refactor as I go, asking for forgiveness rather than permission?

答:
I laughed a little bit at the way you described things as that sounds pretty similar to the code base I work on so I think our situations are pretty similar. Luckily, in my situation I have a forward-thinking manager that has decided the best way to making the codebase better is through modularization using a modern web development framework rather than to just refactor the entire codebase. This way the troublesome spots of the main application can be re-written as separate modules and then be integrated into the main app (but still be essentially independent). This may be an approach you want to bring up since it wouldn't require refactoring the entire (presumabley large?) codebase you are working with.

Of course, I may be a bit off from what you are saying as perhaps your code base isn't as bad as the one I work with, in that case I would say why not do little optimizations as you go along? The dev's on my team have no problem removing stupid or outdated comments and things of that nature and I don't think thats something that should require input from management as usually developers are given some empowerment to optimize things as needed.

If the code base is really fragile then you need to be careful and this can be why they may not want to pursue major refactoring as this could end up turning into a months long project and would probably require branching of a project and putting dev's on that project and taking away from other development tasks, like immediate bug fixes that may cause them to lose customers, etc

All things considered, as far as other people saying you should quit, etc, I think it depends on how management sees things, if they understand the situation and realize why some things may take longer than they optimally should, then things could be fine as far as the work environment, but if they are constantly getting on you about a backlog of work, that could become detrimental over time. I'm fortunate to have management that basically realize the application is a piece of crap, but it does have a lot of customers and brings in money, so its still valuable and worth making bug fixes on, even if just for the short-term.


答:
They are not at all related.

Here is a quote from Microsoft's Small Basic FAQ:

What about the other "Small Basic?"

We noticed there’s another version of "Small Basic" out there. Other
  than the naming coincidence, our version of Small Basic doesn’t have
  anything to do with this other version.

Regarding embracing and extiguishing, I don't think they intend it in that direct a way.  Microsoft's stated purpose for Small Basic is to create a very simple teaching language that complete beginners (probably kids) can use.  I think their "market" is basically middle schools and high schools.  I suppose that by getting kids started on a Microsoft tool they have a better chance with hearts and minds when it comes time to move up to Visual Studio.

Title: Small Basic vs Microsoft Small Basic

Body:
Are Small Basic (SB) and Microsoft Small Basic (MSB) related or is this a confusion based upon similar names?

I have read that SB is written in C and is GPL. The oldest date on SourceForge is 2004 but the facebook group states its over 10years old. MSB is written in .NET 3.5 by Microsoft DevLabs. Wikipedia states it originated in 2008. They seem completely unrelated. Is this another Microsoft "Embrace, Extend, and Extinguish" tactic?

I have read that MSB does not allow distribution:

The license is presented when you install the software.  Small Basic
  includes a command line compiler that can be used as part of the
  product.  You may install and use any number of copies of the software
  on your premises to test how it runs with your programs, distribution
  is not allowed.  Please review the license terms for additional use
  rights/restrictions.  Thank you.

-MSB Forums


问:
Alternatives to *documents* in the SDLC?
Since no one prints anything any more, the concept of actual project documents (meaning, a monolithic piece of formatted text) seems like it could be improved on. Problems with documents are things like Word version incompatibilities, endless messing around with templates, the fact people hate reading them...

I'm wondering if there are alternatives, like websites that would help manage the content, imposing some structure, but allowing things like linking to individual bits. But I guess the site would have to be able to spit out a "document" for the times it's needed (filing, showing sponsors who ask, etc)

For example, instead of a "project plan document", I'm imagining a project planning site where you can work on just the resourcing with relevant people, then you work on scheduling with other relevant people, and work packages with other relevant people.

Instead of an SRS document, some site that lets you manage requirements, assigning priorities, phases etc...but that could ultimately generate an actual SRS document if you needed it.

Thoughts? The context here is small, agile teams but with occasional need to produce documents to demonstrate progress. We're certainly not big enough to warrant anything like Rational or whatever they use these days in big companies.

答:
First off, people still print stuff constantly--it really depends on your particular corporate culture.

That said, try a wiki, so that people can collaborate, update, and link to their hearts' content while still having a history of their docs.  Atlassian produces a fabulous on called Confluence which integrates really nicely with Jira, their bug/project tracking tool.  Or else you could try one of the myriad free ones out there.


答:
I have seen wikis used like this, in place of documents. I think they were using Confluence, though there are many others. And yes, I think it could produce print-friendly documents on-the-fly.

Another thing to consider is what "documents" do you have besides Word documents? We have spreadsheets and Visio files which don't really have Wiki analogues (at least not as far as I know), so if you make heavy use of similar files, you'll have to attach them to the Wiki page and then reference them. Not a big deal, but something to keep in mind as it could change the way the document is read.

Title: Alternatives to *documents* in the SDLC?

Body:
Since no one prints anything any more, the concept of actual project documents (meaning, a monolithic piece of formatted text) seems like it could be improved on. Problems with documents are things like Word version incompatibilities, endless messing around with templates, the fact people hate reading them...

I'm wondering if there are alternatives, like websites that would help manage the content, imposing some structure, but allowing things like linking to individual bits. But I guess the site would have to be able to spit out a "document" for the times it's needed (filing, showing sponsors who ask, etc)

For example, instead of a "project plan document", I'm imagining a project planning site where you can work on just the resourcing with relevant people, then you work on scheduling with other relevant people, and work packages with other relevant people.

Instead of an SRS document, some site that lets you manage requirements, assigning priorities, phases etc...but that could ultimately generate an actual SRS document if you needed it.

Thoughts? The context here is small, agile teams but with occasional need to produce documents to demonstrate progress. We're certainly not big enough to warrant anything like Rational or whatever they use these days in big companies.


答:
In terms of Software development process, I'd have to go with "The Pragmatic Programmer: From Journeyman to Master" by Andy Hunt and Dave Thomas. Its full of gems of useful knowledge that would typically take a lot of actual real-world programming experience to learn otherwise. It is also programming language-agnostic and is mostly easy to understand.

In terms of estimation, the pragmatic programmer has a brief section about it, but the classic "The Mythical Man Month" by Fred P. Brooks would have to be worth reading. Some of the project examples seem a little dated but much of the ideas still ring true today.


答:
I generally think that Word documents are generally a bad thing in software development.  They're bulky, they're clumsy, they don't version well and searching them is painful.

In general, you should try to prefer document formats which version well.  Binary heavy formats like Word, Excel, PNGs, have poor versioning support.  That is, tracking changes is difficult and cumbersome.

Many documents are better stored in a Wiki.  The limited formatting tends to force people to do simple formatting.  Headers, lists, sections.  Nothing complex, after all, the formatting can be bulk changed in one spot instead of updating some well hidden template file.  Nothing is worse waste of people's time than dealing with pedantic document formatting.

Even images, some Wikis have support for Balsamiq mock-ups.  Even if PNGs are necessary, a Wiki with PNGs is a far superior choice to Word files.

As for project planning, you should investigate tools which support Agile methods.  I've used Jira successfully, but it's worth looking around to find a tool for your needs.   Rigid design documents are generally a bad idea.  They usually need a special tool like MS Project, and are difficult to update and share changes.  As above, they also version poorly.

Using a Scrum tool you can define a list of relevant requirements and link from the Epic/User story item to the wiki which provides elaboration.  So the wiki can version the meat of the ticket.  Most scrum tools won't generate a Gantt chart but will do burn-down charts.  A Gantt chart is proscriptive in that it defines reality, a burn-down chart is descriptive in that it can actually measure progress and make predictions about the future.  Needless to say, the burn-down chart is much more useful.


答: Not a book, but I've had good success directing (reasonably bright) non-technical managers to Joel on Software.</p>


答: They are not related.  And there is really little reason for confusion, as there are well over a hundred completely different implementations of the BASIC programming language, many with vaguely similar sounding names.  Sometimes 2 different unrelated implementations have similar names.  Sometimes 2 nearly identical and related Basic implementations will have two completely different brand names on them.</p>

Title: Small Basic vs Microsoft Small Basic


答:
No

An unambiguous specification of a computation is a computer program.

Title: Can you write an unambiguous specification in a natural language like English?

Body:
It seems to me that you cannot possibly write a software specification in English that is completely free of ambiguities, simply due to the informal nature of natural language - and therefore that a truly unambiguous specification must include code written in a formally specified language.

Is this a known result or am I missing something?


问:
Why do so many programmers absolutely hate object prevalence layers?
Prevalence is a simple technique to provide ACID properties to an in-memory object model based on binary serialization and write-ahead logging.  It works like this:

Start with a snapshot.  Serialize the object model and write it to a file.

Create a journal file.  For every call into the object model, serialize the call and its arguments.

When the journal gets too big, you're shutting down, or it's otherwise convenient, perform a checkpoint: write a new snapshot and truncate the journal.

To roll back or recover from a crash or power hit, load the last snapshot and re-execute all the calls recorded in the journal.

The precautions needed to make this work are:

Don't let mutable object references escape or enter the prevalence layer.  You need some sort of proxy or OID scheme, as if you were doing RPC.  (This is such a common newbie mistake it's been nicknamed the 'baptism problem'.)

All the logic reachable from a call must be completely deterministic, and must not perform business-logic-meaningful I/O or OS calls.  Writing to a diagnostic log is probably OK, but getting the system time or launching an asynchronous delegate is generally not.  This is so that the journal replays identically even if it's restored on a different machine or at a different time.  (Most prevalence code provides an alternate time call to get the transaction timestamp.)

Writer concurrency introduces ambiguity in journal interpretation, so it is prohibited.

Is it because ...

people developed a bad taste for them after trying to use one on a project that wasn't well suited* to it?

Klaus Wuestefeld's strident advocacy turned people off?

people who like the imperative programming model dislike separating I/O from calculation, preferring instead to interleave computation with I/O and threading calls?

prevalence layers are so conceptually simple and so intimately bound to the characteristics of the framework they inhabit that they're usually custom-rolled for the project, which makes them too alien/nonstandard/risky?

it's just too hard to keep straight what you have to be careful not to do?

newbies' heads just seem to explode when faced with something that isn't the same kind of two-tier database-driven app they learned to write in school? ;)

*The entire data set fits in RAM, you don't need writer concurrency, and you don't need to do ad-hoc queries, reporting, or export to a data warehouse.  With apologies to SQLite, prevalence is an improvement on save-files, not a replacement for Oracle.

答:
The answer to the question is that while the theory is simple the practice is not.

Just testing such a setup requires dozens of test cases, add in mutli process or multi threaded code and this jumps to hundreds of possible conditions that need to be tested, both for persistence and recovery.

Any transaction monitor such as CICS,Tuxedo, Weblogic, Websphere, JBOSS or  .NET, will provide all these facilities in a clean and tested manner. And any database will provide "enough" transactional/persistence for most applications.

Its mostly a case of that wheel was invented and perfected a long time ago.


问:
What was SOAP invented for?
This question is inspired by this one. What was the initial goal of inventing SOAP? Why was it invented when we had old kind HTTP and REST?</p>

答:
REST is not a standard, it is a (loosely defined) architecture. And it is tied to HTTP, which a lot of people in the corporate world saw as a limitation. So they thought they needed a general standard proper, which works over other transfer layers as well.

And btw SOAP was defined prior to REST (at least according to Wikipedia :-)

Title: What was SOAP invented for?


答: SOAP is way more suitable than plain HTTP for exchanging complex data structures. REST is by design practically restricted to CRUD operations, while SOAP allows arbitrary method calls, which may be something that cannot be pressed into the REST scheme.</p>

Title: What was SOAP invented for?

Body: This question is inspired by this one. What was the initial goal of inventing SOAP? Why was it invented when we had old kind HTTP and REST?</p>


答:
The problem is a database problem and should not be solved with word processes, spreadsheets or wikis.

Author IT is a nice document management tools that is designed to handle this problem. A problem is propritory format and therefore you need commit to it. However, if you are committed, it will do all you have asked and much more. I think it comes with a enterprise price tag, although they might offer something different.


问:
When are Getters and Setters Justified?
Getters and setters are often criticized as being not proper OO. On the other hand, most OO code I've seen has extensive getters and setters.

When are getters and setters justified? Do you try to avoid using them? Are they overused in general?

If your favorite language has properties (mine does) then such things are also considered getters and setters for this question. They are the same thing from an OO methodology perspective. They just have nicer syntax.

Sources for Getter/Setter Criticism (some taken from comments to give them better visibility):

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

http://typicalprogrammer.com/?p=23

http://c2.com/cgi/wiki?AccessorsAreEvil

http://www.darronschall.com/weblog/2005/03/no-brain-getter-and-setters.cfm

http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and

http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

To state the criticism simply: Getters and Setters allow you to manipulate the internal state of objects from outside of the object. This violates encapsulation. Only the object itself should care about its internal state.

And an example

Procedural version of code:

```<code>struct Fridge
{
    int cheese;
}

void go_shopping(Fridge fridge)
{
     fridge.cheese += 5;
}
</code>```

Mutator version of code:

```<code>class Fridge
{
     int cheese;

     void set_cheese(int _cheese) { cheese = _cheese; }
     int get_cheese() { return cheese; }
 }

void go_shopping(Fridge fridge)
{
     fridge.set_cheese(fridge.get_cheese() + 5);
}
</code>```

The getters and setters made the code much more complicated without affording proper encapsulation. Because the internal state is accessible to other objects we don't gain a whole lot by adding these getters and setters.

The question has been previously discussed on Stack Overflow:

https://stackoverflow.com/questions/565095/java-are-getters-and-setters-evil

https://stackoverflow.com/questions/996179

答:
Firstly there are broadly two types of objects which i will comment on, value and service types.

Service types should never have setters, whatever dependencies they require should not be gettable. THe best way to pass dependencies is via a constructor or factory that way all instances are fully formed from the beginning, plain and simple.

Value types should also be immutable, on the oher hand there are times when this is not practical such as an ORM, or some other mapping such as from a widget to an object. All other value types that get passed around the system from one layer or part to another should be immutable and should not have setters.

ContentLicense: CC BY-SA 4.0

Title: When are Getters and Setters Justified?


答:
You can model more than one project at the same time. I mean to have a project with a class 1 and another project with a class 2. If you merge both models into a single big model then you can show relations between those two classes.

The merge is simple because you just need to drag and drop your class 2 coming from another project inside the class 1 diagram and the tool will immediately merge both project. It would also detect java dependencies between both projects if you work with Eclipse and select the Project > extends option.

A deployment diagram is also a good option but I prefer to model more than one project at the same time because in the real life this is what I do. I have currently more than 10 large projects which works together. Having a different model for each project would be difficult therefore a single model is better for me.

Title: How to draw a (UML) class diagram when the classes are dispersed across a distributed system?

Body: Basically how to denote that class foo is from a different server than class bar ? </p>


问:
What are the pros and cons of a language using whitespace vs. {}'s to indicate scope?
There seems to be a conflict over whether its better to use whitespace or tokens like brackets to indicate scope. I've seen many praise python's solution to the inconsistent indentation problem, but many disagree:

Any language that has whitespace as tokens needs to die.

posted later on the same answer:

I was sortof anti-whitespace-as-tokens, until I actually tried it. It probably helped that my personal white-space layout pretty much matches what everyone in python-land uses. Perhaps it's that I am a bit minimalist, but if you're going to indent anyways, why bother with the {}s?

I can see some clear arguments for each side:

using whitespace:

helps reduce inconsistent indentation in code

clears the screen by replace visible tokens with whitespace to serve the same purpose

using tokens:

much easier to cut and paste code to different levels (you don't have to fix the
indentation)

more consistent. Some text editors display whitespace differently.

more popular currently.

Are there any points I missed? Which do you prefer? Any words of wisdom after having worked with one or the other for a long time?

PS. I hate it when languages don't use the same token for each control structure. VB is really annoying with its End If and End While statements, most other languages just use {}'s for everything. But maybe that's a topic for a different question...

答:
The problem I found with a whitespace language was with multi-page conditional expressions. Adding a line in the middle of page two, and getting off by one space in the middle of all mess, can drastically alter the logic of your code. And even if someone's code is "correct", trying to read it makes a terrible guessing game. Which "if" is this 'else' for? I can count braces much easier than I can count invisible blank characters. And the posting machinery on this site keeps smashing them into a single space. </p>

```<code>IMHO "{{{{{" is more reliable than "     ".
</code>```

Body:
The problem I found with a whitespace language was with multi-page conditional expressions. Adding a line in the middle of page two, and getting off by one space in the middle of all mess, can drastically alter the logic of your code. And even if someone's code is "correct", trying to read it makes a terrible guessing game. Which "if" is this 'else' for? I can count braces much easier than I can count invisible blank characters. And the posting machinery on this site keeps smashing them into a single space.

IMHO "{{{{{" is more reliable than "     ".


问:
How to save images into files in a web application and avoid removing them with every build?
I am building a web application and users will be able to upload pics. And I want to store these images into files instead of storing them into the DB.

But if I saved these pics into relative paths to the web application, they will be removed with each build.

So how I can handle this and the best practices related to this issue.

答: Well, you'll need to store a reference to them within a database, then store the images external to the web application. It could be on the same server in an accessible folder outside of the scope, or on a dedicated server for hosting the images.</p>


问:
Open Source Project and Revenue
I started an open source project in 2010 and the project is gaining some visibility. We are now 2 active committers and we hope to engage more contributors in the future.
We received today the second offer to "partner" with a company. This time is a hosting company that wants us to offer a hosting plan with a automatic installation of the software and receive a affiliate payout for each (the company is well-known).

The question is:
Is there a way we can share the revenue within the project contributors?

Our main goal for now is to have more contributors and make better software, not profitability...

PS: We are also in the process to assign the project to the Outercurve Foundation.

答:
There are many ways to share profits.  Personally I favour a merit based share: the more you contribute, the more you get.  However, using a good metric can be hard -- lines of tested code, documentation, test cases?...  If you create a limited company those member will get a share of the profit, I would recommend making sure that whoever joins invest (minimum $300) into the company.   This makes sure they are serious. From then, a share of the profit can be determined by whatever means.

Whatever you do, please take legal advise from a reputable solicitor/lawyer before signing anything with anyone.

Title: Open Source Project and Revenue


问:
what is the meaning of a "Teardown Report"
I am sorry if this a wrong place to ask the question.

I saw the usage "Teardown report" for a product

What does it mean?

答:
A teardown report is a summary of disassembling a product.

From Wikipedia:

A product teardown, or simply teardown, is the act of disassembling a
  product, such as a television set, to identify its component parts and
  functions. For products having secret technology, such as the
  Mikoyan-Gurevich MiG-25, the process may be secret. For others,
  including consumer electronics, the results are typically disseminated
  through photographs and component lists so that others can make use of
  the information without having to disassemble the product themselves.


答:
I think you should have a comment there still, not to explain what the function itself does, which is obvious, but rather what the variable returned by it does.

If the name of the variable explains it, then fine - you probably don't need any comments. If the name is something like "state_x" the programmer calling the function is most likely interested in knowing what states there are. If the state is part of a state machine, perhaps all the states need to be explained one by one.

All of this will of course depend on what documentation you can already find elsewhere in the project: if the behavior of "OBJ" is explained elsewhere, then a list of all declarations without comments is probably a sensible solution. However, my own personal philosophy is that a programmer should be able to pick out any code module of mine and understand what it does just by reading the h-file, without the need of external documents.

And to be picky: if I encounter a non-const get member function I would expect an explanation of why it wasn't declared const. It suggests that the function isn't a simple getter, but rather that there is some sort of internal magic taking place inside that function.