问:
WinRT: How usable will it be?
WinRT: is it really about calling WIN32 (wrapped in COM (exposed as .NET)) via a proprietary extension of C++?

That looks like a lot of wrappers and layers between the developer and the actual functionality.  Does anyone trying to go with it stand a chance at profoundly understanding the ecosystem (if his last name isn't "Petzold")?

答:
The short answer is yes, at least sort of.

The longer answer is that the last MS operating system a significant number of programmers understood very well was MS-DOS 6.x. Windows 3.x was fairly understandable as long as you looked at it as a number of pieces (MS-DOS, DOS extender, Windows kernel, Windows UI) but most people didn't really bother.

For better or worse, however, all the implementations of Win32 have been somewhat convoluted. Although they tried to make it less visible, Windows 95 still had a copy of MS-DOS, a DOS extender, and a rather fragmented implementation of Windows itself, split between a heavily modified version of the 16-bit kernel from Windows 3.x, and a new 32-bit interface -- and some fairly significant pieces of 32-bit code too.

Windows NT was a bit more straightforward, but it was originally written as something like a microkernel with three subsystems (Win32, POSIX, OS/2). The Win32 subsystem always enjoyed a special status though, so it had its own rules (or they broke a lot of rules, depending on your viewpoint). In any case, very few people really understood the system well at a truly fundamental level -- and most application programmers had (at most) only a peripheral, vague awareness of there being a "native API" that a few of the true wizards (and here we're talking people like David Solomon and Bryce Cogswell, not Charles Petzold) used to do things that looked (and often were) impossible using only Win32.

.NET added yet another layer -- and rather an "uneven" one at that. That's not to the say the interface visible to the user was uneven, but that its "bottom" side where it interfaced to the system was quite uneven -- some parts talked to Win32, other parts to DirectX, still others to various COM interfaces, etc. In short, a lot of people understood how to use .NET (at least reasonably well) but probably fewer than one in a thousand really understood all its internals very well.

I would say, however, that that's exactly as it should be. One of the basic points of creating abstractions is to avoid everybody having to learn all the ugly internal details of how everything really works. The problem, at least in my opinion, is rarely the existence of one layer after another getting between his code and how things really work. Rather, the problem is primarily with poor abstractions that don't do nearly enough to keep a programmer from needing to know about the underlying details to be able to get the job done.

MFC would be a classic example -- to use it at all well, you pretty much needed to already know how to write Win32 programs without it. In some ways, it made understanding even more difficult by adding a fair number of wrinkles of its own on top of Win32 itself. If you knew enough about MFC itself and about its underpinnings in Win32, it could actually save you quite a lot of work -- but it required a lot of extra study to understand it well enough to get much benefit. It's almost universally reviled, because most people never understood enough to get much (if any) benefit.

It's a bit difficult at this point to figure out exactly where WinRT will land in the great scheme of things. I think it's safe to say that Microsoft has gained a lot of experience in defining and presenting abstractions that seem simple enough, and work consistently enough, that it's fairly easy to use them without really understanding them very deeply -- but the consistency (especially) lets understanding at a relatively superficial level seem like it's much deeper than it really is, because the external appearance of how they work is quite consistent with a fairly simple mental model (at least in most cases).

I suspect WinRT will be pretty much more of the same -- if you insist on trying to figure out all the details of how everything really works, you'll probably never get much of anything done. Microsoft has enough programmers working on it, that they can create (and hide) internal complexity a lot faster than almost any one person can hope to comprehend it. At the same time, if you're accustomed to working with .NET, not much will change -- it'll work consistently enough with a fairly simple model that you'll be able to treat that model as if it was how things really worked (even though it'll usually vary from partially to almost completely incorrect, and there will be a lot more happening behind the scenes than most programmers realize or want to think about).

Title: WinRT: How usable will it be?


问:
Coding guidelines for seamless merging
I am looking for coding guidelines developers should follow while writing C#/ASPX/SQL code, so that merging into other branches is smooth if not seamless.</p>

答:
Provided you're team is working on the trunk rather than doing feature branches.  Martin Fowler will tell you they're bad in this article

Ensure that:

everyone uses the same set of standards, especially if they're set in the IDE so that it does the formatting for them.

the commits are done regularly so that merging happens often so the merges are small.
developers are following solid principles (classes and methods are small) so developers are not working on top of each other.

the team communicates so major renamings, moving of packages, etc can happen when everyone knows about it.

Then you shouldn't have too much pain in merging.

ContentLicense: CC BY-SA 3.0

Title: Coding guidelines for seamless merging


问:
Is writing software in the absence of requirements a skill to possess or a situation I should avoid?
I find that some software developers are very adept at this, and often times are praised for their ability to deliver a working concept with abstract requirements. Frankly, this drives me crazy, and I don't like "making it up" as I go. I used to think this was problematic, but I've started to sense a shift, and I'm wondering if I need to adjust my thought (and programming) process when given very little direction. Should I begin to acquire this ability as a skill, or stick to the idea that requirement's gathering and business rules are the first priority?</p>

答:
Steve Jobs believed that customers cannot describe exactly what they want the future products to look like, so it is your job to deliver them. So, unless you deliver custom software all the time, forget formal specs and start by creating prototypes and letting the customers play with them and tell you what they think. You have got to put the right person doing the prototyping, and they need to have help. I say this from experience - I am the prototyping monkey who loves creating intuitive interfaces and I teamed up with someone in product who understands what the clients want and can explain things on paper or using Excel.

Neither of us are geniuses, but we think alike - you can almost say we have got chemistry and have had a huge impact on which things are being built and how. Now, only a mid-to-large team can afford to have a prototyper and a non-coder who develops product exclusively, but it is well worth it. Prototyping is the cheapest stage in the software development, so it only makes sense to get the UI and the apparent behavior right. I have not read Code Complete but I think there is something like that written in that book.

Specs are nice to have, but they are never perfect. There exists a theorem about that. You cannot prove that the spec is complete and you cannot prove that the tool has no bugs or that it will halt :)

Yet, software companies do ship software all the time despite these imperfections in the process. The spec will never be perfect. The spec is also UNNATURAL and outdated. A spec to a prototype is like logarithm table is to a single graph - a spec is essentially a boring brochure meant to be printed whereas you could interact with a tool / graph instead. Check out http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html for inspiration.

Now, spec is good if you must have a contract to cover your ass. But a spec should still come after a prototype, not before. It is your job to figure out how to make prototypes cheap.


答:
Take the "If it ain't broke, don't fix it" mantra even further - if it is broke, fixing it will cost the time to fix and the time to fix the merge conflict.  Most of the time you will get lucky, and not have a merge conflict. The rest of the time, you will want to be really sure the pain was worth it. </p>

<p>i.e. If you don't like the formatting, learn to live with it. Don't make changes that are not material to the feature that you are working on. </p>

Title: Coding guidelines for seamless merging

Body: I am looking for coding guidelines developers should follow while writing C#/ASPX/SQL code, so that merging into other branches is smooth if not seamless.</p>

Body:
Take the "If it ain't broke, don't fix it" mantra even further - if it is broke, fixing it will cost the time to fix and the time to fix the merge conflict.  Most of the time you will get lucky, and not have a merge conflict. The rest of the time, you will want to be really sure the pain was worth it.

i.e. If you don't like the formatting, learn to live with it. Don't make changes that are not material to the feature that you are working on.


问:
I feel unprepared to start my first job out of college... how can I improve?
I just graduated from university with a degree in Computer Science/Engineering and was fortunate enough to land a job working in the pharmaceutical industry as a developer. My title is System Developer I, which will require the following skills:

0-3 years development experience with C# .NET and SQL Server
Experience writing T-SQL and stored procedures
XML
Javascript

I learned of the company at a job fair and was not aware that I would need those skills for the job until after they wanted to set up an interview with me. The interview consisted of talking about my background, an almost-too-simple logic test, and a couple SQL questions that anyone with any experience should be able to answer. I was honest with them and indicated that I had absolutely no experience with SQL Server, .NET, XML, or Javascript, but they offered me the position anyway. Of course, I accepted it, but I am now extremely worried that my skills will not be up to snuff.

I fully realize from reading lots of Coding Horror, Stack Overflow, and The Daily WTF that a degree in Comp Sci in no way prepares me to be a software developer; I further realize that I will be a monumental noob in the presence of people who have been doing this for years. I feel like the only thing that makes up for my lack of development experience and programming knowledge are my social skills, innate writing ability, and humility (at least compared with some of my co-graduates who fancied themselves to be the next Steve Jobs... barf) You will never find me being the prima donna constantly complaining about the system, the language, etc... I just want to do my job like I'm told, work 9 - 5, and go home with my paycheck feeling like I'm competent. If that requires home-study, I'm more than willing because I do love programming and computer science.

So far, I've familiarized myself a bit on using SQL Server Management Studio, gave myself a refresher on basic SQL, and started learning more about C# and .NET using Introducing Visual C# 2010 by Adam Freeman from Apress. Can anyone recommend anything else I can do in the meantime to:

A. Chill the ** out and enjoy my new job without worrying so much about getting canned for incompetence

B. Improve my understanding of design patterns and OOP

C. Get the low-down on writing T-SQL in the most efficient way possible

Thanks everyone.

答:
Make your working standards clear

If you undercut their time expectations, by doing overtime, they might get into the habit of depending on your unpaid time.

Don't do overtime unless you really can't make the deadline, overtime means something is wrong with your time management, or the deadline was unrealistic in the first place.

Understand the Platform on your own, as much as possible

learn and understand the technology they use, quickly. be as self-reliant on this part, since most of the .net documentation exists on msdn

if there are parts of the platform, which are proprietary and written by internal developers, see if you can gain access to the documentation.

If there isn't any documentation (bad-sign), then ask the developers specific questions first (things they can answer quickly)

Once you have a slight understanding of the platform's architecture, you can setup a specific time for the developers to explain the platform to you, so you can get a better understanding.

Then ask if you can spend time writing some of the documentation, if there isn't any time for you to write documentation (another bad-sign), write it down for yourself anyway.

Don't ever lower your own standards

this is more for the people joining smaller consulting firms, or smaller development teams.

where the senior developers have lost their passion for writing quality and robust code; and just want to get things working in the shortest amount of time.

if you find yourself making great compromise to the quality of your code, due to "this is just how we do it"

Clearly identify why its wrong, how to fix it, and how it will affect other things (deadline, downstream effects, etc)

if your seniors know its wrong, but still do it, its time to leave.

Find what you like, and focus on it

I myself only have about 2 years of professional experience, when I started I didn't really know what I liked working on (back-end architecture, business rules and logic, or front-end user experience, or a little bit of everything)

Eventually I figured that I really enjoyed thinking about how a user interacts and works with the application, and how I could make their lives easier when using the application.

Probably the most enjoyable part of my work, is knowing that I've made the user's life, just a little bit easier.


答:
It's more a matter of proper SCM usage than coding style. However, a few coding style specific guidelines should be followed:

Avoid long lines, especially lines that do more than one thing (and are thus more likely to contain more than one edit)

Avoid overly long blocks (functions, classes, nested blocks, etc.)

And SCM-usage wise:

Pick a good SCM. The world's most popular one (Subversion) is, unfortunately, not a good one.

Branch liberally (this is why you need a good SCM: bad ones make branching and merging unnecessarily hard).

Commit often. If your commit touches more than one implementation step, you're doing it wrong.

Pull and catch-up-merge often. The later you integrate other people's changes into your own line of development, the more confused the SCM will be.

If you feel you have to reindent, reformat, or refactor, do it in a separate commit and mark it as such.

Never put anything under source control that can be derived from something else - this means no binaries, no generated code, no build intermediates, etc.

As far as SQL scripts go, opinions differ, but IMO, an SQL script, once committed and pushed, should never be touched again (unless it is buggy to the point that it doesn't execute at all). Also, set up a procedure that makes sure everyone runs the right scripts, and never runs them twice. Keeping a list of scripts already executed in the database, and a list of all scripts to be run in source control, is a simple yet effective way, especially because the to-be-run list can be branched and merged like any other source file.

Title: Coding guidelines for seamless merging


问:
New application development - Use existing database or create a new one?
A Client has a huge Windows Application running on a Database. This client wants you to develop an "Express" version of this application, including only, let's say, 20% of its features. This Express version must be a Web Application, opened on the WWW. You have 2 choices:

Use the same Database to develop the web application

Create a new database to the web application, including only the necessary tables and objects and use some synchronization mechanism to keep the databases up to date.

The client prefers the 2nd option, because:

Security: If they have a separated Database for the web app, they will not "expose" the huge Windows App Database on the internet.

Performance: The windows application has some huge process that they run at night and "lock" the database for a couple of minutes. So, creating a separated DB would ensure better performance to the web application.

I prefer the 1st option, because:

Integrity: If we have different databases, we won't be able to create Foreign Keys between them.

Avoid Sync: If we have different databases, we would have to create a synchronization mechanism, which is very prone to failures.

Maintenance: Maintenance will be easier if we have only one database. No change will need to be replicated.

Can you help me decide which way to follow, and why?

答:
If I got you right, the goal is to have one pool of consistent data for both the client application and the web application. Easiest solution is obviously one DB, and as you wrote, a two-DB approach needs a sync mechanism. But let's for a moment think about two-database approach to see what you did not mention in your list:

instead of creating a DB with a different schema, one could create a second DB with the same schema, a copy of all the data, and use the builtin replication mechanism of the MS SQL server. This way, the synchronisation gets much easier and less error prone.

integrity / foreign keys: if you use replication, this won't be a problem: all the data to be referenced is available in both databases

availability and network speed: that is the key thing when thinking about one db versus two. Two databases can be hosted at different sites, with different networks attached.When one server is down (or locked because of some batch process), the other one can still work.

So I recommend to think mainly about the last thing: do you need an increased availability provided by a two database solution? Or shall those two databases always be kept on the same site, perhaps on the same server? Then the "one database" solution is probably the better solution.


问:
Data Structures usage and motivational aspects
For long student life I was always wondering why there are so many of them yet there seems to be lack of usage at all in many of them. The opinion didn't really change when I got a job.

We have brilliant books on what they are and their complexities, but I never encounter resources which would actually give a good hint of practical usage. I perfectly understand that I have to look at problem , analyse required operations,  look for data structure that does them efficiently. However in practice I never do that, not because of human laziness syndrome, but because when it comes to work I acknowledge time priority over self-development.

Over time I thought that when I would be better developer I will automatically use more of them -  that didn't happen at all or maybe I just didn't. Then I found that the colleagues usually in the same plate as me - knowing more or less some three of data structures and being totally happy about it and refusing to discuss this matter further with me, coming back to conversations about 'cool new languages' 'libraries that do jobs for you' and the joy to work under scrumban etc.

I am stuck with ArrayLists, Arrays and SortedMap , which no matter what I do always suffice or either I tweak them to be capable of fulfilling my task. Yes, it might be inefficient but do we really have to care if Intel increases performance over years no matter if we improve our skills? Does new Xeon or IBM machines really care what we use? What if I like build things, but I am not particularly excited whether it is n log(n) or just n? Over twenty years the processing power increased enormously, which gives us freedom of not being critical about which one to use? On top of that new more optimized languages appear which support multiple cores more efficiently.

To be more specific: I would like to find motivational material on complex real areas/cases of possible effective usages of data structures. I would be really grateful if you would provide relevant resources. There is similar question ,but in the end the links again mostly describe or do dumb example(vehicles, students or holy grail quest - yes, very relevant) them and people keep referring to the "scenario decides the data structure to use". I want to know these complex scenarios to be able to identify similarities to my scenario and then use them. The complex scenarios where it really matters and not necessarily of quantitive nature. It seems that data structures only concern is efficiency and nothing else? There seems to be no particular convenience for developer in use one over another.

(only when I found scientific resources on why exactly simple carbohydrates are evil I stopped eating sugar and candies completely replacing it with less harmful fruits - I hope you can see the analogy)

答:
I think you should try mobile or embedded development. Then you will know how using an unnecessary heap object like ArrayList over a primitive array differs in terms of performance and battery time.

Your usage of data structures should change with your development domain. How can you be so ignorant if you are developing a critical real time system or back-end of a web application where that module will be under heavy load?

If you even don't use them, knowing them does not hurt. In your case, if you are developing a front-end application where performance expectations are low, you shouldn't think about using an ArrayList or creating a new data structure which will increase your performance by %20.


答:
Some quick points:

When it comes to data structures, their performance characteristics (and modes of usage) are pretty much all that set them apart.  It makes sense to describe them on this level, and to let developers choose from them accordingly.  Listing possible practical use cases may be illustrative, but always incomplete (with a lot of guessing as to the exact usage scenarios).

Yes, hardware has become a lot more powerful, to the point that for most day-to-day applications programming, it is quite difficult to mess up (although we've all seen some notable exceptions, I'm sure).  The scenarios where the difference between O(N) and O(log(N)) make a huge difference are not commonly encountered in everyday scenarios anymore.  If you ever have to work with really large amounts of data, then you certainly will care.

Remember that most software development is "optimised" for testability, readability, maintainability, etc.  Premature optimisation is seen as an evil in professional software development.  It's a lot easier to work with a hash table that everyone on my team knows than it is for me to write one.  Just as importantly, it takes me no time to use what's already there, and I can be pretty sure it's bug free.

On a side note, I think what you are experiencing is our industry becoming ever more mature in the classical sense.  Your everyday programmer is not there to reinvent the most efficient algorithms, just like car mechanics are not supposed to come up with a new gearbox for your car (yep, it's bad analogy time).  We're still way off from that level of maturity, of course, but it's no surprise if your average "mechanic" is surprised that they aren't using all those theories they learnt at university.  However, if you are the guy at the factory designing the gearbox, you certainly will care if whether it's O(N) or O(log(N)).

Title: Data Structures usage and motivational aspects

Body:
For long student life I was always wondering why there are so many of them yet there seems to be lack of usage at all in many of them. The opinion didn't really change when I got a job.

We have brilliant books on what they are and their complexities, but I never encounter resources which would actually give a good hint of practical usage. I perfectly understand that I have to look at problem , analyse required operations,  look for data structure that does them efficiently. However in practice I never do that, not because of human laziness syndrome, but because when it comes to work I acknowledge time priority over self-development.

Over time I thought that when I would be better developer I will automatically use more of them -  that didn't happen at all or maybe I just didn't. Then I found that the colleagues usually in the same plate as me - knowing more or less some three of data structures and being totally happy about it and refusing to discuss this matter further with me, coming back to conversations about 'cool new languages' 'libraries that do jobs for you' and the joy to work under scrumban etc.

I am stuck with ArrayLists, Arrays and SortedMap , which no matter what I do always suffice or either I tweak them to be capable of fulfilling my task. Yes, it might be inefficient but do we really have to care if Intel increases performance over years no matter if we improve our skills? Does new Xeon or IBM machines really care what we use? What if I like build things, but I am not particularly excited whether it is n log(n) or just n? Over twenty years the processing power increased enormously, which gives us freedom of not being critical about which one to use? On top of that new more optimized languages appear which support multiple cores more efficiently.

To be more specific: I would like to find motivational material on complex real areas/cases of possible effective usages of data structures. I would be really grateful if you would provide relevant resources. There is similar question ,but in the end the links again mostly describe or do dumb example(vehicles, students or holy grail quest - yes, very relevant) them and people keep referring to the "scenario decides the data structure to use". I want to know these complex scenarios to be able to identify similarities to my scenario and then use them. The complex scenarios where it really matters and not necessarily of quantitive nature. It seems that data structures only concern is efficiency and nothing else? There seems to be no particular convenience for developer in use one over another.

(only when I found scientific resources on why exactly simple carbohydrates are evil I stopped eating sugar and candies completely replacing it with less harmful fruits - I hope you can see the analogy)


答:
I was honest with them and indicated that I had absolutely no
  experience with SQL Server, .NET, XML, or Javascript, but they offered
  me the position anyway.

In that case, don't worry about it. They know you don't have experience with these things, so they'll probably provide some training or at least give you some time to come up to speed.

I fully realize from reading lots of Coding Horror, Stack Overflow,
  and The Daily WTF that a degree in Comp Sci in no way prepares me to
  be a software developer...

Don't let that scare you. It sounds like you understand that there's a lot that you don't know, so you're ahead of the game. It's a much bigger problem when a clueless someone thinks they know what they're doing -- they don't want to listen or learn because they think they already know it all. It sounds like you'll be happy and relieved when someone sits down to show you the ropes.

Title: I feel unprepared to start my first job out of college... how can I improve?

Body:
I just graduated from university with a degree in Computer Science/Engineering and was fortunate enough to land a job working in the pharmaceutical industry as a developer. My title is System Developer I, which will require the following skills:

0-3 years development experience with C# .NET and SQL Server
Experience writing T-SQL and stored procedures
XML
Javascript

I learned of the company at a job fair and was not aware that I would need those skills for the job until after they wanted to set up an interview with me. The interview consisted of talking about my background, an almost-too-simple logic test, and a couple SQL questions that anyone with any experience should be able to answer. I was honest with them and indicated that I had absolutely no experience with SQL Server, .NET, XML, or Javascript, but they offered me the position anyway. Of course, I accepted it, but I am now extremely worried that my skills will not be up to snuff.

I fully realize from reading lots of Coding Horror, Stack Overflow, and The Daily WTF that a degree in Comp Sci in no way prepares me to be a software developer; I further realize that I will be a monumental noob in the presence of people who have been doing this for years. I feel like the only thing that makes up for my lack of development experience and programming knowledge are my social skills, innate writing ability, and humility (at least compared with some of my co-graduates who fancied themselves to be the next Steve Jobs... barf) You will never find me being the prima donna constantly complaining about the system, the language, etc... I just want to do my job like I'm told, work 9 - 5, and go home with my paycheck feeling like I'm competent. If that requires home-study, I'm more than willing because I do love programming and computer science.

So far, I've familiarized myself a bit on using SQL Server Management Studio, gave myself a refresher on basic SQL, and started learning more about C# and .NET using Introducing Visual C# 2010 by Adam Freeman from Apress. Can anyone recommend anything else I can do in the meantime to:

A. Chill the ** out and enjoy my new job without worrying so much about getting canned for incompetence

B. Improve my understanding of design patterns and OOP

C. Get the low-down on writing T-SQL in the most efficient way possible

Thanks everyone.


答:
so that merging into other branches is smooth if not seamless.

I don't think coding guidelines per se will be very helpful, but some best practices in using your chosen version control tools will help:

Avoid having two people modify the same section of code at the same time. That's not always easy or possible, especially on larger teams, but multiple simultaneous modifications of the same code is what creates merge conflicts.

In furtherance of the previous point, merge your work as soon as is practical. Don't wait a week to merge if you're done now -- you want to keep the window during which someone else might modify the same code that you worked on as short as you reasonably can.

Learn to use your tools effectively. Merge conflicts will happen, and merging will seem a lot more "seamless" if you know how to resolve them. It'll help if you create some toy projects and create conflicts on purpose. Do you know how to resolve a tree conflict? Can you roll back to a previous version? Can you merge changes between branches?

Coordinate. If two people do have to work on overlapping sections of code, have them coordinate with each other. If they know what they're doing, they can share changes with each other during their work so that there are no surprises at merge time.

Title: Coding guidelines for seamless merging


问:
When to do code reviews when doing continuous integration?
We are trying to switch to a continuous integration environment but are not sure when to do code reviews. From what I've read of continuous integration, we should be attempting to check in code as often as multiple times a day.  I assume, this even means for features that are not yet complete.

So the question is, when do we do the code reviews?

We can't do it before we check in the code, because that would slow down the process where we will not be able to do daily checkins, let alone multiple checkins per day.

Also, if the code we are checking in merely compiles but is not feature complete, doing a code review then is pointless, as most code reviews are best done as the feature is finalized.  Does this mean we should do code reviews when a feature is completed, but that unreviewed code will get into the repository?

答:
First, we should clarify the concept of "continuous integration". In traditional developing methods, continuous integration means we can integrate and build our source code repository everyday, which will avoid the pitfalls of "integration hell". The code reviews are always between the period of Coding and Unit testing. We must guarantee the code merging to the branch can compile with no errors. There seldom has the situation that parts of the feature merges to the branch because it is difficult to handle the coherence of interface and compile errors.

Continuous Integration is popular in the Extreme Programming process. Test-driven development adds Pair programming, which is actual part of a code review process, making continuous integration easy to implement. Extreme Programming itself is a continuous code reviewing and integration process. The code reviews exist in everywhere.

In some open source communities, the code reviews are executed just before the code merging to the branch. It is always the most experienced people in this team to do the code reviews and decide whether the code can merge to the main branch. In this way, the period of Continuous Integration is a little bit longer but the code quality is a little bit better.

Return to the question. There has not standard answer for when to do code reviews, and it depends on your original development process and the actual implementation of your continuous integration.

OwnerDisplayName: SpecialEd


问:
Stuck due to "knowing too much"
Note more discussion at http://news.ycombinator.com/item?id=4037794

I have a relatively simple development task, but every time I try to attack it, I end up spiraling in deep thoughts - how could it extending the future, what are the 2nd generation clients going to need, how does it affect "non functional" aspects (e.g. Performance, authorization...), how would it best to architect to allow change...

I remember myself a while ago, younger and, perhaps, more eager. The "me" I was then wouldn't have given a thought about all that - he would've gone ahead and wrote something, then rewrote it, then rewrote it again (and again...). The "me" today is more hesitant, more careful.

I find it much easier today to sit and plan and instruct other people on how to do things than to actually go ahead and do them myself - not because I don't like to code - the opposite, I love to! - but because every time I sit at the keyboard, I end up in that same annoying place.

Is this wrong? Is this a natural evolution, or did I drive myself into a rut?

Fair disclosure - in the past I was a developer, today my job title is a "system architect". Good luck figuring what it means - but that's the title.

Wow. I honestly didn't expect this question to generate that many responses. I'll try to sum it up.

Reasons:

Analysis paralysis / Over engineering / gold plating / (any other "too much thinking up-front can hurt you").

Too much experience for the given task.

Not focusing on what's important.

Not enough experience (and realizing that).

Solutions (not matched to reasons):

Testing first.

Start coding (+ for fun)

One to throw away (+ one API to throw away).

Set time constraints.

Strip away the fluff, stay with the stuff.

Make flexible code (kinda opposite to "one to throw away", no?).

Thanks to everyone - I think the major benefit here was to realize that I'm not alone in this experience. I have, actually, already started coding and some of the too-big things have fallen off, naturally.

Since this question is closed, I'll accept the answer with most votes as of today. When/if it changes - I'll try to follow.

答: Practise coding. Come up with exercises or find them online, and try to finish them correctly as quickly as possible. When you get your speed up, add considerations like maintainability and performance. You'll realize that it's refreshing to code stuff that won't go into production and it might help you get out of your fear of coding.</p>

Title: Stuck due to "knowing too much"


答:
Do coding in your spare time, the way you did 10 years ago, with less worries and just the fun.

Become a team manager and direct younger developers - who are now in the same mental state as you were 10 years ago.

Title: Stuck due to "knowing too much"

Body:
Note more discussion at http://news.ycombinator.com/item?id=4037794

I have a relatively simple development task, but every time I try to attack it, I end up spiraling in deep thoughts - how could it extending the future, what are the 2nd generation clients going to need, how does it affect "non functional" aspects (e.g. Performance, authorization...), how would it best to architect to allow change...

I remember myself a while ago, younger and, perhaps, more eager. The "me" I was then wouldn't have given a thought about all that - he would've gone ahead and wrote something, then rewrote it, then rewrote it again (and again...). The "me" today is more hesitant, more careful.

I find it much easier today to sit and plan and instruct other people on how to do things than to actually go ahead and do them myself - not because I don't like to code - the opposite, I love to! - but because every time I sit at the keyboard, I end up in that same annoying place.

Is this wrong? Is this a natural evolution, or did I drive myself into a rut?

Fair disclosure - in the past I was a developer, today my job title is a "system architect". Good luck figuring what it means - but that's the title.

Wow. I honestly didn't expect this question to generate that many responses. I'll try to sum it up.

Reasons:

Analysis paralysis / Over engineering / gold plating / (any other "too much thinking up-front can hurt you").

Too much experience for the given task.

Not focusing on what's important.

Not enough experience (and realizing that).

Solutions (not matched to reasons):

Testing first.

Start coding (+ for fun)

One to throw away (+ one API to throw away).

Set time constraints.

Strip away the fluff, stay with the stuff.

Make flexible code (kinda opposite to "one to throw away", no?).

Thanks to everyone - I think the major benefit here was to realize that I'm not alone in this experience. I have, actually, already started coding and some of the too-big things have fallen off, naturally.

Since this question is closed, I'll accept the answer with most votes as of today. When/if it changes - I'll try to follow.


答:
Requirements are the steps in the journey, a vision is the direction

For many applications a highly detailed technical specification is just too much up front since a quick discussion could render their carefully typeset document useless. Instead, start with a vision. If everyone understands the overall picture then the requirements can get filled in along the way through discussions.

As a developer you must learn to use these discussions to trawl for requirements. This means asking the customer leading questions that get them thinking about how their decision today fits into the overall vision. The earlier these more detailed discussions take place then the quicker the overall vision will solidify into a coherent design.

You should keep track of the outcome of these discussions in some kind of issue tracker so that others can comment on them if they missed the original discussion. And so that you have a record you, or other members of your team, can refer back to should you need clarification.

So, learn to code against the vision, but be ready to trawl for those requirements when the time comes.

Title: Is writing software in the absence of requirements a skill to possess or a situation I should avoid?

Body: I find that some software developers are very adept at this, and often times are praised for their ability to deliver a working concept with abstract requirements. Frankly, this drives me crazy, and I don't like "making it up" as I go. I used to think this was problematic, but I've started to sense a shift, and I'm wondering if I need to adjust my thought (and programming) process when given very little direction. Should I begin to acquire this ability as a skill, or stick to the idea that requirement's gathering and business rules are the first priority?</p>


答: When I've got stuck in situations like these, I've found that it helps to stubbornly imagine that I'm an end-user using the hypothetical program to get something reasonably trivial done. Then I try to focus on what the programmatical entry-points needed to support those actions would be, trying as much as possible to ignore other aspects of the system. From here it's often possible to construct a (small!) 'whish list' of features of the finished system, and write some unrealistic code that starts to implement that. After that exercise, I usually am started, and the rest of the system starts to become more clear. It's all about the entry point - and the entry point of the vast majority of all software is the end-users initial actions with a program.

Title: Stuck due to "knowing too much"


答:
I think it is a syndrom that the tasks you are doing are too easy for you.

A few years ago the chanllenge for you was to write a code that will accomplish the given task. This was what fully engaged your mind. Now, your mind (your experience etc.) is working more effective and doing the same task requires only a part of the energy that was previously needed. This is why you're ending in that spirale of deep thoughts. Your mind is defending itself from routine and is fighting for challenge.

I think you should consider changing your work. Maybe you should learn a new programming language.

Title: Stuck due to "knowing too much"


答:
You Are Not Ruthless Enough

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

Edit: The point of this article is paying attention to small details when developing, but I have found it helps to approach any simple or complex task with a ruthless attitude in order to find the single most efficient solution possible and just get the job done.

Title: Stuck due to "knowing too much"


答: When you're young, you don't see risk (possibly the reason junior politicians are scary), but as you get older, your bad experiences paralyze you at every opportunity (possibly the reason senior politicians are stagnant). Adopt an Occam's razor guided approach - go for the solution that has the fewest needs and then evolve from there.</p>

Title: Stuck due to "knowing too much"


答:
It is not possible to write a program without requirements. Even the 'Hello World' has the requirement: to produce output. So, I think you're asking about formal requirements, in form of some big stack of something UML-like. And regarding those, I've met 2 kinds of people:

1) People that need formal requirements. They need to be exactly told what to do, and at best how to do it. They love the sentences like The procedure A taking the argument B will output C, and they hate those: The program should make the work of our deparment more effective. They are usually corporate animals.

2) People who are the oposite to 1. They hate to be told what to do and how to do, they love to be told what should be achieved. They like to talk to the client, analyse what they say and then develop their own solution. They are usually freelancers and don't fit good to corporation.

I won't say which of those is better. Both have their pros and contras. They are simple adequate for the other conditions.


答:
This is simply paralysis by analysis.  It happens to many people in many fields.
You can break through it.

The answer is - JUST GET ON WITH IT ;-)

I post on a fitness forum and many many times people post about different routines, trying to find the exact perfect one for them.  So we tell them just start training and work it as you go along.  You want to get stronger, do some strenght exercises and then tweak things as you go.

When you have a large program and your brain works overtime - just code for the simple cases first.  Initially the program must run, then must take input etc.

Your challenge is to leave things easy to update and refactor later on but the code MUST be no more complicated than it needs to be to do the task at hand.

Remember in the future it is fine to refactor code to meet new priorities.  You cannot predict all of them up front so do not try.

Code for the next task - ONLY.
Code is simply and well so it is easy to refactor if you need to.
Make sure the program works.
Repeat.

Title: Stuck due to "knowing too much"


答:
I had the same problem 15 years ago. I wanted to write perfect, reusable, universal, .... code that made the solution much more complicated than necessary. Today I see this as Gold plating. What helped me a lot was an advice of a colleague:

if you have an idea what might improve functionality, make it more univeral, ... write this idea down into a seperate textfile "ideas.txt" but don't implement this now.

keep on implementing the urgent tasks.

after six months, review your "ideas.txt" and analyse which of these changes would really have benefitted the project.

Title: Stuck due to "knowing too much"


问:
Review quality of code
I have been asked to quality review two code bases. I've never done anything like that, and need advice on how to perform it and report it.

Background

There are two providers of code, one in VB and one in C (ISO 9899:1999 (C99)). These two programs do not work so well together, and of course, the two suppliers blames  each other. I will therefore as a independent person review both codes, on a comprehensive level review the quality of the codes to find out where it is most likely that the problem lies. I will not try to find problems, but simply review the quality and how simple it is to manage and understand the code.

Edit:
I have yet not received much information about what the problem consists of. I've just been told that I will examine the code in terms of quality. Not so much more. I do not know the background to why they took this decision.

答:
For me your question sounds like a "blaming game".

Is the issue really the code quality of the two code providers or more about the interface description between the two?

Written requirements or unit tests might help to settle this kind of problems in the future:

What are valid inputs/outputs what are not?

How should error management be done?

OwnerDisplayName: magol

Title: Review quality of code


问:
get weighted random item
I have, for example, this table

```
+-----------------+
| fruit  | weight |
+-----------------+
| apple  |   4    |
| orange |   2    |
| lemon  |   1    |
+-----------------+
```

I need to return a random fruit. But apple should be picked 4 times as frequent as Lemon and 2 times as frequent as orange.

In more general case it should be f(weight) times frequently.

What is a good general algorithm to implement this behavior?

Or maybe there are some ready gems on Ruby? :)

