问:
How best to prevent having to revisit a change after check in
Normally what happens is that I work on something for a while and then when I am done I check it in(After the test/review process of course).  Sometimes I have to go back and fix something that I got wrong the first time due to me not understanding the problem enough, lack of testing, etc..

What is an acceptable rate for this?  Ideally you would hope that you never have to go back but sometimes you do.  What rate does the average programmer have and what is the expert programmers rate?  Do people track this?  Lastly what kind of checks are best at preventing this?

PS: I am not counting the cases where the requirements have changed and you have to go back in.

I know that there is no real answer to this so let me change the actual question to: "What general checks could be implemented, before code is sent for review or checked in, that would help prevent the need to revisit the change later?"

答:
What I do is to create packages and classes diagrams representing the static structure of my application. Not too much just the structure and I got the code in synchronization with the diagram. My diagrams are not just views of the real world but they are the real world !!

Once I finished this first draft modeling stage I then code, test and deploy. In real project I always need to go back to my code. I can then either change at code level or at graphical level using UML class diagrams. The graphical view is really faster and it is just done by drawing or refactoring my current diagrams. I then again code, test and deploy. And again and again.
This iteration approach is really fast and very efficient because not only the structure is creating at objet level using the class diagram but also the database using database stereotypes and then hibernate.

This works really well because I don't use Model Driven Development with a code generator but only direct mapping and synchronization between UML model, code and databases. There is also no mix between my code and model like with EMF. Code and model are syncrhonized on demand and keep separately. I like UML class diagrams, multiple iterations and hate Model Driven Development code generator because if the code is generated then you can not change it manually at test and deployment level !!


问:
Is "Computer Science != Software Engineering" an excuse to teach programming poorly?
We've all heard it; whenever there's a discussion about CS grads having poor development skills someone eventually says,

Computer science isn't software engineering.

The problem that I see is that programming and software development are taught in CS courses. They're just commonly taught poorly. If it's being taught, then why not teach it right the first time? *

So I would like to see what the opinions are on 2 questions:

Is the CS != SE argument a copout or excuse for not properly teaching programming skills.

Regardless of your answer to question 1; if you were in the almighty position of making such a decision: would you force an emphasis on proper teaching of programming in CS courses?

*. I have a suspicion, based on anecdotal evidence I obtained throughout my education, that most academics in the field haven't had to write code to be maintained and haven't maintained code, and as a result don't have the knowledge/skills to teach it effectively.

答:
Those that can, do; those that cannot, teach.

At my university, the knowledge base of the teachers is woefully deficient. I have seen teachers struggle to understand how to represent semi-structured tables in XML while holding a PHD in Database Design. I've seen my Assembly teacher ask me what my code is doing when it's his code snippet I copied and pasted. I've seen my software design teacher tell us the Agile method is the same as the waterfall method, only faster, that iterative development process model has and can only have 3 iterations because that's what the picture the book uses as example depicts. One of my teachers did not even know what an elseif statement was.

I don't believe they are 'coping out', or making excuses, I truly believe they are doing the best they can with their experiences, which they have precious few.

I agree with the other people posting here that 4 years is not enough to become a seasoned programmer, but the experience my teachers have had is not enough to make them seasoned either. It's much like in Ender's Shadow, where Bean notices the metrics used by the teachers in battle school fall short because the last war which is the guide rule, was too short to truly show what is actually needed. In otherwords, the teachers were doing the best they could, but failed to have the experience to know what is really needed to make a good commander (or good programmer in this case).

ContentLicense: CC BY-SA 2.5


问:
How do programmers in the West see programmers in the East?
The other half of this question: How do Programmers in the East see programmers in the West?

The eastern part of the world (India/China/Philippines ) mainly provide outsourcing services to the western world (USA and Europe).

Do you have the experience of working with offshore teams? If yes, how was it?

Do you hold any generalized ideas or opinions about the programmers from the East (e.g. Are they cooperative, do they deliver on time or do they do quality work?).  What are these based on?

答:
I'm pretty sure the percentage of good developpers is the same in eastern part of the world than everywhere else. This implies that there are a few good developpers in eastern part of the world, like everywhere else.

The problem comes from the fact that "selling software" is the easiest way to make money, so a lot of people pretend they know how to develop because they have written 3 lines of Php code, and try to sell sofware (= outsourcing).

So, it's juste simple maths: there are a lot of so-called software companies, but there are a few real good developpers in eastern part of the world, like everywhere else. To understand, let use numbers, even though they're not real:

100 software companies in western part of the world. 50 of them are good.

10000 software companies in eastern part of the world. 50 of them are good.

So... the chances you get a bad software company are much higher in eastern part of the world than everywhere else. But the important fact is that there are as many good developpers in western part than in eastern part.

To add to the top of that, there's a mentality problem which makes things worse.

And to conclude to what's happening in France: there have been thousands of project that have been outsourced, with catastrophic results, and a lot of them were big projects (big projects outsourcing was like great savings). So now, real geeks and man like me, who are real developpers (real developper = not attracted by money first) have a lot of work in France, because I have do dig in everything that has been done, give "expert conclusion" and the company acts upon. I'm very well paid, so all in one, it's not such a bad thing ;)

Please don't hesitate to correct my post, to make it proper English, because my English is perfectible.

ContentLicense: CC BY-SA 3.0


问:
Agile method for a non-technical product owner + one developer
My current client has several internal products which the IT-department supports. All product owners are non-technical and each application is always developed by one developer (and so is all change requests).

The current methodology is a bit like waterfall. All uses cases are defined first by the product owner. Then the application is developed and released into a test-environment. The user tests it and says yes/no. Any changes results in a change request and a new release (including setup-packages). And it continues like that until the user is happy which results in the product going to production.

I want to introduce an agile method instead to capture changes quicker and focus on the most important features from start. Scrum seems to be overkill since there only is one developer per project. Any other suggestions?

Edit

My client isn't going use anything that isn't documented. So I'm looking for an established and documented method (if there are one which suits one developer).

答:
In a one developer environment the key things are:

```<code>Source control
Continuous build server
Task/bug tracking system
Defined sprints
Unit tests
Code coverage
Independent testing in parallel to development
</code>```

Doing this will make you agile enough without meeting the strict definition of one of documented methodologies.  If the teams grow, then look at the communication aspects of how the team works.

Body:
In a one developer environment the key things are:

Source control
Continuous build server
Task/bug tracking system
Defined sprints
Unit tests
Code coverage
Independent testing in parallel to development

Doing this will make you agile enough without meeting the strict definition of one of documented methodologies.  If the teams grow, then look at the communication aspects of how the team works.


答:
You don't have to follow full Scrum but you can definitely take advantage of its incremental iterative approach which will replace your waterfall.

How will the process change:

POs will not need to define all use cases upfront.

POs will define only use cases they are absolutely sure about at the moment and prioritize them.

Developer will follow commitment process to take multiple most important use cases to next iteration (with fixed length).

PO will be able to verify those use cases during (or worse after) the iteration.

Developer will deliver new "release" after each iteration (this can take big advantage of some automation tools).

Pros of the change:

Better visibility to development process

Better change management where problems are discovered much earlier in development phase and can be targeted immediately in the next iteration without cumulative effect (adding more functionality based on incorrectly implemented feature)

Incremental delivery where after each iteration developer should provide working product with new features

More important features will be delivered more quickly and thus will be more used when developing / testing rest of the product = there can be more feedback about their long term usability

Cons of the change:

POs will have to accept a new model and communicate with developer continuously. If POs are not willing to participate on development and provide continuous feedback and clarifications + validate use cases as soon as possible you can give up any try for change.

POs will have to change the way how they define use cases. Use cases will have to be small enough for iteration and they will have to be independent as much as possible. If developer must work on five use cases concurrently to complete them all it will not work.

The main point of the change: If you want to go for agile you must have much often feedback (small iterations with incremental delivery of working product) and you must have much more communication between developer and PO.

Title: Agile method for a non-technical product owner + one developer

Body:
My current client has several internal products which the IT-department supports. All product owners are non-technical and each application is always developed by one developer (and so is all change requests).

The current methodology is a bit like waterfall. All uses cases are defined first by the product owner. Then the application is developed and released into a test-environment. The user tests it and says yes/no. Any changes results in a change request and a new release (including setup-packages). And it continues like that until the user is happy which results in the product going to production.

I want to introduce an agile method instead to capture changes quicker and focus on the most important features from start. Scrum seems to be overkill since there only is one developer per project. Any other suggestions?

Edit

My client isn't going use anything that isn't documented. So I'm looking for an established and documented method (if there are one which suits one developer).


问:
what are callback frameworks?
I am reading Effective Java and it has the following sentence.

The disadvantages of wrapper classes are few. One caveat is that wrapper
  classes are not suited for use in callback frameworks, wherein objects pass selfreferences
  to other objects for subsequent invocations (“callbacks”).

Now what is a callback framework ? Can you point me to an example of call back framework ?

答:
many gui frameworks are callback frameworks (functions are called as events happen)

any time you have to provide handlers for events you are using a callback framework

