问:
Single or multiple files for unit testing a single class?
In researching unit testing best practices to help put together guidelines for my organization, I've run into the question of whether it is better or useful to separate test fixtures (test classes) or to keep all tests for a single class in one file.

Fwiw, I am referring to "unit tests" in the pure sense that they are white-box tests targeting a single class, one assertion per test, all dependencies mocked, etc.

An example scenario is a class (call it Document) that has two methods: CheckIn and CheckOut.  Each method implements various rules, etc. that control their behavior.  Following the one-assertion-per-test rule, I will have multiple tests for each method.  I can either place all of the tests in a single DocumentTests class with names like CheckInShouldThrowExceptionWhenUserIsUnauthorized and CheckOutShouldThrowExceptionWhenUserIsUnauthorized.

Or, I could have two separate test classes: CheckInShould and CheckOutShould. In this case, my test names would be shortened but they'd be organized so all tests for a specific behavior (method) are together.

I'm sure there are pro's and con's to either approach and am wondering if anyone has gone the route with multiple files and, if so, why?  Or, if you've opted for the single file approach, why do you feel it is better?

答:
Can't really see any compelling reason why you would split a test for a single class into multiple test-classes. Since the driving idea should be to maintain cohesion on a class-level, you should strive for it on a test-level as well. Just some random reasons:

No need to duplicate (and maintain multiple versions of) set-up code

Easier to run all tests for a class from an IDE if they are group in one test-class

Easier troubleshooting with one-to-one mapping between test-classes and classes.


问:
How can I retain knowledge about new technologies I don't use every day?
At work we mostly do WinForms development and it’s not a secret that it is already very outdated. I have a passion to learn new stuff like WPF, MVVM and want to use full advantages of C# 4.0. There is no way I can push my bosses to change “well-recommended” and “proven” technologies like WinForms to something else.

I have up to two hours a day which I can dedicate to self-learning but I simply don’t know the most efficient way to study. I tried to read couple of books and even wrote a simple WPF application but think that it’s not enough.

How can I manage my time learning new things in a way that sticks, even if I don't use it on a daily basis?

答:
If you are passionate about learning new things, there are more hours of the day than you spend at work. Do some smaller hobby-projects on your own time to try out new technologies.

That's what most of us do.

ContentLicense: CC BY-SA 3.0


答:
In addition to actually using the technology in smaller projects, such as Oded and maple_shaft suggested, I find answering questions on SO to be a good way to keep up with what's going on.

I've moved away from WPF programming a bit at work (stuck doing web stuff... ugh), but I still love it and find that browsing/answering questions on SO is one way to keep my WPF knowledge from getting rusty.

Title: How can I retain knowledge about new technologies I don't use every day?

Body:
At work we mostly do WinForms development and it’s not a secret that it is already very outdated. I have a passion to learn new stuff like WPF, MVVM and want to use full advantages of C# 4.0. There is no way I can push my bosses to change “well-recommended” and “proven” technologies like WinForms to something else.

I have up to two hours a day which I can dedicate to self-learning but I simply don’t know the most efficient way to study. I tried to read couple of books and even wrote a simple WPF application but think that it’s not enough.

How can I manage my time learning new things in a way that sticks, even if I don't use it on a daily basis?


答:
If you are compelled to split unit tests for a class across multiple files, that may be an indication that the class itself is poorly designed. I can't think of any scenario where it would be more beneficial to split up the unit tests for a class that reasonably adheres to the Single Responsibility Principle and other programming best practices.

Furthermore, having longer method names in unit tests is acceptable, but if it bothers you, you can always rethink your unit test naming convention to shorten the names.

Title: Single or multiple files for unit testing a single class?

Body:
In researching unit testing best practices to help put together guidelines for my organization, I've run into the question of whether it is better or useful to separate test fixtures (test classes) or to keep all tests for a single class in one file.

Fwiw, I am referring to "unit tests" in the pure sense that they are white-box tests targeting a single class, one assertion per test, all dependencies mocked, etc.

An example scenario is a class (call it Document) that has two methods: CheckIn and CheckOut.  Each method implements various rules, etc. that control their behavior.  Following the one-assertion-per-test rule, I will have multiple tests for each method.  I can either place all of the tests in a single DocumentTests class with names like CheckInShouldThrowExceptionWhenUserIsUnauthorized and CheckOutShouldThrowExceptionWhenUserIsUnauthorized.

Or, I could have two separate test classes: CheckInShould and CheckOutShould. In this case, my test names would be shortened but they'd be organized so all tests for a specific behavior (method) are together.

I'm sure there are pro's and con's to either approach and am wondering if anyone has gone the route with multiple files and, if so, why?  Or, if you've opted for the single file approach, why do you feel it is better?


问:
Using Django without a database
Is Django a good solution for creating applications that won't use any database and communicate only through an internal API? </p>

答:
Depends what you call 'good'. </p>

<p>However, while you can use django with no database, the object-relational mapper is pretty much its first and foremost advertised feature. Django was designed to produce database-backed web sites, so if you're not going to use a database you might end up dealing with a bunch of unnecessary hassle. </p>

Title: Using Django without a database

Body:
Depends what you call 'good'.

However, while you can use django with no database, the object-relational mapper is pretty much its first and foremost advertised feature. Django was designed to produce database-backed web sites, so if you're not going to use a database you might end up dealing with a bunch of unnecessary hassle.


问:
Why aren't there automated translators from one programming language to another?
Most programming languages are Turing complete, which means that any task that can be solved in one language can be solved in another one, or even on Turing machine. Then why aren't there automatic translators that can convert programs from any given language to any other language? I've seen couple attempts for two languages, but they always work only on a limited subset of a language and can hardly be used for converting real projects.

Is it possible, at least in theory, to write 100% correct translator between all languages? What are the challenges in practice? Are there any existing translators that work?

答:
It's theoretically possible but mostly useless. Almost any combination of source and target languages is possible, but in most cases nobody would ever want to look at or use the result.

A fair number of compilers do target C, simply because C compilers are available for almost every platform in existence (and there are automatic compiler generators that will let you design a processor, and automatically generate a C compiler that targets your new processor). There are also, of course, a fair number of implementations that target the languages used by various virtual machines such as .NET, JVM, C--, and LLVM.

The key point, however, is that it's really only useful if you treat the target is basically an assembly language that's only used as a step in the compilation process. In particular, you generally do not want a normal programmer to read or work with that result; it usually won't be very readable.

ContentLicense: CC BY-SA 2.5


答: It's rare, but sometimes it makes sense to have multiple test classes for a given class under test.  Typically I would do this when different setups are required, and shared across a subset of the tests.</p>


问:
Are there any tools that allow you to track and manage test cases and test execution?
For the bugs or issues, there are now many good issues trackers available which allows status and tracking issues and also allows you to organize it to manage specific releases.

I am looking for test case tools should be able to support listing of functionality and test cases with possible linkage to them, allows test suits or test plans (as group/ hierarchies) to organize them. Some of the potential usage could be to identify list of key test cases that must be executed if particular functionality or modules are affected.

Also Additional parameters to support related to system of execution. It would be best if result of execution of tests can be recorded with necessary comments. Web interface and possible email notifications could be essential.

Please note that i am NOT looking at test automation systems like cruise control etc. but more as a system for testing management. I am more keen to see a system that allows visualization of Traceability matrix. Open source projects are most appreciated, though please also suggest if there is commercial software.

Are there any tools that allow you to track and manage test cases and test execution?

答: There are many tools for helping you with test management.If you haven't yet selected a tool perhaps you should consider TestWave (http://www.testwave.co.uk). It is a commercial, hosted test management solution which allows you to create your test scripts, execute them, store any details about the run (including attachments) and also to raise bugs or defects. You can even link your test cases to requirements and releases to make your testing easier to keep track of.</p>


问:
ASP.Net MVC or Web Forms?

Possible Duplicate:

  Why would you use MVC over Web Forms?

What is the difference between ASP.Net MVC and Web Forms? Is either preferable? I want to use ASP.Net development as a springboard to teach myself C#. What is the best way to go about this?

答:
They are two different approaches to creating a web application. Web forms mirror how desktop application are created in visual studio, each page is its own self contained unit. In MVC pages are divided up into models views and controllers, controllers handle signals/events and tell models/views what to do, models handle the data, and the view is the display. each part of the MVC architecture can communicate with the others, and they are designed to be inter changeable so controller A and controller B could both work just fine with Model A.

Right now both are well supported and in common use, MVC is newer to .Net though so webforms is still more common in the industry, but both are good ways to learn. they are completely different though and it is non trivial to switch a project between the two.

Title: ASP.Net MVC or Web Forms?


问:
How do quick & dirty programmers know they got it right?
If you ask programmers why they should write clean code, the number one answer you get is maintainability.  While that's on my list, my main reason is more immediate and less altruistic:  I can't tell if my new code is correct if it's too dirty.  I find that I have focused on individual functions and lines of code so much that when I finish my first draft and step back to look at the big picture again it sometimes doesn't fit together very neatly.  Spending an hour or two refactoring for cleanliness frequently uncovers copy/paste errors or boundary conditions that were very difficult to detect in the rough draft.

