答:
In my experience, having worked in 3 very different industries now, you can start out not knowing much about the domain, but you'll need to learn it eventually and someone will have to understand it to a detailed degree.

The essential problem is down to the client-developer impedance: they want something but will only know it when they see it and you want to solve their problem but can't always get a clear idea of what that problem is.  The more domain knowledge of their (the client's) industry you (the developer) can bring, the easier you can translate vague "wants" into concrete "problems" and solve them.

As an anecdotal example, my previous job was in the chemical industry involving plant management software.  I started with effectively zero knowledge of the domain, but was able to implement the code I needed to solve sub-problems presented to me by the senior developer and the clients.  Over time, I made the effort to learn the industry, so that I could communicate more readily on the client's level.  As I understood their industry, I began to understand what the actual problems were.  When they say things like "we need to track all the data values on this module" I can translate that into what they really mean, which is "we need to keep a historical record of each value this sensor generates, stored for X days of retention, but always evaluated based on the most recent reading from that sensor."  A lot of domain problems have hidden rules (like retention periods on data) that the clients have internalized, but you need made explicit.

So yes, someone needs domain knowledge, and preferably a developer because domain problems are not code problems and translating between the two is not trivial.  Eventually, any developers worth keeping on your team should pick up the domain, so they can make more informed choices about the nuances of their code.


问:
Must developers understand the business domain or should the specification be sufficient?
I work for a company for which the domain is really difficult to understand because it is high technology in electronics, but this is applicable to any software development in a complex domain.

The application that I work on displays a lot of information, charts, and metrics which are difficult to understand without experience in the domain. The developer uses a specification to describe what the software must do, such as specifying that a particular chart must display this kind of metrics and this metric is the following arithmetic formula.

This way, the developer doesn't really understand the business and what/why he is doing this task. This can be OK if specification is really detailed but when it isn't or when the author has forgotten a use case, this is quite hard for the developer to find a solution.

At the other hand, training every developer to all the business aspects can be very long and difficult.

Should we give more importance to detailed specification (but as we know, perfect specification does not exist) or should we train all the developers to understand the business domain?

EDIT: keep in mind in your answer that the company could used external developers and that a formation to all the domain can be about 2 weeks

答:
I really understand what you mean here because we, as company in a tourism industry, faced the same problem. When I was a junior developer, I was also studying tourism at a college. So, you can guess that I am not coming from a computer science background but my tourism knowledge is high.

We were building products in relation with other software companies back then, but domain specific knowledge was lacking a lot. As you described, it is really hard to get it right if you are building a product in tourism industry as there are many cross-cutting concerns, etc.

So, this movement gave a lot of bad results in the long term. Then, we took a huge step forward, and I started to focus only on development rather than the business part of the project. As I have the industrial knowledge and the programming knowledge, the project grows more efficient than ever. Not to mention, we can then make decisions faster since I have the experience on both sides of the coin.

As a concrete answer to your question, it is certainly yes in my personal opinion. If the project your team is working on is a long term project, then take the hard road and train your staff on domain specific fundamentals and details.

OwnerDisplayName: Jerome C.

ContentLicense: CC BY-SA 3.0


答:
From personal experience, the specification is enough as long as you've got someone on the team working with you that does have the domain knowledge.

I work in a very specialized industry: we make software for broadcast media. I barely know a thing about broadcasting, but I know code and I know data, and I've got good people on the project management team that understand broadcasting. That formula's been good enough for the past few years for me to come up with good functionality that the clients like.

Title: Must developers understand the business domain or should the specification be sufficient?

Body:
I work for a company for which the domain is really difficult to understand because it is high technology in electronics, but this is applicable to any software development in a complex domain.

The application that I work on displays a lot of information, charts, and metrics which are difficult to understand without experience in the domain. The developer uses a specification to describe what the software must do, such as specifying that a particular chart must display this kind of metrics and this metric is the following arithmetic formula.

This way, the developer doesn't really understand the business and what/why he is doing this task. This can be OK if specification is really detailed but when it isn't or when the author has forgotten a use case, this is quite hard for the developer to find a solution.

At the other hand, training every developer to all the business aspects can be very long and difficult.

Should we give more importance to detailed specification (but as we know, perfect specification does not exist) or should we train all the developers to understand the business domain?

EDIT: keep in mind in your answer that the company could used external developers and that a formation to all the domain can be about 2 weeks


答:
I think a developer who knows the business is worth their weight in gold.

In a "traditional" scenario where the business has some requirements and some business analysts translate those into technical requirements then the developer works off of those you inevitably have two things which can happen:

You have multiple points of failure. The business analyst may not have gotten all the business requirements translated perfectly and/or the developer
may not translate those into a technical specification perfectly. A variant
on the "secret around the room" scenario. Just the exigencies of
communication.

One or all of the business owner, business analyst or developer are new enough to the organization to miss key items that they wouldn't think about
normally. The seasoned developer who knows the business well can
assist in educating the people in those other roles to make the
product more complete.


问:
Best practices in versioning
I develop some scripts for data analysis in a small team. For the moment we use SVN, but not in a very structured way. We haven't even looked how to use branches even though we need this functionality.

What do you suggest as the best practice to setup the following system:

two code bases (core and plugins)

versions can be incompatible to previous scripts

sometimes individual features are being developed and not yet finished, while other fixes have to be done urgently to the code

In the end we don't deliver the code as a package, but rather place the Python scripts in some directory (with version names?). Some other python script which serves as a configuration choses the desired version, sets the path to these libraries and then starts to import the modules.

I saw stable releases to be named "trunk" so I did the same. However, no version numbers yet. Core and plugins are different repositories, however we have to match versions for compatibility.
Can you suggest some best practices or reference to ease development and reduce chaos? :)
Some suggested GIT. I haven't heard about it, but I'm free to change.

答:
Well, I'm no SVN ninja or anything, but for the two projects, you'd simply have two folders at the top level. Each of those would have some folders:

Release, which would have tags or copies of the project that you decided to give a version number to. And you should really start giving them version numbers.

Trunk, this isn't the "stable releases" folder, but rather where the main development code lives. At some point you're going to release. You call the current trunk "the release version" and tag it or copy it off to the release folder. At that point in time the trunk and the release are the same, but the trunk keeps growing.

Branch, this is where work gets done. If you want to write some code or change something, you copy the trunk off to your own branch, dink with it, test it, (get someone to code review it for sanity), and then merge it back into the trunk. And then retest it.

The releases and tags let you keep track of what version is compatible with what. And the branches should let you develop long-haul items and still make quick urgent bug-fixes.

Haven't tried git yet, it may be fantastic.

Title: Best practices in versioning


问:
Why not write all tests at once when doing TDD?
The Red - Green - Refactor cycle for TDD is well established and accepted. We write one failing unit test and make it pass as simply as possible. What are the benefits to this approach over writing many failing unit tests for a class and make them all pass in one go.

The test suite still protects you against writing incorrect code or making mistakes in the refactoring stage, so what's the harm? Sometimes it's easier to write all the tests for a class (or module) first as a form of 'brain dump' to quickly write down all the expected behavior in one go.

答:
Assuming that your test framework supports it, what I would suggest is that instead of implementing the tests you want to braindump, instead write descriptive pending tests that you will later implement.  For example, if your API should do foo and bar but not biz, just add the following code (this example is in rspec) for your test suite, then attack them one by one.  You get your thoughts down quickly and can address all your issues one by one.  When all the tests pass you will know when you have addressed all your issues you had during your braindump.

```<code>describe "Your API" do

  it "should foo" do
    pending "braindump from 4/2"
  end

  it "should bar" do
    pending "braindump from 4/2"
  end

  it "should not biz" do
    pending "braindump from 4/2"
  end

end
</code>```

Body:
Assuming that your test framework supports it, what I would suggest is that instead of implementing the tests you want to braindump, instead write descriptive pending tests that you will later implement.  For example, if your API should do foo and bar but not biz, just add the following code (this example is in rspec) for your test suite, then attack them one by one.  You get your thoughts down quickly and can address all your issues one by one.  When all the tests pass you will know when you have addressed all your issues you had during your braindump.

describe "Your API" do

  it "should foo" do
    pending "braindump from 4/2"
  end

  it "should bar" do
    pending "braindump from 4/2"
  end

  it "should not biz" do
    pending "braindump from 4/2"
  end

end


答:
Based on my experience*, a single individual with good knowledge of the problem domain and good knowledge of software development is more likely to find the optimal solution to a problem than two individuals, one with excellent knowledge of the problem domain and one with excellent knowledge of software development, working together.

I think it comes down to the simple fact that the communication that happens in the brain of a single individual is many times faster and better than the communication between individuals.

*The main experience I am drawing on to answer this question is 10+ years spent on developing an accounting software package (from inception to 'maintenance mode'). Although my knowledge of software development was pretty good, as compared to my colleagues, I often felt handicapped by a lack of understanding of the problem domain.


问:
What does an MSDN subscription offer?
I'm curious because I notice that the Ultimate subscription costs $12,000... for one year (after that, it's $3,800 to renew). Looking at the subscription chart, you do get quite a bit of software that is normally expensive by itself.

Is the package meant for 1 person or is it meant for like a business-type bundle of some sort? If it's the latter, I can kind of understand that, but I can't fathom where anybody is going to have 12 grand to plop down on something that only lasts 12 months.

