问:
Should UTF-16 be considered harmful?
I'm going to ask what is probably quite a controversial question: "Should one of the most
popular encodings, UTF-16, be considered harmful?"

Why do I ask this question?

How many programmers are aware of the fact that UTF-16 is actually a variable length encoding? By this I mean that there are code points that, represented as surrogate pairs, take more than one element.

I know; lots of applications, frameworks and APIs use UTF-16, such as Java's String, C#'s String, Win32 APIs, Qt GUI libraries, the ICU Unicode library, etc.  However, with all of that, there are lots of basic bugs in the processing of characters out of BMP (characters that should be encoded using two UTF-16 elements).

For example, try to edit one of these characters:

𝄞 (U+1D11E) MUSICAL SYMBOL G CLEF

𝕥 (U+1D565) MATHEMATICAL DOUBLE-STRUCK SMALL T

𝟶 (U+1D7F6) MATHEMATICAL MONOSPACE DIGIT ZERO

𠂊 (U+2008A) Han Character

You may miss some, depending on what fonts you have installed.  These characters are all outside of the BMP (Basic Multilingual Plane).  If you cannot see these characters, you can also try looking at them in the Unicode Character reference.

For example, try to create file names in Windows that include these characters; try to delete these characters with a "backspace" to see how they behave in different applications that use UTF-16. I did some tests and the results are quite bad:

Opera has problem with editing them (delete required 2 presses on backspace)

Notepad can't deal with them correctly (delete required 2 presses on backspace)

File names editing in Window dialogs in broken (delete required 2 presses on backspace)

All QT3 applications can't deal with them - show two empty squares instead of one symbol.

Python encodes such characters incorrectly when used directly u'X'!=unicode('X','utf-16') on some platforms when X in character outside of BMP.

Python 2.5 unicodedata fails to get properties on such characters when python compiled with UTF-16 Unicode strings.

StackOverflow seems to remove these characters from the text if edited directly in as Unicode characters (these characters are shown using HTML Unicode escapes).

WinForms TextBox may generate invalid string when limited with MaxLength.

It seems that such bugs are extremely easy to find in many applications that use UTF-16.

So... Do you think that UTF-16 should be considered harmful?

答: I've never understood the point of UTF-16.  If you want the most space-efficient representation, use UTF-8.  If you want to be able to treat text as fixed-length, use UTF-32.  If you want neither, use UTF-16.  Worse yet, since all of the common (basic multilingual plane) characters in UTF-16 fit in a single code point, bugs that assume that UTF-16 is fixed-length will be subtle and hard to find, whereas if you try to do this with UTF-8, your code will fail fast and loudly as soon as you try to internationalize.</p>

OwnerDisplayName: Artyom

Title: Should UTF-16 be considered harmful?


问:
Pointless Code In Your Source
I've heard stories of this from senior coders and I've seen some of it myself. It seems that there are more than a few instances of programmers writing pointless code. I will see things like:

Method or function calls that do nothing of value.

Redundant checks done in a separate class file, object or method.

if statements that always evaluate to true.

Threads that spin off and do nothing of note.

Just to name a few. I've been told that this is because programmers want to intentionally make the code confusing to raise their own worth to the organization or make sure of repeat business in the case of contractual or outsourced work.

My question is. Has anyone else seen code like this? What was your conclusion was to why that code was there?

If anyone has written code like this, can you share why?

答:
I have heard developers who try to make their coding achievements sound more complex than they really are. I've never heard anyone admit this, but I have seen code that meets your criteria that was created intentionally out of haste or poor practices and not sabotage. The code surrounding the maligned code may have been altered to the point where a particular function is no longer useful.

Someone would actually have to see this code first-hand before coming to the conclusion that only this developer can manage the complexity. Most managers and other business people just come to this conclusion because they don't understand any kind of code and don't want to refill the position.

ContentLicense: CC BY-SA 3.0

Title: Pointless Code In Your Source


答:
I haven't see the code like this but I have seen the code that looks pointless or is pointless for the other reasons:

Backward compatibility. You found much better way to do things but you must keep old (and by now not very useful) API/function because some third-party module out there may be using this API/function for something. Even if the function doesn't do anything useful, absence of it might break some code.

Defensive coding. You know the checks in this code are pointless because this was already checked elsewhere. But what if somebody changes this elsewhere code and removes or changes the checks so that they won't longer match your preconditions?

Organic growth. In big projects, over the years many things change, and it turns out some methods that were used before aren't used anymore, but nobody bothered to remove them since nobody kept track of if this specific method is used or not, they just refactored their pieces of code and by chance it happened they all stopped to use this method. Or conditions that once had meaning but application was refactored in other places so that condition became always true but nobody bothered to remove it.

Over-designing. People might code some things "just in case we'd need it" and never actually need it. Like "let's spawn a thread in case we'd have to do some work offline" and then nobody asks to do anything offline and the programmer forgets about it and moves on to other projects (or maybe even another company) and that code remains there forever because nobody knows why it's there or if it's safe to remove it.

So while I have never seen it done out of malice or misguided approach to job security, I've seen tons of times when it happens as natural result of software development.

Title: Pointless Code In Your Source

Body:
I've heard stories of this from senior coders and I've seen some of it myself. It seems that there are more than a few instances of programmers writing pointless code. I will see things like:

Method or function calls that do nothing of value.

Redundant checks done in a separate class file, object or method.

if statements that always evaluate to true.

Threads that spin off and do nothing of note.

Just to name a few. I've been told that this is because programmers want to intentionally make the code confusing to raise their own worth to the organization or make sure of repeat business in the case of contractual or outsourced work.

My question is. Has anyone else seen code like this? What was your conclusion was to why that code was there?

If anyone has written code like this, can you share why?


答:
I've seen this a few times, in fact just yesterday, I've got to merge some of my bosses code into my new app. In his case it is just down to a general lack of skill and understanding and the belief that he thinks he is quite a skilled developer. </p>

<p>'Method or function calls that do nothing of value.' and 'if statements that always evaluate to true' are a major issue with his code.</p>

Title: Pointless Code In Your Source

Body:
I've seen this a few times, in fact just yesterday, I've got to merge some of my bosses code into my new app. In his case it is just down to a general lack of skill and understanding and the belief that he thinks he is quite a skilled developer.

'Method or function calls that do nothing of value.' and 'if statements that always evaluate to true' are a major issue with his code.


答: I'm a bit more of an optimist. I think what you have descried often occurs when code is refactored carelessly.</p>

Title: Pointless Code In Your Source


答:
Old fellows told me of a time when consultants where paid  by the number of lines of code they produced. And so they maximized profits using amazingly long-winded constructs.

Nowadays I always assume the guy is still learning the language while doing the work. And he's in a hurry.

Title: Pointless Code In Your Source


答:
My question is. Has anyone else seen code like this? What was your conclusion was to why that code was there?

1) Yes.

2) In the cases I've seen, I'd put it down variously to:

Programmer inexperience

Programmer not understanding a particularly complicated and/or poorly executed design he is attempting to modify

Programmer being interrupted in the middle of (say) a refactor.

Carelessness

Now maybe I'm being charitable about it, but my general approach is that it is better to be forgiving / non-confrontational about these things, than to point fingers and carry on about poor quality. Obviously, things could get bad enough that something has to be done, but a gentle nudge in the right direction is usually sufficient.

Of course, you can't take such a laissez-faire approach if quality / mistakes are going to seriously impact "the business".  But in that situation you need mandatory and diligent code reviews of everything, combined with a comprehensive test procedure.

In my experience, people tend to get "up tight" about poor quality code (at least in part) because it offends their personal standards.  It is all very well to (personally) strive for perfection, but it is a bit unreasonable to project your personal standards onto other people.  By the sounds of things (e.g. from the nature of your examples), this is what you are doing.

IMO, this is not productive, and not conducive to a good working relationship with your coworkers.

Title: Pointless Code In Your Source


问:
Should a developer also act as a tester?
We're a scrum team of 3 developers, 1 designer, the scrum master, and the product owner. However, we don't have official tester in our team. A problem that is always with us, is that, testing the application and passing those tests and removing bugs has been defined as one of the criteria to consider a PBI (Product Backlog Item) as done.