However, some people feel it's occasionally okay to intentionally check in dirty code in the interest of shipping software, with a plan to "clean it up later."  Is there is some practicable technique that gives them confidence in the correctness of their code when the readability is less than ideal?  Is it a skill worth trying to develop?  Or is a lack of confidence in the code something some people just find easier to accept?

答: They don't. I'm currently working on a code base created by "quick and dirty" programmers who would "clean it up later." They're long gone, and the code lives on, creaking its way toward oblivion.  Cowboy coders, in general, simply don't understand all of the potential failure modes that their software may have, and don't understand the risks to which they are exposing the company (and clients).


答: I don't think you should even start going down that road. Quick and dirty might give you the temporal benefit of finishing faster, but you always pay ten-foldedly for doing this in the end.</p>

Title: How do quick & dirty programmers know they got it right?

Body:
If you ask programmers why they should write clean code, the number one answer you get is maintainability.  While that's on my list, my main reason is more immediate and less altruistic:  I can't tell if my new code is correct if it's too dirty.  I find that I have focused on individual functions and lines of code so much that when I finish my first draft and step back to look at the big picture again it sometimes doesn't fit together very neatly.  Spending an hour or two refactoring for cleanliness frequently uncovers copy/paste errors or boundary conditions that were very difficult to detect in the rough draft.

However, some people feel it's occasionally okay to intentionally check in dirty code in the interest of shipping software, with a plan to "clean it up later."  Is there is some practicable technique that gives them confidence in the correctness of their code when the readability is less than ideal?  Is it a skill worth trying to develop?  Or is a lack of confidence in the code something some people just find easier to accept?


答:
I don't think they can honestly say they got it right if it's not easily maintainable. If they admit they have to "clean it up later", then there is likely something they haven't thought through enough. Testing it thoroughly will only truly uncover any issues with dirty code.

I personally wouldn't aim to develop the skill of "writing dirty code" and being confident about its correctness. I would rather write proper code the first time around.


答:
In some cases I guess there could be a large suite of regressiontests that will find "all" bugs and verify the behaviour, thereby allowing for a quick and dirty coding technique. But mostly its just a matter of bad project planning and a manager who thinks its more important to get it done, than to get it done right. </p>

<p>And forget about "clean it up later", that never happens. In the rare cases it happens, the programmer will have forgotten most of the code making the job alot more expensive than if he had done it right the first time. </p>

Body:
In some cases I guess there could be a large suite of regressiontests that will find "all" bugs and verify the behaviour, thereby allowing for a quick and dirty coding technique. But mostly its just a matter of bad project planning and a manager who thinks its more important to get it done, than to get it done right.

And forget about "clean it up later", that never happens. In the rare cases it happens, the programmer will have forgotten most of the code making the job alot more expensive than if he had done it right the first time.


答:
Unit tests. Its the only way to have confidence in any code (dirty or not).

On a side note;

short cuts make for long delays (Pippin)


答:
Such programmers almost never know they got it right, only believe so. And the difference may not be easy to perceive.

I remember how I used to program before I learned about unit testing. And I remember that feeling of confidence and trust on a wholly different level after I ran my first decent suite of unit tests. I hadn't known such level of confidence in my code existed before.

For someone who lacks this experience, it is impossible to explain the difference. So they may even go on developing in code-and-pray mode throughout their life, benevolently (and ignorantly) believing that they are doing their best considering the circumstances.

