1.你们的项目组使用源代码管理工具了么？应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。
2.你们的项目组使用缺陷管理系统了么？应该用。ClearQuest太复杂，我的推荐是BugZilla。
3.你们的测试组还在用Word写测试用例么？不要用Word写测试用例（TestCase）。应该用一个专门的系统，可以是TestManager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。
4.你们的项目组有没有建立一个门户网站？要有一个门户网站，用来放ContactInfo、BaselinedSchedule、News等等。推荐SharepointPortalServer2003来实现，15分钟就搞定。买不起SPS2003可以用WSS(WindowsSharepointService)。
5.你们的项目组用了你能买到最好的工具么？应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是"你能买到最好的"。6.你们的程序员工作在安静的环境里么？需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。
8.你们每个人都知道出了问题应该找谁么？应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。
9.你遇到过有人说"我以为…"么？要消灭"我以为"。Neverassumeanything。
10.你们的项目组中所有的人都坐在一起么？需要。我反对VirtualTeam，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。
11.你们的进度表是否反映最新开发进展情况？应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。
12.你们的工作量是先由每个人自己估算的么？应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。
13.你们的开发人员从项目一开始就加班么？不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。
14.你们的项目计划中BufferTime是加在每个小任务后面的么？不要。BufferTime加在每个小任务后面，很容易轻易的就被消耗掉。BufferTime要整段的加在一个Milestone或者checkpoint前面。
16.登记新缺陷时，是否写清了重现步骤？要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写ReproSteps也需要。
17.写新代码前会把已知缺陷解决么？要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。
18.你们对缺陷的轻重缓急有事先的约定么？必须有定义。Severity要分1、2、3，约定好：蓝屏和DataLost算Sev1，FunctionError算Sev2，界面上的算Sev3。但这种约定可以根据产品质量现状适当进行调整。
19.你们对意见不一的缺陷有三国会议么？必须要有。要有一个明确的决策过程。这类似于CCB(ChangeControlBoard)的概念。
20.所有的缺陷都是由登记的人最后关闭的么？Bug应该由Opener关闭。Dev不能私自关闭Bug。
22.你们项目组有TeamMoraleActivity么？每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。
23.你们项目组有自己的Logo么？要有自己的Logo。至少应该有自己的Codename。
24.你们的员工有印有公司Logo的T-Shirt么？要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。
26.你们是给每个Dev开一个分支么？反对。Branch的管理以及Merge的工作量太大，而且容易出错。
27.有人长期不Check-In代码么？不可以。对大部分项目来说，最多两三天就应该Check-In。
28.在Check-In代码时都填写注释了么？要写的，至少一两句话，比如"解决了BugNo.225（给bug编号）"。如果往高处拔，这也算做"配置审计"的一部分。
29.有没有设定每天Check-In的最后期限？要的，要明确Check-InDeadline。否则会BuildBreak。
30.你们能把所有源码一下子编译成安装文件吗？要的。这是每日编译（DailyBuild）的基础。而且必须要能够做成自动的。
31.你们的项目组做每日编译么？当然要做。有三样东西是软件项目/产品开发必备的：1.bugmanagement;2.sourcecontrol;3.dailybuild。
32.你们公司有没有积累一个项目风险列表？要。RiskInventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。
33.设计越简单越好越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scopemanagement。
34.尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是"软件复用"的体现。
36.你们的项目组每个人都写DailyReport么？要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。
37.你们的项目经理会发出WeeklyReport么？要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。
39.你们项目组的会议、讨论都有记录么？会前发meetingrequest和agenda，会中有人负责主持和记录，会后有人负责发meetingminutes，这都是effectivemeeting的要点。而且，每个会议都要形成agreements和actionitems。
40.其他部门知道你们项目组在干什么么？要发一些Newsflash给整个大组织。Showyourteam'svalue。否则，当你坐在电梯里面，其他部门的人问："你们在干嘛"，你回答"ABC项目"的时候，别人全然不知，那种感觉不太好。
42.为项目组建立多个MailingGroup如果在AD+Exchange里面，就建DistributionList。比如，我会建ABCProjectCoreTeam，ABCProjectDevTeam，ABCProjectAllTesters，ABCProjectExtendedTeam等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。
43.每个人都知道哪里可以找到全部的文档么？应该每个人都知道。这叫做知识管理（KnowledgeManagement）。最方便的就是把文档放在一个集中的FileShare，更好的方法是用Sharepoint。
44.你做决定、做变化时，告诉大家原因了么？要告诉大家原因。Empowerteammember的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tellmewhy是人之常情，tellmewhy了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能accessinformation/data，而在于是不是掌握资源。
45.Stayagileandexpectchange要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expectchange。
46.你们有没有专职的软件测试人员？要有专职测试。如果人手不够，可以peertest，交换了测试。千万别自己测试自己的。
47.你们的测试有一份总的计划来规定做什么和怎么做么？这就是TestPlan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用TestPlan来回答。
48.你是先写TestCase然后再测试的么？应该如此。应该先设计再编程、先testcase再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上testcase。至于先testcase再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。
50.你们的程序员能看到测试用例么？要。让Dev看到TestCase吧。我们都是为了同一个目的走到一起来的：提高质量。
51.你们是否随便抓一些人来做易用性测试？要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳--臭的看久了也就不臭了，不方便的永久了也就习惯了。
52.你对自动测试的期望正确么？别期望太高。依我看，除了性能测试以外，还是暂时先忘掉"自动测试"吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能"矫枉必须过正"了。
53.你们的性能测试是等所有功能都开发完才做的么？不能这样。性能测试不能被归到所谓的"系统测试"阶段。早测早改正，早死早升天。
54.你注意到测试中的杀虫剂效应了么？虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。
55.你们项目组中有人能说出产品的当前整体质量情况么？要有。当老板问起这个产品目前质量如何，TestLead/Manager应该负责回答。
56.你们有单元测试么？单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了--可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。
57.你们的程序员是写完代码就扔过墙的么？大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有TestReleaseDocument的说法，程序太烂的话，测试有权踢回去。
58.你们的程序中所有的函数都有输入检查么？不要。虽然说做输入检查是writesecurecode的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。
59.产品有统一的错误处理机制和报错界面么？要有。最好能有统一的errormessage，然后每个errormessage都带一个errornumber。这样，用户可以自己根据errornumber到usermanual里面去看看错误的具体描述和可能原因，就像SQLServer的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的ApplicationBlock。
60.你们有统一的代码书写规范么？要有。CodeConvention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。
61.你们的每个人都了解项目的商业意义么？要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉teammember，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。
62.产品各部分的界面和操作习惯一致么？要这样。要让用户觉得整个程序好像是一个人写出来的那样。
63.有可以作为宣传亮点的CoolFeature么？要。这是增强团队凝聚力、信心的。而且，"一俊遮百丑"，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，coolfeature或者说亮点可以作为质量问题的一个事后弥补措施。
65.不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。
66.你们根据详细产品功能说明书做开发么？要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。
67.开始开发和测试之前每个人都仔细审阅功能设计么？要做。FunctionSpecreview是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说"你看，当初我就是反对这么设计的，现在吃苦头了吧"
68.所有人都始终想着TheWholeImage么？要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。
69.Dev工作的划分是单纯纵向或横向的么？不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个"层"都有一个Owner来Review所有人的设计和代码，保证consistency。
70.你们的程序员写程序设计说明文档么？要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。
71.你在招人面试时让他写一段程序么？要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。
2、Spring实战
3、Spring-Java/J2EEApplicationFramework
SpringFramework开发参考手册（中文版）
4、IntroducingtoSpringFramework（中文修订版）
5、SpringFramework介绍（ppt培训文档）
6、Spring中文社区
7、中国IT实验室Spring框架完全进阶专题
能跟上关键技术的发展，是你在就业市场和未来保持优势的最佳手段。你对我们列出的十门技术精通吗？哪怕是大略精通？
罗素·琼斯，执行编辑2002年12月11日
我不知道你的具体工作是什么。如果你是某冷门领域的专家而变得不可或缺，或者你们的公司十分稳固，以你现有的技术就足以安度你的职业生涯，那我不知道你是否有失业的危险。不管怎样，请你先不要急着寄出那些告诉我你们的公司对用VB3十分满意或你们除C以外永不用其它语言的信件，并保留起那些讲述.NET将如何把Java扫地出门、XML将如何取代关系型数据库、或你怎样能用汇编语言或C写任何软件而任何其它开发工具都不重要的信件。
现在，想象一下如果你像很多受裁员和公司倒闭影响的同行一样失去了工作，那将会怎样。如果你突然需要搬往它处该怎么办？如果你的公司突然做了技术转向又怎么办？
在目前的就业市场，经理们是根据当前和未来的开发需要招聘雇员。作为开发人员，你所掌握的知识是你找工作和保住工作的关键。你要了解技术的发展方向，跟上技术的变化，这一点十分重要，即使你永远不用再找开发方面的工作。
这里是我选出的当前最重要的十大开发技术，最重要的排在前面。看完本文后，请务必加入talk.editors.devx讨论组，提出你选出的十大技术。
1.XML
XML最好的一点是既能存结构化数据也能存非结构化数据。它既能存贮和描述“规格的”(regular)表格数据，也能容纳和描述“粗糙的”(ragged)文件数据。
XHTML是现今写HTML的首选方法。因为它是形式完好（wellformed）的XML，比起古老的、通常是畸形（malformed）的HTML文件，XHTML格式的文件更容易处理。
XSLT和XSL是用于把XML文件转成其它格式的语言。可转换的格式包括：文本文件、PDF文件、HTML、以逗号为分隔符的文件，或其它XML文件。
DTD和XMLSchema描述XML文件所能包含的内容的类型，并让你“验证”XML文件内容的合理性，而不用写特殊代码以确保内容符合规则要求。
XPath和XQuery是用于从XML文件中抽取单个项目或一组项目的查询语言。XQuery扩展了XPath，因而更重要。XQuery与XML的关系正像SQL与关系数据库的关系。
SOAP是Web服务之间的一个标准通讯协议。尽管你不需要对SOAP标准一清二楚，你应该熟悉一般的schema和它的工作原理，以便能应用这门技术。
2.Web服务
Web服务是XML流行后的一个直接产物。因为你能用XML描述数据和物件，因为你能用schema确保XML文件内容的合理性，因为XML是基于文本的规范，XML为跨平台通讯标准提供了一个极其方便的基本格式。如果你还从来没碰到Web服务，你可能很快就会碰到，在未来5年内，你几乎肯定会碰到。熟悉Web服务十分重要，因为它是目前所有跨不同机器、不同语言、不同平台和不同地点的通讯协议中最简单的一个。不管你需要与否，Web服务是迈向互用性的重要一步。
XML工作组主席JohnBosak曾说XML“给Java一些事做”。实际上，Web服务让所有语言都有了一些事做。Web服务让在大型机上运行的COBOL应用软件能调用在手持设备上运行的Java应用程序、能让Javaapplet与.NET服务器交谈、能让微机软件与Web服务器无缝连接，并提供了一个相对容易的方法，让企业不光能向外界提供数据，还能提供功能，而且是一种与语言、平台和位置都独立的方法。
3.面向对象的编程
很多程序员仍认为OOP是象牙塔里的技术。但如果你想一下是什么语言在过去的10年里占主导地位，你就会理解OOP不是象牙塔里的技术。OOP从Smalltalk开始，传到C++和Pascal(Delphi)。Java使OOP大踏步地迈向主流，几年后的VB.NET和C#则完全确立了OOP的优势地位。尽管这些语言中的多数并不要求你必须会OOP，但我觉得如果你不了解OOP的基本概念也不知道如何应用这些概念，你能找到的编程工作将越来越少。
4.Java、C++、C#和VB.NET
我把这些语言列在一起，并不是建议你成为每一种语言的专家。我的理由是：学习编程最有效的方法之一是看代码，而你能看到的大量的代码很可能不是用你所喜爱的语言编写的。
在过去几年，各语言的能力越来越接近。现在，你可以用VB.NET写Windows服务、Web应用程序或命令行程序。即使你只使用一种语言，你也应该学一些其它语言，以便能看懂那些样例，并将其翻译到你所用的语言。这4种语言是基本核心，还有其它一些满足不同需要、颇具用途的语言，如FORTRAN、COBOL、APL、ADA、Perl和Lisp。
5.JavaScript
尽管名字有些相像，但Java与JavaScript并无关联。为什么一个脚本语言会如此重要呢？因为所有主流浏览器都用JavaScript。如果你需要写Web应用程序，你就有足够的理由学JavaScript。JavaScript可以用作ASP或ASP.NET的服务器语言，也可以当做用于扩展XSLT的功能语言(functionallanguage)。JavaScript是Mozilla/Netscape中用于激活基于XUL的程序接口的首选语言。JavaScript的一个变种ActionScript是FlashMX的编程语言。将来，JavaScript很可能成为新设备的编程语言，以及大型应用软件中的宏语言。
与JavaScript相对照的是VBScript。尽管Microsoft的软件对VBScript有良好的支持，但VBScript在未来的开发工作中很可能是一个糟糕的选择。就是Microsoft也倾向于用JavaScript（或Microsoft自己的变种：JScript）写客户端程序。在选择脚本语言时，请选择JavaScript。
6.正则表达式（RegularExpressions）
查寻关系数据库可以用SQL，查询XML可以用XPath和XQuery，查询纯文本文件则可以用正则表达式。例如，你可以用一个命令从一个HTML文件中查找并删除所有的注释。各种开发语言内置的一些简单的文本查询功能，如"IndexOf"函数或VB中经典的"InStr"函数或"Like"操作符，根本不能与正则表达式相提并论。现在，各种主要的开发语言都提供使用正则表达式的途径。尽管正则表达式本身既难懂更难读（是回到早期计算机时代的一种倒退），但它却是一个功能强大而且未被充分利用的工具。
7.设计模式
正像OOP通过把对象分类以简化编程一样，设计模式对一些普遍的对象之间的交互进行分类，并赋予一个恰当的名称。OOP用得越多，设计模式就越有用。一些最常用的模式的名称已经变成了软件开发领域共同使用的术语，所以要跟上信息的主流，你就要对设计模式有相当的理解。
8.FlashMX
如果你需要在客户端得到比HTML和CSS更多的图形和更强的编程功能，Flash是你的答案。用Flash编程比开发Javaapplets或写.NET代码要快得多，也容易得多。
在最新版本(MX)中，Flash不仅仅是画图和制造动画的工具，它已经成为一个编程功能强大的开发环境：能调用SOAPWeb服务，也能调用远端服务器上的ColdFusion、Java或.NET程序。Flash无处不在。它的引擎存在于世界上大多数客户端计算机，包括手持设备、置顶盒、甚至是新的书写板电脑。所以使用Flash能大大扩展你的程序的应用范围。
9.Linux/Windows
熟悉Linux。在一台旧机器或新机器上安装Linux。下载图形用户界面，在其基础上写一些程序。安装Apache，写一个Web应用程序。这个世界不再仅仅是属于Windows，这种趋势可能还会持续下去。如果你是一名中坚的Linux开发人员，那就抛弃你对Windows的憎恶，看看你能否做一些Windows编程。Windows能继续在台式电脑上称王是有其原因的，这不仅仅是因为Microsoft控制了这个市场。
没人知道你们公司会在什么时候决定从Linux转向Windows（或从Windows转向Linux），或者你想跳到一家用另一种平台的公司，或者你想出了开发一个杀手软件的好主意，所以你要争取拥有在不同操作系统上的编程经验。
10.SQL
尽管SQL不像本文讨论的其它技术那样新，而且SQL的重要性在未来10年内很可能降低，但它仍然是一项基本技能。很多开发人员还没有掌握这门技术，或掌握得不够，不足以有效率地使用它。不要依赖具有图形用户界面的SQL生成器替你做事情，你要自己手工地写查询命令，直到你熟悉基本的SQL语法为止。了解SQL不仅能帮助你日后学习XQuery，你还有可能马上发现能简化或改进目前项目的方法。
培养好奇心
你可能永远也没有必要成为这些技术的专家，而且我的选择可能根本不适合你的特殊情况，但通过培养好奇心，你将会发现你应该了解的东西。
1.8版1>修正了"对于以下列开头的地址不使用代理服务器"仍然使用代理服务器的错误。2>应广大用户的要求，导出代理时只导出IP:port，其他信息不导出。