But the problem is that, no matter how much we (3 developers and 1 designer) try to test the application and implemented use cases, still some bugs are not seen and ruin our presentation (Murphy's law) to stakeholders.

As a remedy, we recommended that the company hire a new tester. Someone who's job would be testing, and testing only. An official professional tester.

However, the problem is that, scrum master and stakeholders believe that a developer (or a designer) should also be a tester.

Are they right? Should we developers (also designers) be testers too?

答:
I'd agree with their point that the developers/designers should test their code, with the cavaet that the designer/developer that did a section of code not be the only set of "eyes" on that code before committed to live. While that's not going to grab everything, it'll at least help to avoid the blindness that creeps in at testing and retesting your own code while developing.

From the mention of use case I'll assume that your'e also using code coverage tools? If not it could help see what code might not be tested, and could be popping in unexpected bugs during certain conditions.

That being said, if there's enough work or your organization is of decent size, I'd agree that a professional QA person is needed, would help to focus everyone's roles a bit more, and they could also see if there's any patterns as to what is being missed, and more importantly, how to fix it.


答:
I suspect that although many have seen code that has these issues, few would fess up to writing the same.  In all likelihood, what you're seeing is accumulated software rot - someone adds something, which doesn't really work, the next maintainer adds protective code further along in the chain to guard against the condition that wasn't properly checked in the first place; then someone gets a problem report and adds even more armoring against a specific instance of a problem; another person adds a more general check and forgets to remove some of the old code added previously which dealt with more specific symptoms, etc.

Then there's the problem of code cleanup: there's no particular incentive to remove what appears to be dead code, and tremendous incentive not to do it, because if you don't understand the code completely, your assessment that the code is "dead" will be flawed, and you will wind up breaking the system.

Title: Pointless Code In Your Source


答:
All of those are often symptoms of how a project ages.

 1. Method or function calls that do nothing of value. There are plenty of times when some code is simply left as is (hopefully with a big deprecated warning, but since most languages don't have that warning, it isn't always followed...) because, at one point it served some genuine purpose and no one knew what might happen if the offending lines were removed.

I seem to remember this from a dailywtf:

```<code>@deprecated // he might have been crazy enough to use reflection...
boolean getTrue() {
    return false;
}
</code>```

 2. Redundant checks done in a separate class file, object or method. Layers of communication are also imperfect (ever read Mythical Man Month? If not, what are you doing on the computer!? Go! READ!). Often, one person will work on something and then leave the project, and then the next guy, finding some bizarre bug, throws an extra check here and there to try to eliminate it. When the bug is removed, the checks aren't because, well, if it isn't broke, don't fix it.

 3. if statements that always evaluate to true. Oh, I've done this one. I got a project once, it had a series of probably 10-15 if/else blocks. To change the behavior, I simply put a true|| at the first block. It wasn't until months (years?) later that I came back and said, "Oh, wow, this code was supposed to have been destroyed but never was"

 4. Threads that spin off and do nothing of note. I can imagine a line of thought going like this:

I know! I can handle these two problems asyncronously! I'll create threads foo and bar.

(two months later) Huh, you know, the functionality from bar is a little bit better in foo. I'll move some over.

(one year later) You know, putting this other stuff from bar into foo makes sense.

(many, many years later) "Hey, this bar thread doesn't look like it is doing anything, can we remove it?" "Better not, it's been there many, many years..."

Title: Pointless Code In Your Source

Body:
All of those are often symptoms of how a project ages.

 1. Method or function calls that do nothing of value. There are plenty of times when some code is simply left as is (hopefully with a big deprecated warning, but since most languages don't have that warning, it isn't always followed...) because, at one point it served some genuine purpose and no one knew what might happen if the offending lines were removed.

I seem to remember this from a dailywtf:

@deprecated // he might have been crazy enough to use reflection...
boolean getTrue() {
    return false;
}

 2. Redundant checks done in a separate class file, object or method. Layers of communication are also imperfect (ever read Mythical Man Month? If not, what are you doing on the computer!? Go! READ!). Often, one person will work on something and then leave the project, and then the next guy, finding some bizarre bug, throws an extra check here and there to try to eliminate it. When the bug is removed, the checks aren't because, well, if it isn't broke, don't fix it.

 3. if statements that always evaluate to true. Oh, I've done this one. I got a project once, it had a series of probably 10-15 if/else blocks. To change the behavior, I simply put a true|| at the first block. It wasn't until months (years?) later that I came back and said, "Oh, wow, this code was supposed to have been destroyed but never was"

 4. Threads that spin off and do nothing of note. I can imagine a line of thought going like this:

I know! I can handle these two problems asyncronously! I'll create threads foo and bar.

(two months later) Huh, you know, the functionality from bar is a little bit better in foo. I'll move some over.

(one year later) You know, putting this other stuff from bar into foo makes sense.

(many, many years later) "Hey, this bar thread doesn't look like it is doing anything, can we remove it?" "Better not, it's been there many, many years..."


问:
How to save a young and dying project?
I am posting this anonymously because I don't want to get into potential trouble.

I have a big problem.

I recently joined a team that is less than a year old.  I have been here since a month in to the project started.  The company structure looks like this:

Owner (non-technical)

Project Manager (non-technical)

Lead Developer (Technical, but bad at it)

This project is a website using ASP.Net that the Lead Developer designed a horrible architecture for.  You will have to take my word at it, but basically, the way we are required to build web pages is giving us 3+ minute load times on a single web page over VPN in Debug mode.

It has spiraled to the point where other coworkers agree that they spend more of their day waiting for pages to load than actual development.

Now the big problem is this.  Project Manager does not know technology and admits it.  He has specifically stated that he trusts the Lead Developer to make the correct choices on application architecture.

No one on the team knows what the Owners opinion would be, but everyone is afraid to make waves in this economy (myself especially).

What would you do?

答: It sounds like the business, or at least the project is going to go under at some point soon. Short of quitting, I'd try to distance myself away from it as quickly as possible eg. volunteer/request work on other projects going. Hopefully over time, you'll be spending less time on this disaster, and more on other projects that have a chance of working.  You don't want to be thought of as 'the guy that worked on the project that didn't work'. It's all about protecting your reputation.</p>

Title: How to save a young and dying project?


问:
Is it possible to work with distrusting clients
One of our junior developers has been assigned a new client (we don't have the client yet, we're still working with him to see if we can meet his needs) and the junior developer said the client will hire us if we can do the work on his project without getting access to his server.

I've had a direct conversation with the client who turned out to have had his code stolen before by some offshore company that he outsourced. This made me more sympathetic but I still have mixed feelings about this.

On one hand I want to prove to the client that we're not all bad apples. Also if we do a good job with him, we get a loyal client who'll hire us for all his projects. I haven't heard of this happen before but I guess it happens more often than we'd all like to admit.

On the other hand I'm hesitant to accept working with him because deployment time is going to be a nightmare and no where in my career or education has anyone taught me how to work with clients like him. I (or the junior developer) would have to write a detailed description of exactly what to do with the source to deploy it and that is an annoying burden when I could deploy and test the whole thing in an hour myself.

As I said, I've never had to deal with this before (we're signing a non-disclosure but apparently so did the offshore company before us). We're not fully fully booked so it's not like I have an immediate replacement, but we're not begging for work either and I wonder if working under such restricted environment is worth the trouble.

Another side is that the experience itself could be rewarding for us, but is it experience worth having, as in what's even the likelihood of getting a similar client anytime soon. Are we even expected to comply with such clients?

So since I don't have any first hand experience with this and it definitely wasn't covered in school, how would those with longer experience working with clients deal with a distrusting client like this? Would you even accept the job?

答:
Try to differentiate yourselves in the eye of the client away from off-shore outsourced organizations. If you've had bad experiences with off-shore work, share that experience with the new client. Let them know that you and your outfit are completely different to the off-shore businesses. Everyone knows these off-shore developers are often not worth dealing with. Start by communicating in good English and look for ways to demonstrate your honesty. It's not hard to differentiate given the incredibly low standards out there, particularly for work done in poor countries.

Build your trust with this client gradually, and eventually he/she will come round and give you the access you need to do the job.

ContentLicense: CC BY-SA 2.5


答: You should design with testability in mind but if you don't have a dedicated tester then some things will simply slip through the cracks because there are not enough hours in the day to both design, implement and test software.</p>

Title: Should a developer also act as a tester?

Body:
We're a scrum team of 3 developers, 1 designer, the scrum master, and the product owner. However, we don't have official tester in our team. A problem that is always with us, is that, testing the application and passing those tests and removing bugs has been defined as one of the criteria to consider a PBI (Product Backlog Item) as done.