That said, there can indeed be great programmers and exceptional cases, when one really manages to hold the whole problem space in his/her mind, in a complete state of flow. I have experienced rare moments like this, when I perfectly knew what to write, the code just flew out of me effortlessly, I could foresee all special cases and boundary conditions, and the resulting code just worked. I have no doubt there are programming geniuses out there who can stay in such state of flow for extended periods or even most of their time, and what they produce is beautiful code, seemingly without effort. I guess such persons might feel no need to write puny unit tests to verify what they already know. And if you really are such a genius, it may be OK (although even then, you won't be around that project forever, and you should think about your successors...). But if not...

And let's face it, chances are you aren't. I, for myself, know I am not. I had some rare moments of flow - and countless hours of grief and sorrow, usually caused by my own mistakes. It's better be honest and realistic. In fact, I believe the greatest programmers are fully aware of their own fallibility and past mistakes, so they have consciously developed the habit of double checking their assumptions and writing those little unit tests, to keep themselves on the safe side. ("I am not a great programmer - just a good programmer with great habits." - Kent Beck.)


问:
How should semi-agile team operate during management-imposed waterfall-like "testing phase"
I'm not looking for advice how agile process should work. I know that part. I'm curious what the best way to adapt the process to a typical large, well-established corporation who loves its "processes" and gate/passport reviews.

For those lucky enough not to know what they are, gates/passport things are essentially waterfall milestones presented by development teams to executives: Gate 0 - kick off, identifying positive npv projects; Gate 1 - planning work for the release, coding begins, Gate 2 - code complete/testing phase, Gate 3....

While within our team we've tried to embrace agile as much as we could (peer reviews, iterations, constant communication, doing what makes sense, continuous improvement...), these gates come from way up and there's nothing we can do about them.

Of many things that bug me, one of them is that the corporate environment we are in, imposes some constraints which seem to have adverse effects on how we work. One example is that during development we only focus on new features and ignore existing bugs and even introduce new bugs.  This is unfortunate and goes against agile, but we have no choice since code complete could be in 2 months, but "testing/bug fixing" phase can last 6 months after that.  We are under constant pressure to "finish work" but emphasis is on completing features, not getting a stable product.  This part we sorta learned to live with.

My question is what strategy (successful mode of operation) other teams/companies have found for the "testing" phase that follows a "code complete" milestone?

During "new development" we have iterations and each one gets filled in with stories and tasks. However, currently once development is "done", there's no more iterations and no more planning. Instead, we solely use bug tracking database to monitor how many new bugs are being found and how fast the bugs are being resolved.

Personally, I don't see the difference between adding new UI feature and making existing UI feature work. To me work is work. I proposed that we continue having iterations as normal and continue to schedule work as before, but neither management nor other team members seemed to be on board with that.  So 1) am I way off and is bug track database the best we can do? and 2) if there's a better approach, I'd like to explore it and maybe acquire enough ammunition to take back to my boss.  At the same time I somewhat agree that a lot of times when reacting to bugs we don't have the luxury of waiting till next iteration.

--- Slight clarification based on first few responses ---

We just entered the testing phase. At the moment, there's no more stories, no more iterations. Only bug tracking database. That doesn't sit right with me, that's why I'm curious what other teams would do in this situation.  Also some bugs are definitely the size of a medium size story, while other bugs would take 5 min to fix.  Should 5-min bugs also become stories if we were to continue with iterations? The other argument we've been having is that during "new development" we only interact with Agile tracking tool (Rally) but in "testing" if we continue with iterations, we'd have to maintain paper trail in Rally as well as in bug tracking software.

答:
Try this: Shrink your iterations to a size that you can get done and tested in the Coding Phase. Your testing phase will be finished early (IE: however long it takes your unit tests to run.)

Alternately: Ignore the gates. Your company's definition of Code Complete is meaningless anyway. If you haven't written any code for a feature by the testing phase, then declare that feature "done" and file a bug for the fact that it does not work yet.


问:
Should an interviewer be prepared to answer any question he asks?
As I gain more professional experience, I've become a bit more skeptical about a lot of the politics of the interview process. In particular, I'm curious to know if y'all think it's ok to ask the interviewer the same questions you're asked. For instance, in an interview a few years back, I was asked:

Where do you see yourself in 5 years?

I gave a decent answer, and then asked the interviewer:

Where do you see yourself in 5 years?

He actually gave a fairly thoughtful answer. What about questions like:

Why do you like working here?

Tell me about a time you had a conflict with a coworker and how you resolved it.

Answer this  question.

EDIT:
I meant:

Answer this [insert technical gotcha question here] question.

答:
If you are asking it you should be able to answer it. You are not the only one doing an interview. The candidate (if he is doing it right) will also be interviewing you and your company. You are a future coworker (possibly manager). If I was interviewed and the interviewer couldn't answer "why do you like working here" or something like "You have worked here X years, what about this company keeps you here" I would hold reservations about my future boss. Some of those questions are almost exactly what I asked in my last interviews.

I made the mistake of not interviewing my employer with my first job out of college. I will never, ever, make that mistake again.


答: Speaking from a technical standpoint, in general, yes if the interviewer asks you a technical question such as the difference between an abstract class and and interface, they should be prepared to answer the question themselves. If they can't answer the question themselves it would generally reflect poorly upon the interviewer and the company as it means that the person doing the interview is not qualified to be conducting it. </p>

Title: Should an interviewer be prepared to answer any question he asks?

Body:
As I gain more professional experience, I've become a bit more skeptical about a lot of the politics of the interview process. In particular, I'm curious to know if y'all think it's ok to ask the interviewer the same questions you're asked. For instance, in an interview a few years back, I was asked:

Where do you see yourself in 5 years?

I gave a decent answer, and then asked the interviewer:

Where do you see yourself in 5 years?

He actually gave a fairly thoughtful answer. What about questions like:

Why do you like working here?

Tell me about a time you had a conflict with a coworker and how you resolved it.

Answer this  question.

EDIT:
I meant:

Answer this [insert technical gotcha question here] question.


答:
Most questions your interviewers will ask you are tailored to get to know you. In general you should ask questions that maximizes your knowledge about the company/team and not the individual that is interviewing you.

In case your interviewer is going to be your superior or only team member, it might make sense to figure out whether you can work with them. Just like they are trying to figure out whether you are a good fit for them, you should try to figure out whether you think you would be a good fit as well.

To sum up, there might be some overlapping in their and your questions, however in general the set of questions will be very different from each other.


答: Not exactly any question he might ask, because he shouldn't ask women something like "Are you planning to have kids in the near future". But if just applying the Golden Rule here and he doesn't want to answer something like "Tell me everything you know about our company" if he's totally not an expert on a company he hasn't worked at, he probably wouldn't ask such questions either.


答:
Where do you see yourself in 5 years?

I don't believe there are good answers to this question. I think it's a waste of time. Waste your interviewer's time at your own risk.

Why do you like working here?

Definitely! If the interviewer can't give an honest answer without even thinking about it, you don't want to work there!

Tell me about a time you had a conflict with a coworker and how you resolved it.

This is a behavior-description type question, everyone with a little working experience should have some answer to this. And if you're asking behavior-description questions, you should think about what kind of behavior would be welcome/appropriate/expected from candidates before interviewing them, so an interviewer should have a good answer to that.

Answer this question.

Was this some kind of dadaist interview?


答:
It’s good to learn to accept that no software system of reasonable complexity will be perfect no matter how much unit testing and code tweaking is done. Some degree of chaos and vulnerability to the unexpected will always lurk within the code.  This doesn’t mean that one shouldn’t try to produce good code or conduct unit tests.  These are, of course, important. There’s a balance that has to be sought and this will vary from project to project.

The skill to be developed is an understanding of what level of ‘perfection’ needs to be used for a particular project. For example, if you’re writing an electronic medical records application with a 12 month project timeline you’ll want to devote a lot more time for testing and making sure your code is maintainable than you would for a one-off conference registration web app that has to be deployed by Friday. Problems arrive when somebody doing the EMR app gets sloppy or the registration app doesn’t get deployed in time because the programmer is too busy tweaking code.


问:
How do you include Support in your Sprint?
Our company moved to Scrum recently on a product that was almost coded by a single person (Joe). We have support to do with our exising customers that we try to integrate in our process.

For now we tried the following approach:

We do a rotation on a person in charge each week.

The person in charge for the week may spend up to 8 hours on support.

But we failed to have it work:

Joe always does the support because he knows the code better, and it's always faster for him to do it than to explain it.

We (the rest of us) tend to focus on what's on the Sprint board aka new stories instead of support tasks.

Joe has too much work, he can't handle all the support by himself because he has to do things outside of the Sprint as well.

Have you already faced similar situation? How did you manage to get out of it?

Note: We can't dedicate a single person on the support right now. We hope to in the future.

答:
We took a very similar approach by designating a "Support Programmer" that rotated through the more junior (or newest) developers on the team. They were encouraged to try really hard to figure out the problem before asking the other developers even if it would be faster to kick it over to the developer who knew the code best. This way they were forced to learn the codebase and you avoided knocking people out of "the zone" and destroying productivity. Also, you have to build in some mechanism to keep people from doing an end-around to the non-support programmers to make this work.

A key point is that the team needs to understand that what may be the fastest way to close support issues is not always the most efficient use of the team's time. Make sure the entire team knows that the goal of this structure is to minimize interruptions to people who are in that productive mode at all costs.

That said, the support programmer was not 100% dedicated to support calls. They did work on cases in the sprint, but were supposed to work on the lowest priority items so that if they got hung up on a lot of support issues the fact that they didn't finish their cases wouldn't be such a major concern.


答:
How do you include going to the bathroom in your Sprint?  How do you include time developers spend at home playing with their kids?  What about including time sleeping?

I am being sarcastic of course, the answer is that IMHO you shouldn't include support time in your sprint planning.  The only time that should be included in your sprint planning are tasks directly associated with sprint deliverables.

If a resource is to devote so much time to support then you have less available resource hours from that developer, that sprint.  The feature set included in that sprint should reflect this fact.

Title: How do you include Support in your Sprint?

Body:
Our company moved to Scrum recently on a product that was almost coded by a single person (Joe). We have support to do with our exising customers that we try to integrate in our process.

For now we tried the following approach:

We do a rotation on a person in charge each week.

The person in charge for the week may spend up to 8 hours on support.

But we failed to have it work:

Joe always does the support because he knows the code better, and it's always faster for him to do it than to explain it.

We (the rest of us) tend to focus on what's on the Sprint board aka new stories instead of support tasks.

Joe has too much work, he can't handle all the support by himself because he has to do things outside of the Sprint as well.

Have you already faced similar situation? How did you manage to get out of it?

Note: We can't dedicate a single person on the support right now. We hope to in the future.


问:
What do programmers have to know about business/management?
As I've implied through my other posts, I'm still fairly new to the workforce. During team meetings, I tend to be able to keep up with technical discussion, but when my project manager starts talking about how we've won a new contract, or we're involved in a new proposal bid, or... anything that's business rather than technical, really... I can get lost pretty quickly.

What is the bare minimum all developers need to know about project management/business to function?

答:
As other answers have stated the minimum will vary from situation to situation.  For example, a self-employed contractor may need to know a bit more than the full-time employee as the former may need an accountant and others to help run the business the contractor has.

There are some basics on financial health that I'd consider some basics like understanding where is your company in terms of maturity:  Is it a start-up still burning angel investors money or venture capitalists money now?  How close to profitable is the company?  Are there any big lawsuits that may kill the company in the near term?

I think some of the basics of understanding a project plan at a high level, how change requests are handled, and what kind of general process is there to get through a project are key things to know, as well.  I'm not saying you have to know all the steps in the change management process, but do be aware when this is used and how it may impact your project.

If you want to get more into the business side, you may want to inquire about more details of the contract that was won.  How many units are being sold?  Is this an initial pilot project at the client or is there a mass adoption now?  Those basic kind of questions that may help give a bit more detail to what you may end up having to tackle next.  For example, if your company started getting massive orders, couldn't this lead to some systems being pushed to their limits that may need to get remedied ASAP, no?  While I did give some vague areas and only a few specific examples, these are the parts that I tend to notice with a company.  How bureaucratic HR is would be another factor to not forget here to some extent.


问:
Is there a formal anti-pattern to describe the scenario?
Some code is written to generate Excel Spreadsheets (Office Interop).

The code performs very poorly.

A subsystem is designed to generate the files at night. Performance isn't a concern at night.

A function is created to pick the correct file from the 100 different files available depending on a chosen set of parameters.

Because physical files exist, an archival system is added to backup these files (There is no reason to archive.  These files should be generated on the fly).

This system doesn't include a configuration file, instead it has a hard coded "server picker" function that simply reflects upon the server the code is running upon.

A scheduled task is necessary to support and run this service.

This boils down to a single problem.  The original code performs far too poorly to run in a production environment.

Had the performance problem been resolved, the subsystem and subsequently archiving system, "file picker factory function", hard coded failure point and the maintenance of the scheduled task and its added point of failure have no need to exist.

This is a "cascading failure" if you will.  The original problem led to more bad code, more bad solutions and unnecessary overhead.  Is there a formal anti-pattern or general term to describe it?

答:
Lava flow?

In computer programming jargon, lava flow is a problem in which
computer code written under sub-optimal conditions is put into
production and added to while still in a developmental state.

From
the Perl Design Wiki: Lava Flow is "when code ... spews forth and
becomes permanent, it becomes an architectural feature of the
archaeological variety. Things are built atop the structure without
question and without hope of changing what is beneath them. The
existing code is seen as an historical curiosity."

Often, putting
the system into production results in a need to maintain backward
compatibility (as many additional components now depend on it) with
the original, incomplete design.

Lava flows are often exacerbated by
changes in the development team working on a project. As workers cycle
in and out of the project, knowledge of the purpose of aspects of the
system can be lost, and rather than clean up these pieces, they are
worked around, increasing the complexity and mess of the system.

Lava flow is considered an anti-pattern, a commonly encountered
phenomenon leading to poor design.


问:
Where can I find a legal "permission to work on open source" document?
One of the things I really like about my current job is that we developers are encouraged to make open source contributions.

However, this encouragement has always been verbal. I've read some horror stories about developers having their open-source work legally claimed by their employer. I'd be more comfortable if we had something in writing from my employer saying that contributions are allowed and not owned by the company.

Understanding that you are not lawyers, does anyone know where to find a boilerplate document to this effect?

答:
I'm not aware of any specific templates for agreements between you and your employer. There are templates for use between employer and project, for example:

You could take a look at the Apache Software Foundations Corporate Contributor Licence Agreement.

For more inspiration see the Harmony Agreements CCLA (for licensing) and CCAA(for assignment)


答: I think the simplest thing to do is to add your support activities directly to the list of items included in your sprint.  If these support activities are bug fixes, then they will be prioritized in your backlog in the same manner as you do for enhancements.  If they are time based (like running month end reporting) - these are also easily scheduled.  This is what we do and it works out well.</p>


问:
What does "automated build" mean?
I'm trying to add Continuous Integration to a project.

According to Wikipedia, one major piece of CI is automated builds.  However, I'm confused about what, exactly, that means, as the CI and build automation articles seem to disagree.

Specific points of confusion:  what does "automated build" mean in the context of:

a project using an interpreted language, such as Python or Perl?

building from source on an end-user's machine?

an application that has dependencies that cannot be simply pre-compiled and distributed, such as a database in an RDBMS local to the user's machine?

答:
To my mind, an automated build is something that

happens automatically, either on a schedule or with each commit to source control

creates a set of artefacts that can be deployed simply to any server

The aim is to have a deployment process that can be repeated -- read: tested -- so that by the time you deploy to production, you have a fair degree of certainty that things won't go wrong. The less human interaction in the build and deploy processes, the safer your release will be.

If you have a non-compiled language, you can still build a site and zip it up to create a single artefact.

A good CI tool will allow you to script many tasks into the build process, including the running of unit tests. It will also keep records of your successful and unsuccessful builds, test coverage, etc. But none of that is part of what I'd define as an automated build. (ie. A good automated build process has these things, but a poor one doesn't fail to be called "automated build" because it lacks those things.)