Anyway, yeah, my question is, is this a good deal to anyone at all? Maybe it's just me not having any industry experience and this is actually a steal and millions of companies should be buying it right now, but I just can't personally picture this being worth the money.

答:
The most expensive MSDN option ($12,000 in the US) gives you Visual Studio Ultimate. There are several questions on Stack Overflow [eg this one] about whether VS Ultimate is worth it. (The answer is a rousing IT DEPENDS, of course.) Even if you only got the software for a year (and you don't, you have it forever, which in most cases means 3 years and then you'll go on to another version) it's $50/day. If it saves you an hour a day, you're ahead, right?

If the price gives you pause, there are lots of ways to get it for less or for free. [This question on Programmers for example.] You could get a version less than Ultimate, all the way down to Express which is free. You could join BizSpark or WebSpark or DreamSpark, if you qualify. Your firm could join the Partner Program, either at the Registered level and buy Action Pack, or at the Certified level and get 5 MSDN licenses for $3500. You could become an MVP and be given a free copy (this is actually probably the most expensive way to do it.)

And yes, many companies buy some sort of MSDN (not always Ultimate) for each developer. And find it worthwhile. I could probably get by with Premium but I use something from Ultimate probably once a month.

ContentLicense: CC BY-SA 2.5

Title: What does an MSDN subscription offer?


问:
How does const storage work? (Item 2, Scott Myers Effective C++)
In Item2 on page 16, (Prefer consts, enums, and inlines to #defines), Scott says:

Also, though good compilers won't set aside storage for const objects of integer types...

I don't understand this.  If I define a const object, eg

```<code>const int myval = 5;
</code>```

then surely the compiler must set aside some memory (of int size) to store the value 5?

Or is const data stored in some special way?

This is more a question of computer storage I suppose.  Basically, how does the computer store const objects so that no storage is set aside?

答:
The compiler may consider const values as immediate operands. Immediate operands do not require data storage. The compiler can treat:

```<code>int foo = myVal;
</code>```

the same as

```<code>int foo = 5;
</code>```

The value 5 is not stored in data memory, but rather as part of the instruction sequence.

The compiler must reserve data storage in cases where the address of a the value may be taken. Even in that case, the compiler will still use immediate operations when the value of myVal is used.

Body:
The compiler may consider const values as immediate operands. Immediate operands do not require data storage. The compiler can treat:

int foo = myVal;

the same as

int foo = 5;

The value 5 is not stored in data memory, but rather as part of the instruction sequence.

The compiler must reserve data storage in cases where the address of a the value may be taken. Even in that case, the compiler will still use immediate operations when the value of myVal is used.


答:
If a developer stays in a company/industry over a long period of time, they will slowly but surely learn "the business".

Some companies acknowledge and provide training in "the business". Financial companies are a good example of this.

The more you learn the business, the easier it will become to talk to your users. They will feel more confidence in you. You will more readily understand the quirks of where a system might go wrong if it doesn't quite do as expected for the user.

To answer your question, the specification is NEVER sufficient in my experience. The common problem is they often do not contain enough information, and get out of date quickly.

Experience of the business domain can be mandatory for some companies. They look for developers with experience in the domain when hiring. Some companies even put this higher than the actual tech skills. (No financial experience, no interview is very common, certainly here in the UK).


问:
Does your programming knowledge decrease if you don't practice?
I'm a novice programmer. I study languages such as C, C++, Python and Java (mainly focusing on C++). I'm what you'd call "young and inexperienced" and I admit that because I can't claim otherwise.

As a student, I have many other problems besides programming. I practice programming as often as I can, and especially because my teacher gives me a lot more exercises than the rest of the class (it's a very low level), so oftentimes I spend weeks doing something else such as school projects or sports, or traveling, anything besides programming.

Don't get me wrong though, I love programming. I love to build functional code, to watch as a program comes alive at the push of a button, and to learn as much as I can. The thing is, I simply don't have much time for it.

Straight to the question, now: does your programming knowledge decrease as time passes and you don't practice? You may ask "how much time do you mean?". I don't mean a specific amount of time, but for reference you could take a month-two or even a year as an example.

By knowledge I mean anything from syntax to language functionality.

答:
does your programming knowledge decrease as time passes and you don't practice?

Knowledge, no (at least not the Big Picture concepts).  Skills, yes.


问:
How granular should a command be in a CQ[R]S model?
I'm considering a project to migrate part of our WCF-based SOA over to a service bus model (probably nServiceBus) and using some basic pub-sub to achieve Command-Query Separation.

I'm not new to SOA, or even to service bus models, but I confess that until recently my concept of "separation" was limited to run-of-the-mill database mirroring and replication.  Still, I'm attracted to the idea because it seems to provide all the benefits of an eventually-consistent system while sidestepping many of the obvious drawbacks (most notably the lack of proper transactional support).

I've read a lot on the subject from Udi Dahan who is basically the guru on ESB architectures (at least in the Microsoft world), but one thing he says really puzzles me:

As we get larger entities with more fields on them, we also get more actors working with those same entities, and the higher the likelihood that something will touch some attribute of them at any given time, increasing the number of concurrency conflicts.

[...]

A core element of CQRS is rethinking the design of the user interface to enable us to capture our users’ intent such that making a customer preferred is a different unit of work for the user than indicating that the customer has moved or that they’ve gotten married. Using an Excel-like UI for data changes doesn’t capture intent, as we saw above.

-- Udi Dahan, Clarified CQRS

From the perspective described in the quotation, it's hard to argue with that logic.  But it seems to go against the grain with respect to SOAs.  An SOA (and really services in general) are supposed to deal with coarse-grained messages so as to minimize network chatter - among many other benefits.

I realize that network chatter is less of an issue when you've got highly-distributed systems with good message queuing and none of the baggage of RPC, but it doesn't seem wise to dismiss the issue entirely.  Udi almost seems to be saying that every attribute change (i.e. field update) ought to be its own command, which is hard to imagine in the context of one user potentially updating hundreds or thousands of combined entities and attributes as it often is with a traditional web service.

One batch update in SQL Server may take a fraction of a second given a good highly-parameterized query, table-valued parameter or bulk insert to a staging table; processing all of these updates one at a time is slow, slow, slow, and OLTP database hardware is the most expensive of all to scale up/out.

Is there some way to reconcile these competing concerns?  Am I thinking about it the wrong way?  Does this problem have a well-known solution in the CQS/ESB world?

If not, then how does one decide what the "right level" of granularity in a Command should be?  Is there some "standard" one can use as a starting point - sort of like 3NF in databases - and only deviate when careful profiling suggests a potentially significant performance benefit?

Or is this possibly one of those things that, despite several strong opinions being expressed by various experts, is really just a matter of opinion?

答:
The message Udi is trying to get across is that CQRS is more than just CRUD. Why did I create this record? Why am I changing this record? Why is it being deleted/marked as deleted?

Commands should correspond to actions/use cases that the user makes with the system and express the intent of the action rather than just saying change this. Also, it may seem like it's finer grained but it could be much coarser than it first appears. For instance the upgrade to gold status might involve a change to several attributes and a number of other aggregates might even respond and change in response to the corresponding event.

CQRS is about capturing the language of the business in the Service layer so the UI doesn't have to worry about what happens when I make that gold status upgrade or the shipment has been marked as undeliverable by the carrier, or the employee has been promoted to manager of the technology group. Well technically I'm talking about Event Sourcing now but you get my drift. There are more distinct messages but they are not necessarily more fine grained than standard CUD.


答:
If you put a person who knows only English and a person who knows only Japanese in a room, they wouldn't be able to translate from Japanese to English, in spite of being experts of their respective languages. For the same reason, even expert programmers with no domain knowledge are powerless at figuring out what they needs to build, even when they have a 24x7 access to the best domain expert who is not also an expert at software development.

A spec is an attempt at translating "Japanese" of the domain requirements to the "English" of programming requirements. When you get translation quality comparable to that of Google translate, it is your lucky day; most of the time, the quality is just not there, so you have no way around acquiring at least some domain knowledge. With some persistence, it makes you a decent "translator" by the end of the project, so your value to your company grows significantly. Most of the time, you also have a lot of fun in the process, so it is a win-win situation.


答: Without some aspect of business knowledge you end up with developers who don't ask questions and mindlessly code what the specs say.  I believe it takes "Thinkers" to make good software not just people who can bang on a keyboard.  Understanding not only "What" you are doing but "Why" and how it fits into the bigger picture helps provided greater satisfaction for the development team.</p>


答:
There are a lot of excellent answers. I add my own because after reading them and searching I found that nobody mentions a key issue: bugs.

If the team is not provided with enough people with enough authority and domain expertise, sooner or later bugs will inevitably creep in. Given a knowledge of the domain, there are impossible, or non-sensical values/results/relationship. One could hope that a specification explicitly points them out but in reality the best you can reach is to avoid the most obvious ones (alert me if interest rates become negative, or things like that - this could be or could be not an error but is strange enough to be noteworthy).

This is strongly related to understanding the reasons for choices, and in the best cases it also leads to better software (because if one actually knows the reason behind a request, is able to think about it, rather than having to accept it as a given).

Remember that Einstein said "But thought and ideas, not formulae, are the beginning of every physical theory. ", that is that one thinks not in terms of abstract formulae but of ideas...


问:
Where should SQL/DB Queries be encapsulated in a software system?
I frequently write small applications (either web based or otherwise) that require heavy database usage. i've attempted various ways of handling where to put the actual sql queries (sort of ad-hoc ORM systems). These include:

Models that build themselves up - and only allowing SQL to be inside of a model.

A sort of factory style method where the models are built by a factory class that is allowed to know about SQL.

A third entity that maps models based on their fields/keys into the database and generates
SQL code on the fly based on this.

Is there a common knowledge of which method is best? Or another way I have missed?

Clearly a lot of it will be based on the context of the system itself, which for me is usually to produce lightweight tools or utility frameworks. In experimenting, I've never found any of them that feel intuitively "right" and not clunky, but I also do not want to go for a full framework such as Django or Ruby - both because the tools I create are in a variety of languages and because they usually do not warrant that level of surrounding footprint.

答:
That depends a lot on the actual technology you are using because that determines the set of tools and best practices you will get.

For instance if you work in Java you can use one or multiple properties files and store all the queries there, this has the advantage that you don't have them all over the place in your code and you don't need to recompile to make changes (also you can reimplement the properties class and make it look for changes in the file and reload if something is different that adds the flexibility where you can change queries without redeploying the app). But it has the downside that queries are exposed in plain text on the server so this could be considered a security flaw (easily solved buy reimplementing once more the properties file to read encrypted files). This can apply also if you are using PHP or ASP .NET. or C#.

But if you are working with Java but, let say, using Spring Framework you can have the queries defined as a map in an spring configuration file (XML), or in a bean defined in a config file.

Pros; is't elegant and flexible,

Cons; security considerations of having, once again, queries in plain text laying arround...

So, as you can see, the options are quite numerous limited only by the technology you are using.


问:
Co-worker renamed all of my queries
I don't know if I should be very irritated or what. I single handedly built over 300 queries for a large database, and developed a naming convention so I could find them later. No one else in my office even knows how to build a query, but I came in yesterday to find that all of them had been renamed. I am now having a very hard time finding things, and I am trying to figure out what to do.

I spoke with the person responsible, and she just downplayed the whole thing. She said she renamed them so she can find them more easily. Unfortunately, I am the only one who knows how to build, edit, and maintain them, and the only reason she needed to find them was to test the queries. The new naming convention doesn't make sense at all, and I feel like we have taken a backwards step in the development process.

What I'm trying to figure out is:

1) Am I overreacting?

2) What is the best way to handle this? I hate to mention this to my boss, but after speaking with my co-worker yesterday, I can already tell she feels like she did nothing wrong.