But the problem is that, no matter how much we (3 developers and 1 designer) try to test the application and implemented use cases, still some bugs are not seen and ruin our presentation (Murphy's law) to stakeholders.

As a remedy, we recommended that the company hire a new tester. Someone who's job would be testing, and testing only. An official professional tester.

However, the problem is that, scrum master and stakeholders believe that a developer (or a designer) should also be a tester.

Are they right? Should we developers (also designers) be testers too?


答:
Most answers boil down to these two simple facts:

[1] Code reflects the history of the code, and

[2] Code reflects the expected future of the code.

I have written functions that do nothing of value, IN THE CURRENT APPLICATION ENVIRONMENT given THE CURRENT SPECIFICATIONS, but may be needed in the future.

I have written if-statements that, AT PRESENT, always evaluate to true. But maybe in the past it could be false.

As to redundant checks, hey, I don't trust other code, I don't even trust my own code. If a module depends on N being 1 or 2 or 3 it darned well better make sure of that, and crash informatively if it isn't. It's illegitmate for Module B to explode because Module A screwed up; it is quite legitimate for Module B to complain that Module A screwed up. And remember that, next month, that parameter may be coming from the as-yet-unwritten Module C.

Title: Pointless Code In Your Source


问:
Dealing with multiple business requirement streams without compromising team size
A business has five discrete streams of business requirements to be implemented in software. There is a team of ten developers.

A "naiive" organisational solution is to split the team into five "teams" of two (one per requirements stream). But I feel this compromises the integrity of the team (making teamwork more difficult, causing silo effects, making communication harder etc).

Has anyone any insight into how best organise a developer team like this to deliver against multiple requirement streams? Is it workable to have fewer development teams than there are requirements streams?

答:
I would suggest two teams. 10 is really too many for a single team (too wide a knowledge spread will slow you down and a single team leader should not focus on 5 streams at once), but 5 on each should work comfortably and you can flex to 4:6 if pressures are heavy on one team.

You are absolutely correct that 5 teams is a naive view. If you lose even one person from a stream, you're in trouble; lose them both and you're going to struggle to survive.

It's fairly easy to have multiple streams going through one team. I would recommend a combination of Scrum and Kanban, but in the simplest case you just need a prioritised backlog of work and make it so that anyone on the team, on finishing one job, moves onto the next highest priority job, whatever the stream.

It's ok (in fact, inevitable) to have domain experts such that, if I pick up a job from stream 1 and I've zero knowledge of it, I can go to them for help. But it's important that I ultimately do the work and thus learn at least a little about all streams.

Code reviews also help spread that knowledge, as well as keeping your codebase at a high level of quality.


问:
Are custom DSLs still viable?
Are custom DSLs in JavaScript still viable, Specifically ones written with Antler, Boo, or the former Microsoft Oslo?

With the proliferation of open source JavaScript/ECMAScript engines (V8, IronJS, etc.), does it make more sense to write the functionality needed into one of those instead of writing an entirely new language?

答: DSLs are rarely built as "entirely new" languages. Most of the practical DSLs are built on top of the existing languages - e.g., jQuery is a DSL on top of Javascript. And those DSLs are not necessarily embedded DSLs - they can be standalone as well, but compiled into a combination of the existing languages instead of going all the way down to the low level. </p>

Title: Are custom DSLs still viable?


答:
no matter how much we (3 developers and 1 designer) try to test the application and implemented use cases, still some bugs are not seen and ruin our presentation... to stakeholders.

Consider performing a "controlled run" for a sprint or two, tracking dev and testing efforts separately. At the end of such run, analyze the collected data to find out how much effort you spend on testing.

If you find out that testing takes much effort, pass that data to management - it will be a compelling evidence supporting your request (much more compelling than you have now).

Otherwise (if you find your testing takes little time), consider investing additional effort into doing it better (or learning how to do that). Negotiate that additional effort you plan for with your management - because they may prefer to hire a tester instead. :)

...we recommended that the company hire a new tester. Someone who's job would be testing, and testing only. An official professional tester.

However, the problem is that, scrum master and stakeholders believe that a developer (or a designer) should also be a tester.

Have to admit, management of your company looks pretty lame to me. I mean - ok, it may be really difficult to find out how many testers would be best for the project, fine.

But to have at least one tester is just a safe bet - really funny that they hesitate to give it a try, while claiming themselves scrum / agile.


问:
If TDD is about design why do I need it?
TDD gurus more and more tell us that TDD is not about tests, it is about design. So I know some developers who create really great design without TDD. Should they practice TDD then?</p>

答:
TDD doesn't only help me come to the best final design, it helps me get there in fewer attempts.

I used to have two or three stabs at a problem before deciding which design I thought was best. Now, that exact same time is spent writing tests and focussing my mind on the correct design. And, as a bonus, it leaves me with a suite of repeatable tests. Win!

That said, there are inevitably going to be people for whom TDD offers nothing. As long as they still have automated, repeatable tests at the end of it, that's fine.


问:
Who becomes the product owner?
A business has five requirements streams, with a "stream leader" (called Product Manager, but this is an in-house term) per-stream and a backlog per-stream.

If we wanted to follow Scrum more closely, as I understand it, best practise would dictate the identification of a single product owner managing a single backlog containing requirements from all five streams (it's all just stuff to be done, right?), from which work is pulled by a self-organizing development team.

Can anyone lend any insight into how best identify the person to be the product owner and how best to explain and "sell" the modified approach to the existing stream leaders?

NB: I realize this is a very difficult question.

答:
If those "streams" produce requirements for a single system then yes, you need an overall product owner, most importantly because you need someone to prioritize the requirements.

Implementing functionality in the order in which it provides the most overall business benefit is the core philosophy of Scrum, and that's hard to do if priorities are assigned by five different people with probably sometimes conflicting goals.

That means, the product owner must have (or be given) authority over the "stream leaders" so that he can assign priorities freely. Obviously, if they have any proclivity at all towards empire-building, they will seek to prevent that at all costs. Only if they see the overall success of the product and company as their highest goal (or if the "stream leader" job is not seen as a power base) could you get them to agree by stressing that someone must take the bigger picture into account when managing the requirements.

Title: Who becomes the product owner?


答:
IMHO, one way of team forming could be:

Divide the developers such that each developer team don't get more than two concurrent projects (because more than that, dramatically decreases efficiency). For example, if you have 8 developers and 5 projects at hand, make 3 teams, 2 team with 3 developers each with 2 projects and one team with 2 developers with one project. Development won't need much coordination between teams if you really have different streams. However, if streams are much like each other, then as @pdf said, simply make two teams and divide projects between them.

Designers and testers doesn't need to be dedicated to one specific team. You can make a working pipeline. For example, testers and designers could function in a cross-team manner, that is, they can be ordered to design or test, without belonging to any specific team.

Title: Dealing with multiple business requirement streams without compromising team size

Body:
A business has five discrete streams of business requirements to be implemented in software. There is a team of ten developers.

A "naiive" organisational solution is to split the team into five "teams" of two (one per requirements stream). But I feel this compromises the integrity of the team (making teamwork more difficult, causing silo effects, making communication harder etc).

Has anyone any insight into how best organise a developer team like this to deliver against multiple requirement streams? Is it workable to have fewer development teams than there are requirements streams?


答:
What this particular TDD guru is really trying to say isn't that TDD is a design process (although a number of people have unfortunately interpreted it that way). The message here is that using a process such as TDD, if you do it right, will tend to improve your overall design.

The fundamental concept is one that's much older than TDD; designing for testability. If you rigorously adhere to the SOLID principles, especially the Single Responsibility Principle, you'll find code very easy to test.  On the other hand, if you tend to be a bit sloppier in your design, you'll probably find the process of writing unit tests to force you to do this more often, to avoid the frustration of (a) figuring out what needs to be tested, and (b) spending more time setting up dependencies than writing the actual tests.

You don't have to follow TDD to get the benefits of this, but it does help to write the tests early - preferably very soon after you implement a class, if not before or during.  If you wait too long, you run the risk of the "dirty hybrid" tests the author is talking about, which don't have a lot of value because they're brittle and tend to break during harmless refactoring - not to mention making larger-scale redesigns an excruciatingly difficult process.

You can't know if you're truly designing for testability if you don't write tests, and haphazard "feature tests" with only 15% code coverage don't count.

Of course you can create good designs without ever writing a single test - but are you sure they're great designs?  How do you know, if you they aren't clearly specified by tests?  Testing uncovers a lot of issues, and while a QA process may find visible bugs, they won't uncover poor design decisions.

Title: If TDD is about design why do I need it?

Body: TDD gurus more and more tell us that TDD is not about tests, it is about design. So I know some developers who create really great design without TDD. Should they practice TDD then?</p>


问:
What should you test with unit tests?
I'm freshly out of college, and starting university somewhere next week. We've seen unit tests, but we kinda not used them much; and everyone talks about them, so I figured maybe I should do some.

The problem is, I don't know what to test. Should I test the common case? The edge case? How do I know that a function is adequately covered?

I always have the terrible feeling that while a test will prove that a function works for a certain case, it's utterly useless to prove that the function works, period.

答:
Probably my opinion is not too popular. But I suggest that you to be economical with unit tests. If you have too many unit tests you can easily end up spending half of your time or more with maintaining tests rather than actual coding.

I suggest you to write tests for things you have a bad feeling in your gut or things that are very crucial and/or elementary. IMHO unit tests are not a replacement for good engineering and defensive coding. Currently I work on a project that is more or less unusuable. It is really stable but a pain to refactor. In fact nobody has touched this code in one year and the software stack it's based on is 4 years old. Why? Because it's cluttered with unit tests, to be precise: Unit tests and automatized integration tests. (Ever heard of cucumber and the like?) And here is the best part: This (yet) unusuable piece of software has been developed by a company whose employees are pioneers in the test-driven development scene. :D

So my suggestion is:

Start writing tests after you developed the basic skeleton, otherwise refactoring can be painful. As a developer who develops for others you never get the requirements right at the start.

Make sure your unit tests can be performed quickly. If you have integration tests (like cucumber) it's ok if they take a bit longer. But long running tests are no fun, believe me. (People forget all reasons why C++ has become less popular...)

Leave this TDD stuff to the TDD-experts.

And yes, sometimes you concentrate on the edge cases, sometimes on the common cases, depending where you expect the unexpected. Though if you always expect the unexpected, you should really rethink you workflow and discipline. ;-)

Title: What should you test with unit tests?


答:
There may be many ways to achieve great design, and there are unquestionably many different interpretations of what constitutes "great" - or even "good".  I suspect most TDDers would not agree with you about the definition - that if we were to look at the code you feel is great, we would consider it less than great.  TDD drives us to some very specific qualities, and these qualities are rarely found in non-TDD code.

Testability, obviously, is one of those qualities, and the overarching one.  Extremely small methods and classes are perhaps a sub-characteristic, and this leads to excellent naming.  Maybe you know programmers who achieve these qualities without doing TDD, but I don't.


答:
@Michael answer is one way to do it but there is also another one. In @Michael's answer the PO is above 5 stream leaders. It can sometimes work but if those five stream leaders are business persons from different departments they will hardly get someone from product development team to sit above them. They already have such person and it is usually top manager / executive.