I would suggest that integration/regression tests be run as part of the deployment process, rather than the build process (although, if you have a convenient environment, you can deploy with every build).

Title: What does "automated build" mean?


答:
Okay, at risk of being complete downvote-bait, I'm going to "devils advocate" the opposing view.

I propose that we developers have a tendency to get overly concerned about things like proper practice and code cleanliness. I suggest that, while those things are important, none of it matters if you never ship.

Anyone who's been in this business a while would probably agree that it would be possible to fiddle with a piece of software more or less indefinitely. Duke Nukem Forever, my friends. There comes a time when that nice-to-have feature or that oh so urgent refactoring work just should be set aside and the thing should be called DONE.

I've fought my colleagues about this many times. There's ALWAYS one more tweak, something else that "should" be done for it to be "right". You can ALWAYS find that. At some point, in the real world, good enough just has to be good enough. No real-world, actual, shipping software is perfect. None. At best, it's good enough.


答:
An automated build is a description of a process that should cover the following basics:

Fetch the latest code from Source Control

Compile the latest code into the executable

Run tests (unit tests, system tests, integration tests) against compiled code

Deploy completed executable to a known location for deployment.

Publish the results of the build.

5.1 Successful Compilation, Unit test success

It is a hands-off, process that should run with zero manual intervention.

Title: What does "automated build" mean?

Body:
I'm trying to add Continuous Integration to a project.

According to Wikipedia, one major piece of CI is automated builds.  However, I'm confused about what, exactly, that means, as the CI and build automation articles seem to disagree.

Specific points of confusion:  what does "automated build" mean in the context of:

a project using an interpreted language, such as Python or Perl?

building from source on an end-user's machine?

an application that has dependencies that cannot be simply pre-compiled and distributed, such as a database in an RDBMS local to the user's machine?


答:
The code probably isn't right.

However, it may not matter.

Quick and dirty may be the right way to go in situations where:

The code has a short lifetime. For example, you're transforming a bunch of data into a standard format with an ad-hoc program.

The negative impact of failure is low:

The data you're transforming is non-critical, and errors in it can be easily corrected

The end-user is a sympathetic programmer, who will reason about error messages and work around them by, say, massaging the input.

Sometimes it's not important that code is robust and handles every conceivable input. Sometimes it just needs to handle the known data you have on hand.

In that situation, if unit tests help you get the code written faster (this is the case for me), then use them. Otherwise, code quick and dirty, get the job done. Bugs that don't trigger don't matter. Bugs you fix or work around on-the-fly don't matter.

What's absolutely vital is that you don't misdiagnose these situations. If you code quick-and-dirty because the code is only going to be used once, then someone decides to reuse the code in some project that deserves better code, that code deserved more care.


答:
My lesson in avoiding quick and dirty was when I had six months to deliver what was estimated (under-estimated) to be a year's worth of work.  I decided to research methodologies before starting work. In the end I invested three months of research and was able to deliver in the remaining three months.

We got big gains by identifying common functionality and building the required libraries to handle those requirements.  I still see coders writing their own code when there are available library routines.  These coders often rewrite, or at best cut and paste, the same code when they need to solve the same problem later.  Bug fixes invariably only catch some of the code copies.

One developer gave a telling reply when I asked him to use library code:  "Isn't that cheating?  I had to write all my own code in school."


答:
I'm not sure this is an anti-pattern.  As with all anti-patterns, we have to take your word that whoever thought it was a good idea was mistaken, but in this case that sounds plausible and I'll take your word for it, so that's not the problem.

The problem is that to be useful an anti-pattern needs to describe some sort of general pitfall and how it can be avoided.  In this case, I guess that would be finding a work-around for code that performs badly when you could just have made it perform better.

The problem with that as an anti-pattern, IMHO, is that knowing about it seems unlikely to be of much value.  Whoever did this presumably already understood that it would be nice to know how to make it perform better, so they must not have known how to do it.  So having heard about the general situation as an anti-pattern wouldn't really have helped.

As far as a general term to describe it, "cascading failure", as you suggested, works pretty well.  The term I like for unqualified people off on a mission that didn't make sense in the first place is snark hunting, but that seems too harsh for this situation.  (But I'll somewhat gratuitously throw the link in anyway, since it's the best depiction of a doomed enterprise I know).

Title: Is there a formal anti-pattern to describe the scenario?

Body:
Some code is written to generate Excel Spreadsheets (Office Interop).

The code performs very poorly.

A subsystem is designed to generate the files at night. Performance isn't a concern at night.

A function is created to pick the correct file from the 100 different files available depending on a chosen set of parameters.

Because physical files exist, an archival system is added to backup these files (There is no reason to archive.  These files should be generated on the fly).

This system doesn't include a configuration file, instead it has a hard coded "server picker" function that simply reflects upon the server the code is running upon.

A scheduled task is necessary to support and run this service.

This boils down to a single problem.  The original code performs far too poorly to run in a production environment.

Had the performance problem been resolved, the subsystem and subsequently archiving system, "file picker factory function", hard coded failure point and the maintenance of the scheduled task and its added point of failure have no need to exist.

This is a "cascading failure" if you will.  The original problem led to more bad code, more bad solutions and unnecessary overhead.  Is there a formal anti-pattern or general term to describe it?


答:
```<code>a project using an interpreted language, such as Python or Perl?
</code>```

In the case of interpreted languages, things can be hit or miss. Some interpenetrated languages have compilers but more often than not there is likely not much of a need to use them. In that case, I would generally just scan the code for syntax and parsing errors in place of compilation or skip straight to running the tests on the code.

building from source on an end-user's machine?

To me this would mean that you can provide a single command that end-users can run to get the latest version of the program, compile it, configure and deploy as needed.

an application that has dependencies that cannot be simply pre-compiled and
  distributed, such as a database in an RDBMS local to
  the user's machine?

These would fall under the testing part of the continuous integration as you can automatically destroy and reconstruct the databases to ensure that the scripts are correct and that the program tests against it correctly.

Title: What does "automated build" mean?

Body:
a project using an interpreted language, such as Python or Perl?

In the case of interpreted languages, things can be hit or miss. Some interpenetrated languages have compilers but more often than not there is likely not much of a need to use them. In that case, I would generally just scan the code for syntax and parsing errors in place of compilation or skip straight to running the tests on the code.

building from source on an end-user's machine?

To me this would mean that you can provide a single command that end-users can run to get the latest version of the program, compile it, configure and deploy as needed.

an application that has dependencies that cannot be simply pre-compiled and
  distributed, such as a database in an RDBMS local to
  the user's machine?

These would fall under the testing part of the continuous integration as you can automatically destroy and reconstruct the databases to ensure that the scripts are correct and that the program tests against it correctly.


答:
You are correct in noting that, for some technologies, a compilation step is not necessary. However, I recommend you take a broader view when interpreting the term "build automation". Think about "build" as including the following two major components:

The process for transformation source artifacts (code, database schema, documentation, etc.) deployed to an end user.

The application of quality assurance measures during said transformation

Automation, then, simply refers to making any--if not all--of those operations automatic (that is, not requiring manual intervention). This may include quite a variety of steps, depending on your technology:

Transformation steps:

Compilation

Linking

Packaging

Deployment

Data migration

Backup

Notification

Quality assurance steps:

Compiler warnings / errors

Unit tests

Integration tests

System tests

Deployment authentication

These days, good CI tools will let you address all of these concerns. Initially, most shops are interested in automating compilation of their code, since that's the first--and most visible--source of problems in conventional software development.

Title: What does "automated build" mean?


问:
Why is Python recommended as an entry level programming language?
I've read here on P.SE more questions in which beginner programmers are advised to pick Python as their first programming language.

Don't get me wrong, I like Python. I like it a lot! But its philosophy revolves around "We are all consenting adults here".

From an experience/knowledge point of view, a beginner programmer is not an adult. Which then kinda means it is easier to shoot yourself in the foot and pick up some bad habits even if you survive the wound.

I'm thinking that in a "more static" language it would be harder to shoot yourself in the foot as it will be more restrictive.