Title: what are callback frameworks?


答:
Firstly western programmer tent to only every deal with India programmers that have written code as part of an “out sourcing” agreement.    I expect the best India programmers are writing code for India companies, or are directly employed by large western companies like Microsoft.

I think it would be far to say, whenever I have had to “fix” such code.  (From some reason the weston programmers are expected to sort out the mess a few week before the project is meant to ship.  Maybe if the code is not a mess, a weston programmer will never have to look at it.)

The India programmers did not “get” the vision of what they were meant to be doing.

They saw things like “Unit Testing” as “tick box” item and therefore just wrote enough test methods with no thought about what they were testing.

The India programmers claimed to understand what was needed and to be able to do it, regardless of the truth.

The India programmers never questioned way they were asked to implement a given requirement and therefore never questioned specs that a Western programmer would have questioned and got fixed before writing “correct code to do the wrong thing”.

They worked hard and long hours, but did not produce a solution that work, just something that maybe kept to their reading of the spec.

It is not allowed in the UK to say you can’t work with an India when you are unable to understand what is said in phone meetings etc., therefore you can’t tell anyone that the project is going wrong.  (The time zone problems in themselves are enough to get most UK programmer to recent having to work on a project with India programmers)

There is also a lot of resentment when Western programmers have to spend time “baby sitting” India programmers rather than writing code themselves, unlike trainee programmers in the UK, you know that the next month you will just have to repeat it again with a different set of India programmers.

More I think about this, I think the issues are as much about a software companies thinking they can save money by outsourcing coding to programmers that have no understanding of (or real interest in) the problem domain.  (Understanding how the West works is part of the problem domain).

(The false belief that a “sales” person can bypass the in house development department, write a spec themselves and then get some cheap India programmers to write the code, is still very common.)

I have had better experience with Eastern Europeans programmer, as they see to understand the West better, are in a better time zone.   It is also possible for someone to jump on an aircraft with a reasonable length flight (and little jet lag) for regulation face to face meetings.

Title: How do programmers in the West see programmers in the East?

Body:
The other half of this question: How do Programmers in the East see programmers in the West?

The eastern part of the world (India/China/Philippines ) mainly provide outsourcing services to the western world (USA and Europe).

Do you have the experience of working with offshore teams? If yes, how was it?

Do you hold any generalized ideas or opinions about the programmers from the East (e.g. Are they cooperative, do they deliver on time or do they do quality work?).  What are these based on?


问:
How can I track quality attributes on my team's Kanban?
My team uses a Kanban system for tracking day-to-day progress and it's worked out really well for understanding progress on features (captured as user stories).  We have largely allowed our system design to emerge as we develop features which worked out well until recently.  In the last two week we've had several discussions about architectural trade-offs specifically related to performance and modifiability quality attributes.

I think what's happening is as we implement features and design the system, we're implicitly making decisions about the architecture but not considering those decisions in terms of our known quality attribute requirements.  It would be really great if I could track/capture/visually depict how these important design decisions are being made so team members have a better chance to not create additional tension with in the system's architecture as it is being implemented.  And of course, to complicate things more, features on our board aren't exclusively functional and sometimes hide architectural complexity!

How can I track progress on quality attributes (or other architecturally relevant decisions) visually on my team's kanban?

答:
It is one of the risks of delaying architectural decisions on Agile teams. Obviously the most responsible thing for being agile is to delay architectural decisions until the last responsible moment. But chances are the last responsible moment can (or must) happen early on.