In such scenario you can need another approach where PO is below these five stream leaders. These five stream leaders are not part of product development team - they are customers. PO is the one who communicates with customers and collect product backlog items and assign their priority based on customers needs. Sure it is up to stream leader to discus priorities of their items and assign final priorities satisfying all of them. If they are not able to do that it is up to their managers / executives to solve the problem.

This way where "stream leaders" communicates priorities among themselves to define priorities for whole backlog and not only for their items is common in Kanban.

There is one more reason why this can be desired in Scrum. Product owner should participate during development. He should be able to describe what is needed and make decisions if needed. That decision should come from knowledge about product backlog items collected from "stream leaders". Unless your stream leaders are able to participate on product development as well your product owner should be proxy between team and stream leaders. IMO this leads to better defined responsibilities.

Title: Who becomes the product owner?

Body:
A business has five requirements streams, with a "stream leader" (called Product Manager, but this is an in-house term) per-stream and a backlog per-stream.

If we wanted to follow Scrum more closely, as I understand it, best practise would dictate the identification of a single product owner managing a single backlog containing requirements from all five streams (it's all just stuff to be done, right?), from which work is pulled by a self-organizing development team.

Can anyone lend any insight into how best identify the person to be the product owner and how best to explain and "sell" the modified approach to the existing stream leaders?

NB: I realize this is a very difficult question.


问:
What should I do before open sourcing a project?
I am planning on opening sourcing a project that I've been working on for a while and that I think would benefit the community. I've already cleaned up the code, added a reasonable license, and wrote a packaging script for it that runs the unit tests, etc (it's Python, so that means setup.py). I wrote a README that describes the project, my motivations for writing the library, and the basics of how to use it.

What else is expected of me? Is hosting it on GitHub enough or is it expected that I maintain the PyPI packages too? What about testing it with other versions of libraries (I just defined the dependencies as the versions that I use)? What are some nice-to-haves that people really appreciate?

答:
My advice is to read one or more books or websites particularly targeted toward creating open source projects. There is a lot you can learn from people who have already done what you're wanting to do.

For example, one such book is Producing Open Source Software by Karl Fogel. This is available as a free ebook. Better than reading it, buy a copy to help support the author.

From the section "Who should read this book":

This book is meant for software developers and managers who are
  considering starting an open source project, or who have started one
  and are wondering what to do now. It should also be helpful for people
  who just want to participate in an open source project but have never
  done so before.

The reader need not be a programmer, but should know basic software
  engineering concepts such as source code, compilers, and patches.

At the time that I write this, the book has the following major sections:

Introduction

Getting Started

Technical Infrastructure

Social and Political Infrastructure

Money

Communications

Packaging, Releasing and Daily Development

Managing Volunteers

Governments and Open Source

License, Copyrights and Patents

OwnerDisplayName: guidoism

OwnerDisplayName: Bryan Oakley


答:
If you write software for a living, then the company you work for may feel entitled to the work you do either on their time (reasonable) or in your free time (debatable). After I read Intellectual Property and Open Source: A Practical Guide to Protecting Code, I realized that the safest bet is to discuss this project and your desire to open source it with your employer. Even if they don't have an issue in you releasing this code, it's better to know this up front than end up fired and being sued later.

Once you get the nod, the first thing you will want to do is license it and then publish it somewhere. After that, you can begin to respond to either new users or your own desires.

I've come to really appreciate a good ticket tracking system (that Github has) and a good test setup. Whether it be a virtual host that you install different versions of dependencies and run manual tests or fully automated functional/unit tests, being able to make a change and verify it works is essential.

Title: What should I do before open sourcing a project?

Body:
I am planning on opening sourcing a project that I've been working on for a while and that I think would benefit the community. I've already cleaned up the code, added a reasonable license, and wrote a packaging script for it that runs the unit tests, etc (it's Python, so that means setup.py). I wrote a README that describes the project, my motivations for writing the library, and the basics of how to use it.

What else is expected of me? Is hosting it on GitHub enough or is it expected that I maintain the PyPI packages too? What about testing it with other versions of libraries (I just defined the dependencies as the versions that I use)? What are some nice-to-haves that people really appreciate?


答:
Definitely upload to PyPi and keep it updated, it's really easy and doesn't take much effort. I should be able to use pip/easy_install to install the latest stable version.

Adding a README is a great first step, but having great documentation is even better, and for that you should use sphinx (nice tutorial here). Having quality documentation is crucial if you want people to use your project.


问:
Masters vs. PhD - long
I'm 21 years old and a first year master's computer science student. Whether or not to continue with my PhD has been plaguing me for the past few months. I can't stop thinking about it and am extremely torn on the issue. I have read http://www.cs.unc.edu/~azuma/hitch4.html and many, many other masters vs phd articles on the web. Unfortunately, I have not yet come to a conclusion.

I was hoping that I could post my ideas about the issue on here in hopes to 1) get some extra insight on the issue and 2) make sure that I am correct in my assumptions. Hopefully people who have experience in the respective fields can tell me if I am wrong so I don't make my decision based on false ideas.

Okay, to get this topic out of the way - money. Money isn't the most important thing to me, but it is still important. It's always been a goal of mine to make 6 figures, but I realize that will probably take me a long time with either path. According to most online salary calculating sites, the average starting salary for a software engineer is ~60-70k. The PhD program here is 5 years, so that's about 300k I am missing out on by not going into the workforce with a masters. I have only ever had ~1k at one time in my life so 300k is something I don't think I can accurately imagine. I know that I wouldn't have all of that at once obviously, but knowing I would be earning that is kinda crazy to me. I feel like I would be living quite comfortably by the time I'm 30 years old (but risk being too content too soon). I would definitely love to have at least a few years of my 20s to spend with that kind of money before I have a family to spend it all on. I haven't grown up very financially stable so it would be so nice to just spend some money…get a nice car, buy a new guitar or two, eat some good food, and just be financially comfortable. I have always felt like I deserved to make good money in my life, even as a kid growing up, and I just want to have it be a reality. I know that either path I take will make good money by the time I'm ~40-45 years old, but I guess I'm just sick of not making money and am getting impatient about it.

However, a big idea pushing me towards a PhD is that I feel the masters path would give me a feeling of selling out if I have the capability to solve real questions in the computer science world. (pretty straight-forward - not much to elaborate on, but this is a big deal)

Now onto other aspects of the decision.

I originally got into computer science because of programming. I started in high school and knew very soon that it was what I wanted to do for a career. I feel like getting a masters and being a software engineer in the industry gives me much more time to program in my career. In research, I feel like I would spend more time reading, writing, trying to get grant money, etc than I would coding.

A guy I work with in the lab just recently published a paper. He showed it to me and I was shocked by it. The first two pages was littered with equations and formulas. Then the next page or so was followed by more equations and formulas that he derived from the previous ones. That was his work - breaking down and creating all of these formulas for robotic arm movement. And whenever I read computer science papers, they all seem to follow this pattern. I always pictured myself coding all day long…not proving equations and things of that nature. I know that's only one part of computer science research, but that part bores me.

A couple cons on each side -

Phd - I don't really enjoy writing or feel like I'm that great at technical writing. Whenever I'm in groups to make something, I'm always the one who does the large majority of the work and then give it to my team members to write up a report. Presenting is different though - I don't mind presenting at all as long as I have a good grasp on what I am presenting. But writing papers seems like such a chore to me. And because of this, the "publish or perish" phrase really turns me off from research.
Another bad thing - I feel like if I am doing research, most of it would be done alone. I work best in small groups. I like to have at least one person to bounce ideas off of when I am brainstorming. The idea of being a part of some small elite group to build things sounds ideal to me. So being able to work in small groups for the majority of my career is a definite plus. I don't feel like I can get this doing research.

Masters - I read a lot online that most people come in as engineers and eventually move into management positions. As of now, I don't see myself wanting to be a part of management. Lets say my company wanted to make some new product or system - I would get much more pride, enjoyment, and overall satisfaction to say "I made this" rather than "I managed a group of people that made this." I want to be a big part of the development process. I want to make things.

I think it would be great to be more specialized than other people. I would rather know everything about something than something about everything. I always have been that way - was a great pitcher during my baseball years, but not so good at everything else, great at certain classes in school, but not so good at others, etc. To think that my career would be the same way sounds okay to me. Getting a PhD would point me in this direction. It would be great to be some guy who is someone that people look towards and come to ask for help because of being such an important contributor to a very specific field, such as artificial neural networks or robotic haptic perception. From what I gather about the software industry, being specialized can be a very bad thing because of the speed of the new technology.

When it comes to being employed, I have pretty conservative views. I don't want to change companies every 5 years. Maybe this is something everyone wishes, but I would love to just be an important person in one company for 10+ (maybe 20-25+ if I'm lucky!) years if the working conditions were acceptable. I feel like that is more possible as a PhD though, being a professor or researcher. The more I read about people in the software industry, the more it seems like most software engineers bounce from company to company at rapid paces. Some even work like a hired gun from project to project which is NOT what I want AT ALL. But finding a place to make great and important software would be great if that actually happens in the real world.