Back to my question. Why is Python recommended as an entry level programming language?

What are the points that make it good for teaching a programming language. Or... is it personal preference of the adviser?

答:
For a beginner programmer, lack of static types is a feature, not a bug!

When learning to program even the most obvious things can be hard to understand. Dynamic type systems are very simple and and get out of the way of the more urgent topics in an introductory course, like modularization, control flow, etc.

There are also some conceptual advantages to dynamic typing in an educational setting:

Types are associated with values, not variables. This is arguably more intuitive since it reflects the reason programs actually crash.

Error messages are much more immediate and concrete. In Python you get a lovely stack trace and a message indicating what actually went wrong. In a statically typed language you get a compiler warning saying what would go wrong.

Students working with a compiler can only work on programs they fully understand, lest they face a compilation error they cannot solve.

Runtime error checking allows you to run incomplete programs. This allows for more incremental programs where the student can first worry about making the start of the program correct and only then see what happens.

Some important concepts, like parametric polymorphism and duck typing, come for free in a dynamic language but require more complex type systems in a static language.

Finally, while you still have to handle the same complexity, you don't get all the benefits of static typing when starting to program:

Beginner programs are small and don't have many code paths (so you don't have to worry that much about type bugs in rarely accessed bits of code)

Begginer programs don't use high level interfaces and functions that much so there is also not much to gain in the "use the type system to design the program" department.


答:
For GPLv2 software they have an example of a copyright disclaimer at the bottom of the license:

You should also get your employer (if you work as a programmer) or
  your school, if any, to sign a "copyright disclaimer" for the program,
  if necessary. Here is a sample; alter the names:

Yoyodyne, Inc., hereby disclaims all copyright interest in the program
  `Gnomovision' (which makes passes at compilers) written  by James
  Hacker.

signature of Ty Coon, 1 April 1989 Ty Coon, President of Vice

Title: Where can I find a legal "permission to work on open source" document?

Body:
One of the things I really like about my current job is that we developers are encouraged to make open source contributions.

However, this encouragement has always been verbal. I've read some horror stories about developers having their open-source work legally claimed by their employer. I'd be more comfortable if we had something in writing from my employer saying that contributions are allowed and not owned by the company.

Understanding that you are not lawyers, does anyone know where to find a boilerplate document to this effect?


问:
In agile environment, how is bug tracking and iteration tracking consolidated.
This topic stemmed from my other question about management-imposed waterfall-like schedule. From the responses in the other thread, I gathered this much about what is generally advised:

Each story should be completed with no bugs.  Story is not closed until all bugs have been addressed.  No news there and I think we can all agree with this.

If at a later date QA (or worse yet a customer) finds a bug, the report goes into a bug tracking database and also becomes a story which should be prioritized just like all other work.

Does this sum up general handling of bugs in agile environment?

If yes, the part I'm curious about is how do teams handle tracking in two different systems? (unless most teams don't have different systems).

I've read a lot of advice (including Joel's blog) on software development in general and specifically on importance of a good bug tracking tool. At the same time when you read books on agile methodology, none of them seem to cover this topic because in "pure" agile, you finish iteration with no bugs. Feels like there's a hole there somewhere.

So how do real teams operate? To track iterations you'd use (whiteboard, Rally...), to track bugs you'd use something from another set of products (if you are lucky enough, you might even get stuck with HP Quality Center).  Should there be 2 separate systems? If they are separate, do teams spend time creating import/sync functionality between them? What have you done in your company? Is bug tracking software even used? Or do you just go straight to creating a story?

答:
You can almost never realistically say with 100% certainty that no bugs exist.  Even if every test case was meticulously thought out, tested for, verified, there will probably be that one situation that somebody didn't think of.  Customer identified bugs happen, they aren't the end of the world, but when they do happen I make sure to create them in a user story and give them the highest priority.

I use Rally and love it.  Typically throughout the sprint, testing of features is done as they are completed by QA resources.  When QA finds bugs they usually write them up as Defects in Rally and then the developers attempt to resolve all the defects before the end of the sprint.

Ideally all Defects should be resolved, however for small or trivial Defects it may not be necessary to hold the sprint back by not Accepting the User Story.  QA should make the judgement call.  Do they accept the User Story with the open Defects or not?

Once the sprint is accepted any remaining Defects can be elevated to User Stories for the next sprint.

Another fallacy of your line of thinking I noticed is that you delineated QA as a seperate entity outside the development team.  This is an inherently Waterfall mindset as you just assume that a large Testing phase must occur before release.  This shouldn't be so.  Testing should be occurring alongside the development team DURING the sprint and they should work closely with the developers preparing their test cases and interpreting their test results.

If Agile is done right, the sprint will be fully accepted by the end of the sprint meaning that it is ready for production release (It doesn't necessarily mean that every sprint should be a release, just that it should be production ready if the need arised for it).


问:
Why are .NET ports called Iron*?
The C program Prog when ported to Java would be called JProg, a port to C++ would be Prog++ and a port to Python would be called PyProg. These names are all quite obvious. But the C# port would be called IronProg, which strikes me as strange.

Why is it that programs ported to Visual Basic or C# are often called Iron*?

Examples: IronPython, IronScheme, IronRuby, etc.

答:
Are they? I've mostly seen stuff with 'N' at the beginning, e.g., "NHibernate", "nUnit", "NAnt", "Noda Time", etc.

There's an "IronLanguages" project that does IronPython, IronRuby, etc., but it seems mostly to be concentrating on porting programming languages to the CLR.

Here's a blog post explaining the name. It quotes the creator of the IronPython project:

I'll give you the story, but I'll give you the short version 'cause it's not very good.

At the time, I had a consulting company called "Want of a Nail Software". "Want of a Nail" is based on a children's poem. It's about the importance of small things. I've always kind of believed in the importance of small things. Part of the story of IronPython's actual performance is it wasn't one big thing - Everybody wants to know "What was the one big thing?" There were some big things, but most of it was all the small things - paying attention to performance in every place.

So, that was the consulting company and "Iron" seemed to match.

There were some obvious names: Python.Net, Python#, nPython - All of those were taken. All of the URLs for those were registered.

I didn't want to reuse any of those names, so "Iron" was just kind of a name that appealed to me at a visceral level - I like the feeling of "IronPython".

There's a little bit of "Iron Chef" in it, although I'm always reluctant to admit that.

Title: Why are .NET ports called Iron*?

ContentLicense: CC BY-SA 4.0


答:
What you are discussing in your question are actually 3 different concepts:

Continuous Integration at it's core is making small changes and frequently synchronizing those changes with the "global truth". Instead of making a checkout and holding onto it for a week, a developer should work on tasks that can be completed within a day so that his code is never too far out of sync with the main repository.

In order to achieve this without causing his team pain (i.e. checking in source that doesn't build or breaks existing functionality). The developer has to verify that his code doesn't "break the build". If done manually, this adds additional overhead to the process of development (think of a project that takes a long time to build and/or has many inter-dependencies where a change to one line of code can impact the application in unexpected ways).

To mitigated this situation, we use other techniques to remove this overhead.

We use automated builds to checkout the source and build it optionally running automated tests that verify the application works as it should (this step is only as useful as the test suite).

A further step continuous delivery addresses your issue with database and other concerns. The idea here is to provide some level of versioning for the database and other factors of the environment so that we can confirm as quickly as possible that the application works in an environment as close to production as possible.

Title: What does "automated build" mean?


答:
In my opinion, learning to judge Q&D code for correctness is not a skill worth developing because it's just bad practice. Here's why:

I don't think "quick and dirty" and "best-practice" go together at all. Many coders (myself included) have cranked out quick and dirty code as a result of a skew in the triple constraints. When I've had to do it, it was usually a result of scope creep combined with a ever-approaching deadline. I knew the code I was checking in sucked, but it spit out proper outputs given a set of inputs. Very importantly to our stakeholders, we shipped on time.

A look at the original CHAOS Report makes it pretty clear that Q&D is not a good idea and will kill the budget later (either in maintenance or during expansion). Learning how to judge if Q&D code is right is a waste of time. As Peter Drucker said, "There is nothing so useless as doing efficiently that which should not be done at all."


答:
IMHO, teaching people to code in "safe" languages is a very bad idea. People assume everything is easy, and only think about adding layers and layers of code. And loosing any chance of being able to debug/fix problems when they arise.

Good programmers absolutely must know C/C++ or even assembly. And their mindset has to come from that side as well. And not - "Oh, GC, it does Magic(tm) we are cool, and why C++ doesn't have GC, it's stupid." attitude.

Body:
I've read here on P.SE more questions in which beginner programmers are advised to pick Python as their first programming language.

Don't get me wrong, I like Python. I like it a lot! But its philosophy revolves around "We are all consenting adults here".

From an experience/knowledge point of view, a beginner programmer is not an adult. Which then kinda means it is easier to shoot yourself in the foot and pick up some bad habits even if you survive the wound.

I'm thinking that in a "more static" language it would be harder to shoot yourself in the foot as it will be more restrictive.

Back to my question. Why is Python recommended as an entry level programming language?

What are the points that make it good for teaching a programming language. Or... is it personal preference of the adviser?


问:
How do you code without offending?
What I mean by that is, how do you go about developing on a code base you share with developers who have been working on it for years and are very familiar with it?

I don't want to step on anyones toes, but I get not so subtle complaints about the way I do things, whether it be how I whitespace my code, or how frequently I checkin to SVN (too often). So while I can change those things easily -- I want to be a better team developer in general.

I'm not sure what to do, other than ask, but maybe you guys have some thoughts I could put to practice.

UPDATE

There isn't any style guide to speak of -- it's just people aren't used to sharing the codebase. Everyone has their own little siloed code-world.

This is a perl shop, but I'm sure these apply to any language

UPDATE 2

The CTO who later became CEO was a complete megalomaniac and was the primary source of these complaints. If you didn't do things exactly how he liked, whether it was using a Mac, or Emacs, or 4 tab spaces instead of 2, or dress a certain way, you were inferior. It was a horrific situation that I tried to correct, but the only correct answer for me was leaving.

I am convinced that this was an instance of bullying in a workplace, and subsequently, I'm more aware of what might be subtle bullying and inappropriate behavior in a work environment.

To any developer looking for answers to a situation like this, leave immediately. You can't teamwork your way out of a bad team situation.

答:
As far as code formatting style (whitespace, tabs, where braces go, etc.) you should follow the prevailing standard in the code. If there isn't one, I don't think they have much to complain about. When it comes down to it, whether you put braces on their own line or not, put spaces around method parameter lists, etc. is personal preference, and you should yield to the prevailing style because in the long run, it really doesn't matter. What matters is being consistent.

When it comes to checking code into SVN, I would try evangelize what I feel is the right way to do things, rather than letting myself be steamrolled. I don't check my code in unless it builds and passes tests, and if I'm making several unrelated changes, I break my work up into several commits. If something will be broken for a while, I create a branch and do my work there. Commits get descriptive comments. This works better in my experience than the "check in a pile of changes on Friday at 5:00" method, and it seems to be the prevailing "best practice" according to most of what I've read here and elsewhere.

Title: How do you code without offending?


答: An easy one is to find the style guide and follow it. Most don't have anything too offensive in them, and will prevent you from offending others.</p>

Title: How do you code without offending?

Body:
What I mean by that is, how do you go about developing on a code base you share with developers who have been working on it for years and are very familiar with it?

I don't want to step on anyones toes, but I get not so subtle complaints about the way I do things, whether it be how I whitespace my code, or how frequently I checkin to SVN (too often). So while I can change those things easily -- I want to be a better team developer in general.

I'm not sure what to do, other than ask, but maybe you guys have some thoughts I could put to practice.

UPDATE

There isn't any style guide to speak of -- it's just people aren't used to sharing the codebase. Everyone has their own little siloed code-world.

This is a perl shop, but I'm sure these apply to any language

UPDATE 2

The CTO who later became CEO was a complete megalomaniac and was the primary source of these complaints. If you didn't do things exactly how he liked, whether it was using a Mac, or Emacs, or 4 tab spaces instead of 2, or dress a certain way, you were inferior. It was a horrific situation that I tried to correct, but the only correct answer for me was leaving.

I am convinced that this was an instance of bullying in a workplace, and subsequently, I'm more aware of what might be subtle bullying and inappropriate behavior in a work environment.

To any developer looking for answers to a situation like this, leave immediately. You can't teamwork your way out of a bad team situation.


答:
Ask. That is, ask the folks you work with. Do your best to stick to the established style of the existing code. Ask especially if there's a document list of coding standards, and follow it. If there isn't one, write up a first draft based on what you observe in the code and then ask the other team members to critique it. You'll do the company (and new developers who come after you) a service by starting to document the accepted coding practices. The only risk is possibly getting caught in the middle if it turns out that the old-timers don't agree with each other on what is or isn't acceptable.

Also, don't be afraid to be yourself. You might be the new guy, but you're a member of the team, and your opinions are valid. If you can think of better ways to do something, suggest it. Respect the other team members and the established way of doing things, but don't let them push you around. The company wouldn't have hired you if it didn't value your input.

It'll help a lot if you can find someone on the team that seems friendly and particularly willing to answer questions. (If it's a good team, that should be everyone, but teams aren't always like that.) Your boss may have assigned someone to help get you started. Use that person as a resource. Write down questions as they occur to you, and then ask that helpful person to answer them from time to time.

As for checking in code "too often," why not create your own branch for your periodic commits, and then merge back to trunk when your code is ready? There's no harm to anyone else in doing that, and when your coworkers see you getting benefits from SVN that they'd like, they might follow your lead.

Title: How do you code without offending?


答:
Ask for the company code standards.  Pay more attention to detail.  If you see others follow a very specific form of white space and brace patterns, then follow them.  As a Sr. you could argue this to be nit-picky, but as a Jr. or new guy on a project you need to show that you can follow before you can lead.

Also, understand that any new developers on a project will indeed have a necessary "ramp up" time.  So don't worry yourself over that.

Title: How do you code without offending?


答:
Regarding whitespace: Just do it however the code already does it. Go with the flow.

Regarding SVN checkins: Document them very clearly. That helps people understand what's going on in the code. (Followup: What are their objections to the frequent checkins?)

In general: Start building up a coding standard document. Don't try to fill it with 100 rules. Just add rules as they come up.

Also: Ask questions of your fellow developers. That gives them an opportunity to weigh in before you do something they won't like. Plus, it builds relationships. Plus, you learn more about how the shop works.

Title: How do you code without offending?


答: If dirty code is well tested, it can be trusted. The problem is, that unit testing dirty code is usually very hard and cumbersome. This is why TDD is so good; it reveals and removes dirt and smells.  Also, unit testing is often the first thing to suffer from time preasure. So if the cleanest guy ever made the cleanest code he'd ever done, I would still not trust it one bit, if he omitted the unit tests due to time preassure. </p>


答:
First read their coding conventions document (if they don't have one then ask them to write one so you can follow it)

Then take notice and make a conscious effort to follow that and what they say. It may seem to you that they are being harsh but coding standards are important, its better to point out now whats wrong rather than let it develop into a problem later when you are making larger changes.

I'm sure you will be doing the same in a year or twos time when some newbie is stepping on your toes :)

Title: How do you code without offending?


问:
Single or multiple files for unit testing a single class?
In researching unit testing best practices to help put together guidelines for my organization, I've run into the question of whether it is better or useful to separate test fixtures (test classes) or to keep all tests for a single class in one file.

Fwiw, I am referring to "unit tests" in the pure sense that they are white-box tests targeting a single class, one assertion per test, all dependencies mocked, etc.

An example scenario is a class (call it Document) that has two methods: CheckIn and CheckOut.  Each method implements various rules, etc. that control their behavior.  Following the one-assertion-per-test rule, I will have multiple tests for each method.  I can either place all of the tests in a single DocumentTests class with names like CheckInShouldThrowExceptionWhenUserIsUnauthorized and CheckOutShouldThrowExceptionWhenUserIsUnauthorized.

Or, I could have two separate test classes: CheckInShould and CheckOutShould. In this case, my test names would be shortened but they'd be organized so all tests for a specific behavior (method) are together.

I'm sure there are pro's and con's to either approach and am wondering if anyone has gone the route with multiple files and, if so, why?  Or, if you've opted for the single file approach, why do you feel it is better?

答:
One of my arguments against separating the tests into multiple classes is that it becomes harder for other developers on the team (especially those who aren't as test savvy) to locate the existing tests (Gee I wonder if there is already a test for this method? I wonder where it would be?) and also where to put new tests (I'm going to write a test for this method in this class, but not quite sure if I should put them in a new file, or an existing one?)

In the case where different tests require drastically different setups, I have seen some practitioners of TDD put the "fixture" or the "setup" in different classes/files, but not the tests themselves.


问:
How assertive should I be in handling exceptions in objects?
I have been writing in C# 4.0 a lot lately and trying to write as lean as possible. As such, I have not been using the classic try/catch blocks and using statements as often.

I understand the general function of .Net's garbage collection and exception handling - I want to bulletproof my code and be efficient with objects, but I am trying to achieve this with the minimum amount of 'extra code' (since 'bloat' pissed people off).

And to be clear, I understand using() is fundamental for relinquishing resources to handles and other code and its relationship to the IDisposable interface.

But I am trying to get a better grip about how assertive a programmer should be in exception handling objects.

Are there key places in code you'd say try/catch blocks and/or using statements are inarguably necessary? Within the contexts of garbage collection and exception handling, what common-use objects/scenarios would you recommend explicit attention?

Should you simply make a catch block for every possible exception an object might through? How deep should they be nested? Are there steps I can take to proactively collect garbage (for example, to combat the example in comments of waiting for Dispose() to be called)?

答:
try/finally and using are almost totally orthogonal concerns to memory leaks.  You should use using or try/finally when you have non-memory resources, like a lock, a handle, or a connection, and you need to make sure those are cleaned up.

There are very few or no common cases in .NET where you need to pay explicit attention to avoiding memory leaks.  The only way you'll wind up with a memory leak if if you're retaining a reference to something old and you don't realize it; there are a few ways this can happen, like if that thing has an event you didn't unsubscribe from.  But there's nothing mysterious.

OwnerDisplayName: mquander


答:
using is not a "bloat", it's necessary to free resources wrapped into IDisposable objects. using is compiled into try...finally, with a call to the Dispose method in the finally section. For example, when StreamReader and StreamWriter are used to read and write files, respectively - their Dispose method automatically closes the file. Another example is SqlConnection - its Dispose method must be called to close the connection, and a using statement is a clean way to do it.

Regarding try...catch, their use in .NET does not differ from exception handling in C++ or Java. Exception handling decreases performance a bit, but that whether this is significant can only be determined by profiling the code. Exception handling must not be used for changing control flow, and it"s also not wise to use it to swallow exceptions. These and other important properties of exception handling can be found in OOP/C++/Java/... textbooks.

Title: How assertive should I be in handling exceptions in objects?

Body:
I have been writing in C# 4.0 a lot lately and trying to write as lean as possible. As such, I have not been using the classic try/catch blocks and using statements as often.

I understand the general function of .Net's garbage collection and exception handling - I want to bulletproof my code and be efficient with objects, but I am trying to achieve this with the minimum amount of 'extra code' (since 'bloat' pissed people off).

And to be clear, I understand using() is fundamental for relinquishing resources to handles and other code and its relationship to the IDisposable interface.

But I am trying to get a better grip about how assertive a programmer should be in exception handling objects.

Are there key places in code you'd say try/catch blocks and/or using statements are inarguably necessary? Within the contexts of garbage collection and exception handling, what common-use objects/scenarios would you recommend explicit attention?

Should you simply make a catch block for every possible exception an object might through? How deep should they be nested? Are there steps I can take to proactively collect garbage (for example, to combat the example in comments of waiting for Dispose() to be called)?

OwnerDisplayName: kol


答:
using is only allowed by the language for situations where you should almost certainly be doing it - that is, classes which implement IDisposable. You're free to write code that implements IDisposable needlessly if you really want to, but almost all libraries will only do it for a reason - because the object needs to be cleaned up. You can write the dispose logic yourself if you want to, but there is really no benefit because using does exactly the same thing, it's just clearer.

Your definition of 'bloat' is an interesting one. While I understand that boring plumbing code is undesirable, that just makes it a candidate for walling up in a base class, not excluding it altogether. If boring code is proliferating, it can be an indication that you are violating DRY and should aim to refactor so that you specify the behaviour only once for everything that needs it.

OwnerDisplayName: Tom W


答:
Nested levels of try catch must be avoided if all they do is nothing but log the exceptions. If object supports IDisposable then it must be wrapped in using block.

Exceptions must be caught mostly on root entry points, instead catching and rethrowing at various levels. It just makes code little more complex to analyze stack traces.

Try-finally must be used only if resource object does not support IDisposable, or to turn some Boolean switches or to synchronize threads.

Don't ever use exceptions as part of logic, for example if I catch exception a then follow method b else follow method c, something like that. Other example include using exception in place of return type. Imagin you have ValidateUserPass method that returns void and throws exception instead of returning proper result. I know it is argueous but invalid logic is a user error and exception should mostly be used for system or network failure.

Do not throw generic exception Exception, but use proper encapsulated class for it.

At root level, catch all exceptions because it must be logged, and at intermediate level, do not catch exception unless you want to continue the logic in alternate way.

For example,

```<code> try{
     connectToDevice()
     return;
 }catch(IOException ex){

 }
 connectToDatabase();