答:
Yes you are overreacting.

There something called version control that among other things it is used to not have to beat the $#!7 out of coworkers when they mess with your stuff. Just rollback to the previous version and lock the file therefore letting her handle the anger. That will open up the opportunity for you to explain that performing radical changes on code that has dependencies on someone else's stuff without a solid reason and without asking first is not just wrong, extremely impractical and practically a sin.

Off course this assumes that your naming convention is better than her's and that you can actually backup this decision with solid objective arguments, if that's not the case the most wise thing to do start changing your code as soon as you can to handle the changes and try come up with a better naming convention next time.

Do not take it to your boss, the mature way to solve it is directly with your coworker, you'll have to work with her after that so its stupid to damage the relation for a easily solvable quarrel.

OwnerDisplayName: anon

Title: Co-worker renamed all of my queries


答:
I would recommend you implement the gateway pattern. It provides a nice level of abstraction from your code (models ect) and your SQL.

I've never found any of them that feel intuitively "right" and not
  clunky, but I also do not want to go for a full framework such as
  Django or Ruby - both because the tools I create are in a variety of
  languages and because they usually do not warrant that level of
  surrounding footprint.

You know more about the requirements your projects than me (so feel free to ignore me) but I don't find any of your arguments for implementing your own system very persuasive. Have you actually benchmarked the response times of your system against a well established framework? The established frameworks have had lots of very skilled coders optimise them. Do you actually need that extra performance (assuming there is any?).

I'm also a little unsure of what advantage having your system in a variety of languages will give you. It sounds like a recipe for complex buggy code.

Title: Where should SQL/DB Queries be encapsulated in a software system?

Body:
I frequently write small applications (either web based or otherwise) that require heavy database usage. i've attempted various ways of handling where to put the actual sql queries (sort of ad-hoc ORM systems). These include:

Models that build themselves up - and only allowing SQL to be inside of a model.

A sort of factory style method where the models are built by a factory class that is allowed to know about SQL.

A third entity that maps models based on their fields/keys into the database and generates
SQL code on the fly based on this.

Is there a common knowledge of which method is best? Or another way I have missed?

Clearly a lot of it will be based on the context of the system itself, which for me is usually to produce lightweight tools or utility frameworks. In experimenting, I've never found any of them that feel intuitively "right" and not clunky, but I also do not want to go for a full framework such as Django or Ruby - both because the tools I create are in a variety of languages and because they usually do not warrant that level of surrounding footprint.


问:
Is mentioning my blog on my resume helpful or hurtful to a job search?
I have a blog that I use mostly to record solutions to problems I have had, that I had some trouble finding an answer to. Mostly problems where the online doc I googled provided too much info, and I found the answer to my question on the fifth page of my third google hit.

(Or if I asked the question here, I either didn't get an answer or I got slammed for asking a question that "the answer could be easily googled.")

I frequently look up stuff on this blog to remind myself of how I solved a problem, and it gets a decent amount of hits from others as well.

Anyway, I was wondering if mentioning this blog on my resume would help or hurt me in a job search? The topics are all over the map.

What I would hope it shows is that

I am a person who finds solutions to problems

I have used many different technologies in my work

I am not afraid to tackle a challenge

What I am concerned it shows is that

This person had trouble with something that simple?

Why is this person bothering to blog this stuff?

答:
You are right when saying that some people will certainly see you as a noob while browsing your blog... however:

most employers will NOT visit your blog. They don't care

a part of the remaining employers will see it as a good thing. Will see you as a problem solver!

a part of the remaining employers will take you like a noob.

Would you be hired, and report to, a person that think he should not hire you because you ask yourself questions on your blog?

Certainly not!

Problem solved.


答:
Disclaimer

This answer is not intended to be comprehensive and detailed illustrated textbook from series "... for Dummies", may contain the wrong conclusions from faulty assumptions and involves the reader's own ability to read and understand the documentation

Preface

The proposed solution is based on the following assumptions:

core and each plugin are separate independent Projects

each Release contain pre-defined arbitrary (able vary from release to release) set of individual Components of strictly defined version

Solution

In suggested solution expected and suggested the usage of such opportunities of SVN, as:

Branches

Tags

Externals

Each Component will give own placement: in can be separate repository or predefined path inside common repo. In any case Solution consists of only linked by svn:externals independent Components. For each Component (by agreement) URL of stable state is determined and fixed for the duration of the development.
Under the above conditions, to simplify the notation and understanding of workflow in the future, use the following preset:

Each component have own repo

Stable point of each component is repo's trunk

Repository of Solution hereinafter have name SuperRepo (as opposed to repositories of Components, which have Repo/somestring/ name)

Hereby, our task is: build Repo* for components, build SuperRepo after it, where each folder is linked relevant repo's trunk, HEAD revision (we don't use PEG-revisions in every-day development).

After these steps development continues in the usual manner, for each WIP for components we can use all and any svn-techniques (branching, tagging, merging)

In Release time we must have map: which components and versions of components should (might) be have been included in the release. Version of component may be defined as revision number (inside component repo) or as tag - it does not matter. With this map we can edit SuperRepo's trunk (trunk!) to our needs (add-remove externals, for used in release externals freeze revision by changing external definition: adding PEG-revision for trunk linking or changing URL to corresponding tag) and tag polished trunk of SuperRepo for future reference. Export tag after all for publishing

This way each release will have known set of components in known state and can be easily assembled as Lego

Title: Best practices in versioning

Body:
I develop some scripts for data analysis in a small team. For the moment we use SVN, but not in a very structured way. We haven't even looked how to use branches even though we need this functionality.

What do you suggest as the best practice to setup the following system:

two code bases (core and plugins)

versions can be incompatible to previous scripts

sometimes individual features are being developed and not yet finished, while other fixes have to be done urgently to the code

In the end we don't deliver the code as a package, but rather place the Python scripts in some directory (with version names?). Some other python script which serves as a configuration choses the desired version, sets the path to these libraries and then starts to import the modules.

I saw stable releases to be named "trunk" so I did the same. However, no version numbers yet. Core and plugins are different repositories, however we have to match versions for compatibility.
Can you suggest some best practices or reference to ease development and reduce chaos? :)
Some suggested GIT. I haven't heard about it, but I'm free to change.


问:
Why Aren't There New Versions of C?
While many other languages have rapid development, such as Python, which has come out with a whole new version in the past few years, or to use a framework, Rails, which evolves super-fast (A book that was published in early 2011 is now obsolete), it seems that there are no updates for C. Why is this?</p>

答: I would argue that one of C's most important features is its simplicity.  Any "evolution" that adds complexity is not an advancement.  I just shake my head when I hear about object-oriented COBOL -- one of the reason COBOL has enjoyed so much success is because OOP languages don't offer any compelling advantages in its niche (high-speed batch data processing).  Likewise, I don't think that adding closures or making functions first-class elements will improve C.  Best to leave it clean and simple, and use it as a base for new languages with new features.  That strategy worked well for C++ and Objective-C, while still preserving C's value as a small, simple language.</p>