I'm a very competitive person. I thrive on competition. I don't really know why, but I have always been that way even as a kid growing up. Competition always gave me a reason to practice that little extra every night, always push my limits, etc. It seems to me like there is no competition in the research world. It seems like everyone is very relaxed as long as research is being conducted. The only competition is if someone is researching the same thing as you and its whoever can finish and publish first (but everyone seems to careful to check that circumstance). The only noticeable competition to me is just with yourself and your own discipline. I like the idea that in the industry, there is real competition between companies to put out the best product or be put out of business. I feel like this would constantly be pushing me to be better at what I do.

One thing that is really pushing me towards a PhD is the lifetime of the things you make. I feel like if you make something truly innovative in the industry…just some really great new application or system…there is a shelf-life of about 5-10 years before someone just does it faster and more efficiently. But with research work, you could create an idea or algorithm that last decades. For instance, the A* search algorithm was described in 1968 and is still widely used today. That is amazing to me. In the words of Palahniuk, "The goal isn't to live forever, its to create something that will."

Over anything, I just want to do something that matters. I want my work to help and progress society. Seriously, if I'm stuck programming GUIs for the next 40 years…I might shoot myself in the face. But then again, I hate the idea that less than 1% of the population will come into contact with my work and even less understand its importance.

So if anything I have said is false then please inform me. If you think I come off as a masters or PhD, inform me. If you want to give me some extra insight or add on to any point I made, please do. Thank you so much to anyone for any help.

答:
Here is the algorithm. You can turn this into a markov chain and calculate your odds.</p>

```<code>IF (I.CantStandVisualBasicSyntax) THEN
    BecomeASurfer()
END IF

IF (I.LikeProgramming AND I.WantMoneyBefore30) THEN
    PursueMasters()
ELSE IF (I.LikeProgramming AND I.CanWaitForMoney) THEN
    IF RAND(0, 1.0) < 0.1 THEN
        // Very Unlikely
        PursuePHD()
    ELSE
        PursueMasters()
    END IF
ELSE IF (I.LikeResearch) THEN
    // Unreachable code
    IF (I.CanWaitForMoney) THEN
        PursuePhd()
    ELSE IF (RAND(0, 1.0) < 0.1) THEN
        // Very unlikely
        PursuePhd()
    ELSE
        PursueMasters()
    End IF
Else
    BecomeASurfer()
End IF
</code>```

Title: Masters vs. PhD - long

Body:
Here is the algorithm. You can turn this into a markov chain and calculate your odds.

IF (I.CantStandVisualBasicSyntax) THEN
    BecomeASurfer()
END IF

IF (I.LikeProgramming AND I.WantMoneyBefore30) THEN
    PursueMasters()
ELSE IF (I.LikeProgramming AND I.CanWaitForMoney) THEN
    IF RAND(0, 1.0) < 0.1 THEN
        // Very Unlikely
        PursuePHD()
    ELSE
        PursueMasters()
    END IF
ELSE IF (I.LikeResearch) THEN
    // Unreachable code
    IF (I.CanWaitForMoney) THEN
        PursuePhd()
    ELSE IF (RAND(0, 1.0) < 0.1) THEN
        // Very unlikely
        PursuePhd()
    ELSE
        PursueMasters()
    End IF
Else
    BecomeASurfer()
End IF


答:
The choice is simple:

If you want to do computer science research, get a PhD.

If you want to learn advanced topics to be a better programmer, get a Masters.

Now, there are some misconceptions you have about PhD programs. Given your long entry, let me reply with bullet points:

You will be financially supported in a PhD program in the United States. This include tuition and money for rent, food, and a car. The pay, however, is mostly subsistence level.

Once you do have a PhD, you will be able to command a higher salary. Job openings for Google and Apple mention PhDs as "preferred," even when it's not a research position. [This could be that graduate school is the new bachelors, the signal that you are capable of completing significant and intense work.]

Yes, as a researcher you will be chasing money, writing papers, and reading related works. The amount that you code, however, entirely depends on the kind of school or company you end up at. In programs with few or no PhD students, you will be coding almost everything yourself. In lower-ranked or not-ranked PhD programs, you will be doing a large share of the coding. In top tier institutions, however, your students will be independent enough that you will not need to program at all. It all depends on what aspect of programming that you like. If it's creating and thinking creatively and problem finding that you love, you will get plenty of that conducting research.

How good or bad you are at technical writing now doesn't matter. Why? Because you will improve. Your advisor will whip you into shape. You'll also be reading books like George Gopen's The Sense of Structure: Writing from the Reader's Perspective.

I've never heard of any researcher being "too specialized" that their skills became completely obsolete due to technological change. A PhD knows enough of the fundamentals that they can forge new paths in the latest areas, always.

The research world is highly competitive! This is usually a downside of research, having to deal with rejection upon rejection, as reviewers miss all of the points of your brilliance, sometimes to hyper-macho degrees. You think it's a plus, however.

You may or may not hit a "home run" with your PhD. Yes, you may do something that changes the world, but most likely you will make something that shows you are competent at research.

Overall, you seem like the type who wants to run on all of your cylinders, at full capacity, covering all of your skills. When you are a researcher, you are your own boss and you decide what is worthy of study. That is academic freedom.

However, there is so much doubt in your message, I don't think you'd have the motivation to pull through the darker times of a six+ year program. Just to be sure, why don't you go for a Master's Thesis option and find an advisor. If you find you like research, then you will have just the right things to say when you are writing your personal statement for applying to a PhD program.

Title: Masters vs. PhD - long

Body:
I'm 21 years old and a first year master's computer science student. Whether or not to continue with my PhD has been plaguing me for the past few months. I can't stop thinking about it and am extremely torn on the issue. I have read http://www.cs.unc.edu/~azuma/hitch4.html and many, many other masters vs phd articles on the web. Unfortunately, I have not yet come to a conclusion.

I was hoping that I could post my ideas about the issue on here in hopes to 1) get some extra insight on the issue and 2) make sure that I am correct in my assumptions. Hopefully people who have experience in the respective fields can tell me if I am wrong so I don't make my decision based on false ideas.

Okay, to get this topic out of the way - money. Money isn't the most important thing to me, but it is still important. It's always been a goal of mine to make 6 figures, but I realize that will probably take me a long time with either path. According to most online salary calculating sites, the average starting salary for a software engineer is ~60-70k. The PhD program here is 5 years, so that's about 300k I am missing out on by not going into the workforce with a masters. I have only ever had ~1k at one time in my life so 300k is something I don't think I can accurately imagine. I know that I wouldn't have all of that at once obviously, but knowing I would be earning that is kinda crazy to me. I feel like I would be living quite comfortably by the time I'm 30 years old (but risk being too content too soon). I would definitely love to have at least a few years of my 20s to spend with that kind of money before I have a family to spend it all on. I haven't grown up very financially stable so it would be so nice to just spend some money…get a nice car, buy a new guitar or two, eat some good food, and just be financially comfortable. I have always felt like I deserved to make good money in my life, even as a kid growing up, and I just want to have it be a reality. I know that either path I take will make good money by the time I'm ~40-45 years old, but I guess I'm just sick of not making money and am getting impatient about it.

However, a big idea pushing me towards a PhD is that I feel the masters path would give me a feeling of selling out if I have the capability to solve real questions in the computer science world. (pretty straight-forward - not much to elaborate on, but this is a big deal)

Now onto other aspects of the decision.

I originally got into computer science because of programming. I started in high school and knew very soon that it was what I wanted to do for a career. I feel like getting a masters and being a software engineer in the industry gives me much more time to program in my career. In research, I feel like I would spend more time reading, writing, trying to get grant money, etc than I would coding.

A guy I work with in the lab just recently published a paper. He showed it to me and I was shocked by it. The first two pages was littered with equations and formulas. Then the next page or so was followed by more equations and formulas that he derived from the previous ones. That was his work - breaking down and creating all of these formulas for robotic arm movement. And whenever I read computer science papers, they all seem to follow this pattern. I always pictured myself coding all day long…not proving equations and things of that nature. I know that's only one part of computer science research, but that part bores me.

A couple cons on each side -

Phd - I don't really enjoy writing or feel like I'm that great at technical writing. Whenever I'm in groups to make something, I'm always the one who does the large majority of the work and then give it to my team members to write up a report. Presenting is different though - I don't mind presenting at all as long as I have a good grasp on what I am presenting. But writing papers seems like such a chore to me. And because of this, the "publish or perish" phrase really turns me off from research.
Another bad thing - I feel like if I am doing research, most of it would be done alone. I work best in small groups. I like to have at least one person to bounce ideas off of when I am brainstorming. The idea of being a part of some small elite group to build things sounds ideal to me. So being able to work in small groups for the majority of my career is a definite plus. I don't feel like I can get this doing research.

Masters - I read a lot online that most people come in as engineers and eventually move into management positions. As of now, I don't see myself wanting to be a part of management. Lets say my company wanted to make some new product or system - I would get much more pride, enjoyment, and overall satisfaction to say "I made this" rather than "I managed a group of people that made this." I want to be a big part of the development process. I want to make things.

I think it would be great to be more specialized than other people. I would rather know everything about something than something about everything. I always have been that way - was a great pitcher during my baseball years, but not so good at everything else, great at certain classes in school, but not so good at others, etc. To think that my career would be the same way sounds okay to me. Getting a PhD would point me in this direction. It would be great to be some guy who is someone that people look towards and come to ask for help because of being such an important contributor to a very specific field, such as artificial neural networks or robotic haptic perception. From what I gather about the software industry, being specialized can be a very bad thing because of the speed of the new technology.