PS

I've implemented current algorithm in Ruby https://github.com/fl00r/pickup

答:
The conceptually simplest solution would be to create a list where each element occurs as many times as its weight, so

```<code>fruits = [apple, apple, apple, apple, orange, orange, lemon]
</code>```

Then use whatever functions you have at your disposal to pick a random element from that list (e.g. generate a random index within the proper range). This is of course not very memory efficient and requires integer weights.

Another, slightly more complicated approach would look like this:

Calculate the cumulative sums of weights:

```<code>intervals = [4, 6, 7]
</code>```

Where an index of below 4 represents an apple, 4 to below 6 an orange and 6 to below 7 a lemon.

Generate a random number n in the range of 0 to sum(weights).

Go through the list of cumulative sums from start to finish to find the first item whose cumulative sum is above n. The corresponding fruit is your result.

This approach requires more complicated code than the first, but less memory and computation and supports floating-point weights.

For either algorithm, the setup-step can be done once for an arbitrary number of random selections.

ContentLicense: CC BY-SA 4.0

Title: get weighted random item

Body:
The conceptually simplest solution would be to create a list where each element occurs as many times as its weight, so

fruits = [apple, apple, apple, apple, orange, orange, lemon]

Then use whatever functions you have at your disposal to pick a random element from that list (e.g. generate a random index within the proper range). This is of course not very memory efficient and requires integer weights.