One thing that helps is to clearly delineate early on your key driving requirements; things that you clearly know you must have (but don't have to necessarily implement right now.) Your evolving architecture (which attempts to be minimalistic and flexible) should accommodate existing or future support for such requirements.

More importantly, however, your evolving architecture  MUST NOT implement artifacts that get (or can get) in the way of supporting such key driving requirements, even if those artifacts are meant for resolving current requirements. We can refer to such artifacts as interfering artifacts, artifacts that deliver a real value (as they implement a solution to existing requirements) but whose presence makes it difficult/costly to implement a future key driving requirement.

In cases when you must implement an interfering artifact, your task would be to plan for its removal at some point (so that you can implement the key driving requirement that is being interfered.)

Obviously this is all esoteric without an actual, tangible context (like a real project). But more or less your development process model and your evolving architecture must take these considerations into account.

Implicit requirements are the dead of architectures.Everything must be made explicit, both the key driving requirements and those that are ancillary. You don't need to implement a requirement early on. You only need to be able to account for it.

PS. By requirement, I mean system-level architectural requirements and not necessarily the ephemeral application-level requirements that can be accommodated without substantial changes to the architecture. Hope it helps.


问:
Is there a way to combat Sales perpetually overcommitting?
I seem to be repeatedly stuck in a situation where release dates are set not based on anything technical, but because someone in Sales has committed to a customer by then.  Based on discussions with friends in development at other companies, the same thing seems to happen.

"Here is the committed feature set and here is the committed release date", and it's difficult to argue because at this point there is money riding on it, and that trumps everything.

In general, is there a way to push back on this?  If not for this release, what about in future?  The problem I have is that the only way I see one way of doing so, and that's by doing the best I can, but release the software 'as is', so to speak.

I don't want to release bug-ridden software since it's my name attached, but doing 80 hour weeks for months at a time just vindicates the arbitrarily set release date.

edit: for the record, I'm not doing 80 hour weeks now, just that comes to mind as what would be required to cover the expected feature set by the release date.

答:
Show them this image (or this) and tell them that you are working with an impossible triangle.

```<code>  ·-----------------------·
 / \                       \
·   \   ·-------------------·
 \   \   \                 /
  \   \   \-----------·   /
   \   \   \     /   /   /
    \   \   \   /   /   /
     \   \   \ /   /   /
      \   \   /   /   /
       \   \ /   /   /
        \   ·   /   /
         \     /   /
          \   /   /
           \ /   /
            ·---·
</code>```

In any project, if you fix two corners of these three:

Time

Scope

Quality

... then the third is the only flexible one. What makes it impossible is the expectations. If they alway fix Time too short and Scope too big, then the Quality will always suffer. In an agile project, all three corners are more or less flexible.

(Disclaimer: I exclude the Cost factor from the traditional project triangle and make Quality the corner. The Time is the Cost in software projects.)

I hope you succeed in making your way to a more agile project management.

Body:
Show them this image (or this) and tell them that you are working with an impossible triangle.

  ·-----------------------·
 / \                       \
·   \   ·-------------------·
 \   \   \                 /
  \   \   \-----------·   /
   \   \   \     /   /   /
    \   \   \   /   /   /
     \   \   \ /   /   /
      \   \   /   /   /
       \   \ /   /   /
        \   ·   /   /
         \     /   /
          \   /   /
           \ /   /
            ·---·

In any project, if you fix two corners of these three:

Time

Scope

Quality

... then the third is the only flexible one. What makes it impossible is the expectations. If they alway fix Time too short and Scope too big, then the Quality will always suffer. In an agile project, all three corners are more or less flexible.

(Disclaimer: I exclude the Cost factor from the traditional project triangle and make Quality the corner. The Time is the Cost in software projects.)

I hope you succeed in making your way to a more agile project management.


答:
Most GUI frameworks, and, SAX (Streaming XML) XML parsers use callbacks.

The basic pattern is that you pass an instance of a handler class (or sometimes just a method reference) when you initialize another class.  When a specific event occurs the "handler" class is called to deal with the event.

This is typically how you get your code to run when a button on a GUI is pressed.

Title: what are callback frameworks?

Body:
I am reading Effective Java and it has the following sentence.

The disadvantages of wrapper classes are few. One caveat is that wrapper
  classes are not suited for use in callback frameworks, wherein objects pass selfreferences
  to other objects for subsequent invocations (“callbacks”).

Now what is a callback framework ? Can you point me to an example of call back framework ?


问:
Will Python developers find it easier to learn C (and vice versa)?
Since Python was written in the C programming language, does it mean that if I know C  I will learn and master Python faster than it would take me to learn it without prior knowledge of C?

Or will Python coders find it easier to learn C than programmers from other languages not related to C?

答:
Python and C arguably share many concepts, so learning one of these languages will definitely help you with the other one (they belong to the same category of imperative languages, even though they do differ significantly on some points).  Here are a few common concepts:

"Control structures": loops, tests

Function calls and return values

Variables have a type (both languages are strongly typed), and operations must respect these types

Basic variable types: integers, floats, strings, etc.

That said, Python is both simpler and much more expressive than C: programs written in Python are usually 2-10 times shorter than equivalent C code, and Python offers more useful data structures than C (namely: lists, dictionaries, sets, objects,…).

So, I would strongly recommend that you learn Python first.  C will be much easier to learn afterwards, because Python will allow you to grasp the right programming concepts much faster.


答:
The aim is to get to a stable, useable (or shippable) system as quickly as possible.

So I don’t see any real problem in having to revisit a change, provided each change is moving the system in the correct direction and it is not making it harder for anyone else to do their job.

The worse sin is to break something that the customers are already using, hence the need for automated regression tests, customers are a lot more forgiving if the new bits are not 100% the first time they see them.

Title: How best to prevent having to revisit a change after check in

Body:
Normally what happens is that I work on something for a while and then when I am done I check it in(After the test/review process of course).  Sometimes I have to go back and fix something that I got wrong the first time due to me not understanding the problem enough, lack of testing, etc..

What is an acceptable rate for this?  Ideally you would hope that you never have to go back but sometimes you do.  What rate does the average programmer have and what is the expert programmers rate?  Do people track this?  Lastly what kind of checks are best at preventing this?

PS: I am not counting the cases where the requirements have changed and you have to go back in.

I know that there is no real answer to this so let me change the actual question to: "What general checks could be implemented, before code is sent for review or checked in, that would help prevent the need to revisit the change later?"


问:
"Release Early Release Often" for Android and iPhone Apps
I wanted to know the experiences others have about doing the Agile way of "Release Early, Release Often" with iPhone and Android Apps. Its not a problem with webapps as the update happens at the server and user does not have to do anything specific for updates

It may not be a big problem with Android, as the approval process is smooth compared to iPhone app store.

Can someone share the experiences/suggestions/examples they've for releasing early and often to Android and iPhone markets?

答:
I've got experience with Android. Android supports the "release early and often" methodlogy. Ususally, your program is updated within minutes of adding a newer version of the apk.

However, one problem I found is fragmantation. Believe it or not, there are tons and tons of websites that directly scrape the Android Market and thus duplicate its contents. About 60% of the users of your app may download it from sources other than the Android Market. All these other markets scrape the Android Market with different time intervals, or may only scrape it once for each app, just to add it to their database and come up in search results. As a result, at any given time users can download a randomly selected past version of your app based on which website or market they get it from.

Because of this duplication of content going on, I haven't tried setting up multiple accounts on multiple markets and release on them simultaneously. The few times I tried, I found that I couldn't add my app because it was already added...

OwnerDisplayName: leenasn


问:
Two-way calendar sync with any client
I have a database of calendar events, that can be administered by the user through a web application.

I would like to offer to the user, functionality for viewing their calendar in any client of their choice (to the extent that open standards are implemented), primarily Outlook and Google calendar.

I would also want for the clients, such as Outlook, to be able to edit and delete events, which would then be pushed to the web application, or which the web application would pull, or simply: which would somehow be synced.

Additionally, it would be neat to be able to create a tentative event in the database, send a meeting request to the client, and have the client's accept or reject status somehow reported back to the application. But if this can't be achieved, that's no big deal.

What would be the best approach for such integration? Would my application have to have built in support for communication with every single client API, such as Exchange etc.? Or are there any open standards that I could adopt?

My initial attempts with iCal have not been rewarding so far. Perhaps I'm trying to do something that iCal cannot do. In that case, are there other techniques that can?

答: I would look at exchange for handling this -- it does most of the stuff natively and you can use exchange extensibility for the cases where it don't cover you, like entering calendar events into a web app.</p>

Title: Two-way calendar sync with any client


答:
It really depends on your development practices and where you're checking into. When committing to a development/experimental branch, it's not important at all. Get the code in. It doesn't matter if it's messy when you're working on it, just as it doesn't matter too much if a car mechanic gets dirty when working on an engine or changing the wheels.

Where it matters is when you're going to a mainline or support branch. There you should take great care to make sure that before commit that the code both:

Builds, and

Passes its test suite.

Ideally that will be a one-step check driven by your build system (if it isn't, it's too many steps!)

Once it passes those checks, which should include sufficient new tests to show that you've fixed the problem without introducing new faults, then commit. (A good method is to get the code to a good state on a working branch before merging back to mainline; a DVCS like Git makes this much easier.) Then have a Continuous Integration system rerun the build and tests from a clean check-out so that you can know you've not missed anything stupid (integration tests might be run less often, as they're more expensive but they're also important); if that shows problems, fix those immediately and don't be embarrassed about any loss of face. The aim should be to have the mainline (or supported branches, depending on project/site rules) buildable and clean at all times.


答:
Release Early

This is bit of an issue in case of Android/iOS Apps if your main channel of distribution and promotion is going to be Market/AppStore. If you release too early with some glitches (especially force-closes) you'll have some unhappy users. Just a few unhappy users can get your initial scores quite low, which will seriously hurt your chances of the app showing up high in search results.

Release Often

As you already said, not an issue with Market. With AppStore it has improved a lot, trusted apps get their updates approved withing few hours.

Title: "Release Early Release Often" for Android and iPhone Apps

Body:
I wanted to know the experiences others have about doing the Agile way of "Release Early, Release Often" with iPhone and Android Apps. Its not a problem with webapps as the update happens at the server and user does not have to do anything specific for updates

It may not be a big problem with Android, as the approval process is smooth compared to iPhone app store.

Can someone share the experiences/suggestions/examples they've for releasing early and often to Android and iPhone markets?


答:
Scrum is overkill, but Agile is more natural for small teams, even one person teams.  The point of Agile is laying out a backlog of user stories upfront that accurately describe the client's use cases.

Before the start of each sprint, priority and LOE (Level of Effort or Points) are determined for user stories, and based on what is possible in the 2-3 week sprint timeframe, user stories are added to the sprint.

At the end of the sprint, all the user stories should be developed and tested and the most important aspect of all is that all functionality from previous sprints should be unaffected and the software should not be left at the end of the sprint in a broken state.

Does it make sense to release to the client after every sprint?  No, it doesn't and this is a common misconception of Agile that I see all the time.  I encounter few clients who want a working release after every sprint.  Some may want a release every quarter for instance, and if Agile is being followed, then the last released sprint should always be in a usable state where a release can be prepared for the client on a regular interval.  Some clients may also want an environment where they can authorize, demo and evaluate the latest sprint so that they can keep up to date on the real time progress of the project.

What about the challenges of providing software in a usable state within the first few sprints of a fresh new project?  The first few sprints of a new project can be a big challenge because the amount of architecture and design work as well as foundation work that needs to occur always peaks at the beginning of a new project and gradually diminishes throughout development.

This can be dealt with in a number of ways, many shops will use the initial backlog of user stories to make and document core architecture decisions before the first sprint even begins.  Other times the project is invisioned to be structurally similar to other previous projects and a project template is used that lays out the foundation for the core design and future development.  I have also worked on teams where the architecture team starts to kick off the project with a 2-3 week Preamble before the first sprint is officially supposed to begin.  The first sprint can start out small, for the developers too, for a typical CRUD application I always like to start off with a login page and authentication.  It is easy to start, clearly defined what is finished, and can be clearly tested by QA at the early stages of the project.

EDIT: So how this helps your client is that changes can be made to user stories throughout the process, and this can reflect in modified timelines, estimations, quicker turnaround for the customer, more feedback to the client and more transparency to the client.  This benefits you in that you will be more agile in dealing with changes to the original scope in the middle of a project.


问:
What are the non-technical reasons that make Object-Relational Mapping tools (ORMs) so difficult to write?
I know the technical pitfalls of writing an ORM are pretty well-known nowadays, but what are some non-technical factors (e.g., Scope) that make it difficult to writing a good ORM?

I have already read the technical reasons for why ORMs are so difficult to write from this Stackoverflow post: https://stackoverflow.com/questions/404083/is-orm-still-the-vietnam-of-computer-science

答:
Time and scope are technical factors as they are orthogonal to time/space resources and output reach (scope) used by a particular process (in this case, writing a piece of software.)

A non-technical reason would be driving out requirements, requirement elicitation, customer negotiation and so on. It would be hard to measure the effect of such non-technical reasons (or impediments) to the development of something that is clearly meant for usage by technical staff.


问:
Should interface names begin with an "I" prefix?
I have been reading "Clean Code" by Robert Martin to hopefully, become a better programmer.  While none of it so far has been really ground breaking it has made me think differently about the way I design applications and write code.

There is one part of the book that I not only don't agree with, but doesn't make sense to me, specifically in regards to interface naming conventions.  Here's the text, taken directly from the book.  I have bolded the aspect of this I find confusing and would like clarification on.

I prefer to leave interfaces unadorned. The preceding I, so common in today’s legacy wads, is a distraction at best and too much information at worst. I don’t want my users knowing that I’m handing them an interface.

Perhaps it is because I'm only a student, or maybe because I have never done any professional or team based programming but I would want the user to know it is an interface.  There's a big difference between implementing an interface and extending a class.

So, my question boils down to, "Why should we hide the fact that some part of the code is expecting an interface?"

Edit

In response to an answer:

If your type is an interface or a class is your business, not the business of someone using your code. So you shouldn't leak details of your code in this thrid party code.

Why should I not "leak" the details of whether a given type is an interface or a class to third-party code?  Isn't it important to the third-party developer using my code to know whether they will be implementing an interface or extending a class?  Are the differences simply not as important as I'm making them out to be in my mind?

答:
In my (Java) code, I tend to have this convention in the APIs I expose to callers:

Functionality is provided through interfaces, and never by classes.

Non-functional parts are classes.

By non-functional, I mean things like pure data structures (such as classes that act as bridges to XML serialization or the ORM), enumerations and exceptions, all of which can't be interfaces (well, you can for the pure data classes, but it's a lot of work for very little gain as there's nothing that those classes do except hold data).

In terms of naming conventions, interfaces tend to map to either actor nouns (e.g., FooBarWatcher) or adjectives (e.g., FooBarWatchable) and both pure data classes and enumerations map to non-active nouns (e.g., FooBarStatus); the IDE can guide the API consumer without special naming conventions. Exceptions follow usual Java conventions (FooBarException, FooBarError, FooBarFault) of course.

I'll also often put the interfaces in their own package or even in their own library, just to ensure that I'm not tempted to break my own rules. (This also helps me manage the build when I'm deriving the code from external sources such as WSDL documents.)


答:
Be aware of the annoyance factor of very frequent releases. It's one thing to update your web app daily, or even more often, so that users automatically see whatever small changes you've made since the previous release. But if a user has to take some action, however small, to install new updates, frequent updates quickly become tiresome.

I've encountered apps that seem to need constant updates on both iOS and Android, and it leaves the impression that the software is of low quality. Changes from one version to the next are often so small that they're hard to notice, so as a user I assume that all those updates are mostly bug fixes. And if the changes are noticeable, it makes the app feel less predictable, less familiar.

I'd say that if your app isn't solid enough to make it available for at least several weeks, consider waiting to release until it is. I know that sometimes bugs aren't discovered until after release, and of course you should fix significant ones ASAP, but if that happens more than once in a while you should look at ways to improve your testing process.

Another way to look at it is that every time you release a new version of your app, you're saying "Hey! Look at this!" If you do that too often users who might have been impressed by all the new stuff you added between version 1.0 and 2.0 will instead be bored by the minimal differences between 1.9.6 and 1.9.7.

A better approach is to design your app so that you can update content as often as you like without updating the app itself. If you know that you might want to change the app's appearance around various holidays, for example, build your app so that it can download themes from a server instead of updating the app before and after the holidays.


问:
Using Mercurial repository inside a Git one: Feasible? Sane?
I am thinking on creating a Mercurial repository under a Git repository.
e.g.

```<code>..../git-repository/directory/hg-repo/
</code>```

The 2 repositories

Is it possible to manage (keeping your sanity)? How similiar is it to this?

I am a computer science student at University. I manage my work in Git, mainly as a distribution mechanism (after realizing that rsync fails when you have changes in more than one place) between my desktop and usb drive. I try use of Git as a VCS as I do work.

I have finished a semester where I did a small group project to prepare for a larger group project next year. We had to use Subversion, and experienced the joys of a centralised VCS (including downtime).

I tried to keep the subversion repository separate to my Git repository for the subject**, however it was annoying that it was seperate (not in the place where I store assignments). I therefore moved to using an Subversion repository inside my Git repository.

As I think ahead (maybe I am thinking too far ahead) I realise that I will have to try and convince people to use a DVCS and Mercurial will probably be the one that is preferred (Windows and Mac GUI support, closer to Subversion).

Having done some research into the whole Git vs Mercurial debate (however not used Mercurial at all) I still prefer Git.

Can I have a Mercurial repository inside a Git one without going mad (or it ruining something)? Or is it something that I should not consider at all?

(Or is it a bad question that should be deleted?)

** I think outside of Australia it is called a course

答:
I've done similar things when transitioning projects. I wouldn't particularly recommend it -- there is just always a landline to step on and it definitely takes some options off the table. I would just use hg for the project and transfer the final bit into git when it is done.

On the technical side make sure you ignore the .hg folder and other hg artifacts. That at least gives you a fighting chance.


问:
How to improve your ability to debug existing code
A common task in the working world is dealing with existing, but buggy code. What are some tips to improve your skills as a debugger?</p>

答:
Testing incrementally.

Go depth first in your code and test it from smallest module moving up gradually.In this way, you are not under too much stress trying to figure out where the problem exactly might be.

It also means that it affects less code at a time since you are moving incrementally..as at times I have had issues where I fixed something and that lead to breaking lots of other stuff. I give credit to my boss for this as he taught me this when I messed around.


问:
How to handle management pushing legacy systems?
I am currently on a paid internship, and have been tasked with maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years. Management agrees the "system is on life support", and I receive a fairly regular supply of bug reports from end users currently using the system.

Management now wants to extend the project for another year, and in the process nearly triple the user base.

As an intern (or any entry level position) how do I "push back"? I've already written a report stating my concerns, albeit in an open-ended document. Is there protocol or document type for suggesting changes? Am I in a position to make suggestions, or should I simply continue to support the old system?

To clarify, software development is not my company's primary business. As such no internal protocols exist. Additionally, the project has no formal documentation at all, and no requirements documents either. The development is very ad hoc.

答:
I've already written a report stating my concerns

Good.  That is about the extent of what you can do as an intern.  For future reference when writing such reports I emphasize presenting hard facts in an unbiased, professional manner that is void of emotional prejudices.  You don't know who will read the report, possibly somebody who may or may not have caused some of the issues you are describing or had made decisions that led to these issues.  Anything other than cold facts could be taken by such people as an affront, or an offense and will cause them to not like you and possibly not take any of it seriously.

Management now wants to extend the project for another year, and in the process nearly triple the user base

Keep in mind that business decisions like this are made because they are trying to make due with resources that they have available to them.  I am certain that management is probably aware of the issues with the legacy software, and are probably aware of the user complaints, but do they have the software development resources available to deal with refactoring or a rewrite?

Most of the time they do not, especially if software is not the bread and butter of the company and quality and user satisfaction with the software will not directly affect the bottomline.  Making these kinds of decisions are sometimes why being a manager sucks because you are often in a lose-lose situation no matter what you do.

maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years

Mistakes were made throughout the project that led it to this point.  Lack of solid user input or requirements, lack of proper product management and change control to manage changing requirements and needs, and lack of adequate technical resources to implement caused the problems as they exist today.  I don't know if obsolete is the right word though.  Is the underlying technology built on desupported frameworks and technologies, or is it just not the cutting edge or ideal technologies?

As an intern (or any entry level position) how do I "push back"?

You are in a position of least power and you are temporary at that.  It doesn't matter if you are right, I wouldn't expect an intern to ever "push back" on me.  I expect them to learn, discuss issues as they see them, and follow orders.  That's about it.  Once an order is given I expect it to be carried out to the best of their ability, because the time for discussion is over at that point.


答:
I am currently on a paid internship, and have been tasked with maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years. Management agrees the "system is on life support", and I receive a fairly regular supply of bug reports from end users currently using the system.

The system isn't obsolete if people are still using it and it's supporting the business activities. Since it's still being used, the business can't just throw it away - it needs to be supported until the need for the system no longer exists. That could be a change in business objectives or a new system has been developed, tested, and deployed successfully to the end users.

Really, 5 years isn't that long. I've worked with code that was 10 years old before. If it's still serving the needs of the user, why throw it away? That's throwing away a lot of money spent to develop it. Until it becomes unfeasible to maintain due to increasing costs or the requirements change drastically, there's no business reason to throw it away.

Management now wants to extend the project for another year, and in the process nearly triple the user base.

If management says that this system is "on life support", why are they trying to deploy it further? It's common that maintenance activities continue on a legacy system until it's replaced, but if a system is in end-of-life, it's not typically deployed to more people. Extending maintenance is one thing, but adding users who rely on the system is a different situation all together.

To me, it sounds like it's not actually end of life, but rather in a maintenance phase and will continue to be there until the system no longer serves the needs of the users.

As an intern (or any entry level position) how do I "push back"? I've already written a report stating my concerns, albeit in an open-ended document. Is there protocol or document type for suggesting changes? Am I in a position to make suggestions, or should I simply continue to support the old system?

You need to continue to support the old system. Later, you mention that software is not your company's primary business. In such an environment, the job of software teams is to support the company's primary business. However, the software teams also need to keep the business objectives in mind.

In the mean time, capture your suggestions in a way that isn't overbearing. Point out other technologies or techniques that could be integrated with the system or used if/when a new system is created and their pros/cons. How you do this depends on the company, but considering some later points, perhaps establishing a wiki or other collaborative site would be useful.

In a non-software business, software is a cost and the software teams (especially the software project/program managers) should be working to minimize the cost of building and maintaining software systems as much as possible, while supporting the needs of the end users. Throwing away software that (as far as I can tell, from your post, anyway) meets the needs of the users goes against what's in the best interests of the software team.

*To clarify, software development is not my company's primary business. As such no internal protocols exist. Additionally, the project has no formal documentation at all, no requirements documents. The development is very ad hoc.

To me, this is the problem. Not producing documentation, not developing to a specification, and a lack of consistency tends to increase the cost of developing software. Working toward fixing this would be my highest priority, and I would do that by working on things like a coding standard, version control, producing self-documenting code and design documents, defect tracking, and requirements specifications.

Title: How to handle management pushing legacy systems?

Body:
I am currently on a paid internship, and have been tasked with maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years. Management agrees the "system is on life support", and I receive a fairly regular supply of bug reports from end users currently using the system.

Management now wants to extend the project for another year, and in the process nearly triple the user base.

As an intern (or any entry level position) how do I "push back"? I've already written a report stating my concerns, albeit in an open-ended document. Is there protocol or document type for suggesting changes? Am I in a position to make suggestions, or should I simply continue to support the old system?

To clarify, software development is not my company's primary business. As such no internal protocols exist. Additionally, the project has no formal documentation at all, and no requirements documents either. The development is very ad hoc.


问:
When should a class or module be in a separate Assembly/DLL?
Are there any guidelines for deciding when a class should be in its own assembly/DLL?  I often see two schools of thought:

1) Every "grouping" of classes belongs in its own DLL e.g. Repositories, Services, DTOs, Infrastructure, etc.

2) Everything should be in a single DLL but separated out via namespaces/folders e.g. have a "Core" DLL with additional namespaces e.g. Core.Repositories, Core.Services, Core.DTO, etc.