</code>```

Here if I will catch all exception then I will eat up or catch wrong exception if I will put all in try block. Here in case my device connection fails I want to connect to database and work in offline mode. This is part of the logic only if device fails to connect.

But if user has entered a null as an address string, that should not be caught here because it is not an error to connecting device. My null pointer exception should be caught at root level, and not in this code.

For logging, catch all exceptions.

For alternative branch of execution, catch only one type of exception.

Body:
Nested levels of try catch must be avoided if all they do is nothing but log the exceptions. If object supports IDisposable then it must be wrapped in using block.

Exceptions must be caught mostly on root entry points, instead catching and rethrowing at various levels. It just makes code little more complex to analyze stack traces.

Try-finally must be used only if resource object does not support IDisposable, or to turn some Boolean switches or to synchronize threads.

Don't ever use exceptions as part of logic, for example if I catch exception a then follow method b else follow method c, something like that. Other example include using exception in place of return type. Imagin you have ValidateUserPass method that returns void and throws exception instead of returning proper result. I know it is argueous but invalid logic is a user error and exception should mostly be used for system or network failure.

Do not throw generic exception Exception, but use proper encapsulated class for it.

At root level, catch all exceptions because it must be logged, and at intermediate level, do not catch exception unless you want to continue the logic in alternate way.

For example,

 try{
     connectToDevice()
     return;
 }catch(IOException ex){

 }
 connectToDatabase();

Here if I will catch all exception then I will eat up or catch wrong exception if I will put all in try block. Here in case my device connection fails I want to connect to database and work in offline mode. This is part of the logic only if device fails to connect.

But if user has entered a null as an address string, that should not be caught here because it is not an error to connecting device. My null pointer exception should be caught at root level, and not in this code.

For logging, catch all exceptions.

For alternative branch of execution, catch only one type of exception.


答: Where I work, we use TFS for source control and work item tracking. Both the stories and the bugs are work items in TFS, as are the tasks necessary to complete either. The code, when checked in, is associated with the work items, and the builds are associated with both the check-in and the work items, so it's clear which builds are meant to fix which bugs.</p>

Title: In agile environment, how is bug tracking and iteration tracking consolidated.

Body:
This topic stemmed from my other question about management-imposed waterfall-like schedule. From the responses in the other thread, I gathered this much about what is generally advised:

Each story should be completed with no bugs.  Story is not closed until all bugs have been addressed.  No news there and I think we can all agree with this.

If at a later date QA (or worse yet a customer) finds a bug, the report goes into a bug tracking database and also becomes a story which should be prioritized just like all other work.

Does this sum up general handling of bugs in agile environment?

If yes, the part I'm curious about is how do teams handle tracking in two different systems? (unless most teams don't have different systems).

I've read a lot of advice (including Joel's blog) on software development in general and specifically on importance of a good bug tracking tool. At the same time when you read books on agile methodology, none of them seem to cover this topic because in "pure" agile, you finish iteration with no bugs. Feels like there's a hole there somewhere.

So how do real teams operate? To track iterations you'd use (whiteboard, Rally...), to track bugs you'd use something from another set of products (if you are lucky enough, you might even get stuck with HP Quality Center).  Should there be 2 separate systems? If they are separate, do teams spend time creating import/sync functionality between them? What have you done in your company? Is bug tracking software even used? Or do you just go straight to creating a story?


问:
Do you find references invisible when you scan code, and are there any coding guidelines for their usage?
I have developed a habit of using safe C++ constructs where possible, but there is one place where I'm always not sure if it's better to use references or resort to good ol' pointers.

Example code:

```<code>int FillFancyPointer(char *&ptr)
{
    ptr = NULL;

    char *tmp_ptr = static_cast<char*>(calloc(...));
    if(!ptr)
        return -1;

   ptr = tmp_ptr;
   return 0;
}
</code>```

Later in code:

```<code>char *ptr = nullptr;
if(FillFancyPointer(ptr)>=0 && ptr)
   Nice();