Another, slightly more complicated approach would look like this:

Calculate the cumulative sums of weights:

intervals = [4, 6, 7]

Where an index of below 4 represents an apple, 4 to below 6 an orange and 6 to below 7 a lemon.

Generate a random number n in the range of 0 to sum(weights).

Go through the list of cumulative sums from start to finish to find the first item whose cumulative sum is above n. The corresponding fruit is your result.

This approach requires more complicated code than the first, but less memory and computation and supports floating-point weights.

For either algorithm, the setup-step can be done once for an arbitrary number of random selections.


答:
I think learning datastructures for most of us developpers is not that important any more.

you have either an (un-)ordered list or a kind of dictionary (hashmap).

Instead you implement against a list interface and your code doesn-t care if the list is an array list, a linked list or b+-tree. All that counts is the interface api.

Of course there are rare situations where performance/memoryconsumtion really matters. Only then you need to know about the different implementations and their performance/memory characteristics. I assume that these cases are less than 0.1% of all.

At scool you learn algorithms and datastructures by implementing them. On the job you finde these in ready made libraries and just uses them.


答:
Sounds to me like what you really need is some instrumentation to sit between the to applications and spy on what messages they are passing each other (depending on how they communicate this may be something you need to write your self or something already available like wireshark)

once you can see the messages you can decide who is right and who is wrong compared to the interface spec. of course its possible the spec is ambiguous in which case you either need to fix the spec (and possibly incur more costs for changes to one of the components) or convert your spy tool into a compatibility shim