At work we just lump everything in a single Assembly called "Business".  There are some folders but there's no real separation - business objects (with logic, some of which shouldn't even be classes) are lumped in a "BusinessObjects" folder without care.  Things used in more than one class are in a "Core" folder.  Utilities are in a "Utilities" folder, the data access infrastructure is a "Data" folder - you get the idea.

For a new module I'm working on I want/need to have a separate data access layer (think a rudimentary Repository implementation) but I don't want to just throw it under the "BusinessObjects" folder with the other 160 (!) classes there.  At the same time I'm concerned about creating a new Class Library since everyone is used to stuffing a class in the single Library; a folder/namespace could work however.

答:
Some other guiding princicples I work with:

Do you think you will re-use this code in other projectS? For one group of related web applications, we had one user account-related module that all the applications made use of, since they all used the same model for user accounts and logins. I've done similar things with geometry and math libraries and reused them in multiple applications, just by including the DLL.

Do you want to be able to modify / deploy this code without redeploying / recompiling the whole project? Sometimes it's been useful to just rebuild the module, deploy and restart the web application.

It sounds like in your case a basic and generic Repository could be useful again in the future, it might be worth it to separate it into a new DLL if you can.


答:
I find it's better to have more projects (i.e. assemblies) with classes divided by category in each project than one project with all of these classes in separate namespaces. You should aim for your projects to be reusable and to represent different layers in an application. You can then feasibly reuse these projects in future applications without having to include a whole bunch of unnecessary classes.