Title: Why Aren't There New Versions of C?


问:
When Agile goes wrong
I'm writing an Agile course for some of the new guys we are on-boarding recently, and I want to add a cautionary tale so they understand that Agile is not meant for all projects.

My problem is that, because of the nature of the projects I work in with Agile has worked pretty well so far, I can't honestly point out what can go wrong and why when you use it in the wrong kind of project.

What are things to look out for when an Agile project goes wrong?

答:
Here are a few questions that may be useful to look for an answer in terms of finding an example where an attempt at Agile can go poorly:

Is Agile the new micromanagement?

The Agile process: how and what should be documented?

Right mix of planning and programming on a new project

Have you ever heard of "pseudo Agile"?  Here are a couple of blog entries about it:

From Pseudo-Agile to Waterfall – The path of a small and new software company

Pseudo Agile!

There is something to be said for companies that may take their own view of what is Agile and butcher it into something else.

Title: When Agile goes wrong


答:
Agile in my opinion is all about the culture of the team that is practicing.  If the culture sucks, the team members do not get along, and people are not collaborating to meet sprint committments then the culture or team is deficient.

I wouldn't necessarily say however that Waterfall will necessarily work in such an environment, it is not a black and white situation, very little is truly black and white.

A good Agile team is communal.  They have a tribal spirit of community where all members are working towards the same goals.  The team succeeds or fails together.  They work together on solving problems.  A team member will stop what he is doing with his tasks to help a struggling team member out.  Everything is sink or swim.

When this is not the case then it quickly becomes apparent what is wrong.  If the team members are sitting down, typing on their laptops or texting, or zoning out during the daily standup then you don't have a good Agile team.  If your project managers are enforcing all the Scrum procedures, definitions and terminologies but everybody is just keeping cadence and paying lip service, then this is just a rather blatant farce of what Agile truly is, and this in many ways leads to team dysfunction, inefficiency, missed deadlines and failed projects.

Failing Agile is in many ways worse off than a moderately successful Waterfall team and probably have lower project success rates.

Title: When Agile goes wrong

Body:
I'm writing an Agile course for some of the new guys we are on-boarding recently, and I want to add a cautionary tale so they understand that Agile is not meant for all projects.

My problem is that, because of the nature of the projects I work in with Agile has worked pretty well so far, I can't honestly point out what can go wrong and why when you use it in the wrong kind of project.

What are things to look out for when an Agile project goes wrong?


答:
People that didn't understand what agile is (was?) all about and apply it to:

clients that are unavailable for comment until the deadline

...and threat legal action afterwards;

managers that keep developers away from the client, (probably because they're slightly underpaid,  and could jump ships, going to work for said client) and play a game of the "broken telephone" in a desperate (often successful, though) attempt at looking busy and useful,

See also: mushroom management,  aka "kept obscure, fed manure" and pointy-haired bosses. :)

teams that are too big to go anywhere;

companies that are keeping on their payroll once-renowned system architecture designers that are desperately diverting attention from the fact they completely lost sight of the actual coding craft, by overdesigning magnificent, unpractical, hard-to-realize, UML sagrada familias.

Title: When Agile goes wrong


答:
I will add to the great answers already posted that, by my experience, agile and specifically Scrum will only work if management AND team are willing to put lot of visibility of what's going on.

This means that in public companies (governments for example), it will be very difficult to make it work properly.

Title: When Agile goes wrong


答:
I worked on a highly successful Agile team, as well as a few that attempted Agile, but couldn't get it to work.

The successful one had the following elements:

Truly "Agile" requirements.  There were user stories, and we coded off of them.

Available product owner.  If a user story I was coding from was incomplete, I could easily go to the product owner, ask him what should be there, add it, and the complete the code.

Commitment to the process and a realization that it was a learning curve.

Focused team.

Managers who knew and understood the Agile way of doing things who were committed to making it work.

The successful team did Agile, and did it really well.  I would think that if you don't have any of those points above, you could fail quite easily. The first and second things go hand in hand, and if you don't have that, then Agile won't work.

The team I was on that didn't do Agile well had a few elements too:

Lack of committment from management. The management didn't believe in the philosophy, and were hesitant to commit as a result.

Requirements documented in other places than user stories.  See above about management commitment.  Also, we had highly paid requirements analysts and big expensive requirements tools that someone needed to justify the use of.

Title: When Agile goes wrong


答:
The biggest failure with "Agile" teams is a result of what is called Cargo Culting. Essentially, teams want the effects of successful agile teams so they mimic the visibile actions

Daily standups (that run for an hour or so)

Breaking work into sprints

User stories (that are usually little more than a sentence but an estimate is expected)

Those are the three that you'll see consistently "applied" in these environments but very little committment to actually being agile. In fact you'll hear management say we're "doing agile." (Run away at those two words it's a bad sign.)

You'll also hear a lot about technical debt but their definition of technical debt is "do it quick and dirty and maybe we'll get around to making it better later." (Translation: we are going to make it sound like we're concerned with maintainability but in reality we will keep the same boiler room mentality because that's what's worked for us in the past).

Other key phrases: "I know these stories aren't fully defined but we're doing agile so we can fix them as we go."

"We're doing agile development so you should be able to accomodate what I need within the sprint as I identify it."

"We're not able to lock down our committed stories at the beginning of the sprint because needs keep changing mid-sprint."

The key indicator on whether an Agile project will be successful is if the project lead (scrum master or whatever role) has had experience or formal training on leading an agile project. Too often I've seen people read about Agile in a book or take a two day course on being a scrum master and think they've got the chops to successfully implement it. Sorry it ain't happening captain.

Title: When Agile goes wrong


问:
Practical considerations for HTML / CSS naming conventions (syntax)
Question: what are the practical considerations for the syntax in class and id values?

Note that I'm not asking about the semantics, i.e. the actual words that are being used, as for example described in this blogpost. There are a lot of resources on that side of naming conventions already, in fact obscuring my search for practical information on the various syntactical bits: casing, use of interpunction (specifically the - dash), specific characters to use or avoid, etc.

To sum up the reasons I'm asking this question:

The naming restrictions on id and class don't naturally lead to any conventions

The abundance of resources on the semantic side of naming conventions obscure searches on the syntactic considerations

I couldn't find any authorative source on this

There wasn't any question on SE Programmers yet on this topic :)

Some of the conventions I've considered using:

UpperCamelCase, mainly as a cross-over habit from server side coding

lowerCamelCase, for consistency with JavaScript naming conventions

css-style-classes, which is consistent with naming of css properties (but can be annoying when Ctrl+Shift+ArrowKey selection of text)

with_under_scores, which I personally haven't seen used much

alllowercase, simple to remember but can be hard to read for longer names

UPPERCASEFTW, as a great way to annoy your fellow programmers (perhaps combined with option 4 for readability)

And probably I've left out some important options or combinations as well.  So: what considerations are there for naming conventions, and to which convention do they lead?

答:
I strongly believe the thing that matters most is consistency.

There are two ways to look at this:

A good argument can be made for alllowercase or css-style-clauses (probably the better choice) because they will be the most consistent with the code they'll be in. It will lend a more natural flow to the code overall and nothing will be jarring or out of place.

An equally good argument can be made for a style that is distinct from HTML tag names or CSS clauses, if it will differentiate IDs and classes in a way that aids readability. For example, if you used UpperCamelCase for IDs and classes, and didn't use it for any other construct or purpose, you would know you had hit on one every time you saw a token in that format. One restriction this might impose is that it would be most effective if every ID or class were a 2+ word name, but that's reasonable in many cases.

In writing this answer out I came to find that I'm much more inclined toward the second choice, but I will leave both because I think both cases have merit.


问:
Does not documenting code result in job security?

Possible Duplicate:

  Should you write good documentation and clean code to increase the “Bus Factor”?

I often ask young programmers why they are not documenting their code. Their responses, perhaps jokingly, frequently include "job security." I hear this from experienced professionals, too. And not just in programming; network engineers and system administrators widely subscribe to this belief.

Can you really ensure job security by holding the details of your work in your head rather than on paper (or in files)? What's your experience?

答:
I doubt it. If you're writing bad code without comments, you're a bad programmer. That doesn't sound like good job protection... You probably won't be able to hide it from all technical staff on your team. Eventually someone will call you out to management for not being a very good developer. You are more likely to have good job protection if you earn a reputation for being a great developer who writes good code. This is much more likely to protect your job, since finding good developers is much harder than getting someone to understand poorly written code.

In any case, I don't think developers really need to worry about job security today. it's one of the largest growing job markets, so it's not like you need to hold on for dear life to one job. If you lose your job for whatever reason, turn around and there are plenty of other job opportunities.


答:
I think that young people don't document the code because they came from college (or similar IT educational system) doind only small projects alone, so documentation is not needed.

Most experient programmers can be these young people older or just people that works on the same single project for years, so it knows all the aspects of the project and don't care about the others because he is the senior/mastermind of that project.

Not documenting the code for job secutiry only will hold your position if is a small or old company with old mind.

Title: Does not documenting code result in job security?

Body:
Possible Duplicate:

  Should you write good documentation and clean code to increase the “Bus Factor”?