When it comes to being employed, I have pretty conservative views. I don't want to change companies every 5 years. Maybe this is something everyone wishes, but I would love to just be an important person in one company for 10+ (maybe 20-25+ if I'm lucky!) years if the working conditions were acceptable. I feel like that is more possible as a PhD though, being a professor or researcher. The more I read about people in the software industry, the more it seems like most software engineers bounce from company to company at rapid paces. Some even work like a hired gun from project to project which is NOT what I want AT ALL. But finding a place to make great and important software would be great if that actually happens in the real world.

I'm a very competitive person. I thrive on competition. I don't really know why, but I have always been that way even as a kid growing up. Competition always gave me a reason to practice that little extra every night, always push my limits, etc. It seems to me like there is no competition in the research world. It seems like everyone is very relaxed as long as research is being conducted. The only competition is if someone is researching the same thing as you and its whoever can finish and publish first (but everyone seems to careful to check that circumstance). The only noticeable competition to me is just with yourself and your own discipline. I like the idea that in the industry, there is real competition between companies to put out the best product or be put out of business. I feel like this would constantly be pushing me to be better at what I do.

One thing that is really pushing me towards a PhD is the lifetime of the things you make. I feel like if you make something truly innovative in the industry…just some really great new application or system…there is a shelf-life of about 5-10 years before someone just does it faster and more efficiently. But with research work, you could create an idea or algorithm that last decades. For instance, the A* search algorithm was described in 1968 and is still widely used today. That is amazing to me. In the words of Palahniuk, "The goal isn't to live forever, its to create something that will."

Over anything, I just want to do something that matters. I want my work to help and progress society. Seriously, if I'm stuck programming GUIs for the next 40 years…I might shoot myself in the face. But then again, I hate the idea that less than 1% of the population will come into contact with my work and even less understand its importance.

So if anything I have said is false then please inform me. If you think I come off as a masters or PhD, inform me. If you want to give me some extra insight or add on to any point I made, please do. Thank you so much to anyone for any help.


答:
"Should one of the most popular encodings, UTF-16, be considered harmful?"

Quite possibly, but the alternatives should not necessarily be viewed as being much better.