For instance, based on what you have mentioned, I would definitely have the following projects:

Core

Data

Domain (or BusinessObjects)

Services

Utilities (or Helpers)

Title: When should a class or module be in a separate Assembly/DLL?

Body:
Are there any guidelines for deciding when a class should be in its own assembly/DLL?  I often see two schools of thought:

1) Every "grouping" of classes belongs in its own DLL e.g. Repositories, Services, DTOs, Infrastructure, etc.

2) Everything should be in a single DLL but separated out via namespaces/folders e.g. have a "Core" DLL with additional namespaces e.g. Core.Repositories, Core.Services, Core.DTO, etc.

At work we just lump everything in a single Assembly called "Business".  There are some folders but there's no real separation - business objects (with logic, some of which shouldn't even be classes) are lumped in a "BusinessObjects" folder without care.  Things used in more than one class are in a "Core" folder.  Utilities are in a "Utilities" folder, the data access infrastructure is a "Data" folder - you get the idea.

For a new module I'm working on I want/need to have a separate data access layer (think a rudimentary Repository implementation) but I don't want to just throw it under the "BusinessObjects" folder with the other 160 (!) classes there.  At the same time I'm concerned about creating a new Class Library since everyone is used to stuffing a class in the single Library; a folder/namespace could work however.


问:
web Service - what happens when client doesn't get the response?
We have developed a WCF service which acts as an API to our system.

some of the methods expose functionality which eventually writes and updates data to DB.

Lets say that the client sent one of those requests, the service performed the needed operations while the client disconnects for some reason and did not get the response.

the response holds information about success/failure of all sub-operations

An example of "problematic" data being updated - "Add X amount to Balance of Member M".

So if the client did not get the response - the client doesn't know that the data was updated.

How should we deal with this scenario while keeping the client side implementation as clean as possible?

答:
Send a transaction Id.

The server stores the transaction ID (And the client ID).

When a new transaction is sent the server checks if it has already been processes.. If it has is sends an error code the the client.


问:
Anybody use the Team Software Process (TSP) and/or Personal Software Process (PSP)?
More info on it here:
http://en.wikipedia.org/wiki/Team_Software_Process

What has your experience been?

答: TSP only gives you some beautiful charts and artificial data to do nice presentation and boggs down the project big time. It can be sold just becuase management is not a developer and doesn't know how developers do thier work. If, fortunately, a company has managment who knows something about development, the company will never uses TSP at all or will drop the process like trash.</p>


答:
You're an intern. I doubt very much whether you are even remotely au fait with the day to day business imperatives as a whole and as other people have noticed, a 5 year old code base is not really that old.

Decisions about replacing legacy systems are not always technically driven; they are driven by changing business requirements. Input to those can be difficulties relating to maintaining; but at the end of the day, you need to recognise that your position does not necessarily mean you have all the available and required knowledge. I would go so far as to say you actually have very little of the required knowledge to make the call on what is the best move at present.

My advice to you is this: learn from the experience and stop assuming that your knowledge trumps that of people who have to run the business on a day to day basis.

Your job is to keep the system working, not to suggest a shiny new replacement.

It seems to me that a lot of young programmers do not realise that maintenance of older systems is a bigger part of programming work than designing shiny new systems/


答:
YOU DON'T!!! This is a GREAT Opportunity!

You are an Internship to learn! This project is a real world as it gets.

You are very lucky to have it. The fact that you are unqualified is not your concern. (If\when management realized this you will have gained a whole lot)

YOU will be qualified once you are done with this internship, And that's great news.

PS: Make backups religiously, be sure ANYTHING you do can be rolled back. Start with the Issues that are "Easy fixes" But big pain points for users. Take baby steps.


答:
Quit

There are lots of sensible suggestions in the answers already, which hopefully can help work out this dysfunctional relationship. But in the end, you decide how much you want to work.

It's easy to get pressured by coworkers into overworking. But you're sacrificing your personal life when you do that.

Here's what you can do:

Say to your boss, "I've had to work a lot more overtime than I want to here. From now on, I'm not going to work more than X hours per month."

As others have suggested, estimate how many hours things will take up front. Remind them that "at my limit of X hours per month, I probably won't finish this by the deadline." Put this in an email for later reference.

Refer to that email when the deadline goes whooshing past. "See? As projected, we could not hit this deadline in reasonable work hours."

If they continue to pressure you to work overtime and all communication efforts fail, quit.

Personal experience

I quit my last job because I was always working overtime and always being asked to work more. I told them clearly in my exit interview that I liked a lot of things about the job, but didn't see any end to the overtime in sight.

I also clearly expressed that desire in my interview for my new job, and was given enthusiastic response. They have held true to their word: I'm rarely asked to work overtime here.

My former employer has a high developer turnover rate, and is finding it harder to recruit these days because they have a reputation for overworking. Maybe the extra cost of recruiting and training will teach them a lesson. But if not, it's not my problem.

Title: Is there a way to combat Sales perpetually overcommitting?

Body:
I seem to be repeatedly stuck in a situation where release dates are set not based on anything technical, but because someone in Sales has committed to a customer by then.  Based on discussions with friends in development at other companies, the same thing seems to happen.

"Here is the committed feature set and here is the committed release date", and it's difficult to argue because at this point there is money riding on it, and that trumps everything.

In general, is there a way to push back on this?  If not for this release, what about in future?  The problem I have is that the only way I see one way of doing so, and that's by doing the best I can, but release the software 'as is', so to speak.

I don't want to release bug-ridden software since it's my name attached, but doing 80 hour weeks for months at a time just vindicates the arbitrarily set release date.

edit: for the record, I'm not doing 80 hour weeks now, just that comes to mind as what would be required to cover the expected feature set by the release date.


问:
BDD to replace the test teams work - how best to do it?
The system we are developing, using .NET, is extremely large, complex, and some modules are poorly written. We have a large user acceptance test team that is aiming for 100% business scenario coverage, which takes about 6 weeks.

Can we use behavior driven development to replace some of the manual tests being done by the test team?  How would that information be readable to the test teams so they can be sure it's working? Does BDD replace our integration tests?

答:
Behavior driven development is about more than just automated acceptance tests.
For more information on that see the wikipedia page on BDD or check the excellent list resources Liz Keogh has compiled on BDD

Now on topic:
You could start automating the acceptance tests using BDD tools for .Net. StoryQ and SpecFlow are examples of BDD tools that support scenario's(acceptance tests) in plain text.

Using such a tool not only makes the scenario's readable for the test team, they can actually write these tests themselves. That should give them confidence the tests are working.