reviewing their code is certainly not without its merits but it will not help you trace interface issues (especially if the spec is wrong)

Title: Review quality of code

Body:
I have been asked to quality review two code bases. I've never done anything like that, and need advice on how to perform it and report it.

Background

There are two providers of code, one in VB and one in C (ISO 9899:1999 (C99)). These two programs do not work so well together, and of course, the two suppliers blames  each other. I will therefore as a independent person review both codes, on a comprehensive level review the quality of the codes to find out where it is most likely that the problem lies. I will not try to find problems, but simply review the quality and how simple it is to manage and understand the code.

Edit:
I have yet not received much information about what the problem consists of. I've just been told that I will examine the code in terms of quality. Not so much more. I do not know the background to why they took this decision.


答:
Since you're getting "stuck" over-thinking possible end-user use-case scenarios, there is something to consider here if you're going to be publishing an API and expect that people unknown to you will utilize that API. Once an API is published, you either have to continue to support it, even though you later realize how bad your first release  is, or you have to break the code of everyone, possibly unknown to you, who has written against it thus risking alienating them for all future time.

The standard solution is to publish with the stipulation that the API might change in any way at any time until you get a sense of what it is your users need and API consumers are doing.

In that solution I think is your own solution.  Write just some little thing that does one or two things, maybe does them just OK, keeping the understanding to yourself that anything you do may change in the future.