I often ask young programmers why they are not documenting their code. Their responses, perhaps jokingly, frequently include "job security." I hear this from experienced professionals, too. And not just in programming; network engineers and system administrators widely subscribe to this belief.

Can you really ensure job security by holding the details of your work in your head rather than on paper (or in files)? What's your experience?


问:
How important is index size when searching?
My company has recently began using Apache Solr to search its data. As we learn how to use it we have gone down the path of indexing multiple fields to get the results we need. Most of these are either N-Grammed or Edge-N-Grammed (N-grammed, but only from the edge; for starts-with searching).

Gramming by nature takes up a lot of space, which takes more time to search. Space is cheap, but time is less so. Index time is not too important, since a delta-import (only get the changes since last index) is extremely quick and you only pay a penalty on the first import. What we've not been able to determine is what effect the index size has on query times. Obviously a larger index takes longer to search, but the time added by n-gramming a field is difficult to predict.

How do you determine whether a field is worth gramming? Can you predict how much longer a query will take when you gram a field?

答:
Well, the best thing you can do is run your own benchmarks!

Compare the average speed over several thousand test queries on an index that includes ngrams vs one that excludes them. It doesn't have to be your full actual index (since that may take a long time to generate), just a large enough sample size to get an idea.

Note that you can use debugQuery=on to analyze how a query is performed and maybe to generate a better index. For example, see Hathi Trust's Digitla Library Tuning Search Performance. By using CommonGrams and analyzing queries they were able to reduce average query time by 50%.

So, running your own benchmarks is best, but there are also some existing benchmarks online. For example see Sakai Solr Benchmark, which compares—among other things—the query performance using an index with ngrams and one without. If the details are similar enough to your use case, this benchmark should give you a rough idea of how it will turn out for you. To summarize this benchmark:

Using documents about 2000 words in length and composed of random English words at English-like frequency. Total corpus about 6gb.

Limiting the indexed n-grams to 3-, 4-, and 5-grams (also with one test indexing left-anchored edge n-grams up to length 15).

Performing benchmarks under load of 5 concurrent users.

Using average to sub-par server hardware.

Results (in average query time):

Without n-grams: 159ms

With 3-, 4-, and 5-grams: 393ms

With 3-, 4-, and 5-grams and left-anchored edge up-to-15-grams: 450ms

(They also have some other results including what they are calling "lean" indexes).

The takeaway: If your data is similar enough to theirs, adding n-grams to the index may increase your query time by a factor of 2.5 to 3. Of course, you have to take these results with a grain of salt, because there are so many factors specific to your data. This is best used not as a fact, but as a guideline for what to perhaps expect when you run your own benchmarks.


问:
How does the MongoDb licence define "commercial" and "non-commercial" use?
I have a question about "commercial" and "non-commercial" usage, also with the usage of MongoDb.

Lets imagine we got a website without a business model, the site grows in popularity but still no incomming money. Are we talking about non-commercial at this point?

And once the website starts making money, is it allowed to decide at that point to get a commercial license?

Thanks for help.

答:
Any software that has distinct license terms for Commercial vs. Non-commercial usage should define those terms in the license.  If they do not define the terms you will need to ask them what they mean.

For your specific question about MongoDB the commercial Licensing option exists only if you do not want to or can't comply with the AGPL terms.  My interpretation is that as long as you comply with the AGPL terms you can use MongoDB for any purpose, commercial or not and if you you do not want to comply with the AGPL you must get a commercial license even if your application is non-commercial.

As is the case with most licensing questions: Ask the owner of the the copyright these sorts of questions.  They know better than random people on the internet.

OwnerDisplayName: randomKek


答:
Any responsible manager will dismiss an employee who has become indispensible. The reason is the longer they are there, the bigger the damage when they leave.

For an employees point of view, this kind of "Job security" is not wise - management cannot promote someone who is indispensiable, they cannot give them the new projects. You will be stuck on the same ground hog day for the rest of you life. Might not sound to bad at age 20, but 20 years later doing the same thing the same way with a manager old enough to be you son .... So you decide to leave, but can't find a job because of you reference checks, and mostly will never know why.... Worst case, probably, implausable - certainly not.

Edit / Clarification
There are many ways to dismiss someone in this situation - a sideways or even downward move may be appropriate, however if the person is an empire builder they usually just build another empire, and often will not go willingly (once they see power being taken away). If they just "fell" into being irreplaceable, they will usually be the first person to identify the issue and will willing participate in the solution, that is not what this question is about.
If the entire organizations vitality or even survival depends on not being able to dismiss an individual, then it will cost less to do it sooner rather than later.

There are very few Steve Job's in this world, and the guy that is building his empire is, on balance, very unlikely to be one of them. I have often observed "irreplaceable" people being replaced, usually at a much smaller cost than anyone imagined.


答:
Definitely not. They wouldn't last very long on my team, especially if I was their superior.

Documenting work is valuable for the company in general so I cannot see how this would be allowed to continue unless the company itself does not realize the value being lost by not having proper documentation in place.

I'll be damned if I can remember every little detail about the code that I have written over the past several years, so if I haven't documented anything I will eventually put myself out of work.


答:
I have not experienced this firsthand, but I think it's a very silly mindset from the get-go.

Why become indispensable by being bad at your job when you can become indispensable by being good at your job?

As a young programmer, I will tell you that I try hard to document my code at least moderately, but this is the sort of thing where habit will play a much bigger role than intention. When I first started programming, I didn't have a solid appreciation of the value of commenting code. As I got into more programming classes and deadlines got shorter while projects got harder, I didn't always comment my code because I didn't always have time. I hadn't gotten into the habit of documenting as I wrote, so I would often document as an afterthought.

I believe many people are in a place like this: if commenting code isn't a deliberate practice from day one, it takes more work to ingrain it, and many people probably never put forth the effort to make that happen. However, I never willfully keep comments out of my code. If I have time and remember that it needs doing, I believe it should be done.


答:
I do not know this from personal experience, but hypothetically, there are many circumstances when agile is not the best option.

Projects whose product is life or property critical - For example, you do not want to use agile to develop the software that runs your pacemaker. Why? Because you have near-zero tolerance for errors. Consider a classic example of programming error within medicine in regards to the Therac 25.  Granted, it wasn't built with agile, but the point is this: Developing life or property critical is no place to say, "we'll clean that up on the next sprint" or "we don't need great, just good enough."

Projects with too many junior developers - Agile expects a certain amount of autonomy within the participating group. If there isn't enough experience on the team, then that autonomy can work against you.

Projects that require a higher degree of control or planning than what is traditionally offered with Agile.

I'm assuming either someone else will jump in and help out with better examples, or downvote this bit of tripe I've written ;-).

Just remember that when the only tool you have is a hammer, every problem looks like a nail.  Not all projects are nails.

Title: When Agile goes wrong


答:
A good number of companies operate under "tribal knowledge" when it comes to internal projects. People who've been around a while accumulate knowledge and are often reluctant to let it out to new members of the tribe. Some will cite security concerns ("Our business rules are on a need-to-know basis and you don't need to know them for your project"). Some will answer in acronyms terms that only someone with years of experience in the company will know ("You need to use the unified TXD interface, not the TXM interface, to get the UIO properties to find the JV standard values. From there you need to...").

Sometimes this is by design, with people defending their knowledge and superiority on the team. Sometimes it's just how the company's software development culture evolved. The first kind can be a very toxic work environment and is common in companies that practice misguided cutthroat management techniques like "rank and yank". The second can happen due to a inconsistant or poor management and tends to be more common in smaller companies/teams that grew fast with few controls.

All in all, it's not a good work environment and a good programmer will take steps to prevent it from happening in their organization. Yes, it can result in job security for some but it's at a heavy cost to the company and to team members.


答:
As much as we all like to believe otherwise, information hoarding can work.  At best it's a risky strategy, since clearly information hoarding is inherently selfish, and people will probably get angry if they catch you.

As an aside, you might be wondering "how could anyone possibly not get caught?" However, I've witnessed people that hoard information from the technical staff but pretend to management that they are cooperating.  But all information sharing is in fact deliberately incomprehensible or false.

This doesn't fool the technical staff for long, but it does make it hard to prove, and anyone in position to information hoard has probably been around longer and therefore has more trust from management.  Especially since they are in position to create a story of themselves heroically saving project after project from successive waves of programmers that can never seem to get the system to work right.

Information hoarding is especially effective if the information being hoarded includes a lot of the actual system requirements, since technical employees can eventually figure out even the most obscure code given enough time.  But doing all that plus determining the requirements takes even longer, and will be almost impossible to do without it getting back to the information hoarder.

Obviously, it requires bad management to let such a situation to develop, and to let it continue, but even in this day and age there are still a very small number of companies with a single department or two that in their very worst moments allow occasional bad management.

Interestingly, for the information hoarder life as a miser is often pretty tough.  They probably can't improve their skill set because they are busy being essential to whatever their hoarded information pertains to.  Soon they can't change jobs because that's all they really know how to do.  And they have to live in fear of new management with sense enough to see what's going on and the guts to pay the short term costs of fixing the problem.

So, I wouldn't recommend it to anyone who isn't unethical and desperate.  But under some circumstances it can provide more job security then not doing it.  But less career security.


问:
Is there a case study that convincingly demonstrates that clean code improved development?
I'm in my first real job as programmer and what I see is just the "Big Ball of Mud" code (without useful comments too), but I like to do clean code, and it's really hard for me to code in a worse way.