If you could get them to writing these tests for all new features before you start coding them. You're getting one step closer to BDD. This gives you the benefit of having an executable specification. You know when the software meets the acceptance criteria, i.e. you're done.
When done the specification becomes an automated regression test.

Probably not all tests can be automated or or are worth automating. Sometimes thing can be automated but if you're not carefull they can turn into a maintenance nightmare.

Even if you can automate all specifications this way, testers still have to do some testing by hand or using other tools. You can't replace testers with automated tests, but you could probably reduce the 6 weeks to a lot less.


答: If it's vital that the client receive the response, then you'll have to do a two-phase-commit type of interaction (client invokes service; service returns token of some sort; client ACKs with token).  It's not clear from your question though whether this is really required or simply "nice to have".  Would it be acceptable to provide a history-type service, where the client can query for the status of the last (possibly the last N) service invocations?</p>

Title: web Service - what happens when client doesn't get the response?

Body:
We have developed a WCF service which acts as an API to our system.

some of the methods expose functionality which eventually writes and updates data to DB.

Lets say that the client sent one of those requests, the service performed the needed operations while the client disconnects for some reason and did not get the response.

the response holds information about success/failure of all sub-operations

An example of "problematic" data being updated - "Add X amount to Balance of Member M".

So if the client did not get the response - the client doesn't know that the data was updated.

How should we deal with this scenario while keeping the client side implementation as clean as possible?


答: In many ways, consistency is more important than convention. As long as you're consistent in your naming schemes, they won't be hard to work with. Prefix interfaces with an I if you like, or just leave the name unadorned, it doesn't matter to me as long as you pick a style and stick with it!</p>

Title: Should interface names begin with an "I" prefix?

Body:
I have been reading "Clean Code" by Robert Martin to hopefully, become a better programmer.  While none of it so far has been really ground breaking it has made me think differently about the way I design applications and write code.

There is one part of the book that I not only don't agree with, but doesn't make sense to me, specifically in regards to interface naming conventions.  Here's the text, taken directly from the book.  I have bolded the aspect of this I find confusing and would like clarification on.

I prefer to leave interfaces unadorned. The preceding I, so common in today’s legacy wads, is a distraction at best and too much information at worst. I don’t want my users knowing that I’m handing them an interface.

Perhaps it is because I'm only a student, or maybe because I have never done any professional or team based programming but I would want the user to know it is an interface.  There's a big difference between implementing an interface and extending a class.

So, my question boils down to, "Why should we hide the fact that some part of the code is expecting an interface?"

Edit

In response to an answer:

If your type is an interface or a class is your business, not the business of someone using your code. So you shouldn't leak details of your code in this thrid party code.

Why should I not "leak" the details of whether a given type is an interface or a class to third-party code?  Isn't it important to the third-party developer using my code to know whether they will be implementing an interface or extending a class?  Are the differences simply not as important as I'm making them out to be in my mind?


问:
What skills to add for an older CS grad living in rural area?
The answers to this question might be different than the generic, "I graduated.  Duh, now what should I do?"  Living in an area with a low population presents limited opportunities compared to those in more urban or suburban communities.  On the other hand...maybe the answers will be largely the same.  I'm asking you folks who might be looking at this from a perspective of more years on the inside for your wisdom.

I have just finished a CS degree.  I am about 40 (does it matter much?).  I left a successful, professional career in the laboratory robotics industry because it required me to either move to a big city or continue to travel extensively.  In a few years we could potentially move somewhere else or I could start travelling again but I need to start working now.  I need to make myself as employable as possible.

There are few jobs available in my area for computer professionals.  Of those few, the majority seem to be IT related more than software development related -- SharePoint, ERP, network security, web services, etc..

Might I be well served by trying to pick up some IT knowledge? Or should I continue to work on my software development chops?

I have my own project now that I am proud of and excited about and could happily continue to extend it.  It is a good vehicle for learning new stuff until (and hopefully after) I find employment.  I'm hoping to get some others involved in it as well.

Or I could start a new project that would be a vehicle for learning something marketable -- from .net to being able to support all that legacy COBOL there seems like a lot of stuff out there.

Thanks for whatever insight anyone shares.

答: If you're looking to make yourself more employable, then try to pick up whatever skills your local market wants.  I'd be wary about taking an IT job, as that could get you pigeonholed as a "systems admin" type, which can make it difficult to transition to a development role.  If you can, I'd recommend trying to find a recruiter in your area.  They're familiar with the local market and can best advise you as to what skills are in demand and who's hiring.</p>


答:
There are two things you can try on.

If you are good in development, say website or desktop applications, you can apply for freelance projects on websites like Odesk, Elance, and other similar websites. This will not only help enrich your knowledge but also your pocket.

You can collaborate and contribute to any open-source project. They can be found on google project hosting site or github or codeplex. This won't earn you money but significant knowledge and ease you from client over-headache. You will have the source code at hand which is a great starting point.

Once you feel confident enough after developing and working on some projects, apply for a good opening. Or a start a development company of your own :-) ... Best of luck

Title: What skills to add for an older CS grad living in rural area?

Body:
The answers to this question might be different than the generic, "I graduated.  Duh, now what should I do?"  Living in an area with a low population presents limited opportunities compared to those in more urban or suburban communities.  On the other hand...maybe the answers will be largely the same.  I'm asking you folks who might be looking at this from a perspective of more years on the inside for your wisdom.

I have just finished a CS degree.  I am about 40 (does it matter much?).  I left a successful, professional career in the laboratory robotics industry because it required me to either move to a big city or continue to travel extensively.  In a few years we could potentially move somewhere else or I could start travelling again but I need to start working now.  I need to make myself as employable as possible.

There are few jobs available in my area for computer professionals.  Of those few, the majority seem to be IT related more than software development related -- SharePoint, ERP, network security, web services, etc..

Might I be well served by trying to pick up some IT knowledge? Or should I continue to work on my software development chops?

I have my own project now that I am proud of and excited about and could happily continue to extend it.  It is a good vehicle for learning new stuff until (and hopefully after) I find employment.  I'm hoping to get some others involved in it as well.

Or I could start a new project that would be a vehicle for learning something marketable -- from .net to being able to support all that legacy COBOL there seems like a lot of stuff out there.

Thanks for whatever insight anyone shares.


问:
Is "Computer Science != Software Engineering" an excuse to teach programming poorly?
We've all heard it; whenever there's a discussion about CS grads having poor development skills someone eventually says,

Computer science isn't software engineering.

The problem that I see is that programming and software development are taught in CS courses. They're just commonly taught poorly. If it's being taught, then why not teach it right the first time? *

So I would like to see what the opinions are on 2 questions:

Is the CS != SE argument a copout or excuse for not properly teaching programming skills.

Regardless of your answer to question 1; if you were in the almighty position of making such a decision: would you force an emphasis on proper teaching of programming in CS courses?

*. I have a suspicion, based on anecdotal evidence I obtained throughout my education, that most academics in the field haven't had to write code to be maintained and haven't maintained code, and as a result don't have the knowledge/skills to teach it effectively.

答:
Is the CS != SE argument a copout or excuse for not properly teaching programming skills.

No. CS is not SE. That's a fact, not an excuse.

Regardless of your answer to question 1; if you were in the almighty position of making such a decision: would you force an emphasis on proper teaching of programming in CS courses?

No. It would be like forcing astronomers to learn the details of building telescopes. Or forcing programmers to learn the details of building computers. Related stuff, but one man doesn't need to know everything.


问:
Is it best to minimize using pointers in C?
I think most people would agree that pointers are a major source of bugs in C programs (if not the greatest source of bugs). Other languages drop pointers entirely for this reason. When working in C, then, would it be best to avoid using pointers whenever practicable? For example, I recently wrote a function like this:

```<code>void split (char *record, char *delim,
            int numfields, int fieldmax,
            char result[numfields][fieldmax]);
</code>```

While not as versatile as a dynamically allocated variable, in that it requires the programmer to know the number of fields in advance and anything over fieldmax is truncated (which is sometimes acceptable), it eliminates the need for memory management, and the potential for memory corruption. I think this is a pretty good trade, but I was wondering what the opinions of other programmers on this were.

答:
Those char* should really be const, unless you actually meant a pointer to one single character, which I find to be quite unlikely. Apart from that, pointers are the reason C is so fast- they're extremely efficient. What else are you going to do, copy everything around everywhere? The ability to alias any variable at any time is risky, but it's also very powerful.

If you don't like bugs, and you still like performance, then upgrade to C++. It's vastly less buggy when written with adherence to it's most basic principles and can be faster than C, and is certainly no slower in the general case.


答:
In my opinion, it doesn't make any sense to use C and want to avoid pointers. If you do so, then you'd better use another language.

Pointers are unavoidable in C. This is what make C so powerfull and also what make C a pain in the ass sometime. C is meant to be used with pointers.

Arrays are pointers, functions are pointers, memory allocation work through pointers, and so on. Take advantage of that or change language.

Title: Is it best to minimize using pointers in C?

Body:
I think most people would agree that pointers are a major source of bugs in C programs (if not the greatest source of bugs). Other languages drop pointers entirely for this reason. When working in C, then, would it be best to avoid using pointers whenever practicable? For example, I recently wrote a function like this:

```<code>void split (char *record, char *delim,
            int numfields, int fieldmax,
            char result[numfields][fieldmax]);
</code>```

While not as versatile as a dynamically allocated variable, in that it requires the programmer to know the number of fields in advance and anything over fieldmax is truncated (which is sometimes acceptable), it eliminates the need for memory management, and the potential for memory corruption. I think this is a pretty good trade, but I was wondering what the opinions of other programmers on this were.


答:
Don't push back. The only thing you should do is voice your concerns in a clear, concise manner. The fact of the matter is that most businesses you will work at in the future will have legacy systems. Those legacy systems need to be maintained because in many cases are too expensive to replace.

In many cases you may even have the best intentions of replacing the current system with a better system, however, you may just introduce new and different bugs...when you leave the system will quickly turn into a legacy system again and the company will be in the same spot it was before. Nothing is obsolete until no longer servers its purpose or is completely incompatible with modern systems. My company has a 20+ year old system that we are just now converting to ASP.NET. The system still runs but support for the old technology is dwindling and making it work with modern web browsers is becoming increasingly more time consuming.

What you can do:

Leave Things Cleaner

When you maintain something leave it cleaner than when you started. make your fix, but also clean things up so the next time somebody needs to make a modification it is easier to understand.

Create Documentation

If lack of documentation is a problem, create documentation. When you're working on a particular part of the system document it.

Make It Less Painful

As I stated you can voice your concerns but your best off just working diligently on the system and making it better to work on for those after you. Fix bugs properly. Document. Disperse code smells. Make it better. And when you do these things, let your superiors know. Tell them that your doing X, Y and Z to improve the development process. That builds credibility and in the long run that is going to help you and your company more than anything else.


问:
What is the/Is there a right way to tell management that our code sucks?
Our code is bad. It might not have always been considered bad, but it is bad and is only going downhill. I started fresh out of college less than a year ago, and many of the things in our code puzzle me beyond belief. At first I figured that as the new guy I should keep my mouth shut until I learned a little more about our code base, but I've seen plenty to know that it's bad.

Some of the highlights:

We still use frames (try getting something out of a querystring, almost impossible)

VBScript

Source Safe

We 'use' .NET - by that I mean we have .net wrappers that call COM DLLs making it almost impossible to debug easily

Everything is basically one giant function

Code is not maintainable. Each page has multiple files that are created every time a new page is made. The main page basically does Response.Write() a bunch of times to render the HTML (runat="server"? no way). After that there can be a lot of logic on the client side (VBScript), and finally the page submits to itself (often time storing many things in hidden fields) where it then posts to a processing page which can do things such as save the data to the database.

The specifications we get are laughable. Often times they call for things like "auto-populate field X with either field Y or field Z" with no indication of when to choose field Y or field Z.

I'm sure some of this is a result of not being employed at a software company, but I feel as if people writing software should at least care about the quality of their code. I can't even imagine that if I were to bring something up that anything would be done soon, as there is a large deadline looming, but we are continuing to write bad code and use bad practices.

What can I do? How do I even bring these issues up? 75% of my team agree with me and have brought up these issues in the past, yet nothing gets changed.

答:
I've never thought it is easy to tell managers especially Project Managers about bad code and refactoring. First, they must trust you, even if you are senior guy you still need time to be trusted. Second, they simply don't understand how bad the problem is. If today is the last day to release a new build, and the build fails. They know how serious it is, but they never know the build just failed because lots of problems such as bad code, inadequate testing etc.

I've been done configuration and deployment tasks in a web project. It often takes much time to fix unexpected issues each time I deploy a new build. Most of issues were security and integration (between several web/Windows applications). Our code sucks, others' code sucks, they're completely spaghetti code.

We were planning for a new version and I strongly asked for some refactoring, just add detail log to login/authentication code where bugs often occurred. Managers agreed, but then it was put in a nice-to-have list and I don't know if it will be done since we already had a big list of features and a tight time frame.

OwnerDisplayName: Azkar


答:
I would start by leveraging your knowledge of the laboratory robotics equipment industry.  Are there any APIs or SDKs provided by the manufacturers of the equipment or any way to get your hooks into the signals returned by the hardware?  Given your unique knowledge of the industry, was there some sort of feature (ex. advanced monitoring or analysis) many customers had asked for but were unable to find from the product?

This would be a longer term suggestion compared to a typical "learn Sharepoint" answer and may not meet your short term needs, but if you're able to expand your knowledge of how to interact with the robotic equipment from a programmer's perspective, you may open yourself up to employment back at the previous employer, at a different non-travelling role, or employment at a big customer looking to extend the functionality of the equipment.


答:
Before stepping over a small chunk of code, see if you can accurately determine the outcome. This does tend to fly in the face of don't assume anything (which I up voted BTW) but as you gain experience, it can help narrow down where to look.

This may sound trivial, but learn the nuances of your debugger and learn the hot-keys. Sometimes debuggers can be slow enough that your mind wonders when your stepping through. If you can keep up with the machine and aren't mousing around, that can help.

If you can modify code while debugging:

consider asserting pre AND post conditions. Sometimes you can then step over, instead of into code.

for if statements with complicated expressions, consider something (some may frown at this but it works for me)

like:

```<code>bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
   // more code here
}
</code>```

instead of:

```<code>if ( a < 5 || a > 10 )
{
   // more code here
}
</code>```

For the cases you can't debug everything, for whatever reason, learn to "rubber-duck" with a co-worker. Sometimes the act of explaining sheds light. (ok, maybe this isn't exactly in the questions theme, but I think it's close enough to warrant mention)

Title: How to improve your ability to debug existing code

Body: A common task in the working world is dealing with existing, but buggy code. What are some tips to improve your skills as a debugger?</p>

Body:
Before stepping over a small chunk of code, see if you can accurately determine the outcome. This does tend to fly in the face of don't assume anything (which I up voted BTW) but as you gain experience, it can help narrow down where to look.

This may sound trivial, but learn the nuances of your debugger and learn the hot-keys. Sometimes debuggers can be slow enough that your mind wonders when your stepping through. If you can keep up with the machine and aren't mousing around, that can help.

If you can modify code while debugging:

consider asserting pre AND post conditions. Sometimes you can then step over, instead of into code.

for if statements with complicated expressions, consider something (some may frown at this but it works for me)

like:

bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
   // more code here
}

instead of:

if ( a < 5 || a > 10 )
{
   // more code here
}

For the cases you can't debug everything, for whatever reason, learn to "rubber-duck" with a co-worker. Sometimes the act of explaining sheds light. (ok, maybe this isn't exactly in the questions theme, but I think it's close enough to warrant mention)


问:
Creating a webservice API - how much "credit" should I give the client/developer
When creating a web service API, how much should I count on the developer to act by my rules?

We are really aimed on creating an API so the developers shouldn't develop client side logic too much...

for example, if in one of my methods we require the client to send us a unique ID - we are relying on the client that the ID sent is really unique - so the client should also keep track of it's requests and add logic to it's code.

is it ok or should we try to solve ths kind of issues in a different more transparent ways?

答:
Never trust user input, even if that user is an API consumer. Its your responsibility to maintain integrity in your data, their reponsibility to maintain theirs. If your code requires the clientID to be unique then check its unique before you save it.

Trusting user input couples your code with theirs, when they have bugs on their system they can then introduce bugs into yours.


答:
From my own experience living in a less populated area,

Networking is crucial if there's any wiff of any technical/nerdy group to get involved in, get involved. In a small town everyone knows everyone. Do good work and people will remember you and think of you for that next job. Many of the technical companies may be very small shops, and those type of people tend to hire who they know, so get in good with them.

Get to know the local buisiness folk Goes along with 1. Be known to the local business people as the computer guy. Be it general IT or making them a website or something more elaborate. Its crucial to get your name out there.

Be a jack of all trades. One advantage of being in a smaller market is it forces you to diversify. You don't get pigeonholed as easily into one technology forever. Local businesses seeking developers cannot count on their being 5000 expert python developers within a few square miles. Instead they'll be more willing to accept someone with more moderate levels of experience in what they want. So be sure to diversify your skills. As implied in (2) this may not be strictly programming, but any form of IT or computer support.

Outside of tapping local resources, be sure to

Get involved in the closest metropolitan area's contracting market. You can possibly find flexible contracting gigs that allow you to work remotely. Leverage your lower cost of living to accept lower paying gigs that the competition can't accept. Even if you need to go in, you may be able to room-share with other professionals who also commute in longer distance to work a few days in a major metropolitan area.

As a last resort use sites like elance and rentacoder. I find people on these sites really don't have great compensation, so I avoid them. But if need be, these can be a last resort.


问:
Should non-interface code be hidden from the client?
I am working on a library which had several headers that are meant to only be used by the library itself. I also have a few classes and functions in headers that I do not want the client to use. For instance, I have a header that contains debugging functions, but they should not be used outside of the library as it could cause problems.

Should this code be hidden from the client? If so, how?

