软件开发的成功之道：探索12法则

软件开发成功12法则是指导开发团队建立高质量软件的指导原则。这些法则包括敏捷开发、持续集成、自动化测试、面向用户价值等方面的规范。通过遵循这些法则，开发团队能够更快地交付高质量的软件，减少bug数量，提高用户满意度。这些法则还体现了团队协作、沟通、技术创新等方面的要点，帮助团队更好地组织和规划软件开发过程。在当今竞争激烈的市场环境下，遵循软件开发成功12法则可以帮助团队提升竞争力，更好地满足客户需求。

下面小编跟大家分享一个简单易学的软件开发成功12法则教程，get新技能是需要行动的，喜欢的朋友赶紧收藏起来学习下吧！

本文篇幅较长，但是对于程序员来说仔细看完肯定会有收获，作者对于开发和项目治理的功力颇深，文中的许多经验办法微软沿用至今。也许读完项目治理需要很长的时间和大量金钱，但是joel的这一套衡量系统，按joel的话说：“三分钟你就可把握。你可以把省下的时间去读医学院了”（注：美国的医学院可是要读死人的！）。下面我们就开始吧！

Joel 衡量法则

你们用不用源文件治理系统？

你们可以把整个系统从源码到ＣＤ映像文件一步建成吗？

你们天天白天都把从系统源码到ＣＤ映像做一遍吗？

你们有软件虫治理系统吗？

你们在写新程序之前总是把现有程序里已知的虫解决吗？

你们的产品开发日程安排是否反映最新的开发进展情况？

你们有没有软件开发的具体说明书？

你们的程序员是否工作在安静的环境里？

你们是否使用现有市场上能买到的最好的工具？

你们有没有专职的软件测试人员？

你们招人面试时是否让写一段程序？

你们是否随便抓一些人来试用你们的软件？

“Joel 衡量法则”好就好在你只需照着逐条回答以上问题，然后把所答为“是”的问题算成一分，再加起来就可以了，而不需要去算什么天天写的程序行数或程序虫的平均数等等。但咱丑话说在前面，可别用“Joel 衡量法则”去推算你的核电站治理程序是否可靠。

假如你们得了12分，那是最好，得了11分还过得去，但假如只得了10分或低于10分，你们可能就有很严重的问题了。严酷的现实是：大多数的软件开发公司只能得到2到3分。这些公司假如得不到急救可就玄了，因为像微软这样的公司从来就没有低过12分。

当然，一个公司成功与否不仅仅只取决于以上标准。比如，让一个治理绝佳的软件公司去开发一个没有人要的软件，那开发出来的软件也只能是没有人要。或反过来，一帮软件痞子以上标准一条也达不到，没准照样也能搞出一个改变世界的伟大软件。但我告诉你，假如不考虑别的因素，你只要能达到以上12条准则，你的团队就是一个可以准时交活的纪律严明的好团队。

1. 你们用不用源文件治理系统？

我用过商业化的源文件治理系统，我也用过免费的系统，比如CVS，告诉你吧，CVS挺好用。但假如你根本就没有用源文件治理系统，那你就是累死了也没法让你的程序员出活：他们没法知道别人在改动什么源文件，写错了的源文件也没法恢复。

使用源文件治理系统还有一大好处是，由于每一位程序员都把源文件从源文件治理系统里提出来放到自己的硬盘里，几乎不会发生丢失源文件的事，最起码我还没听说过。

2. 你们可以把整个系统从源码到CD映像文件一步建成吗？

这句话问的问题是：从你们最新的源码开始到建立起能够交出去的最后文件，你们有多少步骤要做？ 一个好的团队应该有一个批处理程序一步便可将所有的工作做完，像把源文件提取出来，跟据不同的语言版本要求（英文版，中文版），和各种编译开关（#ifdef）进行编译，联接成可执行文件，标上版本号，打包成CD映像文件或直接送到网站上去，等等等等。

假如这些步骤不是一步做完，就有可能出人为差错。而且当你很接近产品开发尾声的时侯，你可能很急于把最后几个虫解决，然后尽快地交活。假如这时候你需要做20步才能把最终文件制出来，你肯定会急得要命，然后犯一些很不该犯的错误。

正因为这个原因，我工作的前一个公司从用WISE改用InstallShield：我们必需要让我们的批处理程序完全自动化地，在夜里，被NT scheduler起动把最终文件制成，WISE不能被NT scheduler启动而InstallShield可以，我们只能把WISE扔掉。（WISE的那帮家伙向我保证他们的下一代产品一定支持在夜里自动运行.)

3. 你们天天白天都把从系统源码到CD映像做一遍吗？

你们有没有碰到过这样的事情：一个程序员不小心把有毛病的源码放进源文件治理系统，结果造成最终文件没法制成。比如，他建立了一个新源文件但忘了把它放进源文件治理系统，然后他高兴奋兴锁机回家了，因为在他的机器上整个编译得很好。可是别人却因为这没法工作下去了，也只好闷闷地回家了。

这种造成最终文件没法制成的情况很糟糕，但却很常见。假如天天在白天就把最终文件制一遍的话，就可以让这种事不造成太大危害。在一个大的团队里，要想保证有毛病的源码及时得到纠正，最好天天下午（比如午餐时）制一下最终文件。午餐前，每个人都尽可能地把改动的源文件放到源文件治理系统里，午餐后，大家回来，假如最终文件已经制成了，好！这时大家再从源文件治理系统里取出最新的源文件接着干活。假如最终文件制作出错，出错者马上修正，而别人还可接着用原有的没问题的源程序干活。

在我以前曾干过的微软Excel开发组里，我们有一条规定：谁造成最终文件制作出错，谁就得被罚去负责监视以后的最终文件制作过程，直到下一位造成最终文件制作出错的人来接任他。这样做不仅可以督促大家少造成最终文件制作出错，而且可以让每个人都有机会去了解最终文件制作过程。

假如想更多了解这个话题，可以读我的另一篇文章 Daily Builds are Your Friend.

4. 你们有软件虫治理系统吗？

不论你有任何借口，只要你写程序，哪怕只是一个人的小组，假如你没有一个系统化的治理软件虫的工具，你写的程序的质量一定高不了。许多程序员觉得自己可以记得自己的软件虫。没门！我从来记不住超过2到3个软件虫。而且第二天早上起床后忙着去买这买那，好不轻易记住的软件虫早忘掉了。你绝对需要一个系统来管住你的那些虫。