It's not possible to get it all right, or in some cases even ANY of  it right, when you start because design is really a journey of discovery; it's the last to  emerge, not the first thing to get done.

You can't design an API right away and never have to break it to your consumers.  You get why that is. By the same token you can't write software and not have to possibly throw it all away and start over with a new approach.

I don't think you have a problem in the sense of you've accidentally evolved into something less creative, productive or desirable. I think that you have high standards which you're accidentally misapplying  to your situation-- a common mistake in thinking everyone makes.

Experience never counts against you unless you become a cynical know-it-all, done-it-all, and that really sounds like the opposite your situtation.

I have a couple images that I keep in my mind when I go big. One  is of playing with Lego. I put it together and take it apart at will. What I start out making may not be what I end up making. I am surfing and advantaging myself of the possibilities that come to my mind as I go along, often recreating my goals entirely on the spot in a flash of inspiration... that's what creativity IS.

The other image is an analogy I heard that describes doing real science. You're groping around in a dark room for a black cat which may not be there. It's unnerving only if you count yourself as a failure for not finding that  cat. There is no other way to find black cats. That's the only activity that ever locates them. Anything else is some form of already having  what you're allegedly looking for.

Title: Stuck due to "knowing too much"


答:
I fully agree with @SnOrfus that the "Create a new database to the web application" is the more expensive solution.

If this is not an argument for the customer as @mattnz suggested you may have an interim solution by refactoring parts of the solution into a common library that contains code that is necessary for both. This way you can at least reduce the maintanace nightmare.

Title: New application development - Use existing database or create a new one?

Body:
A Client has a huge Windows Application running on a Database. This client wants you to develop an "Express" version of this application, including only, let's say, 20% of its features. This Express version must be a Web Application, opened on the WWW. You have 2 choices:

Use the same Database to develop the web application

Create a new database to the web application, including only the necessary tables and objects and use some synchronization mechanism to keep the databases up to date.

The client prefers the 2nd option, because:

Security: If they have a separated Database for the web app, they will not "expose" the huge Windows App Database on the internet.

Performance: The windows application has some huge process that they run at night and "lock" the database for a couple of minutes. So, creating a separated DB would ensure better performance to the web application.

I prefer the 1st option, because:

Integrity: If we have different databases, we won't be able to create Foreign Keys between them.

Avoid Sync: If we have different databases, we would have to create a synchronization mechanism, which is very prone to failures.

Maintenance: Maintenance will be easier if we have only one database. No change will need to be replicated.

Can you help me decide which way to follow, and why?


问:
Bug fixing approach
I have been working on a database project, and I recently received a bug report for the remote execution of some queries.

Usually, you try to find out the actual cause for the bug to occur and then fix it.

But sometimes what I do when I'm fed up of doing some research (and can't find suitable information on the internet) is just change the logic, which takes me much less time compared to the other option.

Is this approach correct, or should I try to fix the original bug involving more R&D?

答:
Indeed, this would not be the correct way to go at this. In my opinion this will only raise the chance of creating new bugs or the chance of someone finding this same bug again.

Bugs should be fixed, not worked around.

Of course I'm not sure what you replaced it with. If you replaced a faulty query with a correct one you could call it a fix. If you wrote a completely different one it would be a work around if you ask me.

Better try and fix the bug to make sure it doesn't show it's head again!

Title: Bug fixing approach


答:
In my head this raises alarmbells.

Granted, I am not a database programmer. My work is not nearly as security critical for example. But when you say

But sometimes what I do is fed up of doing some research (cant find suitable information on the internet) I just change the logic which takes me much less time as compared to the other.

I get the feeling that you know yourself that the approach you're taking is most likely not the one you should be taking.

To me it seems you're treating symptoms rather than the underlying problem. And I can't say I have never done so. But experience tells me that, although it might never happen, this will usually come back to bite you in places you don't want to be bitten.

I would say that your last sentence is correct. Take the time to find and fix the original bug. You can't be sure you've fixed the issue if you haven't figured out what the issue was in the first place.

Any workaround might cosmetically solve your problem, but could as well introduce side-effects you hadn't thought of, besides possibly still leaving your system exposed to the original problem.

Title: Bug fixing approach

Body:
I have been working on a database project, and I recently received a bug report for the remote execution of some queries.

Usually, you try to find out the actual cause for the bug to occur and then fix it.

But sometimes what I do when I'm fed up of doing some research (and can't find suitable information on the internet) is just change the logic, which takes me much less time compared to the other option.

Is this approach correct, or should I try to fix the original bug involving more R&D?


答:
If you can just throw away the part of the code which contains the bug, and the software product is still functional and conform to the original requirements, then you shouldn't have written this part of the code at all in the first place.

So yes, if you can solve a bug while removing the code that you don't need, this is a good approach. You may still ask yourself why you've written the code that you don't need.

Title: Bug fixing approach


问:
Why is quicksort better than other sorting algorithms in practice?
This is a repost of a question on cs.SE by Janoma. Full credits and spoils to him or cs.SE.

In a standard algorithms course we are taught that quicksort is O(n log n) on average and O(n²) in the worst case. At the same time, other sorting algorithms are studied which are O(n log n) in the worst case (like mergesort and heapsort), and even linear time in the best case (like bubblesort) but with some additional needs of memory.

After a quick glance at some more running times it is natural to say that quicksort should not be as efficient as others.

Also, consider that students learn in basic programming courses that recursion is not really good in general because it could use too much memory, etc. Therefore (and even though this is not a real argument), this gives the idea that quicksort might not be really good because it is a recursive algorithm.

Why, then, does quicksort outperform other sorting algorithms in practice? Does it have to do with the structure of real-world data? Does it have to do with the way memory works in computers? I know that some memories are way faster than others, but I don't know if that's the real reason for this counter-intuitive performance (when compared to theoretical estimates).

答:
Quicksort is often a good choice as it is reasonably fast and reasonably quick and easy to implement.

If you are serious about sorting large amounts of data very quickly then you are probably better of with some variation on MergeSort. This can be made to take advantage of external storage, can make use of multiple threads or even processes but they are not trivial to code.