答:
Should this code be hidden from the client? If so, how?

Off course. You do it by not providing the headers. That is, you just provide the shared libraries, and the headers declaring classes your client should use.


答:
A common way to handle this is public and private headers.

Given that some things must appear in a header file, either for physical implementation reasons, or for performance/inlining reasons, you need to split somehow.

Have your public header include the private header; and add comment(s) nearby that this is an implementatinn detail and subject to change.

Of course, you still need to ship the headers, and they will be visible to your end user, but they would use those internals at their own risk.

Title: Should non-interface code be hidden from the client?

Body:
I am working on a library which had several headers that are meant to only be used by the library itself. I also have a few classes and functions in headers that I do not want the client to use. For instance, I have a header that contains debugging functions, but they should not be used outside of the library as it could cause problems.

Should this code be hidden from the client? If so, how?


答:
You shouldn't assume that anyone is going to be following your rules. You should assume that there is at least one malicious user out there who is going to try to break your system. You accept an int and expect it to be positive, assume that someone is going to try to send 0 or negative values. You accept objects, so assume people will pass objects in invalid states or null values. You should program defensively - someone will try to use your API in a manner that you don't expect. If you don't have control over the code, never assume that someone else will not make a mistake (intentionally or otherwise).

You use an example of a unique ID for a client. If the client provides this information, how do you know that multiple clients won't provide the same "unique" ID, even unintentionally? If the client provides this ID, you first assume that there are no defects in the client code and every ID a particular client generates is unique and valid. You also assume that you don't have a malicious client that isn't trying to spoof unique IDs.

Title: Creating a webservice API - how much "credit" should I give the client/developer

Body:
When creating a web service API, how much should I count on the developer to act by my rules?

We are really aimed on creating an API so the developers shouldn't develop client side logic too much...

for example, if in one of my methods we require the client to send us a unique ID - we are relying on the client that the ID sent is really unique - so the client should also keep track of it's requests and add logic to it's code.

is it ok or should we try to solve ths kind of issues in a different more transparent ways?


答:
If I was designing the service I would do all of the database updates in a transaction.  If the client disconnects prior to the completion of the process roll back the transaction.  In this method if the client did not get a response the client can assume that the update failed.

If this is not acceptable you could create a set of tables for the submission process.  Then compare each submission to all previous submissions (or at least those inside a certain window) that were disconnected. Then check and see if the submission is the same as the previous submission and return the  results from the original... though I see so many potential pitfalls here.


问:
What kind of innovative non-cash financial benefits do I offer to my developers to retain them along with a competitive salary?
Stock options don't make much sense, since the company's private. [It still does, if you are a facebook of sorts AND the regulatory system permits sites like secondmarket, but I digress.]

I could think of some:

Health benefits to parents and parents-in-laws

Sponsoring a fuel-saving bike to drive to office

Gift cards for occasions like completion of 1, 3, 5 years of service

I really could do with more suggestions here.

EDIT:
Thanks everyone for the response. To summarize, here are the additional things my HR could do:

Matching contribution to employee retirement fund provided the employee contributes

Funding continuing education, professional courses etc.

Company subscription to ACM, IEEE, Safari Books etc.

Meal vouchers

Membership to gyms

Hosting a recreation room at office

Spot bonuses

Time off for code spikes in recognition of individual contribution

Sabbaticals

答:
Buy them really, really good hardware for them to develop on. I don't know if you have any idea how great it is for us geeks to have decent hardware to work on. Eight or 16 threads, 24GB of RAM, 120GB SSD, multiple monitors, Firepro graphics cards, keyboards and mouses of their choice, USB steak griller, you know.

Buy them the office furniture of their choosing (within reason - a million buck calf-skin matching monogrammed chair-and-desk-and-pen-holder set would be a bit extravagant.) Having a comfortable office chair that is ergonomically healthy is more important than most people think.

Subsidise, even partially, some private hardware purchases for your staff. Being able to afford that radio-controlled helicopter, HTPC or 2nd (or 3rd!) graphics cards might work wonders for your staff's e-egos.


问:
Is "Mapper" a valid design pattern or is it a variation of the "Factory" pattern?
A common pattern I see is what's known as the Mapper pattern (not to be confused with DataMapper which is something else entirely), which takes as an argument some kind of "raw" data source (e.g. an ADO.NET DataReader or DataSet) and maps the fields to properties on a business/domain object.  Example:

```<code>class PersonMapper
{
    public Person Map(DataSet ds)
    {
        Person p = new Person();
        p.FirstName = ds.Tables[0].Rows[0]["FirstName"].ToString();
        // other properties...
        return p;
    }
}
</code>```

The idea being your Gateway/DAO/Repository/etc. will call into the Mapper before it returns, so you get a rich business object versus the underlying data container.

However, this seems to be related, if not identical, to the Factory pattern (in the DDD parlance, anyways), which constructs and returns a domain object.  Wikipedia says this re: the DDD Factory:

Factory: methods for creating domain objects should delegate to a specialized Factory object such that alternative implementations may be easily interchanged.

From that quote the only difference I could think of is that the DDD-style Factory could be parameterized so it could return a specialized type of object if the need arose (e.g. BusinessCustomer versus ResidentialCustomer) while the "Mapper" is keyed to a specific class and only does translation.

So is there a difference between these two patterns or are they essentially the same thing with different names?

答:
Although this is the first time I hear of the Mapper pattern, to me it sounds more like the Builder pattern rather than the Factory.

In the Factory pattern you encapsulate the logic for creating objects of a number of related classes.  The prime example would be a situation where you need to create an object of a particular subclass of some abstract base class depending on some parameters.  So a Factory always returns a pointer or a reference to the base class, but it actually creates an object of the appropriate derived class based on the parameters you give it.

In contrast, a Builder class always creates objects of the same class.  You would use it if the creation of an object is complicated, e. g. its constructor takes lots of arguments, not all of which may be available instantly.  So a builder object might be a place which stores the values for the constructor arguments until you have them all and are ready to create the "product", or it may provide reasonable default values and let you only specify the arguments whose values you need to change.  A typical use case for the Builder pattern is for creating objects you might need in a unit test, to avoid cluttering the test code with all the creation logic.

To me a Mapper sounds like a variant of a Builder, where the constructor parameters come in the form of a database record or some other "raw" data structure.


问:
What's your favourite quote about programming?
What's your favourite quote about programming?

One quote per answer, and please check for duplicates before posting!

答:
The best thing about a boolean is
  even if you are wrong, you are only
  off by a bit. - (Anonymous)

LastEditorDisplayName: Roger Pate


问:
What are the benefits of using database abstraction by ORM?
I'm starting to use the ORM recommended by the framework I choose, and though I like the idea of the added layer of abstraction the ORM provides, I'm starting to realize what this really means. It means I'm no longer working with my database (mysql) and any mysql-specific features are gone, out the window, like they don't exist.

The idea the ORM has is that it's trying to help me by making everything database agnostic. This sounds great, but often there is a reason why I choose a specific database system. But by going the database agnostic route, the ORM takes the lowest common denominator, which means I end up with the smallest set of features (the ones supported by all databases).

What if I know that for the long term I won't be switching the underlying database? Why not access the database-specific features, too?

答:
One thing that hurts using ORMs is that many of their fans tend to claim we no longer need to know SQL and RDB theory. The results vary from funny to utterly catastrophic. And this is despite the million times that ORM' manufactures and pundits state that we must know SQL and RDB theory well to properly use and configure a ORM.

Why people take a tool that has its uses on many, but not all contexts into a magical, universally applicable silver bullet is beyond me.


答:
Yes, you can do this in C++ by using the PIMPL idiom.  If you use this idiom you only need to let the client see a header defining a simple wrapper class, which has a pointer to the real class as its data member.  Because you are using a pointer, you would only need to forward declare the real implementation class in the header of the wrapper class.  The header of the real implementation class only needs to be included in the .cpp file of the wrapper, so the client will never see it.

Having said that, using PIMPL adds complexity to your code.  Now, if you need a new public member function, you would have to add it in two places.  Also, you would have to go through more levels of call stack when you debug.  You should really think long and hard whether hiding some functions from your client is worth this extra work.

P.S. The PIMPL idiom has another important use.  It lets you break dependencies between components, which reduces coupling making your code easier to modify, and it can also significantly reduce the build time.


答:
Other languages don't "drop pointers entirely," they just restrict what you can do with them, give them a syntax that looks like non-pointer variables, handle some operations on them behind the scenes, and call them something else, like a reference or object.  If you ever have to make a distinction between assigning a copy of something or not, you are dealing with pointers.

With the exception of programming paradigms that pass everything by copy, with obvious performance implications, the use of pointers is unavoidable in all but the simplest of programs.  By all means, use stack variables where it makes sense, but if you try to avoid pointers too much, you will introduce a whole different breed of potential bugs.


答: Good luck using the standard runtime or any third-party libraries.  If you mean you want to avoid pointer manipulation then you might have a chance, but I don't think you'll gain any real benefit.  It's the nature of the beast; if you want protection from pointer errors, then you'd be better off using a different language.