</code>```

The problem with this, IMHO, is that the ptr appears to be read only variable when looking at the code, while in reality it is modified.

The COM approach ISmthn *ptr;, CoCreate(..., &ptr) seems more pronounced. But it's also more error prone, as there is this ** stuff everywhere.

Come to think of it, output variables like std::string will also be masked with such approach.

int Foo(const string &in, string &inout)

Do you find references confusing in such places?

答:
If you’re concerned about mutability, make references const unless they need to be mutable, and leave it at that. A function’s name and documentation should convey its purpose and whether it intends to modify one of its parameters.

Users of the function shouldn’t need to care whether something is passed by value or reference; the “invisibility” of references—that they have the same syntax as values—is one of their strengths. The reason for introducing references to C++ in the first place was to “invisibly” support operator overloading. In addition to their consistency, they are also amenable to generic programming, which is a big thing in the C++ world. And in C++0x, it gets more interesting: you can pass variables syntactically by value, but they can be move-constructed, eliminating the need for a copy.


答:
The product ships.

Code doesn't exist in a vacuum. I have suffered untold grief firefighting the consequences of quick and dirty and cowboy coding. But sometimes finishing the product is the priority, not figuring out how to write the best code. Ultimately, if the product ships and works well enough, the users and customers won't know or care how "bad" the code inside is, and I will admit there have been times when I didn't care at all about "getting it right" as long as I got it out the door.

Yes, this in an organizational issue and "should never happen." But if you happen to be writing code in an organization that is poorly managed and heavily deadline-driven, at the individual programmer level one's options are limited.


答:
To address the part of your question about what exceptions you should catch, have a look at this article:

How to Design Exception Hierarchies

Despite the title, it's very useful in understanding the different types of exceptions.  There are three types, and they should be handled in three different ways:

Usage error.  This is due to an error in coding - fix your code.

Logical error.  An unavoidable condition, such as file not found - handle the exception.

System failure.  A system error such as out of memory - shut down the program.

(File not found is unavoidable because even if you call File.Exists(), it's possible someone could delete the file just before you access it.  So to really be correct, you still need to handle it.)

The only case where you definitely need try/catch blocks is for logical errors.  In those cases, you can't guarantee avoiding the exception, so you need to handle it.


问:
Why aren't there automated translators from one programming language to another?
Most programming languages are Turing complete, which means that any task that can be solved in one language can be solved in another one, or even on Turing machine. Then why aren't there automatic translators that can convert programs from any given language to any other language? I've seen couple attempts for two languages, but they always work only on a limited subset of a language and can hardly be used for converting real projects.

Is it possible, at least in theory, to write 100% correct translator between all languages? What are the challenges in practice? Are there any existing translators that work?

答:
Is it possible, at least in theory, to write 100% correct translator between all languages? What are the challenges in practice?

Translating from a more-structured language to a less-structured language that is still Turing-complete, is always possible.

This claim should be viewed in a strictly technical sense: It means that the translated program will produce exactly the same result when it is executed.

Nothing is implied about the readability of translated code, or the preservation of the original program structures.

Translating from a less-structured language to a more-structured language is possible, but the translated code will remain in its less-structured form.


答:
"Automated build" means that you can go from source control to a shippable package with one (schedulable) action (typically a shell script or batch file).

What exactly constitutes a build, in this context, depends a lot on what exactly it is you're shipping, how it gets delivered, and which steps are required for the various parts of your development stack, but in any case, you start with what's in source control, and you end up with a shippable product (or an error message and an angry project manager).

For a simple Python project, an automated build might consist of only two steps - checking out the sources, and copying relevant files to the correct directories. For more complex projects, it might involve things like:

compiling, linking

running automated tests

creating installer packages

installing

modifying database(s)

creating backups (in case you need to roll back)

Title: What does "automated build" mean?


问:
Does JavaFX have a future?
I have not intended to hash and rehash the same matter, but just to decide, what to learn first (JavaFX, Flex, HTML5, etc.) I would pull through a kind of survey, especially as the recent similar questions here came out since at least one year.

So, what is JavaFX prospect as a RIA technology for the next couple of years?

答:
I would learn HTML5 because it is the standard way of doing things. Lets say you have 100 hours to spend learning any of the technologies you mention in your question. If you spend 100 hours learning JavaFX and 2 years from now JavaFX is dead then your knowledge of JavaFX is useless. If you spend 100 hours learning HTML5 then 2 years from now when HTML5 is even more available than it is today your 100 hour effort is still relevant. </p>

<p>Learn HTML5 and if you can't do something you need in it then look at alternatives. </p>

OwnerDisplayName: Albert Galiev

Title: Does JavaFX have a future?

Body:
I would learn HTML5 because it is the standard way of doing things. Lets say you have 100 hours to spend learning any of the technologies you mention in your question. If you spend 100 hours learning JavaFX and 2 years from now JavaFX is dead then your knowledge of JavaFX is useless. If you spend 100 hours learning HTML5 then 2 years from now when HTML5 is even more available than it is today your 100 hour effort is still relevant.

Learn HTML5 and if you can't do something you need in it then look at alternatives.

OwnerDisplayName: ams


问:
As a young developer, should I be worried about having to use "out-of-style" tech at work?
I'm a recent college graduate (last May!). While I was still in school, I wanted to make sure that I had a job before I graduated, and very early (probably too early) in my job search I settled on one in a region I'd been hoping to move to after undergrad.

However, I've been second guessing this decision for months now, for several reasons. One is that I'm not very challenged at work, and I feel like I haven't improved much at programming since starting here. I can always make time to work on open source (and have in the past) outside of my job, though, so I do have a venue to get around this disappointment. More importantly, I'm worried by the fact that my job is basically to work on a creaky old Perl web application (using Mason and a weird in-house ORM).

Am I shooting myself in the foot here by working with a technology that's no longer popular, and won't really help me out getting a job in the future? I rarely see Perl jobs, and when I do, it's usually doing something I'm not interested in (front-end web development stuff).

Systems programming, visualisation, network programming, or at least backend web development stuff are the sort of topics that I'd actually enjoy working in -- it doesn't seem like my current work experience is helping me towards positions doing any of these things.

答:
If I were you I would certainly consider doing some after-work reading and programming in another language (e.g. Python, Java, Scala, Ruby, C++, and so) so when you apply for another job you can show that you have knowledge about languages that are in wider use than Perl. Also, if you have other interest areas, I would definitely do some extra reading.

On the other hand be aware that many programming techniques you are using are probably the same regardless of the programming language.

So, again, my suggestion would be: don't worry too much but start learning something new in your spare time. As soon as you have gathered enough knowledge you will surely find a more exciting job.


答:
There is still plenty of demand for people good with perl.  You will find that the networking industry, and many *nix based sysadmin jobs use perl extensively.  </p>

<p>That being said, I echo others that suggest pushing your own boundaries.  Even if you are just working with perl, find ways to optimize and streamline the programs.  For example if you see a linear approach taken with a program (often the sign of an inexperienced programmer), can you find a way to modularize the code to improve maintainability?  The basic ability to read a bit of code, regardless of language, and optimize and transform it into better code is a highly sought after skill.  </p>

Title: As a young developer, should I be worried about having to use "out-of-style" tech at work?

Body:
I'm a recent college graduate (last May!). While I was still in school, I wanted to make sure that I had a job before I graduated, and very early (probably too early) in my job search I settled on one in a region I'd been hoping to move to after undergrad.

However, I've been second guessing this decision for months now, for several reasons. One is that I'm not very challenged at work, and I feel like I haven't improved much at programming since starting here. I can always make time to work on open source (and have in the past) outside of my job, though, so I do have a venue to get around this disappointment. More importantly, I'm worried by the fact that my job is basically to work on a creaky old Perl web application (using Mason and a weird in-house ORM).

Am I shooting myself in the foot here by working with a technology that's no longer popular, and won't really help me out getting a job in the future? I rarely see Perl jobs, and when I do, it's usually doing something I'm not interested in (front-end web development stuff).

Systems programming, visualisation, network programming, or at least backend web development stuff are the sort of topics that I'd actually enjoy working in -- it doesn't seem like my current work experience is helping me towards positions doing any of these things.

Body:
There is still plenty of demand for people good with perl.  You will find that the networking industry, and many *nix based sysadmin jobs use perl extensively.

That being said, I echo others that suggest pushing your own boundaries.  Even if you are just working with perl, find ways to optimize and streamline the programs.  For example if you see a linear approach taken with a program (often the sign of an inexperienced programmer), can you find a way to modularize the code to improve maintainability?  The basic ability to read a bit of code, regardless of language, and optimize and transform it into better code is a highly sought after skill.


答:
Code a bit outside of work, but I don't feel you're hurting yourself just yet.  You're a recent hire so you're an entry level developer - at this stage of the game you should be learning things like Development Cycle and how things "Should" be done.

Pursue some things outside of work so you can pad your stats.  In my opinion, you can either code or you can't.  Language and syntax can be learned - but the ability to think and solve problems on your own can't.


答:
First of all, stop thinking that your job is not bringing your further towards your dream job! Every job does! Everything is only up to you!

This is your first job after your graduation and everyone can understand that you didn't have a good choice or might have considered some other factors, like moving to the place where you'd like to stay. This is a valid "excuse", you can mention it if directly asked during a job interview.

Every programming job contributes to your experience as a developer. There are many language agnostic things every developer has to learn on his own (implementing loosely coupled architectures, debugging and profiling the code, writing unit tests etc...) that can be learnt in ANY language, and Perl is not the worst one to use. I used to practice all three in VBA developing for MS Access and that was much fun.

This is not productive, after all: as long as you consider your current job being boring and useless you won't learn much from it. In many cases your future employer would be interested your "learning curve" -- how quick you are at mastering new technologies, not at how boring you last job was!

So, the ways that help you out are the following:

Try to master the language you are currently working with as deeply as you can. Watch the perl tag on SO site and try to answer the question people ask there. Read papers on many developer resources etc. Try to become a guru in this area!

Perl is a multi-paradigm language, now supporting OOP and many other paradigms. Try to split those from the language and look at them individually. What type of inheritance does Perl have? What are different types of access modifiers are available here for classes and class members etc? Is it strongly typed or not? Many language function a similar way, as long as you know how it works in general you'll easily capture the difference in other languages.

Acquire a deep understanding of your current system: why is it implemented in Perl? How are different aspects, like performance, security, reliability solved here? What are unsolved problems, caveats, potential breaches? How would you cope with them? Maybe there there are some reasonable refactoring of the current code base is needed?

And don't stay on this job for long if you are dissatisfied with it -- just enough to learn basic skills, to show your willingness to learn and your will-power to overcome the dullness of your tasks!

When you apply for your second job in more or less near future you still can be treated as a junior developer! You should try to emphasize what you have learned on your first job, how you coped with your problems of maintaining legacy code and brownfield system, how you managed to extend your horizons and what new cool features you have learned there.

Never, never tell during the job interview that you are bored with your current job and that is the reason why you're looking for something else. "Boring" is so subjective and often means that you are just not good enough to stand the challenge of learning the things in your current position and applying them accordingly. Show your willingness to learn, to expand your knowledge and you'll get your dream job, I am sure.