I'm searching for some study case where the usage of clean code (I see various definitions here of what is clean code) improved the development and maintainability.

答: What you need to understand is that no company sets out to write mediocre code.  The problem is that 50% of the code, give or take, is written by the below average programmers of your company.  You're preaching to the choir when you expound the benefits of clean code.  The trick is how to do it.  Do some research on things like peer review tools, static analysis, automated testing, continuous integration, TDD, scrum, extreme programming, etc. and present potential solutions instead of just explaining why the problem is bad.


问:
What class structure allows for a base class and mix/match of subclasses? (Similar to Users w/ roles)
I have a set of base characteristics, and then a number of sub-types. Each instance must be one of the sub-types, but can be multiple sub-types at once. The sub-types of each thing can change. In general, I don't care what subtype I have, but sometimes I do care.

This is much like a Users-Roles sort of relationship where a User having a particular Role gives the user additional characteristics. Sort of like duck-typing (ie. If my Foo has a Bar, I can treat it like a ThingWithABar.)

Straight inheritance doesn't work, since that doesn't allow mix/match of sub-types. (ie. no multi-inheritance).

Straight composition doesn't work because I can't switch that up at runtime.

How can I model this?

答: One way to do this is to a mapping table in a database to map users to allowed permissions, and create a db function to check permissions and add that to the beginning of any db request that requires permissions. This allows run time editing of roles and arbitrary permissions for each user.</p>


答:
Agile is not suitable for fixed-term or fixed-price contracts. Once you've signed up for such a beast, you have to deliver. Agile is very good at continuing development for ever, as customers change their minds and 'clarify' their requirements. That does not help you on the day the money runs out, but still have to finish the work.

Agile is very good for the post-project phase when you are doing incremental updates and bug fixes however.

The other aspect where Agile fails is not a fault of Agile, its a fault of people who insist on all the old stuff like full-on project documentation, up-front designs, and poor lines of communication. (The half-arsed agile manifesto).

Title: When Agile goes wrong


问:
Must developers understand the business domain or should the specification be sufficient?
I work for a company for which the domain is really difficult to understand because it is high technology in electronics, but this is applicable to any software development in a complex domain.

The application that I work on displays a lot of information, charts, and metrics which are difficult to understand without experience in the domain. The developer uses a specification to describe what the software must do, such as specifying that a particular chart must display this kind of metrics and this metric is the following arithmetic formula.

This way, the developer doesn't really understand the business and what/why he is doing this task. This can be OK if specification is really detailed but when it isn't or when the author has forgotten a use case, this is quite hard for the developer to find a solution.

At the other hand, training every developer to all the business aspects can be very long and difficult.

Should we give more importance to detailed specification (but as we know, perfect specification does not exist) or should we train all the developers to understand the business domain?

EDIT: keep in mind in your answer that the company could used external developers and that a formation to all the domain can be about 2 weeks

答:
There are almost always trade-offs to be made between the value of each feature in the spec, how closely the spec must be implemented to valuable, and the cost of meeting any combination of spec features.  Often good trade-offs can only be made when the knowledge to do all of the above exists in one person, or a closely working team, including the actual software architect and/or coder.

Without such extremely localized knowledge and possibly even gut feelings, the result can easily end up as a very costly nearly useless product that very closely meets the written spec.

The cost of creating a spec that does not have the above problems can often be greater than training the architect and/or coders to have enough domain knowledge to work with a less inscrutably detailed spec (assuming the legalities and business contracts allow this).


问:
Reasons to Use Version Control

Possible Duplicate:

  I'm a Subversion geek, why I should consider or not consider Mercurial or Git or any other DVCS?

  What is the value of using version control?

I am a relative noob to programming, and am not going to be developing super-good software or even programming professionally anytime soon.  With this predicament, is there really any reason to learn git or subversion or any other version control systems?

答:
When you write your own code, you are bound to do things that screw it up. (Being a noob, it's even more likely.) Wouldn't it be handy to be able to go
back to the last point where it sort of worked?  Version control
will let you do this.

Also, if you want to look at the code that is being built in the
    open source world, it will help you a bunch if you know how to get
    it out of the version control system it's in.

You won't be a noob forever--why limit yourself?  If you eventually
    get a job programming, you will have to use version control, so get
    used to it early.

Title: Reasons to Use Version Control


答:
What you want are Interfaces.

Each interface can mandate a characteristic.  A class can implement multiple interfaces as it pleases:

```<code>interface Foo {
  boolean doFoo();
}

interface Bar {
  boolean doBar();
}

class fooImpl implements Foo {
  boolean doFoo(){
    . . .
  }

}

class barImpl implements Bar {
  boolean doBar(){
    . . .
  }

}

class fooBarImpl implements Foo, Bar {
  boolean doFoo(){
    . . .
  }
  boolean doBar(){
    . . .
  }
}
</code>```

UPDATE

Alternatively, implement the state pattern.  One state would be HasABar, and would provide the desired behavior for when your Foo has a Bar.  Another state might be HasABat, providing different behavior.  Your Foo object may start with HasNothing, until you give it a Bar, which would change the state to HasABar.

```<code>interface FooState {
   Drink getDrink() throws InvalidStateException;
}

class HasNothing implements FooState {
   Foo foo;

   HasNothing(Foo foo) {
      this.foo = foo;
   }

   Drink getDrink() throws InvalidStateException {
      throw new InvalidStateException("There's no Bar");
   }
}

class HasABar implements FooState {
   Foo foo;

   HasABar(Foo foo) {
      this.foo = foo;
   }
   Drink getDrink() throws InvalidStateException{
      Foo foo.getBar().getDrink();
   }
}

class Foo {
   FooState state;
   Bar bar;

   public Foo() {
      state = new HasNothing(this);
  }

   Bar getBar() {
      return bar;
   }

   void setBar(Bar bar) {
      this.Bar = bar;
      if (null != bar) {
         state = new HasABar(this);
      }
      else {
         state = new HasNothing(this);
      }
   }

   Drink getDrink() throws InvalidStateException{
         return state.getDrink();
   }
}
</code>```

At this point you are not really dealing with subtypes, you've got one type that behaves differently depending on state during runtime.

Title: What class structure allows for a base class and mix/match of subclasses? (Similar to Users w/ roles)

Body:
I have a set of base characteristics, and then a number of sub-types. Each instance must be one of the sub-types, but can be multiple sub-types at once. The sub-types of each thing can change. In general, I don't care what subtype I have, but sometimes I do care.

This is much like a Users-Roles sort of relationship where a User having a particular Role gives the user additional characteristics. Sort of like duck-typing (ie. If my Foo has a Bar, I can treat it like a ThingWithABar.)

Straight inheritance doesn't work, since that doesn't allow mix/match of sub-types. (ie. no multi-inheritance).

Straight composition doesn't work because I can't switch that up at runtime.

How can I model this?

Body:
What you want are Interfaces.

Each interface can mandate a characteristic.  A class can implement multiple interfaces as it pleases:

interface Foo {
  boolean doFoo();
}

interface Bar {
  boolean doBar();
}

class fooImpl implements Foo {
  boolean doFoo(){
    . . .
  }

}

class barImpl implements Bar {
  boolean doBar(){
    . . .
  }

}

class fooBarImpl implements Foo, Bar {
  boolean doFoo(){
    . . .
  }
  boolean doBar(){
    . . .
  }
}

UPDATE

Alternatively, implement the state pattern.  One state would be HasABar, and would provide the desired behavior for when your Foo has a Bar.  Another state might be HasABat, providing different behavior.  Your Foo object may start with HasNothing, until you give it a Bar, which would change the state to HasABar.

interface FooState {
   Drink getDrink() throws InvalidStateException;
}

class HasNothing implements FooState {
   Foo foo;

   HasNothing(Foo foo) {
      this.foo = foo;
   }

   Drink getDrink() throws InvalidStateException {
      throw new InvalidStateException("There's no Bar");
   }
}

class HasABar implements FooState {
   Foo foo;

   HasABar(Foo foo) {
      this.foo = foo;
   }
   Drink getDrink() throws InvalidStateException{
      Foo foo.getBar().getDrink();
   }
}

class Foo {
   FooState state;
   Bar bar;

   public Foo() {
      state = new HasNothing(this);
  }

   Bar getBar() {
      return bar;
   }

   void setBar(Bar bar) {
      this.Bar = bar;
      if (null != bar) {
         state = new HasABar(this);
      }
      else {
         state = new HasNothing(this);
      }
   }

   Drink getDrink() throws InvalidStateException{
         return state.getDrink();
   }
}

At this point you are not really dealing with subtypes, you've got one type that behaves differently depending on state during runtime.


答:
Reasons to Use Version Control is really one - you have no reasons not to use version control.

Regardless of experience and skills, code quality and level of tasks.

Title: Reasons to Use Version Control

Body:
Possible Duplicate:

  I'm a Subversion geek, why I should consider or not consider Mercurial or Git or any other DVCS?

  What is the value of using version control?

I am a relative noob to programming, and am not going to be developing super-good software or even programming professionally anytime soon.  With this predicament, is there really any reason to learn git or subversion or any other version control systems?


问:
Are nullable types preferable to magic numbers?
I have been having a little bit of a debate with a coworker lately.  We are specifically using C#, but this could apply to any language with nullable types.  Say for example you have a value that represents a maximum.  However, this maximum value is optional.  I argue that a nullable number would be preferable.  My coworker favors the use of zero, citing precedent.  Granted, things like network sockets have often used zero to represent an unlimited timeout.  If I were to write code dealing with sockets today, I would personally use a nullable value, since I feel it would better represent the fact that there is NO timeout.

Which representation is better?  Both require a condition checking for the value meaning "none", but I believe that a nullable type conveys the intent a little bit better.

答: If you forget to check for the magic number (going to happen right), then a magic number will continue for a little while with nonsensical data. Much better to have a null that causes an exception as soon as possible.</p>


问:
When to learn the command line version of a programming tool?
Almost every programming tool has a command line version; many of which also have a gui version. It takes a lot of time and memorization effort to learn the different commands and various options/switches of the command line version.

So  I have a couple of questions (which are not necessarily mutually exclusive):

1) When would you bother learning/memorizing the commands in the command line version of a tool which also comes in a gui version ?