The fundamental issue is that there are many different concepts about: glyphs, characters, codepoints and byte sequences. The mapping between each of these is non-trivial, even with the aid of a normalization library. (For example, some characters in European languages that are written with a Latin-based script are not written with a single Unicode codepoint. And that's at the simpler end of the complexity!) What this means is that to get everything correct is quite amazingly difficult; bizarre bugs are to be expected (and instead of just moaning about them here, tell the maintainers of the software concerned).

The only way in which UTF-16 can be considered to be harmful as opposed to, say, UTF-8 is that it has a different way of encoding code points outside the BMP (as a pair of surrogates). If code is wishing to access or iterate by code point, that means it needs to be aware of the difference. OTOH, it does mean that a substantial body of existing code that assumes "characters" can always be fit into a two-byte quantity — a fairly common, if wrong, assumption — can at least continue to work without rebuilding it all. In other words, at least you get to see those characters that aren't being handled right!

I'd turn your question on its head and say that the whole damn shebang of Unicode should be considered harmful and everyone ought to use an 8-bit encoding, except I've seen (over the past 20 years) where that leads: horrible confusion over the various ISO 8859 encodings, plus the whole set of ones used for Cyrillic, and the EBCDIC suite, and… well, Unicode for all its faults beats that. If only it wasn't such a nasty compromise between different countries' misunderstandings.

Title: Should UTF-16 be considered harmful?

Body:
I'm going to ask what is probably quite a controversial question: "Should one of the most
popular encodings, UTF-16, be considered harmful?"

Why do I ask this question?

How many programmers are aware of the fact that UTF-16 is actually a variable length encoding? By this I mean that there are code points that, represented as surrogate pairs, take more than one element.

I know; lots of applications, frameworks and APIs use UTF-16, such as Java's String, C#'s String, Win32 APIs, Qt GUI libraries, the ICU Unicode library, etc.  However, with all of that, there are lots of basic bugs in the processing of characters out of BMP (characters that should be encoded using two UTF-16 elements).

For example, try to edit one of these characters:

𝄞 (U+1D11E) MUSICAL SYMBOL G CLEF

𝕥 (U+1D565) MATHEMATICAL DOUBLE-STRUCK SMALL T

𝟶 (U+1D7F6) MATHEMATICAL MONOSPACE DIGIT ZERO

𠂊 (U+2008A) Han Character

You may miss some, depending on what fonts you have installed.  These characters are all outside of the BMP (Basic Multilingual Plane).  If you cannot see these characters, you can also try looking at them in the Unicode Character reference.

For example, try to create file names in Windows that include these characters; try to delete these characters with a "backspace" to see how they behave in different applications that use UTF-16. I did some tests and the results are quite bad:

Opera has problem with editing them (delete required 2 presses on backspace)

Notepad can't deal with them correctly (delete required 2 presses on backspace)

File names editing in Window dialogs in broken (delete required 2 presses on backspace)

All QT3 applications can't deal with them - show two empty squares instead of one symbol.

Python encodes such characters incorrectly when used directly u'X'!=unicode('X','utf-16') on some platforms when X in character outside of BMP.

Python 2.5 unicodedata fails to get properties on such characters when python compiled with UTF-16 Unicode strings.

StackOverflow seems to remove these characters from the text if edited directly in as Unicode characters (these characters are shown using HTML Unicode escapes).

WinForms TextBox may generate invalid string when limited with MaxLength.

It seems that such bugs are extremely easy to find in many applications that use UTF-16.

So... Do you think that UTF-16 should be considered harmful?


问:
What is the benefit of not using Hungarian notation?
One of the things I struggle with is not using Hungarian notation.  I don't want to have to go to the variable definition just to see what type it is.  When a project gets extensive, it's nice to be able to look at a variable prefixed by 'bool' and know that it's looking for true/false instead of a 0/1 value.

I also do a lot of work in SQL Server.  I prefix my stored procedures with 'sp' and my tables with 'tbl', not to mention all of my variables in the database respectively.

I see everywhere that nobody really wants to use Hungarian notation, to the point where they avoid it.  My question is, what is the benefit of not using Hungarian notation, and why does the majority of developers avoid it like the plague?

答:
Because its original intention (see http://www.joelonsoftware.com/articles/Wrong.html and http://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroids) has been misunderstood and it has been (ab)used to help people remember what type a variable is when the language they use is not statically typed. In any statically typed language you do not need the added ballast of prefixes to tell you what type a variable is. In many untyped script languages it can help, but it has often been abused to the point of becoming totally unwieldy. Unfortunately, instead of going back to the original intent of Hungarian notation, people have just made it into one of those "evil" things you should avoid.

Hungarian notation in short was intended to prefix variables with some semantics. For example if you have screen coordinates (left, top, right, bottom), you would prefix variables with absolute screen positions with "abs" and variables with positions relative to a window with "rel". That way it would be obvious to any reader when you passed a relative coordinate to a method requiring absolute positions.

update (in response to comment by delnan)

IMHO the abused version should be avoided like the plague because:

it complicates naming. When (ab)using Hungarian notation there will always be discussions on how specific the prefixes need to be. For example: listboxXYZ or MyParticularFlavourListBoxXYZ.

it makes variable names longer without aiding the understanding of what the variable is for.

it sort of defeats the object of the exercise when in order to avoid long prefixes these get shortened to abbreviations and you need a dictionary to know what each abbreviation means. Is a ui an unsigned integer? an unreferenced counted interface? something to do with user interfaces? And those things can get long. I have seen prefixes of more than 15 seemingly random characters that are supposed to convey the exact type of the var but really only mystify.

it gets out of date fast. When you change the type of a variable people invariably ( lol ) forget to update the prefix to reflect the change, or deliberately don't update it because that would trigger code changes everywhere the var is used...

it complicates talking about code because as "@g ." said: Variable names with Hungarian notation are typically difficult-to-pronounce alphabet soup. This inhibits readability and discussing code, because you can't 'say' any of the names.

... plenty more that I can't recall at the moment. Maybe because I have had the pleasure of not having to deal with the abused Hungarian notation for a long while...

ContentLicense: CC BY-SA 4.0


答:
the reason it is avoided is because of systems hungarian which violates DRY (the prefix is exactly the type which the compiler and (a good) IDE can derive)

apps hungarian O.T.O.H. prefixes with the use of the variable (i.e. scrxMouse is a x coordinate on the screen this can be an int, short, long or even a custom type (typedefs will even allow you to change it easily))

the misunderstanding of systems is what destroyed hungarian as a best practice

Title: What is the benefit of not using Hungarian notation?

Body:
One of the things I struggle with is not using Hungarian notation.  I don't want to have to go to the variable definition just to see what type it is.  When a project gets extensive, it's nice to be able to look at a variable prefixed by 'bool' and know that it's looking for true/false instead of a 0/1 value.

I also do a lot of work in SQL Server.  I prefix my stored procedures with 'sp' and my tables with 'tbl', not to mention all of my variables in the database respectively.

I see everywhere that nobody really wants to use Hungarian notation, to the point where they avoid it.  My question is, what is the benefit of not using Hungarian notation, and why does the majority of developers avoid it like the plague?


答:
Wikipedia has a list of advantages and disadvantages of the hungarian notation and can thus probably provide the most comprehensive answer to this question. The notable opinons are also a quite interesting read.

The benefit of not using hungarian notation is basically only avoidance of its disadvantages:

The Hungarian notation is redundant when type-checking is done by the compiler. Compilers for languages providing type-checking ensure the usage of a variable is consistent with its type automatically; checks by eye are redundant and subject to human error.

All modern Integrated development environments display variable types on demand, and automatically flag operations which use incompatible types, making the notation largely obsolete.

Hungarian Notation becomes confusing when it is used to represent several properties, as in a_crszkvc30LastNameCol: a constant reference argument, holding the contents of a database column LastName of type varchar(30) which is part of the table's primary key.

It may lead to inconsistency when code is modified or ported. If a variable's type is changed, either the decoration on the name of the variable will be inconsistent with the new type, or the variable's name must be changed. A particularly well known example is the standard WPARAM type, and the accompanying wParam formal parameter in many Windows system function declarations. The 'w' stands for 'word', where 'word' is the native word size of the platform's hardware architecture. It was originally a 16 bit type on 16-bit word architectures, but was changed to a 32-bit on 32-bit word architectures, or 64-bit type on 64-bit word architectures in later versions of the operating system while retaining its original name (its true underlying type is UINT_PTR, that is, an unsigned integer large enough to hold a pointer). The semantic impedance, and hence programmer confusion and inconsistency from platform-to-platform, is on the assumption that 'w' stands for 16-bit in those different environments.

Most of the time, knowing the use of a variable implies knowing its type. Furthermore, if the usage of a variable is not known, it can't be deduced from its type.

Hungarian notation strongly reduces the benefits of using feature-rich code editors that support completion on variable names, for the programmer has to input the whole type specifier first.

It makes code less readable, by obfuscating the purpose of the variable with needless type and scoping prefixes.

The additional type information can insufficiently replace more descriptive names. E.g. sDatabase doesn't tell the reader what it is. databaseName might be a more descriptive name.

When names are sufficiently descriptive, the additional type information can be redundant. E.g. firstName is most likely a string. So naming it sFirstName only adds clutter to the code.

I myself don't use this notation, because I dislike the unnecessary technical noise. I nearly always know which type I am dealing with and I want a clean language in my domain model, but I write mostly in statically and strongly typed languages.


答:
Hungarian notation is a naming anti-pattern in modern day programming environments and form of Tautology.

It uselessly repeats information with no benefit and additional maintenance overhead. What happens when you change your int to a different type like long, now you have to search and replace your entire code base to rename all the variables or they are now semantically wrong which is worse than if you hadn't duplicated the type in the name.

It violates the DRY principle. If you have to prefix your database tables with an abbreviation to remind you that it is a table, then you are definitely not naming your tables semantically descriptively enough. Same goes for every other thing you are doing this with. It is just extra typing and work for no gain or benefit with a modern development environment.


答:
I'll just focus on SQL Server since you mentioned it. I see no reason to put 'tbl' in front of a table. You can just look at any tSQL code and distinguish a table by how it is used. You would never Select from stored_procedure. or Select from table(with_param) like you would a UDF or Execute tblTableOrViewName like a stored procedure.

Tables could be confused with a View, but when it comes to how they are used; there is no difference, so what is the point? The Hungarian notation may save you the time of looking it up in SSMS (under table or views?), but that's about it.

Variables can present a problem, but they need to be declared and really, how far from your declare statement do you plan on using a variable? Scrolling a few lines shouldn't be that big of a deal unless you're writing very long procedures. It may be a good idea to break up the lengthy code a little.

What you describe is a pain, but the Hungarian Notation solution doesn't really solve the problem. You can look at someone else's code and find that the variable type may get changed which now requires a change to the variable name. Just one more thing to forget. And if I use a VarChar your're going to need to look at the declare statement anyway to know the size. Descriptive names will probably get you further. @PayPeriodStartDate pretty much explains itself.


答:
As a MS SQL Server specific problem:

Any stored procedures prefixed with 'sp_' are first searched for in
  the Master database rather than the one it is created in. This will
  cause a delay in the stored procedure being executed.


问:
What does it mean to be agile?
We have a project that everyone says we will be doing in a agile way but I doubt we have clearly understood what agile is.

In previous projects we had planning meetings, then defined the product back log and allocated the work to developers in 2 to 3 week sprints. Every morning we had scrum meetings (which seemed to go on for 1/2 an hour each time) and each developer got on with it after that. Hardly anyone wrote any tests until at the end of sprint and work that was not completed was added on to the next sprint.

Developers hardly spoke to each other and there was no TDD involved in development. In fact most developers had a spec at the start and just got on with it for the 2 or 3 weeks the sprint was arranged for. There was hardly any communication with the client/stake holder.

QA got involved usually a few months later and by then we found missing requirements which further increased the amount of work we had to do. Clearly there was no feedback loop.

So my question is, where did we go wrong and how can I prevent the team from making the same mistakes.

答:
What you are describing isn't Agile by definition (Agile Manifesto)  it is Waterfall with daily status meetings. Agile means easily adapting to change, if there is no interactive feedback loop with the product owner and thus the customers, then what change is occurring?

Agile is about rapid failures, through constant communication with the product owner/customers. It is better to fail sooner than later, less work is done, and less is "lost". And you don't get stuck with the argument, that "we don't have time to do it correctly, since we spent so much time doing it wrong, we just need to continue on this same path, even though it leads to failure".

Sounds like your managment is doing "SCRUM, but ..." where the "but" is where they throw out all the SCRUM stuff that they don't understand or agree with and just do things the same haphazard waterfall way as always, but with new shiny buzzword names to it all.

In SCRUM the daily stand up is NOT about delivering status to management, it is to force developer interaction, so you know what your fellow team members are doing and can help each other out and not duplicate work. If it takes more than 45 seconds per person you are doing it wrong. It is about transparency for the team, if one person is giving the same status multiple days on something that should be a single days worth of work, the team can resolve the persons problem sooner than later.

If you aren't testing each others code as it is written, then you aren't doing it correctly either. Testing should be embedded into the process not an after thought. QA should be included in the planning sessions and give estimates on how long things will take to test.

If you are not meeting Sprint commitments and rolling things over, you aren't doing it correctly. Sprints are about commitments if you are committing to too much work, stop doing that, there is no way you can introduce any predictibility or repeatability if you can't accurately commit to deliverables.

Title: What does it mean to be agile?


答:
if the team (and its management) truly want to "be agile," they should start by reading and discussing as a team the Agile Manifesto and its principals. Then pick one of the agile methodologies that have been created (Scrum, for example), get some training on it, and start by following that. I'd recommend following it pretty closely for a while before modifying it, but that's just me.

They should also look deeply into Engineering Practices which are used to support the particular agile project methodology chosen.

Title: What does it mean to be agile?

Body:
We have a project that everyone says we will be doing in a agile way but I doubt we have clearly understood what agile is.

In previous projects we had planning meetings, then defined the product back log and allocated the work to developers in 2 to 3 week sprints. Every morning we had scrum meetings (which seemed to go on for 1/2 an hour each time) and each developer got on with it after that. Hardly anyone wrote any tests until at the end of sprint and work that was not completed was added on to the next sprint.

Developers hardly spoke to each other and there was no TDD involved in development. In fact most developers had a spec at the start and just got on with it for the 2 or 3 weeks the sprint was arranged for. There was hardly any communication with the client/stake holder.

QA got involved usually a few months later and by then we found missing requirements which further increased the amount of work we had to do. Clearly there was no feedback loop.

So my question is, where did we go wrong and how can I prevent the team from making the same mistakes.


答: As others here have said the developers can cross-test each others' code (unit or functional testing), and perhaps your scrum master and product owner can help with integration testing, but for user acceptance testing you should be making sure you're getting lots of feedback from the customer's testing - which means frequent deployments that they can work with in the way that real users do and a really open communications channel.


问:
Does agile development need a framework in place first?
We are planning a new project and we want to go with a services oriented architecture.
Everyone agrees that this is the way to go but how does this fit in with starting the development using agile methodologies?

I do not have any experience with SOA, although I have some experience with TDD (test driven development). The team I work with thinks that we need a framework in place before we can even start looking at developers doing work with TDD. In others we spend weeks getting a framework in place (a SOA framework) and then the developers can build on this framework to do their work.

From a TDD point of view, I would have expected each developer to just flesh out the functionality using MOCKs etc whilst the framework is being developed (although I have no idea what a framework in SOA would involve). Then we could plug in the actual framework calls when we need to. Not sure if this right but it feels the correct way.

答: Definitely not. Agile is based on small increments and constant feedback. Starting with a framework is more likely to generate scope creep and besides that, you won't be having anything to show in, at least, the first month of development. It's much more important to be on the same wavelength with the stakeholders, so being able to show some working functionality (even if it's just a mockup) very fast is more important than a framework. You can flesh out the framework as you develop your application and you can later evolve it into something you will use in other projects.</p>


问:
Are enforced Professional Development Plans useful?
Many companies, especially larger ones have mandatory professional development plans for their employees. Employees and managers set out a personalized professional development plan and follow up on the progress every so often.

As a developer, do you find such PDPs useful, do you follow through with your commitments?

As a manager, do you think such PDPs bring value to the company and improve the overall quality of the employees?

It seems that good developers will continue to educate themselves and strive to be better regardless of companies' procedures while bad ones won't.

Are there benefits of having PDPs or is it just something managers feel they need to do?

答:
I love the idea that my employer is at least pretending to be concerned about my career development.  Frankly though, this is a good thing.  The more money you invest in your employee's self-betterment and overall career progression, the more you invest in your company.</p>

```<code>Smarter, healthy, more qualified employees = better work = more money = everyone happy.
</code>```

Body:
I love the idea that my employer is at least pretending to be concerned about my career development.  Frankly though, this is a good thing.  The more money you invest in your employee's self-betterment and overall career progression, the more you invest in your company.

Smarter, healthy, more qualified employees = better work = more money = everyone happy.


问:
How should contributions to an open source project be managed by the owner(s)?
When managing an open source project (using a service like GitHub) how would one respond to the following:

Somebody has kindly submitted a patch to add a new feature or address a problem. Any one of the following situations occur:

The source code doesn't meet one or more naming conventions, etc.

I feel that the source code could be improved in a certain way. Perhaps the same effect can be achieved with far simpler source, or perhaps another useful feature would be needed.

Q1. Is it acceptable for me to alter the submitted source? (is this possible on GitHub?)

Q2. Should all such submissions be rejected in accordance with submission guidelines?

Q3. If yes to Q2, what about a really neat idea that was poorly implemented? Is it acceptable for me to just go ahead and create my own?

I want to encourage contribution but at the same time it is important to maintain a certain standard.

答:
Set up, if you haven't already, a document that describes the project's standards. Be sure to outline everything you feel is important when contributing code to your project.

Then, respond to the person who supplied the code detailing that you very much appreciate the contribution, and that you would like to include the patch, but there are some issues. Provide a link to the document and cite the particular issues you see. Then, ask that person to fix the issues and resubmit the code.


答:
Doing a lot of upfront design (which you will need if you want to build a good framework) is not what agile is about. Especially the first increments are quickly deployed using agile methodologies.

My gut feeling says your choice for a services oriented architecture might be the problem. I'm not saying you shouldn't do any architecture in an Agile project but the first increments will guide you towards a good architecture. If you're really doing an agile project you will let requirements guide you to the right architecture by refactoring old pieces of code to newer insights.

Title: Does agile development need a framework in place first?

Body:
We are planning a new project and we want to go with a services oriented architecture.
Everyone agrees that this is the way to go but how does this fit in with starting the development using agile methodologies?

I do not have any experience with SOA, although I have some experience with TDD (test driven development). The team I work with thinks that we need a framework in place before we can even start looking at developers doing work with TDD. In others we spend weeks getting a framework in place (a SOA framework) and then the developers can build on this framework to do their work.

From a TDD point of view, I would have expected each developer to just flesh out the functionality using MOCKs etc whilst the framework is being developed (although I have no idea what a framework in SOA would involve). Then we could plug in the actual framework calls when we need to. Not sure if this right but it feels the correct way.


答:
Agile is many things to many people and some feel strongly about those things than other.  Read Agile manifesto.  This is just my opinion, but at the end of the day Agile is about doing what's right with minimal amount of overhead and using whatever good and proven methods/techniques (i.e. TDD...) that make sense for your specific situation.

As others have already mentioned, most agile teams strive to deliver small increments in small iterations.  And whenever possible you should be doing the same thing.  At the same time, it pays to have the right design done upfront.  If your application requires a framework, by all means go ahead and put the framework in place.  Yes, you will not be able to deliver anything working for several weeks and maybe more, but if you and your team feel that you need it, then do it. The corner stone of Agile is that it's about people, do what people believe you need to do and they will have your back and be vested in the product. We used to force constraints that made the entire team feel weird and awkward and that's just bad.

At the same time keep in mind that you can treat your framework as a separate deliverable that must be delivered to a "development team" so that the team can deliver the final product.  Most of the time after the minimal foundation is in place, you can work on framework in increments just like you would on actual product.  Decide the absolute minimum you would need from the framework to make the product do something and focus on that first.

Also IMHO, take the phrase "no big design upfront because you are agile" with a grain of salt.  Although you definitely do not need to go into details and spend 6 weeks writing design documents, for a large scale project it still pays to spend some time thinking about overall architecture and high-level design.  Put the big pieces in their right places so your team has a clear roadmap where you want to end up.  Because you only do high-level design, if your direction changes, you will only need to update high-level documentation (shouldn't be a lot).  I would never rely on refactoring alone to dictate the final structure of a large application.  Your goal is to do minimal design NEEDED, not absolute minimum to a point where there's virtually no design upfront and requirements drive evolution of your modules.

Finally, just because you can't deliver anything actually working until the entire framework is in place, it doesn't mean you can't chop up the framework into several pieces and focus on each one individually along with TDD.  You can abstract away SOA interfaces, database, network communications, some other back-end logic and even though all of this must be in the framework, you can do write each one using TDD and mock up whatever interfaces those pieces will talk to.  Some of your team can start working on actual application code using mock classes that pretend that your final framework is in place.

So forget about methodology, take a step back and ask yourself (and the team), is SOA the right approach for this application? If it is, you can definitely make it work with agile.


答:
Agile is only a software development methodology. To understand it better, imagine that you work in a car manufacturing company. Agile just tells you how to manage your work to create a car better (not necessarily to create a better car). However, it doesn't require you to have engine manufacturing pipeline in place first.

Agile is all about breaking long periods of development into smaller periods (sprints) to give developers and businessmen a chance to understand which way they should go sooner, so that they can act more flexibly.

A team can start agile methodology, even without having a framework. In that case, one of the Product Backlog Items could be As a developer, I want to create a framework, so that I can develop faster.

Thus the answer is no, agile doesn't need you to have a framework in place first.


答:
I think the reasons not to use Hungarian notation have been well covered by other posters.  I agree with their comments.

With databases I use Hungarian notation for DDL objects that are rarely used in code, but would otherwise collide in namespaces.  Mainly this gets down to prefixing indexes and named constraints with their type( PK, UK, FK, and IN ).  Use a consistent method to name these objects and you should be able to run some validations by querying the metadata.


答:
Hungarian notation is almost completely useless in a statically typed language. It's a basic IDE feature to show the type of a variable by putting the mouse over it, or by other means; moreover you can see what the type is by looking a few lines up where it was declared, if there's no type inference. The whole point of type inference is to not have the noise of the type repeated everywhere, so hungarian notation is usually seen as a bad thing in languages with type inference.

In dynamically typed languages, it can help sometimes, but to me it feels unidiomatic. You already gave up your functions being restricted to exact domains/codomains; if all your variables are named with hungarian notation, then you are just reproducing what a type system would have given you. How do you express a polymorphic variable that can be an integer or a string in hungarian notation? "IntStringX"? "IntOrStringX"? The only place I've ever used hungarian notation was in assembly code, because I was trying to get back what I'd get if I had a type system, and it was the first thing I've ever coded.

Anyways, I could care less what people name their variables, the code will probably still be just as incomprehensible. Developers waste way too much time on things like style and variable names, and at the end of the day you still get a ton of libraries with completely different conventions in your language. I'm developing a symbolic (i.e: non text-based) language where there are no variable names, only unique identifiers, and suggested names for variables (but most variables still have no suggested name because there simply does not exist a reasonable name for them); when auditing untrusted code, you can't depend on variable names.


答:
Agile development approach can be greatly complemented by a framework and the structure of your code.

At the risk of being bashed for linking to my own project, I've been working on a framework specifically optimized for Agile Development. Here is small except from documentation explaining approach to application building with very vivid requirements. It's still work in progress but should be able to answer your question.

http://agiletoolkit.org/learn/app


答:
Another thing to add is that, what abbreviations would you use for an entire framework  like .NET? Yeah, it's so simple to remember that btn represents a button and txt represents a text box. However, what do you have in mind for something like StringBuilder? strbld? What about CompositeWebControl? Do you use something like this:

```<code>CompositeWebControl comWCMyControl = new CompositeWebControl();
</code>```

One of the inefficiencies of the Hungarian notation was that, by having larger and larger frameworks, it proved not only not to add extra benefit, but also to add more complexity for developers, because they now had to learn the nonstandard prefixes more and more.

Body:
Another thing to add is that, what abbreviations would you use for an entire framework  like .NET? Yeah, it's so simple to remember that btn represents a button and txt represents a text box. However, what do you have in mind for something like StringBuilder? strbld? What about CompositeWebControl? Do you use something like this:

CompositeWebControl comWCMyControl = new CompositeWebControl();

One of the inefficiencies of the Hungarian notation was that, by having larger and larger frameworks, it proved not only not to add extra benefit, but also to add more complexity for developers, because they now had to learn the nonstandard prefixes more and more.


问:
How to model future iPhone application GUI?
Say you're working on designing the world's greatest iPhone app.

How do you decide what UI would be more effective, would be more intuitive etc? How do you take an idea and decide how to visually represent it?

Do you use any programs (on a mac) to model something like that?

答:
People are hard to model.  Testing is the best solution.

Mock up the app GUI on paper, or as a small web site if possible, and find people representing your assumed user demographic on which to user test it.  Iterate and improve the fidelity of the prototype or mockup as you go.  When you get enough functionality to be even slightly useful, distribute or even ship several well instrumented prototypes and examine the usage feedback.

Be creative or borrow the best paradigms from any related successful, popular or common products (not just including apps).