答:
Quick sort is considered to be quicker because the coefficient is smaller that any other known algorithm. There is no reason or proof for that, just no algorithm with a smaller coefficient has been found. Its true that other algorithms also have O(n log n) time, but in the real world the coefficient is important also.

Note that for small data insertion sort (the one that is considered O(n2) ) is quicker because of the nature of the mathematical functions. This depends on the specific coefficients that vary from machine to machine. (At the end, only assembly is really running.)
So sometimes a hybrid of quick sort and insertion sort is the quickest in practice I think.

Title: Why is quicksort better than other sorting algorithms in practice?

Body:
This is a repost of a question on cs.SE by Janoma. Full credits and spoils to him or cs.SE.

In a standard algorithms course we are taught that quicksort is O(n log n) on average and O(n²) in the worst case. At the same time, other sorting algorithms are studied which are O(n log n) in the worst case (like mergesort and heapsort), and even linear time in the best case (like bubblesort) but with some additional needs of memory.

After a quick glance at some more running times it is natural to say that quicksort should not be as efficient as others.

Also, consider that students learn in basic programming courses that recursion is not really good in general because it could use too much memory, etc. Therefore (and even though this is not a real argument), this gives the idea that quicksort might not be really good because it is a recursive algorithm.

Why, then, does quicksort outperform other sorting algorithms in practice? Does it have to do with the structure of real-world data? Does it have to do with the way memory works in computers? I know that some memories are way faster than others, but I don't know if that's the real reason for this counter-intuitive performance (when compared to theoretical estimates).


答:
You shouldn't center only on worst case and only on time complexity. It's more about average than worst, and it's about time and space.

Quicksort:

has an average time complexity of Θ(n log n);

can be implemented with space complexity of Θ(log n);

Also have in account that big O notation doesn't take in account any constants, but in practice it does make difference if the algorithm is few times faster. Θ(n log n) means, that algorithm executes in K n log(n), where K is constant. Quicksort is the comparison-sort algorithm with the lowest K.


答:
Quicksort does not outperform all other sorting algorithms. For example, bottom-up heap sort (Wegener 2002) outperforms quicksort for reasonable amounts of data and is also an in-place algorithm. It is also easy to implement (at least, not harder than some optimized quicksort variant).

It is just not so well-known and you don't find it in many textbooks, that may explain why it is not as popular as quicksort.


答:
You don't know too much; you don't know enough!  And you've only recently realized that.

Don't think about your design choices as something that you have to get "right", because there is no "right"--there are many "wrongs", but there are also tradeoffs (in execution speed, time to complete the coding task, extensibility, etc.).  The code you write if well-conceived will still have various strengths and weaknesses.

The goal should be to get to the point where understanding these strengths and weaknesses in the context of current and future use and maintenance is not dramatically harder than writing code in the first place.

So don't avoid deep thoughts, but remember that you need experience, not just thought, to become a master at this sort of design.  Think until you you reach a point where you are not confident of a particular choice, then implement what you hope is the best one, try it out, and learn from how it went.

Title: Stuck due to "knowing too much"


答:
Drop that "background" out of your head - it's useless for the assignment you've got.

For both programs, do the same: read the code, file by file, line by line. Anything that doesn't feel right, add it to the list of issues. Typos, duplicate or dead code, things that are hard to understand, IDE/compiler warnings, anything. Use free form comments, don't worry about the structure at this moment, just fill the list with what catches your attention.

After done with the list, review it. Re-check if your notes are correct. If you can see some sort of structure / grouping in the issues you noticed, rearrange the list to fit. Submit the list to whoever asked you about it.

At past project, my colleague has been told to review a component I was assigned to maintain, 5 or 10 K LOC if memory serves. He went over it and submitted a list of 180 items (one hundred eighty issues noticed). Week later, management gave me a full power and unlimited time to rework that component. I spent about a month, addressed all the items that guy listed. Five years of intensive use that passed after review, there were two or maybe three bugs submitted against this component.

Title: Review quality of code


问:
Why does adding more people to a late project make it later?
It's a fairly common adage that adding more programmers to a late project will make matters worse. Why is this?</p>

答:
Because no one takes the time to have a well thought out, planned, tested process for: hiring, training, developing and supervising programmers let alone brining them up to speed on a particular project.

If you are managing a team of developers, you should have several contacts right now of people you would like to hire if you have an openning. Join developer groups.

How fast can you get a brand new development machine setup and ready to go?

Have you ever tested your project documentation and specs by showing them to a developer on another project? Did they look at it and determine they could start working on the project if necessary?

How up to date is any project schedule?

Save up for a rainy day because when a project falls behind it is more like a huricane.

ContentLicense: CC BY-SA 2.5


答:
If your task is not to find the actual bugs, but as you say, simply measure the quality, then you will need a way to measure it.

In C this is quite easy, you can simply check how well the code conforms to a known coding standard. The most well-known and recognized authority is probably MISRA-C, but there is also CERT C. Either can be used, though the former is more suitable for high integrity systems and the latter for PC programming. Both standards focus on banning dangerous practice.

From such a coding standard you can pick a number of rules that should be part of the review. For example, it would make a lot of sense to include all MISRA-C rules that ban reliance on undefined behavior. As a result, you should get a number of rules which can be used as a mean to measure quality.

Then comes the actual review. You would certainly need to do it manually, but the professional way would be to also use a static analysis tool. There are plenty of them supporting MISRA-C, and some supporting CERT C. The fancier tools can also find various other bugs such as data anomalies, buffer overruns, needless complexity etc ect. They can also perform code coverage, to see if there is any code in the program that will never be executed.