2) What tools should I learn the command line version of ? .... compilers ?  version control system ? etc, etc

答: I'm not sure that you should ever try to memorize the switches on a command-line tool. If you're creating a shell script or whatever to automate some task, you'd better look all that stuff up-- spend the thirty seconds now, to avoid hours of pain figuring out what went wrong later. If you're using the same command-line tool over and over again, maybe you should make a shell script...


问:
Queue in facebook games [looking for opponent and such]
I've seen many games on FB have queue which connects you to an opponent you should be playing against.

So my question is: In which language can it be coded? Is it possible to do it in PHP/Javascript?

Does anyone have any real/live example or tutorial how is this done?

Thanks in advance!

答:
You can write up a system like that in any Turing-complete language.  It's really not that complicated.  Here's the basic, high-level principle (for one way to do it; you can probably do it other ways):

You have a list of all people waiting for a match.  (Not necessarily a List list, but some data structure that can hold multiple people.)  When a new applicant shows up, check them against the list and see if you find a suitable match.  If so, pull the match off the list and send each player's system a notification that they need to connect with the other system.  Otherwise, add the newcomer to the list.  If someone gets tired of waiting and disconnects, remove them from the list.

Details of how to implement this will obviously vary quite a bit depending on exactly what your system is doing.  In the simplest case, there's no such thing as an unsuitable match, so your waiting list will never be longer than one player.  At the other extreme, if your list is likely to contain thousands of players for whatever reason, you might want to look at optimizing the lookup somehow.  But in the in-between territory, the technique I just described will probably work well.


问:
How do I Integrate Production Database Hot Fixes into Shared Database Development model?
We are using SQL Source Control 3, SQL Compare, SQL Data Compare from RedGate, Mercurial repositories, TeamCity  and a set of 4 environments including production.

I am working on getting us to a dedicated environment per developer, but for at least the next 6 months we are stuck with a shared model.

To summarize our current system, we have a DEV SQL server where developers first make changes/additions.  They commit their changes through SQL Source Control to a local hgdev repository.  When they execute an hg push to the main repository, TeamCity listens for that and then (among other things) pushes hgdev repository to hgrc.  Another TeamCity process listens for that and does a pull from hgrc and deploys the latest to a QA SQL Server where regression and integration tests are run.  When those are passed a push from hgrc to hgprod occurs.  We do a compare of hgprod to our PREPROD SQL Server and generate deployment/rollback scripts for our production release.

Separate from the above we have database Hot Fixes that will need to be applied in between releases.  The process there is for our Operations team make changes on the PreProd database, and then after testing, to use SQL Source Control to commit their hot fix changes to hgprod from the PREPROD database, and then do a compare from hgprod to PRODUCTION, create deployment scripts and run them on PRODUCTION.

If we were in a dedicated database per developer model, we could simply automatically push hgprod back to hgdev and merge in the hot fix change (through TeamCity monitoring for hgprod checkins) and then developers would pick it up and merge it to their local repository and database periodically.

However, given that with a shared model the DEV database itself is the source of all changes, this won't work. Pushing hotfixes back to hgdev will show up in SQL Source Control as being different than DEV SQL Server and therefore we need to overwrite the reposistory with the "change" from the DEV SQL Server.

My only workaround so far is to just have OPS assign a developer the hotfix ticket with a script attached and then we run their hotfixes against DEV ourselves to merge them back in.

I'm not happy with that solution.  Other than working faster to get to dedicated environment, are they other ways to keep this loop going automatically?

答:
Do you have a hot fix branch based off your production mainline? If so then you could merge the hotfix updated back into Dev once they have been applied to your production environment. </p>

```<code>|---Mailine
V
|
|------ Hot Fixes (code merged from current prod) | Ready for QA
|  ^    -----QA :
|  |            :
|  |            : QA approved and ready for Prod
|  |          V
^-------Prod    __ Hotfixes approved push back to mainline
</code>```

Body:
Do you have a hot fix branch based off your production mainline? If so then you could merge the hotfix updated back into Dev once they have been applied to your production environment.

|---Mailine
V
|
|------ Hot Fixes (code merged from current prod) | Ready for QA
|  ^    -----QA :
|  |            :
|  |            : QA approved and ready for Prod
|  |          V
^-------Prod    __ Hotfixes approved push back to mainline


答:
It's all a matter of preference really, or matter of laziness. CamelCasing is easier to type, but I prefer to use underscore notation as I find it personally easier to read and debug than CamelCase. There is no one set coding convention to abide by, I've never worked at a place that had the same coding guidelines as the place before it.

Most companies have guidelines you generally have to abide by any way to keep the code clean and easier for everyone to work on. If you're a freelancer, then you can go all out as you're the only person working on the code. There are only 2 coding conventions in my opinion to follow: CamelCase or Underscore notation. My advice is to pick one and then stick with it.

Title: Practical considerations for HTML / CSS naming conventions (syntax)

Body:
Question: what are the practical considerations for the syntax in class and id values?

Note that I'm not asking about the semantics, i.e. the actual words that are being used, as for example described in this blogpost. There are a lot of resources on that side of naming conventions already, in fact obscuring my search for practical information on the various syntactical bits: casing, use of interpunction (specifically the - dash), specific characters to use or avoid, etc.

To sum up the reasons I'm asking this question:

The naming restrictions on id and class don't naturally lead to any conventions

The abundance of resources on the semantic side of naming conventions obscure searches on the syntactic considerations

I couldn't find any authorative source on this

There wasn't any question on SE Programmers yet on this topic :)

Some of the conventions I've considered using:

UpperCamelCase, mainly as a cross-over habit from server side coding

lowerCamelCase, for consistency with JavaScript naming conventions

css-style-classes, which is consistent with naming of css properties (but can be annoying when Ctrl+Shift+ArrowKey selection of text)

with_under_scores, which I personally haven't seen used much

alllowercase, simple to remember but can be hard to read for longer names

UPPERCASEFTW, as a great way to annoy your fellow programmers (perhaps combined with option 4 for readability)

And probably I've left out some important options or combinations as well.  So: what considerations are there for naming conventions, and to which convention do they lead?


问:
Refactoring While Programming
When posed with a problem, particularly when it is complicated in nature, I try to take some time to think about the approach I am going to take to solve the problem.  Despite this, what often happens is, as I am programming the solution, I start to think of details of the problem that I missed, and I adjust the code accordingly.

What results is a mess of code that needs to be refactored.

I want to "refactor as I go," but while it sounds easy enough to do, I have a really hard time doing it.  When the detail that I missed is small, it is tempting to make a small update to my design, rather than erase what I've already written and write it the way it is supposed to be.

It sounds like a question with an obvious answer, but are there any techniques to use to better "refactor as you go"?  I know that this is a good principle, but I fail with it time and time again.

答: Unit testing the code might help.</p>

OwnerDisplayName: Kirby

Title: Refactoring While Programming

Body: Unit testing the code might help.

OwnerDisplayName: Edson Medina


答:
Here's what I often do: leave yourself notes as comments, or even commented-out code. When you've got the sloppy code working, you can now re-organize it easily.

Also, there's nothing inherently wrong with refactoring as you go, just make sure you have ways to test that your refactored code doesn't introduce new bugs before you proceed.

Title: Refactoring While Programming

Body:
When posed with a problem, particularly when it is complicated in nature, I try to take some time to think about the approach I am going to take to solve the problem.  Despite this, what often happens is, as I am programming the solution, I start to think of details of the problem that I missed, and I adjust the code accordingly.

What results is a mess of code that needs to be refactored.

I want to "refactor as I go," but while it sounds easy enough to do, I have a really hard time doing it.  When the detail that I missed is small, it is tempting to make a small update to my design, rather than erase what I've already written and write it the way it is supposed to be.

It sounds like a question with an obvious answer, but are there any techniques to use to better "refactor as you go"?  I know that this is a good principle, but I fail with it time and time again.

OwnerDisplayName: Luke Dennis


问:
How do I showcase my work experience in programming?
I'm a student of web development languages like PHP, Ruby, and Python. Currently I'm working on some school projects but I'm trying to work on some weekend projects which I can use to showcase for potential employers, what's the best way to set this up? Specifically, are there any tips you have for a new programmer because I don't want opinions on how this or that should or shouldn't be set up. If possible please give real examples.

Edit: what about Git? Is this a good place to show my projects?

答:
I don't think you need a 'showcase portfolio' that much, unless you're a designer. What is in your head is far more important.

Prepare a good CV that clearly lists the techniques you're used and your impact (ie. optimized stored procs so average query execution time went down 20%). You are more likely to be asked technical questions during your interviews that asked to show your 'portfolio'.


答:
Is it possible that you're writing interfaces as if taking a top-down approach to solving a problem, but then implementing from the bottom up? If so then I think that's the logical mismatch that is causing you problems.

Based on what you're describing it might be better to break the problem down so that you can think of at least one thing you need to do, then implement just that. Think of another thing you need to do and implement just that. Keep on going, building your solution so that you write the absolute fundamentals first, then the building blocks that rest on top of those and so on upward until you've got the actual solution nailed down. I tend to find that the complete solution, even to hard problems, tends to sneak up on you and suddenly jump out when following that sort of approach.

If you keep the intermediate building blocks logically focussed and deliberately keep each segment of code closed and limited then the amount of refactoring you'll need to do should always be small and isolated.

Title: Refactoring While Programming


答:
You seem oblivious to one simple fact: most CSS is not done by programmers.

It's done by graphic designers.

They don't care about our editing wars and couldn't care less about what we do with the shift key.

They don't even probably know where that fancy _ key is. (or what its name is)

They don't care about code aesthetics, they care about aesthetic aesthetics.

(And they may have a point there)

They don't read the spec, they get the tutorial.

And then double-check references on w3schools.

Some of them probably believe they cannot use uppercase classnames because of reasons.

They're full of weird, mostly irrelevant misconceptions.


答:
What results is a mess of code that needs to be refactored.

Just blow through the problem until you understand it. Then make a fresh, correct implementation after you know its form.

To answer your question in more general terms: Remind yourself that necessary changes generally cause less ripple/retesting if made sooner than later.

Title: Refactoring While Programming


答:
Probably the fundamental observation in Fowler's Refactoring book is that you are much better off separating changes that affect code behavior from changes that don't.  Those in the latter category, we call "refactoring".  If you mix these changes, you mess them up - so don't.  You can switch back and forth between coding and refactoring modes, but don't do both at the same time.  Because if you try to, you won't know what you did wrong.

If you try to introduce a behavior-modifying change, and the behavior doesn't modify: you did something wrong; review it and fix it.  Maybe just roll it back.

If you try to introduce a refactoring, and the behavior does modify: you did something wrong; review it and fix it.  Maybe just roll it back.

You can't make that simple assessment if you attempt both changes at once.  Nor can you, if you don't have unit tests.  Write them.  And do one thing at a time.

Title: Refactoring While Programming


答:
Another good rule of thumb is that every method should do one thing only.

If you break down the processing of what you are trying to implement into small discrete steps, and code the steps as methods, then when it is time to re-factor, you will find that the only refactoring that makes any sense is to change the order that the methods are called in or to leave some methods out of the execution path.

Also, since your methods are discrete, you are free to re-factor any single method as long as the value returned is what it should be, none of the other code will be any the wiser that a change was made.

This sets the stage for you to perform incremental improvements to your code over time by simply optimizing a method here and there.  The overall logic doesn't change, just the details of a particular step.

If you follow this up from methods to classes, where in your classes do or represent only a single object, you will find that, just as with the methods, your refactoring becomes more just a reshuffling of the order that your classes are constructed and used, and less about actually changing the detail logic.

You know you have hit the sweet spot when the program specification changes drastically and suddenly, but you are able to accomodate nearly all of the required changes simply by modifying the relationships between your objects - without changing their internal implementation at all!  It feels like you suddenly acquire nirvana!

Good luck and may all your code be bug free!

Rodney

Title: Refactoring While Programming


答:
... it is tempting to make a small update to my design, rather than erase
  what I've already written and write it the way it is supposed to be.

Nothing is supposed. The only supposed thing is that:

you can do any thing you want

your lifetime / worktime is limited and you can only reach a limited number of things.

What do you want? One finished absolutely perfect super-duper-excellent-clean-code project, or three finished projects, only 70%-code-elegancy compared to the former, but 3 times 95% of the from the user's point of view? What will be more useful for the world, for your people, for your mission?

What do you want?

Of course, in long term, it might pay off to refactor (lowers mtce time etc.), but only in long time. We, programmers, are often tempted to refactor and optimize much sooner than it is needed. We often refactor a code that is not further developed, which means wasted time.

I use my own golden rule of 2-3. In the first usage of particular code, I just bastle it ASAP. It almost never pays off to think about more general usage of it, because you don't have enough information yet on what use-cases might come. And also, this part of code might be never used again. When the code is needed second time, I try to make the first code more general to apply to this case also, or I choose to copy it (but this I don't like). With the 3rd usage I feel I have quite sufficient information to refactor and, as this part of code seems to be really used, I feel it pays off.

Title: Refactoring While Programming


答:
I am unaware of any specific study, but check out work by Steve McConnell.  </p>

<p>If anyone has it, he will. For instance  a two minute scan found this (16 years old but still relevant today). </p>

Title: Is there a case study that convincingly demonstrates that clean code improved development?

Body:
I'm in my first real job as programmer and what I see is just the "Big Ball of Mud" code (without useful comments too), but I like to do clean code, and it's really hard for me to code in a worse way.

I'm searching for some study case where the usage of clean code (I see various definitions here of what is clean code) improved the development and maintainability.

Body:
I am unaware of any specific study, but check out work by Steve McConnell.

If anyone has it, he will. For instance  a two minute scan found this (16 years old but still relevant today).


答:
Null: common error value, unspecified, void, or absence of value.

Zero: An actual, but not necessarily logical or intuitive value (in this context). Also a common value in initialization.

In the context of your problem, the timeoutInMilliseconds property is optional and there is no mention that the overhead of this approach would disqualify it as an option.

Conclusion: There are exceptions, and solutions vary by languages and domain;  in this case, I would choose Null. Where (I believe) some people get this wrong is when they do not separate the data from the interface well. They just expect any client to read the documentation (or implementation) to determine how these special values are to be used/handled -- the special cases leak into the client's program and it can be quite unclear. By adding a good abstraction layer, the usage can be much clearer.

Title: Are nullable types preferable to magic numbers?

Body:
I have been having a little bit of a debate with a coworker lately.  We are specifically using C#, but this could apply to any language with nullable types.  Say for example you have a value that represents a maximum.  However, this maximum value is optional.  I argue that a nullable number would be preferable.  My coworker favors the use of zero, citing precedent.  Granted, things like network sockets have often used zero to represent an unlimited timeout.  If I were to write code dealing with sockets today, I would personally use a nullable value, since I feel it would better represent the fact that there is NO timeout.

Which representation is better?  Both require a condition checking for the value meaning "none", but I believe that a nullable type conveys the intent a little bit better.


问:
Shared memory multiprocesses
I'm building an multi processes application and I need to save session ID, the sessions ID is 32 bit, and of course it can't be used twice in its lifetime, I'm currently using DB that saves all the ID in a table, and I do the following,

ID table is (int key, char used(1)) //1 is used, 0 is not
1. lock table
2. get one key for one sessions
3. update used field in it to used
4. unlock

After the session is finished the process use below to free key,
1. lock table
2. update used field in it to not used
4. unlock

I'm really wondering whether this is a good/fast implementation. and please note it's multi processes application.

答: By definition database access is no the fastest repository. I need more details about the process to tell you something more useful, but keep in mind that using a database to do what you want is the simplest way but not the fastest. This link shows how Voltdb generates its unique transaction ID in a distributed environment : http://voltdb.com/company/blog/lifecycle-transaction.</p>

Title: Shared memory multiprocesses


答:
A quick (but by no means exhaustive) search of Google Scholar turns up a lot of articles which refer to Bob Martin's Clean Code, but I haven't personally seen any papers that cover a correlation between "clean code" and improved development.

However, think about your question for a moment. You are asking about improved development, and that in itself is a very broad subject area covered not simply by writing better code, but also by many other factors such as communication, managing expectations, methodology and streamlining processes, testing, continuous integration, and really the whole box and dice when you consider just how many things go into making a software development project successful, let alone improving on it.

So you question should probably be: does writing clean code contribute to improved software development? To answer that, the only "evidence" I could provide with would be entirely anecdotal, and for that I think the Clean Code book would be an excellent reference, as it is written not only by Bob Martin himself, but also with many chapters contributed by some of the smartest software developers out there. If that doesn't help, then perhaps a little cold hard logic might apply.

If you make a mess in your home, and you never get around to cleaning it, then living in your home will become a chore.  It becomes harder to find things, harder to move around, and nobody in their right mind will want to visit you if you live in a filthy environment. The same too with code. If your code is a mess, you find it harder to located problems, let alone fix them.  It becomes easier to justify a work-around that might not do the job, but hey, it sure beats having to wade through all that old legacy muck, right? In the end, just like never tidying your home, allowing your code to become untidy will cost you time, and effort, and created difficulties for you in the long run. Keeping your code clean however will provide you with a nicer platform to work in, make refactoring and debugging less of a chore, and will require you to worry less often about whether you'll be able to maintain your code easily over time.

No, I don't have direct evidence to give you, and these are merely the thoughts of someone who has been doing this stuff for a very long time, and who hopefully has earned a little software development wisdom along the way. :-)