As for VB, that is far harder. There is probably no widely-recognized authority you can cite, although there are perhaps coding standards you can use, maybe this one? (found it in Google, I've never used it). Microsoft would be the best authority to cite, they seem to have some vague, shallow guidelines for how to write VB, but those won't be anywhere near as professional as the C coding standards.

Title: Review quality of code


问:
Exception hierarchy design
In my company we are building a webapp containing serveral central services that we design ourselves and then specify as interfaces. I.e. the interfaces are application specific and they are then implemented with third party libraries which we may change over time. When it comes to exceptions, I have realized that the exceptions thrown by our services should be our own application-specific exceptions as opposed to implementation specific exceptions.

Now, I am wondering how our exceptions should be structured and related to each other.

First, consider a generic exception MyAppException. This exception indicates that something unexcpected went wrong and the best thing we can do is to display a message to the user saying that something went wrong and that we are working on it. The error could be that the database crashed or something similair. This exception would pretty much be thrown from all methods working with the database.

Secondly, consider an exception MyAppDuplicateException. This exception would indicate that the user tried to save something into the database that was already there. Here, we can display a much more specific error message and this exception is only thrown from the methods that inserts or updates database rows.

The application can also contain other exceptions similar to MyAppDuplicateException for other excpected error situations. Ex MyAppNotFoundException etc...

Now to my questions:

Should the other exceptions extend MyAppException? I actually see no reason for this, I have just seen it in a lot of places and wonder if there is a purpose to it. The downside of this as I see it is that a try/catch-statement does not need to care about the specific exception in this case. It can just catch the top exception and because of this it does not need to handle the specific error which was pretty much the point of having the specific exception.

If the other exceptions does not extend MyAppException, should MyAppException be a java.lang.RuntimeException? This would not require executing code to catch it, which to me sounds natural since the point of the exception is to say that something unknown happened and the executing code is not excpected to be able to handle it. The code at the entry point of the request could still have a try/catch statement that catches MyAppException and makes sure that a message is displayed to the user.

edit There is no question if the specific exceptions like MyAppDuplicateException should be checked or not, the should defenetly be checked.

答:
Sometimes you want to catch a specific type of exception (e.g. MyAppDuplicateException) and sometimes you want to catch a whole category of exceptions (e.g. MyAppException). By having MyAppDuplicateException extend MyAppException you're giving the calling code a bit more flexibility in how it deals with the different exceptions.

The best advice I've heard on this is that generally speaking you should throw a checked exception if whatever called your method obeyed its contract. It's a way of saying "here are the things that might be expected to fail". I would definitely make MyAppDuplicateException and the like checked exceptions (i.e. not RuntimeExceptions).

There's a very good article here which should help you avoid most of the common pitfalls.

Title: Exception hierarchy design


答:
Here's an algorithm (in C#) that can select random weighted element from any sequence, only iterating through it once:

public static T Random<T>(this IEnumerable<T> enumerable, Func<T, int> weightFunc)
{
    int totalWeight = 0; // this stores sum of weights of all elements before current
    T selected = default(T); // currently selected element
    foreach (var data in enumerable)
    {
        int weight = weightFunc(data); // weight of current element
        int r = Random.Next(totalWeight + weight); // random value
        if (r >= totalWeight) // probability of this is weight/(totalWeight+weight)
            selected = data; // it is the probability of discarding last selected element and selecting current one instead
        totalWeight += weight; // increase weight sum
    }

    return selected; // when iterations end, selected is some element of sequence.
}
```

This is based on the following reasoning: let's select first element of our sequence as "current result"; then, on each iteration, either keep it or discard and choose new element as current. We can calculate the probability of any given element to be selected in the end as a product of all probabilities that it wouldn't be discarded in subsequent steps, times probability that it would be selected in the first place. If you do the math, you'd see that this product simplifies to (weight of element)/(sum of all weights), which is exactly what we need!

Since this method only iterates over the input sequence once, it works even with obscenely large sequences, provided that sum of weights fits into an int (or you can choose some bigger type for this counter)

Title: get weighted random item

Body:
I have, for example, this table

```
+-----------------+
| fruit  | weight |
+-----------------+
| apple  |   4    |
| orange |   2    |
| lemon  |   1    |
+-----------------+
```

I need to return a random fruit. But apple should be picked 4 times as frequent as Lemon and 2 times as frequent as orange.

In more general case it should be f(weight) times frequently.

What is a good general algorithm to implement this behavior?

Or maybe there are some ready gems on Ruby? :)

PS

I've implemented current algorithm in Ruby https://github.com/fl00r/pickup

Body:
Here's an algorithm (in C#) that can select random weighted element from any sequence, only iterating through it once:

public static T Random<T>(this IEnumerable<T> enumerable, Func<T, int> weightFunc)
{
    int totalWeight = 0; // this stores sum of weights of all elements before current
    T selected = default(T); // currently selected element
    foreach (var data in enumerable)
    {
        int weight = weightFunc(data); // weight of current element
        int r = Random.Next(totalWeight + weight); // random value
        if (r >= totalWeight) // probability of this is weight/(totalWeight+weight)
            selected = data; // it is the probability of discarding last selected element and selecting current one instead
        totalWeight += weight; // increase weight sum
    }

    return selected; // when iterations end, selected is some element of sequence.
}

This is based on the following reasoning: let's select first element of our sequence as "current result"; then, on each iteration, either keep it or discard and choose new element as current. We can calculate the probability of any given element to be selected in the end as a product of all probabilities that it wouldn't be discarded in subsequent steps, times probability that it would be selected in the first place. If you do the math, you'd see that this product simplifies to (weight of element)/(sum of all weights), which is exactly what we need!

Since this method only iterates over the input sequence once, it works even with obscenely large sequences, provided that sum of weights fits into an int (or you can choose some bigger type for this counter)


答:
I have realized that the exceptions thrown by our services should be
  our own application-specific exceptions as opposed to implementation
  specific exceptions.

By this you mean exceptions defined by your third-party implementation? Correct?

First, consider a generic exception MyAppException. This exception indicates >that something unexcpected went wrong and the best thing we can do is to >display a message to the user saying that something went wrong and that we are >working on it. The error could be that the database crashed or something >similair. This exception would pretty much be thrown from all methods working >with the database.

If this kind of exception represents an error in your program that is not caused by bad user input but rather some problem with your code, then in Java it should be a runtime exception.

Secondly, consider an exception MyAppDuplicateException. This exception would >indicate that the user tried to save something into the database that was >already there. Here, we can display a much more specific error message and this >exception is only thrown from the methods that inserts or updates database >rows.

This is a checked exception in Java.

If the other exceptions does not extend MyAppException, should MyAppException >be a java.lang.RuntimeException?

Yes.

This would not require executing code to catch it, which to me sounds natural >since the point of the exception is to say that something unknown happened and >the executing code is not excpected to be able to handle it. The code at the >entry point of the request could still have a try/catch statement that catches >MyAppException and makes sure that a message is displayed to the user.

Yes that's right.

Title: Exception hierarchy design

Body:
In my company we are building a webapp containing serveral central services that we design ourselves and then specify as interfaces. I.e. the interfaces are application specific and they are then implemented with third party libraries which we may change over time. When it comes to exceptions, I have realized that the exceptions thrown by our services should be our own application-specific exceptions as opposed to implementation specific exceptions.

Now, I am wondering how our exceptions should be structured and related to each other.

First, consider a generic exception MyAppException. This exception indicates that something unexcpected went wrong and the best thing we can do is to display a message to the user saying that something went wrong and that we are working on it. The error could be that the database crashed or something similair. This exception would pretty much be thrown from all methods working with the database.

Secondly, consider an exception MyAppDuplicateException. This exception would indicate that the user tried to save something into the database that was already there. Here, we can display a much more specific error message and this exception is only thrown from the methods that inserts or updates database rows.

The application can also contain other exceptions similar to MyAppDuplicateException for other excpected error situations. Ex MyAppNotFoundException etc...

Now to my questions:

Should the other exceptions extend MyAppException? I actually see no reason for this, I have just seen it in a lot of places and wonder if there is a purpose to it. The downside of this as I see it is that a try/catch-statement does not need to care about the specific exception in this case. It can just catch the top exception and because of this it does not need to handle the specific error which was pretty much the point of having the specific exception.

If the other exceptions does not extend MyAppException, should MyAppException be a java.lang.RuntimeException? This would not require executing code to catch it, which to me sounds natural since the point of the exception is to say that something unknown happened and the executing code is not excpected to be able to handle it. The code at the entry point of the request could still have a try/catch statement that catches MyAppException and makes sure that a message is displayed to the user.

edit There is no question if the specific exceptions like MyAppDuplicateException should be checked or not, the should defenetly be checked.


问:
User Authentication. Database lookup vs RPC call
If we have more than one service that uses same database - is it ok to move out user authentication on separate server and use RPC calls, instead of traditional database lookup? </p>

答: Having a dedicated service for user authentication is a good evolution of your service model because it provides a layer of indirection between the database and the client services. This allows you to evolve the data model without necessarily impacting other services. Moving user entitlements (authorization) out of the database has similar benefits.</p>


问:
Versioning and client upgrade strategy for web applications
I'm writing a web app and am wondering about future upgrades and how upgrading the webapp will affect the user experience.

In particular, I was wondering how a company like Google approaches this problem. For example, I have seen several examples where a particular google app will ask the user if they want to upgrade to 'the new google docs', or similar. This is the experience I would like to provide, but I'm not sure how to go about it. If it matter, I'm writing an app that uses backbone.js and has a heavy JS client side component. I have seen several discussions talking about versioning the REST component or the WebServices component, but none that discuss the actual client-side code or backend components (of course, the backend may not matter much if it is all behind a versioned webservice)

I'm interested in how they achieve this, from an application standpoint and from a (presumably) backend DB standpoint.

So it seems like there are several issues.

Where in the web root do the versioned applications live?

How do you serve multiple versions to different users?

How do you version the backend datastore?

Since I'm using backbone, I am particularly interested in to design the router for this type of app. If the various versions live in a subdir, how do I create a proper router?

There are probably some other considerations as well. Any advice would be welcome.

答:
Using feature flags could help. Basically a feature flag tells the system whether a user should see a given piece of functionality. For example, if you just added a user settings option then you could wrap that with a feature flag to control who sees the feature. Some of the criteria a feature flag can consider include:

Global setting (allow everybody or nobody)

Specific users (allow specific beta users)

Random users (allow a percentage of users, e.g. for A/B testing)

Timestamp (allow use after the launch date or during a specific time of day)

Feature flags can compliment use of load balancing and staggered deployments. For example, if you want to go live with a feature at a precise time, you'd do a staggered deployment and then flip the switch. More generally, this allows you to change the behavior of the running site without being as dependent on how deployments are timed.


问:
Should we document stand-up meetings?
Another team in my company start to document their stand-up meetings, but I believe it is a waste of time. As far as I know, stand-up meetings are for communication not for status reporting (please, correct me if I am wrong)

So, Should we document stand-up meetings?

答:
In the last company I worked for, we used to only document grand decisions made during stand-up meetings.

As you said, stand-up meetings are for communication inside a small group of people, and it does only concern that specific group of people... anyway... sometimes... someone says something interesting that may be important and eventually can influence the way the project is made (it was often warnings about tricky bugs to take care of, or technical points very important to know). That's why we started to document ONLY the 'important for a better future' points.

I think, document stand-up meetings is smart if you are absolutely sure about the importance of the content and only if you can say it will help your team sometime in a near or distant future.

Title: Should we document stand-up meetings?


答:
There isn't (there almost can't be) an absolute answer to that - its very much an it depends...

Pragmatically, if you're doing "what did I do, what am I going to do, here are my issues" then there might well be merit, for some (those notionally in charge), in recording that so that you can check against it in the next meeting (although "working on" should also be apparent by other means) - but not particularly beyond that i.e. its a piece of information that should cease to have value once the next meeting has finished.

Additionally if there are matters/meetings arising from the standup then there is potentially value in recording those to keep track of whether the followups actually took place (although again I'm sure I'll be told that mostly this should become apparent by other means).

Formal minutes though? I'd've thought those contrary to the spirit of the thing.

Title: Should we document stand-up meetings?

Body:
Another team in my company start to document their stand-up meetings, but I believe it is a waste of time. As far as I know, stand-up meetings are for communication not for status reporting (please, correct me if I am wrong)

So, Should we document stand-up meetings?


答:
It is not possible because of security reasons to ask the web-client-user if he wishes to upgrade the web-server-app. A web app that has write access into its own program folder will make a lot of hackers happy.

On an android/iphone app you have a mobile-device-local-installed-app that can be updated locally if the user allows it.

the example with upgrade to 'the new google docs' is not software update on the server but one of two features that are both implemented on the server at the same time and the "upgrade-switch" just asks which of the two features to use.

Title: Versioning and client upgrade strategy for web applications

Body:
I'm writing a web app and am wondering about future upgrades and how upgrading the webapp will affect the user experience.

In particular, I was wondering how a company like Google approaches this problem. For example, I have seen several examples where a particular google app will ask the user if they want to upgrade to 'the new google docs', or similar. This is the experience I would like to provide, but I'm not sure how to go about it. If it matter, I'm writing an app that uses backbone.js and has a heavy JS client side component. I have seen several discussions talking about versioning the REST component or the WebServices component, but none that discuss the actual client-side code or backend components (of course, the backend may not matter much if it is all behind a versioned webservice)

I'm interested in how they achieve this, from an application standpoint and from a (presumably) backend DB standpoint.

So it seems like there are several issues.

Where in the web root do the versioned applications live?

How do you serve multiple versions to different users?

How do you version the backend datastore?

Since I'm using backbone, I am particularly interested in to design the router for this type of app. If the various versions live in a subdir, how do I create a proper router?

There are probably some other considerations as well. Any advice would be welcome.


答:
In my experience, stand-ups are a great way for getting a "heartbeat" of where the team is on the project. The ones I attend are a few minutes each, which aren't really long enough to merit documenting, but they great for getting a sense where things are along the process, and for giving me a heads-up on anything that could impact me in the immediate term.

If something particularly profound of noteworthy comes up from a stand-up meeting you should document just that and broadcast it out separately, but I wouldn't get into the habit of documenting every meeting every day.

Title: Should we document stand-up meetings?


答:
Your scrum should be:

What I've worked on

What I'm working on next

Any blockers

That's it. Quick and to the point. 5-10 mins max. Absolutely no need to document, but if anyone needs to jot something down to action, that shouldn't be an issue.

Title: Should we document stand-up meetings?


答:
Yes, this coding horror happens even for me. Getting struck with Stack Overflow.
Coding in detail for a small application.
But when it's an outsourced project, it doesn't eat much time because of time constraints.
And also working with a group of new bunch of people can get over this, I feel.</p>

Title: Stuck due to "knowing too much"


答: Treat stand-up as a casual meeting – without the expectation that statements are formal, final, etc. which will make people less likely to raise topics they're not yet comfortable with – but simply have the understanding that anything important should have the discussion continue somewhere else even if it's just a simple email to the team. Besides helping keep standup from turning into a full project meeting this also avoids excluding anyone who couldn't make it to a particular standup.</p>

Title: Should we document stand-up meetings?


问:
WinRT: How usable will it be?
WinRT: is it really about calling WIN32 (wrapped in COM (exposed as .NET)) via a proprietary extension of C++?

That looks like a lot of wrappers and layers between the developer and the actual functionality.  Does anyone trying to go with it stand a chance at profoundly understanding the ecosystem (if his last name isn't "Petzold")?

答:
Its partly what you say - it is a native API that (no doubt) does wrap much of the existing code, and that code will be part win32, part COM. As Microsoft has explicitly said its native, then it won't be wrapping any .NET code, unless that was wrapped native code anyway.

You can access it using a standard C++ system: its called WRL and is like the old ATL templates and smart pointer classes. At least it doesn't use the stupid and non-standard ^ syntax that C++/CX uses.

A selling point of WinRT is that it is a 'clean' API, and that the nasty implementation details will be hidden underneath it - so you don't have to worry about writing part win32, part COM API depending on which MS team wrote which new API. However, MS has a history of changing things, so while its nice and clean today, you should expect Microsoft to complicate it up over time.

Title: WinRT: How usable will it be?


答:
One of the benefits of Agile is that each team can determine what works best for them, and go with it.

However: should you take notes? No; in my experience, the minute a team decides to start backtracking on some of the core principles such as:

individuals and interactions over processes and tools (documented scrums that begin to be non-scrum-like)
AND

working software over comprehensive documentation (scrum minutes one day, who knows what would be next)

then that team will begin to move away from Agile and toward a more documentation-heavy and low-velocity approach to work.

In Martin Fowler's "It's Not Just Standing Up", there's nary a mention of note-taking or documenting the "minutes" of a stand-up meeting.  All you should take away from that stand-up meeting are GIFTS:

To help start the day well

To support improvement

To reinforce focus on the right things

To reinforce the sense of team

To communicate what is going on

As a mnemonic device, think of GIFTS:
  Good Start, Improvement, Focus, Team, Status

However, if someone has a blocker that you need to help him or her work through and you take a note on what they are saying, that's totally different. -- knock yourself out with that.

As a point of reference, I'm a Product Owner and am mentoring the ScrumMaster right now in my company, and of all the Agile meetings we have (scrum, sprint planning, sprint review, sprint retrospective), the only one we take official minutes of is the retrospective, because that gives the team something concrete to work toward and refer to in the next sprint (and those "minutes" are a couple sets of short bullet points).

Title: Should we document stand-up meetings?


答:
In my current company, we have 2 Scrum teams with separate standups and document them by sending a summary email at the end of each standup. It works pretty well, making important information immediately known to all the members of the other team. We don't particularly keep a history of the mails for archive purposes though.

So my advice would be :

For a single team, documenting stand ups may not be worth the time spent. The Scrum Master can just relay alerts or important information orally to whom he sees fit afterwards.

For multiple teams whose work is closely related, documenting stand ups is a way to broadcast potentially game-changing information immediately after the meeting without waiting for a Scrum of Scrums to happen.

Title: Should we document stand-up meetings?


答:
I see no problem marching away from such a meeting and firing off an email to the group as a reminder/clarifier of a significant decision that were made or actions that arose. After all, you don't want to risk forgetting or letting time fade the memory of what was discussed.

But as for formally documenting the meeting, like you might do for a more traditional meeting... well, it seems counter-intuitive. Such meetings are supposed to be lean and agile, so bogging them down with too much 'process' seems counter-productive.

Title: Should we document stand-up meetings?


问:
Is it a bad practice to store large files (10 MB) in a database?
I am currently creating a web application that allows users to store and share files, 1 MB - 10 MB in size.

It seems to me that storing the files in a database will significantly slow down database access.

Is this a valid concern? Is it better to store the files in the file system and save the file name and path in the database? Are there any best practices related to storing files when working with a database?

I am working in PHP and MySQL for this project, but is the issue the same for most environments (Ruby on Rails, PHP, .NET) and databases (MySQL, PostgreSQL).

答:
In many cases, this is a bad idea. It will bloat the database files and cause several performance issues. If you stick the blobs in a table with a large number of columns it's even worse. </p>

<p>However! Some databases, like SQL Server have a FILESTREAM column type. In this case, your data is actually stored in a separate file on the database server and only an ID to the file is saved in the table. In this case I don't see much of a reason not to keep the data in the SQL server. The files are automatically included as part of the server backup, and the database and the files are never out of sync. The problem with Tony's suggestion of storing file names, is that the database and the filesystem can get out of sync. The database will claim a file exists when it's been deleted on disk. If a process is modifying the database and then crashes, the files and the database will not match (i.e. no ACID with files outside of a database). </p>

Body:
In many cases, this is a bad idea. It will bloat the database files and cause several performance issues. If you stick the blobs in a table with a large number of columns it's even worse.

However! Some databases, like SQL Server have a FILESTREAM column type. In this case, your data is actually stored in a separate file on the database server and only an ID to the file is saved in the table. In this case I don't see much of a reason not to keep the data in the SQL server. The files are automatically included as part of the server backup, and the database and the files are never out of sync. The problem with Tony's suggestion of storing file names, is that the database and the filesystem can get out of sync. The database will claim a file exists when it's been deleted on disk. If a process is modifying the database and then crashes, the files and the database will not match (i.e. no ACID with files outside of a database).


答:
You might run into some of this problems:

Doing a SELECT * which involves the row with the large blob takes very long, even if you don't need the blob (Of course you should do a specific select, but sometimes applications are written like this)

Doing a backup can take much longer. Depending on your needs you may need to lock your tables for the time of the backup, so you may want to keep your backup time low

Restoring will also take much more time.

If you run out of space, you have to think of some way (maybe moving the whole database to a new server) to solve this problem. Storing the files on the file system you can always mount another hard drive and set soft links.

Simply looking into a file for debugging or other information is not as easy. This also includes scripts which might not have access to the database but need some information from various files.

Of course you also get some benefits:

Backing up data and file menas they are in sync

Removing the file without the database knowing is not possible

You don't have to read the file from disk but can do it in one sql statement

You can download the database, include the dump into your development environment and have all dependencies right there

Personally I don't do it as I find the cons much heavier than the pros. But as stated above it totally depends on your use case and such.

Title: Is it a bad practice to store large files (10 MB) in a database?

Body:
I am currently creating a web application that allows users to store and share files, 1 MB - 10 MB in size.

It seems to me that storing the files in a database will significantly slow down database access.

Is this a valid concern? Is it better to store the files in the file system and save the file name and path in the database? Are there any best practices related to storing files when working with a database?

I am working in PHP and MySQL for this project, but is the issue the same for most environments (Ruby on Rails, PHP, .NET) and databases (MySQL, PostgreSQL).