个人开发web应用，从需求设计，界面设计，数据库设计，API设计等，好的开发流程是怎么样的？ 第1页

正在整理这个问题的答案，写的比较多，不知道有没有人可以从头到尾的看完。

项目开发，单人开发和一个团队开发类似，不过是更简单，省略了沟通协作人员安排调度的问题。所以从团队开发讲整个项目的完整流程，个人的自然也清楚了。

第一部分是写这个答案的引言，省略去了。从第二部分开始，先说项目开发过程中团队人员的分工协作。

二 人员安排

毕业至今的大部分项目都是独立完成，虽然也有和其他同事协作的时候，但自认为对团队协作的了解和认知都还有所欠缺。很清楚团队协作的重要性，但尚未有很好的机会在相对成熟的团队中锻炼实践。

先抛开软件开发团队中人员的具体安排不讲，单纯的看软件开发工作的分工。在上面设想的开发架构中，宏观上可将一个项目划分为前端、程序、数据库三个模块。由此可推导出团队中需要的成员：美工、程序员和项目经理。

认为理想的软件开发团队由四个专业技能过硬的成员组成：一个美工，熟悉UI的设计并具备将效果图转换成前端页面的能力，也就是得同时精通PhotoShop、HTML、CSS、jQuery等前端知识；一个程序员，熟练掌握代码的编写重构；一个项目经理，具备需求分析的能力、数据库设计维护的能力、架构设计的能力、程序编写的能力、前端样式脚本编写的能力，最重要的是对业务流程有精准的把握；一个部门经理，和前三位不一样，部门经理只具备领导能力即可，他是兼职，不需要把全部时间投入到团队中。

大部分中小型项目可以由这样的四人团队完成，可如果项目较大，已经大大超出了四个人可完成的工作量，可以再加一个前端开发人员。也就是说两个前端开发者，一个负责UI设计，做出完整的效果图，这个人的设计功底应该比较强；一个负责将效果图转换成页面，并完成样式、脚本等的编写，这个人对前端样式脚本的掌握应该比较熟练。同时程序员的数量也可以增加，可以根据业务将软件划分成不同的功能模块，按照功能模块进行工作量上的划分，交给不同的程序员完成。也可以根据程序架构进行工作量上的划分，实体由谁来负责、接口由谁来负责、应用层由谁来负责、业务逻辑层由谁来负责、数据访问层由谁来负责，等。无论项目如何庞大，这个项目的整体设计师只能有一位，那就是项目经理，负责UI的设计者，最好也只有一位，这样可以确保整个项目设计的完整性、协调性。

也没有更大规模项目的开发经验，如果成员质量可靠的话，四个人的开发团队足以应付大部分Web业务系统的开发。一直主张，在可能的情况下，团队中的成员质量应该越高越好，而团队中的成员数量则应该越少越好。因为四人以上的团队，沟通成本会随着人员数量的增长指数增长，工作效率也会随着人员数量的增长指数下降。

团队成员中沟通的问题稍后介绍，先来讲下团队各成员的工作重心。项目经理负责数据库的详细设计、程序架构和前端的宏观设计，把控全局且必须参与到具体的开发工作中。项目经理是整个团队成员中工作量最大的一位，必须是全职，在一个项目完工之前，他不应该去做与这个项目无关的任何其它工作。部门经理主要负责跟踪项目开发进程，督促项目经理和团队的工作，并满足项目经理调用公司各种资源的需求。部门经理可以定期组织会议听取项目经理和团队针对项目的工作汇报，也可以提出自己的部分意见，但对于项目的开发实现没有任何的决定权。部门经理的责任最大，但日常工作量并不多，因为他无需涉及具体的项目开发工作。

对项目的最终展现有决定权的只能有两个人，一个是客户，一个是项目经理。客户是第一位的，提出需求；项目经理是第二位的，决定此需求的实现方式。除此之外，不应该有其它任何人干涉项目的具体工作。尤其是管理者，比如这里的部门经理。部门经理必须要跟踪并督促项目的进展，但万万不要干涉具体的项目开发设计。

负责整体设计的人一定要参与到开发工作中，谁设计的谁就要参与到具体开发中，不懂开发不想开发开发不了就不要参与设计。有些懂技术的管理者喜欢自己设计项目，然后交由下面的人去实现自己的设计，这种看似没有问题的分工方式实际上是最致命的。管理者喜欢这样做，是想让这个项目按自己的理念完成，让这个项目处于自己的掌控之中，但同时，具体的开发工作又是非常繁琐耗费精力的，这部分工作全交给下面的员工去做，自己坐享其成。这样分工的问题在哪里呢？坦白的讲，很多管理者对技术的掌握、对业务的了解远不如基层员工，由他来负责设计，设计本身可能就是有问题的。更坏的情况是，不负责整个项目的整体设计，整体设计由项目经理来做，但关键性的业务，非要自己来设计。项目经理、程序员在去实现这样的设计时，会遇到很多问题，有的是在开发过程中就做不下去了，有的勉强开发出来，却给后期的扩展维护更改埋下了巨大隐患，一个失败的项目也就这么出来了。

在法律术语中有“谁主张谁举证”的说法，在软件开发中也应该有一条类似的术语，“谁设计谁开发”。你设计却让别人去开发同你主张却让别人举证一样荒唐。“谁设计谁开发”可以有效避免上面提到的问题，如果项目设计者知道由自己去参与实现自己的设计，那他在设计时就会慎重许多。如果他自己开发都无法实现自己的设计，那别人又能如何呢？这样责任就会归咎到根源上。如果真的形成这样一条铁律，或许就不会有人去轻易的干涉设计工作，因为成本太高、代价太大。

之所以花这么多时间讲管理者、设计者、开发者之间的分工，是因为过去经手的诸多项目中有不少都是毁在了管理者的干涉上。但是，人员分工方案和“谁设计谁开发”原则只是一种理想的情况，现实的工作中，怕很难能做到这点。团队之间需要一个相互角逐的过程，每个人都在往里面施加自己的影响力，最终胜出的那个人才可能有最终的话语权。有人的地方就会有江湖，有江湖的地方就会有争斗。

曾多次向同事讲过《人月神话》中提到的巴比伦塔的故事，上帝为了阻止人们建造巴比伦塔而创造了不同的语言，使人与人之间无法沟通，最终导致此工程的失败。团队协作中最核心的问题就是沟通。适时的进行定期的、不定期的会议对团队人员之间的相互磨合至关重要。《动物世界》中有记录，狼群即便是在非守猎的闲暇时间也会定期组织聚会，增进感情、明确组织中的成员地位。人也应该是一样的。

人与人间的沟通效率直接决定着整个团队的工作效率。在上面提到的对软件开发团队的成员划分中，项目经理对数据库、程序、架构的设计要和程序员对接，项目经理对界面、前端的设计要和美工、前端开发者对接，项目经理对全局的设计、比如前端脚本和后端程序的互调要和所有人对接。UI设计者要和将UI转换成具体页面并编写相应脚本的前端人员对接。前端人员要和程序员进行对接。项目经理是所有沟通渠道的枢纽，责任重大。

人不是机器，都会有情绪，有好恶，这种好恶情绪会导致团队各成员之间互相合得来或合不来，这是致命的。在团队，应该杜绝个人情绪，抛开喜怒哀乐只就事论事就工作论工作。为了保证沟通渠道的畅通，定期的会议是必须的，项目开发过程中，也可根据实际情况增加临时会议。团队初建之时，为了增进相互了解，定期的会议应该是相对频繁的。团队成型之后，定期的会议可以适当（是适当）减少，而着重于增加沟通效率。既然都相互熟悉了，那就把沟通成本降到最低。除了会议，也可以尝试进行其它的团体活动，比如适时的户外活动、定时聚餐等等，以增进相互了解。团队的形成，终需要时间的磨合，而如何把这个磨合时间降到最底，团队带头人的责任最大。在团队中，个人能量的大小不是最重要的，重要的是整个团队能量的大小。成然，团队中每个成员的质量在一定程度上决定着整个团队的质量，可如果每个成员仅仅在技术上优秀，互相之间却不沟通协调、甚至在工作上为一己之私勾心斗角，那这个团队永远不会是一个成功的团队。团队中的每个成员都应该拥有大局观念、团结意识，这才是第一位的。

锻炼团队最有效的方式和锻炼个人的一样，还是实战，如果不考虑人员变动，三个项目过去，团队自然可以成型。

认为理想的WEB应用程序开发框架是自己先前设想的那种，前端、程序、数据库之间互相分离，以上关于团队成员的划分安排即是在这种开发框架下设定。如果不是这种开发模式，比如用了服务器控件、比如用的是其它编程语言、比如不支持多数据库，甚至是非WEB应用项目的开发，团队成员划分方案大致类似。

三 了解需求

虽然在本文档中对软件开发的环节逐个分别进行讨论，但这并不是说各个环节之间是完全隔离的。正如下面的图中所绘，了解需求、需求分析、文档设计等环节之间都是有交集的，而非孤立的。在了解需求的时候项目经理的脑海中其实已经开始进行需求分析、项目设计了，在需求分析的时候项目经理的脑海中也已经开始进行项目设计了，文档的整理也都是在这些环节中逐步先成型于脑海，最后将其表述在WORD文档中。

在第二次世界大战中，美国陆军兵器修理部首创5W2H分析法，又叫七何分析法，这对于决策和执行性的活动措施非常有帮助，也有助于弥补考虑问题的疏漏，此分析法非常适用于软件开发前的需求了解、确认、分析。2H，How to do、How much实际就是就是对需求进行分析的过程，这个会在下个章节中介绍。5W，What、Who、Why、Where、When才是了解需求时要向目标对象确认的问题，是本模块要介绍的内容。

在软件需求了解过程中，对要思考的5W问题进行了新的排序。

步骤（1）做什么（What）？

第一个要搞明白的，这是什么？要实现什么功能？必须要实现的功能有哪些？不确定是否要实现的功能有哪些？核心的功能有哪些？是WEB应用系统还是桌面应用程序？是注重处理业务实现还是注重信息展示还是两者兼有？对于数据库有没有特别的要求？有没有什么规范、有的话是什么？

初次了解，就应该用草纸给出一个大致的列表，列出开发要实现的核心功能。What是5W的核心，尽可能详细的弄明白自己将要开发的是什么样的软件非常重要。不过，也别期望经过些简短沟通分析就能把所有细节确定下来，完整需求的确认是贯穿好多个环节的。

以往的项目中，甚至有到开发阶段才发现自己对需求的理解有误。设计都已经完了，都已经开始开发了，出现这样的问题自然会非常麻烦，但也应该有相应的解决措施。也正因为如此，在了解需求时才不得不仔细，尽可能的和项目负责人多会面多沟通以搞清楚这个What。

步骤（2） 谁（who）？

项目的需求来自于谁（哪里）？项目的使用者是谁？项目的沟通协调人是谁？项目的检验者是谁？项目的主负责人是谁？

就曾遇到过的情况，项目的开发需求一般来自于四种目标对象：

A、客户。这是最常见的情况，因为单位的客户有某一方面的具体需要，才要做这个项目。只要客户那边负责项目沟通协调的是个明白人，后面一切都好办。而且就过去遇到的情况，协调人一般都是基层员工或基层员工的小领导，对现实的需求也都比较清楚，这样自己的工作做起来还是比较容易的。

B、自己。这是特殊情况，比如提到的权限管理系统，是因为自己的兴趣，觉得有必要做个什么项目。自己想要的东西，当然自己最清楚了，这本来是了解需求的最简单情况，但因为自己想要的总是太过完美，总是想开发一个尽乎完美的产品，所以其实这个才是最难的。

C、市场。更多的像是在说互联网产品，既然是来自于市场，那就面临着诸多的不确定性。你的使用者都是泛泛的用户，没有非常明确的需求。只能是自己通过可能的渠道去了解，并参考网络中已有的资源，来大致确定一种需求，再进行开发。如果项目经理的能力足够，又没有来自领导层的不靠谱干预，这个也是有可能开发出实用性产品的，不过，不容易。

D、领导。公司的领导层凭空想要这么一个东西，比如别的公司有病理心电，我们没有，你们做一个。这还不是最麻烦的，更麻烦的是凭空想象这么一个产品还在凭空规定一种技术，要求必须这样这样开发，要求必须按他的想法来做。曾经说过，见过的同行中60%以上的人不识货，见过的客户中80%以上的人不识货，见过的领导中100%的人不识货，真的不是夸张，所以这是四种情况中最麻烦的一种。也可能是被糊涂的领导折磨过敏了，总之，以后如再遇到这种情况，一定做好心理准备，如果发现领导是自己见过的糊涂的那种，尽可能的想办法把活推给别人。

并不是做互联网产品出身，所以对第三种情况不敢妄谈，但并不认为自己对互联网产品的了解就不如企业内部应用系统。也一直希望手里的系统都能像互联网产品一样易用稳定，这是自己追求的产品目标。

项目的使用者肯定不是唯一的，结合上面的What，应该弄明白会有哪几类使用者，每类使用者之间可使用的功能有什么区别，每类使用者的人数大致有多少，哪一类是系统的主要用户，这对于设计阶段划分系统角色非常重要。

因为自己的工作，项目开发需求大都来自于A情况，也就是实实在在的客户。这种情况，项目最终的成败不仅仅是由产品的好坏来决定。项目最终能否顺利验收，说白了，也就是项目校验者、主负责人的一句话。 所以应提前弄清楚项目的协调人、校验者、主负责人，这对于后期工作也是至关重要的。

步骤（3）何地（where）？

开发完成的项目最终要部署在什么地方？环境是内网还是外网？什么操作系统什么数据库什么环境可变动否？确定的还是不确定的？

比如现在开发的远程医学平台，在每个省份每个客户那里的部署环境都不大一样，尤其是网络环境。有的是要部署在内网，有的是要部署在外网，有的是要求内外网都可以访问。虽然最终的网络环境对开发工作影响并不大，但还是提前知道有点心理准备为好。操作系统一般都是Windows的，数据库一般是Oracle和 SQLServe，这些要求一般都是由开发者来提，不过也有客户为了跟他们内部的系统保持一致直接要求必须用什么库。

对于不确定的部署环境，开发者只能提前做好多个准备，不过这个问题不大。了解清楚Where，主要是为后期项目的部署做好准备。

步骤（4）何时（when）？

目标对象要求多长时间完成工作？自己初步估计需要多长时间可以开发完成？目标对象的可承受时间下限是什么？

目标对象可能是客户、自己、市场、领导。对于客户，他们当然是要求愈快愈好，其实大部分情况他们自己也说不清楚具体的时间，只是希望今天提出要求，明天就能出来，这当然是不可能的。要了解的是他们能承受的上限，开发时间千万不要越过这个上限。

可以在计划上对项目进行分期，一期实现核心的功能，先上线运行，后面再逐步完善。想一次性完美实现所有的需求，不但时间不允许，怕开发人员的能力也是不够的。

先出来这么一样产品，让客户先用着，后面再一点点完善。说的直白点，就是敏捷开发、频繁迭代，这也是好多领导多次要求的开发方式，但其实这样做的问题非常多，而且这种方式非常不适合项目的目标对象是客户的情况。

先期的产品定然有瑕疵，匆忙上线只会让客户对这个产品各种不满意，而且客户一但看到这个产品，那怕明知它是先期的，也会提出各种各样的更改要求。这样，忙于应付客户更改要求的开发人员哪里还有时间继续未完成的开发工作？所以前期应尽可能的和目标对象角逐，把时间拖到最长，以尽可能多的完成这个产品，完成的差不多时再拿给用户看。后期的产品已经很完善了，如果功能、效果图又都在前期做过详细确认，这时客户的更改要求应该会相应少些，既便很多，不涉及根本功能的变更，开发者要做的工作也就相对容易了。

目标对象是领导和市场的处理方式类似，如果目标对象是自己，开发工作一般都只能抽业余时间，也应该有非常明确的时间底线才好，不能总是拖着。所有的工作，抛开时间来谈都没有任何意义。

在这里整理软件开发的完整流程，就是想将项目周期压缩到最低。因为目标对象的耐性不是无限的，可以尽量拖着以把产品做到最好，但拖的时间越长，自己面临的各方压力就会越大，如果达到临界值，项目也就报废了。这种情况也是出现过很多次的，不能不引起警觉。

步骤（5）为什么（why）？

Why应该是贯穿在前四个W中的，每得到一个W的答案，都应该多问一句，这样做的目的是什么？为什么要这样做？不这样做不行吗？用另外一种做法行不行？Why提供了一个更好更深入了解需求的机会。

从项目启动开始，手里边就应该有一支铅笔、一个钻笔刀、几张白纸，以便随时把自己的思路记录下来。和目标对象沟通了解需求时应该注意积累一些小的技巧。在会面时近可能的用手机进行录音，以方便自己后期查对。备好纸笔，对关键性问题进行记录。见面时注意把控整体的交流氛围并注意一些沟通技巧，如果是相对正式的会谈大家应该提前互相预约一下，让双方都有些准备，自己要提前准备好要问的问题。首次见面，应该互留下联系方式，以方便后面随时沟通。如果能深入到前线，和目标对象天天照面，那就更好了，可以随时对需求了解确认，这样就很少出问题了。还有，如果可能的话，让目标对象提供一些和项目相关的书面材料，表格、文档、手册、宣传材料。不管有用没用，先搜集过来再说。

无论准备的有多充分，也不能祈求一次简单的会面、一次简单的沟通就能把所有的需求了解清楚。你能理解的清楚，目标对象却未必能一次就把自己想要的说清楚，有时甚至会遗忘掉关键部分。沟通、了解、分析、确认是一个循环的过程，就像上面的流程图中所绘，跟客户的沟通确认是贯穿整个开发前的阶段的，甚至会延续到开发之中、开发之后。

了解需求之后，可以落实的是，初步的沟通笔记、录音资料，目标标对象提供的相关文档资料，脑海中本项目的早期零散琐碎片段。

四 需求分析

对需求进行分析的过程，就是将早期进行需求了解时搜集到的资料、脑海中的零散碎片进行整理的过程，最终以文档的形式将需求具体化下来。

需求分析时，首先将手里面掌握的零碎的资料做下整理，把用户提到的要求再梳理一下，用草纸做下大致的记录。然后考虑前面提到的2H的问题。

步骤（6） 怎样（How）？

实现这样的需求应该怎样做？有没有技术难点、可否实现？业务流程应该是怎样的？数据库如何设计？总的架构如何设计？框架如何设计？前端如何设计？能安排给谁来做各模块？目前的需求有哪些模糊的部分需要再次确认？

考虑How的问题，并不是说现在就要给出一个详细的实施方案，而是说要对目前掌握到的这个初步需求进行分析，发现其中的实施难点、需求模糊点。对于难点，考虑下其可否解决、成本如何；对于模糊点，标记出来后面再次确认。

步骤（7）多少（How much）？

这个项目的繁杂度如何？做的话时间成本、人力成本是多少？项目的收益是多少、对单位对自己对现在对将来有什么益处？对单位来讲有没有市场？对个人来讲能不能锻炼自己巩固提升自己的位置、还是仅仅徒增麻烦？

抛开时间来讲，所有的工作都没有任何意义。抛开成本来讲，工作更是没有意义。这里的成本，主要是开发中涉及的人月的问题，需要多少人多少时间。项目的收益，先从个人来讲，再从公司来讲，对于自己和公司都没有任何好处的项目，尽可能的不要接手。

对手中得到的书面资料及用户的录音资料进行分析整理，把核心部分条理化，确认的和模糊的分别标记。和目标对象保持沟通，把模糊的部分清晰化。

早期的需求分析，我们至少要得出下面四个问题的的初步答案。

第一个，初步整理后的需求确认书。在对了解需求时的资料进行梳理后，整理出一份前期的需求确认书。至少要把核心需求列清晰，以文档的形式具体化下来，并和客户保持非正式沟通、确认。这样的沟通确认应该是多次的、循环的，以对这个确认书进行多次的完善，逐步的将其具体化。

第二个，可行性研究。对这个初步的需求确认书进行可行性研究，用户的要求是否可以实现。如果不可以，为什么？难点在哪里？如果可以，难度系数如何？从个人来讲、从单位来讲付出收益间是正值还是负值？在你看来，结合你当前的时间安排，这个到底值不值得抽出时间来开发。

第三个，业务流程。就自己了解到的用户需求，实现这些需求的业务流程是怎样的。核心业务有哪些？核心业务的流程是什么？附属业务有哪些？附属业务的流程是什么？比如要给犬只办卡、比如要进行会诊、比如要交费、比如要统计、比如要管理网站展示信息、比如要进行权限管理，等等，大致的流程是怎样的？这些要和用户确认清楚。更详细的流程，会在设计阶段具体化下来，这里必须得出初步的流程。

第四个，开发成本。如果说这个项目可以开发，值得开发，业务流程也理得差不多了，那需要多少人、具体到是谁？需要多少时间、最少要多少时间、最长要多少时间？你个人以及公司能否持续投入这样的时间和人力来做这项工作？

早期分析之后，即便得到的结论是不值得开发，或者说要耗费的成本很多、公司可能无法投入这些成本，个人恐怕也没有最终的决定权。项目是否要开发，只能说明自己的意见，会和最上面的领导层或者商务部门间进行角逐，但拍板的还是大BOSS。如果说非要开发自己觉得不能开发的项目，或者说对自己来讲不值的项目，这时能做的只有明哲保身了，以手里的其它重要工作为借口把工作推给别人。如果推也推不掉，那就坦然接受了，全力去做这个不可改变的事情，力求把损失降到最低而把可能的收益最大化。

在整个的需求分析过程中，在早期的需求确认书出来之后，我们和目标对象的沟通应该是持续的。在最后应该和目标对象进行一次正式详细的沟通，把早期的需求确认书、早期分析之后零散的碎片进一步整理，然后再出一份正式的需求确认文档，交由用户签字确认。这份文档，就是目前可得到的最详细的需求确认文档。

在这个需求分析、对需求反复确认的过程中，脑海中其实已经开始进行项目的初步的设计才对。流程、架构、界面、数据库、程序、前端、业务、权限等等片段，已经开始出现在脑海中了。需要哪些人来做哪些模块、各模块大致要花多少时间、哪些功能哪些环节可能会出现问题、项目开发之中开发之外的阻力可能会有哪些？这些自己心里面都应该有数了，只是，仍然没有具体化下来，而这个具体化的过程，就是项目设计的过程。

五 项目设计

经过需求分析之后，我们手里已经有了一份比较明确的需求确认书，同时项目经理的脑海中也有了一个模糊的模型。项目设计环节，就是要以这份需求确认书为基本依据，和客户继续保持沟通，将脑海中的项目模型具体化下来，落实成效果图、CDM、PDM及开发文档等电子资料。

一直在讲，无论到哪个环节，都不敢说需求已经全部确认下来。人的时间和精力是有限的，但客户的需求却是无限的，哪怕仅仅针对当前的项目。我们能做的不是把客户的需求全部了解清楚，而是把了解到的需求搞明白、弄清楚，不要领会错了。对于了解的需求，可以少些，但不能出错。了解错了，设计就会出错，开发就会出错，一错全错。

项目设计阶段，要考虑的主要有七个问题。第一个是业务流程，核心业务、附属业务的流程各是什么样的；第二个是前端，包括效果图、页面、脚本、样式；第三个是数据库，把业务流层转换成表结构、表与表间的关系；第四个是开发用什么样的架构，前端、程序、数据库之间以什么方式对接；第五个是程序，既包括前端脚本的程序也包括后台的程序，程序的架构是什么样的，工厂模式、三层、还是其它；第六个是技术关键点，比如有的要用到读卡机等外接硬件、比如要放在触摸屏上、比如要有视频功能、比如要读取影像文件，这些特定的技术点如何攻破。第七个是人员安排和时间结点，具体到哪个人来做哪项工作，每项工作的时间节点是什么。

业务流程是我们在需求分析过程中就已经开始确认的，但这里要尽一步具体化。拿起手里的铅笔，把项目中的所有业务列举出来，再把每个业务的流层图画出来。反复检查这些流程图，检查业务的每一个环节，并跟客户沟通确认。当所有的流程图可以无误的表述各个业务时，我们的设计就已经成功了一半。

画流程图的过程，就是在脑海中模拟使用要开发的软件的过程，不过这时的软件还在虚无缥缈之中。在我们的脑海中虚拟出一个大工厂，但里面什么也没有，尝试着走入这座工厂去完成自己的任务——也就是客户提出的需求。为了实现需要的功能这里可能要建一个车间，然后思考车间应该有多大、应该建成什么样子的？为了完成要实现的功能这里应该放置一台机器，这台机器应该如何安放、用来制造什么物质？就这样的自由组合拼接，直到这个工厂可以实现我们提出的所有的功能、完成我们所有的业务流程。然后继续在脑海中模拟使用这个工厂，一遍又一遍的走我们的业务流程，直到确认每个环节都不再出现问题，都可以应付现实的需求。在这个过程中，业务流程中不合理部分会被修改或剔除，我们的流程会更趋于，同时我们要开发的软件也已经开始成型。

在梳理这些业务流程的时候，或者说在建工厂的时候，脑海中应该已经开始考虑界面部分如何实现了，还是用手里的铅笔，把界面的草图画出来。每个业务的每个环节，在前端如何展现？以什么样的方式最有特点、最绚丽出众、最易于人机交互？只是，项目经理也只能给出一个大致的草图，具体的设计实现还是由美工人员来完成。

外观界面是项目给人的第一印象，站在客户的角度来讲很重要。就像一座房子，你用的钢筋混泥土的质量再好，入住的人是看不到的，可如果装修的很奢华，那给人的第一印象就是这房子很高大上。程序员一般容易轻视界面的重要性，觉得这不过是一幅皮囊，只要架构足够稳定，界面再怎么绚丽，也不过是是增删改查几种动作的操作方式不同而以。这样想也无可厚非，说明项目开发团队中每个人的关注点不同，但项目经理应该有全局关念，要清楚的知道每个部分的轻重。在不同的需求、不同的客户、不同的领导、不同的时间、不同的外部状况下，各部分的轻重缓急并非是一成不变的。

数据库的设计跟界面草图的设计几乎同步，业务流程分析完毕、界面草图绘制完成，实现这些业务用到哪些表就很明确了。还是用手中的笔，把要用到的表列出来，把每张表的关键字段列出来，把表与表间的关系标注出来。从其功能上来讲，数据库就像工厂的仓库，但对软件设计者而言，数据库更像是一栋楼房的地基，直接决定着整个项目的稳定性。

有人说数据库难以设计，其实难的并不是数据库的设计，而是业务流程的梳理。再复杂的业务，只要理得清，表现在数据库中，无外乎是表与表间的三种关系：one-to-one、one-to-many以及many-to-many。更进一步的，many-to-many实际上就是两个one-to-many。对于核心业务部分尚不能明确表与表关系的，能一对多就不要一对一，能多对多就不要一对多。这样开发的复杂度会增加，却消除了后面可能的修改扩展的隐患。 “刻削之道，鼻莫如大，目莫如小。鼻大可小，小不可大也；目小可大，大不可小也。举事亦然。为其后可复者也，则事寡败矣。”说的就是这个道理。对于非核心业务也不能明确关系的，可根据实际情况，综合考量开发实现的烦琐程度及未来的可变性再做决定。

当业务流程、前端界面、数据库的草图出来，就开始考虑项目的整体架构、前端脚本和后台程序的局部架构。前端和程序之间通过何种方式互调？程序和数据库之间以什么方式对接？前端脚本的代码如何编写？后台程序如何设计可以把代码重复率降到最低、把程序的稳定性、可调整性抬到最高？

类似于表现在数据库的三种关系，再复杂的业务，表现在具体的前端、程序中，无外乎是四种动作，对数据库操作的四种动作：增（Add）、删（Delete）、改（Update）、查（Select）。更进一步的，四种动作其实就两种：读和写。查为读，增、删、改为写，读写动作的操作频繁度比例大约为十比一。

界面、页面、样式、脚本、程序、权限、数据库、整体架构、局部架构，自己想要的到底是什么样子的？发挥好高级语言封装、继承、多态的特性，使架构和程序更加的安全、易用、稳定、高扩展、高内聚、低耦合且功能更强大。在开发过程中，应该把自己遇到的暂时不好解决的问题及一闪而过的项目灵感等进行记录，然后在后面的修改扩展中或者是下一个项目的开发中，吸收优秀的处理经验、竭力避免已经出现过的问题。只有通过这样的反复积累，自己在开发细节上的处理才会日趋完善。

项目设计就是给出这个项目的实施方案。在设计的过程中，有可能会发现一些业务之外的技术难点，这些技术难点大都是之前未曾遇到过的或者是遇到过未曾完美解决的。比如前面提到的视频、影像及外接硬件等，这些技术难点如果攻不破，项目肯定也没办法完成。对于这些技术难点，应该额外分配人手专门对其研究、评估，这个也马虎不得。对于特定的项目，个人比较偏向于用开源软件解决这些特定的技术点，比如处理网页视频通信的有WebRTC、OpenMeetings，处理影像的有dcm4chee等等。不过这样做的问题也不少，如果开源产品不成熟，研究配置起来是非常耗时的，而且后期的更改维护几乎是不可能的，因为更改开源产品的源代码代价很大，相较之下反不如自己研究开发呢。对于公司通用的项目，遇到相应的技术难点，肯定是要专门分配人手研究的，比如有些公司本身就是做PACS的，那影像读取部分自然要掌握核心代码。

业务流程的草图出来后，多次检查有无遗漏环节，并和目标对象循环沟通确认。然后把根据业务流程图绘制的前端界面草图交给UI设计师，并把想法告知，由其用PhotoShop将草图具体化成效果图，这个阶段，仍然和目标对象保持沟通。效果图出来后，找目标对象确认，并再次确认需求分析、业务流程有无遗漏、有无错误。经过客户、UI设计师、项目经理之间的反复沟通、反复确认、反复修改之后，出来一份最终的效果图。然后项目经理根据效果图之后更加完整的需求把数据库草图具体化下来，用PowerDesigner设计出相应的CDM图、PDM图，并用此工具整理出完整的数据库文档。这样前端界面和数据库的设计就算完成了。后面就是考虑程序和架构的具体实现方式了。

最后应该考虑的是人员安排及开发周期问题，具体到团队中的谁、要做什么工做、时间节点是什么，可以借用Project工具，为开发任务分配资源、跟踪进度、管理预算和分析工作量。控制大型项目的第一个步骤是制定进度表，进度表由里程碑和日期组成。里程碑必须是具体的、特定的和可度量的事件，能进行清晰地定义。

过去的项目开发对时间的控制非常糟糕，大部分项目最终完成所用的时间都是自己初期预估的三倍，这到也成了自己的一条经验。客户、公司给出的时间和自己的预估相差很大，所以自己的早期预估只能是非常保守的预估，后面就是长期的和公司、客户拖延时间。还真应了那句编程名言：最初的90%的代码用去了最初90%的开发时间，余下的10%的代码用掉另外90%的开发时间。项目经理心里面应该有非常明确的人员安排计划、时间节点跟踪计划，并将其落实到文档中。开发进度应该严格依照进度表推进，并根据明确的时间节点（里程碑）进行定期的考核、演示。

在需求分析之后应该有初步的流程草图、模糊的项目模型和相对明确的需求确认书，而在项目设计之后，必须有客户确认的前端效果图、完整的数据库表结构、数据库文档及详细具体的项目开发文档。这个项目开发文档，可以是一份，也可以拆分成多份。里面有开发背景、需求分析、业务流程、技术难点、架构、程序编写方式、人员安排、时间规划等等的详细介绍。当这些文档出来之后，我们的设计也就已经明确下来。

六 项目开发

项目开发环节所触碰的都是些具体的技术细节。在过去的项目中，开发环节所用到的时间要远大于前面提到的六分之一的比例，是最费心的。也正因此，才觉得自己过去项目开发前的设计工作做的很不完善，因为在设计理想的情况下，软件开发工作只不过是一些重复性的体力劳动，根本无需再耗费心力。

理想情况终归是理想情况，真实的情况是，自己接手的很多项目从架构、程序到页面、样式、脚本，甚至是前端设计工作，都由一个人独自完成。一方面，公司未必有足够的人力安排到你所在的项目；另一方面，即便人手足够，也未必能将合适的人拧合在一起去组建成一个团队。这又涉及到公司部门管理的问题。而一个人又很难掌握开发一个完整项目所需的、各部分的诸多技术细节，擅长写后台程序的人未必擅长写样式，擅长写样式的人未必擅长写脚本，擅长样式和脚本的人却又未必擅长做UI设计，虽然你可能都会，却很难做到都擅长，这是人的局限性——我一直在试图突破的局限性。

于是，在这种更多的、非理想的情况下，在一个人有局限性的情况下，我在做需求分析设计时是不可能事无巨细的。以自己当前的水平，设计过程并不能渗透到所有的细节中。虚拟的工厂毕竟不是真实的工厂，哪怕自己对所有的技术都很精通，怕也很难在前期设计阶段虚拟出一个和最终真实工厂一样的模型。项目设计者之间设计水平的差距就体现在这个构建虚拟模型的过程中，谁的设计模型虚拟的更真实、更具体、更合理谁就更胜一筹。优秀的设计者虚拟出的设计模型肯定和最终开发出的真实项目相差不大才对，因为在合理情况下，项目的物理实现（Realization）都能依照它的设计实现（Implementation）有条不紊的推进。

因上所述，项目设计者更应当在平时扎扎实实的提高自己各方面的基本功，以尽可能的完善前期设计。而为了应付非理想情况下的前期设计，项目开发者要注意的问题也有很多，就过去的经验，项目开发过程中要关注的主要有下面几项：

第一个要注意的问题是页面、样式、脚本、程序的编写细节。我们在完成设计后动手开发，第一件要做的事情是将UI设计师出的效果图转换成HTML页面，也就是美工常说的切页。那页面是什么格式的，HTML、ASPX、JSP还是PHP？美工和负责前端脚本的开发人员、负责后台程序的程序员之间应该先达成一种共识，其实在项目设计阶段，这里应该是先规划好的：页面、脚本、后台程序间通过什么样的方式交互？虽然前台脚本和后台程序完全是两码事，在细节上差异巨大，但编写脚本和编写程序要追求的目标是相似的——脚本和程序的架构设计都应该尽可能的低重复、高扩展、易用易调取、安全，甚至是样式和页面的设计也应该追求类似的目标，比如页面、样式、脚本、程序都要求低重复性。如何保证高内聚、低耦合定律？如何在程序中抓捕所有的异常、不让任何一个异常被暴露？等等这些问题，在设计架构时就应该考虑到。自己过去的笔记中有关于架构的问题列表，应该做些整理，力求不再让这些问题出现在开发环节。不敢对样式和脚本的技术细节枉谈，但具体到后台程序的编写，思路可以参考《重构，改善既有代码设计》这本书，里面有很多代码重构的技巧、实例值得学习借鉴。在开发环节，前端和后台程序的编写是可以并行的。有些环节必须单步顺序执行，比如只有效果图出来后才能出切页，但大部分环节是可并行的。在不同的开发阶段团队人员的工作量也是不一样的，熟悉之后，可以更轻松的对团队中的人力资源进行调配。

第二个要注意的问题是代码生成器等工具的使用。要创造软件生产流水线，主要依赖的工具就是代码生成器。学会使用CodeSmith之后，代码编写的效率有了很大的提高。CodeSmith就像是软件工程中的机器人，其存在的目的就是为了消灭重复工作、消除体力劳动，让人专心于创造工作。像数据库设计工具PowerDesigner、代码审查工具StyleCop、程序帮助文档生成工具SandCastle等等都是类似的目的，学会使用这些工具，可以让自己的工作事半功倍。不过“有机械者必有机事，有机事者必有机心”，想要熟练的应用这些工具也是要费时间和心思的，而且工具并非万能的。比如CodeSmith，过去一直试图用其生成尽可能多的代码，但却总有些部分需要手动去改，这样整个项目的编码就会分成三部分：一部分是纯手工编写的，比如工具类库；一部分是混合的，既有生成的也手动更改的；一部分是纯工具生成的，比如数据库访问层。常用的工具类到是可以统一做下整理到工具类库，也不麻烦，但需要手工改动的其它部分还是要耗人力的。希望可以将这部分需要手工改动代码降到最低，让绝大部分代码可以由工具自动生成、自动修改。尽管便捷工具的问题有很多，但整体来讲，还是有不少好工具值得人花些时间去学习使用。

第三个要注意的问题是开发进度跟踪。在项目设计阶段，应该有比较明确的进度表才对，即便没有很明确的文档、没有用Project，项目经理心里也应该对时间有数，在某个时间点某个功能必须完成、在某个时间点必须出来可演示的版本、在某个时间点必须可以上线试运行、在某个时间点所有的项目开发工作必须完成。还是那句话，抛开时间来讲工作毫无意义。为了跟踪项目开发进度，确保项目的每个阶段性目标可以按时完成，定期的团队会议是不可或缺的。通过会议间的沟通协调，找出时间延后或提前的原因，以部署下一阶段的开发任务。当每个阶段性目标都可以准时完成时，整个项目的开发定然也能按时完成。

第四个要注意的问题是人与人间的沟通、协作。中小型的项目，一个人可以勉强应付的，我决不会希望去安排两个人。一个人面临再多的问题也都是项目的问题，多一个人性质就完全变了，沟通协调、意见统一、互相游说争辩，耗费的无用的时间可是要倍增的。但是，你总不可能所有的项目都独自开发，更多的情况下，还是要跟人合作的——人或多或少。良好沟通协作的前提是团队中所有的成员必须在出现不同意见时保持心平气和，团队人员和客户之间互相角逐，团队人员之间互相角逐，团队人员和团队领导者之间互相角逐，团队领导者和公司各部门、和公司领导之间也在互相角逐，费心费口舌！为了保证沟通渠道的畅通，定期的会议是必须的，团队也应该定期向领导作汇报，并时刻和用户保持沟通，时刻了解用户的想法、纠正可能的错误。一直到现在，都不敢说用户的需求已经全部确定了下来！

第五个要注意的问题是开发过程中的沼泽地。在开发过程中（设计阶段也有）经常会碰到突然毫无头绪的情况，有早期的设计也不管用，就是不知道如何走下去了。还有可能突然发现，后期一些功能的实现把整个程序结构全给打乱了，虽然跌跌撞撞完成了要实现的功能，却觉得程序超脱了自己掌控。再有就是开发遇到致命问题，如陷入泥沼一样，项目到了进退不得的地步。灵感丧失的状况经常出现，对着屏幕大脑却一片空白，这时通常会躲到空空的楼道阁间中来会踱步，才会理出些思绪。还有，自己开发的每个项目几乎都有相应的笔记，不停的写不停的分析，这些笔记一方面用于计划、安排、总结自己当前的工作，一方面帮助自己清理思路找到工作灵感。还是比较偏向于在灵感缺失时到外面去走走换个思路的办法，再就是平时应该多读些技术类的书、多关注网上的实际案例、多参与高难度项目的开发，让自己拥有源源不断的源头活水，如此，思维将永不枯竭。遇到程序结构被打乱的情况也无需担心，只要不影响大局，后面可以专门抽出时间来对相应的代码进行重构、整修。开发过程中沼泽地的出现大都还是因为早期设计考虑的不完整，如果早期对架构设计的足够灵活，增删功能都应比较自如才是，项目是不太可能出现致命问题的。应该在设计之时考虑到相应的回改机制，如果在开发过程中出现了一些不可测的问题，数据库、架构、程序能否方便灵活的做出相应调整？

第六个要注意的问题是程序文档的整理。规模较大的、比较正规的项目，程序文档不可或缺。程序文档在中小型项目中的作用并不大，因为团队间的协作开发完全可以通过直接查看源程序及程序注释来降低互相对接时出现的麻烦。Java中有javadoc命令，用于生成自己API文档的，.NET平台下有工具SandCastle。用工具生成就很简单了，所以不论具体作用有多少，最好出一份程序文档，哪怕仅仅是为了做做表面工作、提供给项目验收者查看。这里着重要说的是接口文档，如果按自己设想的架构，前端和后台程序间通过ajax调用WebServcie接口进行交互，那这个接口文档是必须的。而且，打算在新架构中将这些交互接口做成通用的，不仅提供给自己的项目前端使用，还可以将其开放给外部平台，如此，接口文档更是不可或缺。最好有个测试用的接口平台，比如在XX医院时见到的那种，可以方便的在平台上对接口进行测试，这对外部接口调用者来说是非常方便的。只是不知道，他们用的什么技术做成的那个平台。

上面提到的几点有些在前面章节已经做过介绍，比如时间规划、进度控制、人员协作等，这些工作本应在开发之前就已经规划好。但是，正如上面所述，很多情况下，需求分析、设计并不能做到理想中的完整、详细、具体，所以开发阶段还是要关注很多细节。开发前的分析设计对项目实际的开发工作有着决定性的影响，应劳记这一点，务必在真正动手开发前做好充分的准备。设计是思，开发是行，务必要三思而后行。如果问题都到开发阶段才被暴露出来，有些就会非常麻烦了。

七 项目测试

从接触技术至今，从未系统学习整理过软件测试相关的理论知识，也从未读过一本和项目测试相关的书籍。我的技术经验、思路大都来自于实实在在的开发实践，而在自己所接触过的项目中，测试又都是非常简略的一环，没有理论中的那般重要。为什么说“理论中的那般重要”，是因为在所了解到的项目开发理论中，几乎所有人都在讲测试环节是最重要的一部分，也是最耗时、最需要耐心的。

为了整理这一章节的内容，从网络上搜索了一些软件测试相关的文章，却并未看出多少端倪，不过，软件测试工程里几个重要的概念已经弄明白。下面先把这几个重要概念的介绍摘录到这里，这部分大都采摘于这个网址：

。后面，会再介绍一下自己在实际开发中遇到的一些测试相关问题，并整理下自己的所思、所悟。

软件测试从测试方式上分为黑盒测试和白盒测试，从测试范围上可分为单元测试、集成测试、系统测试、验收测试 。黑盒测试、白盒测试、单元测试是开发人员分在不同的开发阶段要做的事情；黑盒测试、集成测试、系统测试是测试人员在测试周期内级层做的工作；验收测试一般是在用户方做的工作。

黑盒测试：不考虑程序内部结构和逻辑结构，主要是用来测试系统的功能是否满足需求规格说明书。 一般会有一个输入值，一个输出值，和期望值做比较。黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

白盒测试：主要应用在单元测试阶段，是对代码级的测试，针对程序内部逻辑构，测试手段有：语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖。白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

单元测试（Unit Testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试

集成测试：是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其它软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各个组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。也可以理解为在软件设计单元、功能模块组装、集成为系统时，对应用系统的各个部件（软件单元、功能模块接口、链接等）进行的联合测试，以决定它们能否在一起共同工作，部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。

系统测试：系统测试是基于软件需求说明书的黑盒测试，是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确，并非一项简单的任务，被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他的动态运行行为应该与软件规约进行对比。软件系统测试的方法很多，主要有功能测试，性能测试，随机测试等。

在本章的开头提到，一方面理论说测试环节非常重要，另一方面在实践中却并未觉得它如理论所说的那般重要，这是矛盾的地方。并不是认为理论说的有错，只是自己目前用的是C#语言，开发的大都是WEB项目，主要是企业内部应用系统，项目规模都不大，可能和这些原因有关系（尤其是最后一个），所以测试环节在自己的项目中并不特别的重要。

企业内部应用系统一般都部署在专网、内网中，几乎不用考虑安全问题。小规模的项目，用户量很少，并发的问题、性能的问题也很少遇到瓶颈。如果项目不是被匆忙的开发上线，那从自己手里交出的项目有5%以下的可能出现问题。在被公司的其它人员（工程人员或其它开发者）测试之后，有4%以下的可能出现问题。这4%以下的问题要在上线试运行或正式运行之后才能被逐渐发现，再慢慢修正。

5%不是个小的数值，这还是保守的说法。这个数值受制于软件开发前期相关设计的合理性、软件工程所使用架构的稳定性、软件开发过程中的细心程度及在开发过程中使用的测试技巧，等。过去一直致力于在测试环节之外的设计、开发阶段将可能的BUG消灭掉，一直认为如果设计足够严密、开发足够谨慎，那出现BUG的机率自然会减少。从来不相信公司内部的测试流程，当然，也没有阻止过公司组织人员对软件进行测试。很清楚的知道，这帮家伙只能测试些表层问题，根本刺探不到根本。一直坚信，最好的测试人员就是产品的用户，所有的问题都会在实用中被暴露，但是，当软件的BUG暴露到了用户那里，这个软件产品还有没有资格被称为好的产品？

中小型的WEB项目，就自己的经验，在开发成型之后的测试、使用过程中主要会出现四类BUG：

第一类是比较明显的错误。比如出现错别字，样式问题导致的页面显示混乱或对通用浏览器不兼容，表单字段合理性验证问题导致程序异常，页面之间的跳转出错，操作过程抛出程序异常（Exception），等。

第二类是不容易发现的错误。比如多用户同时操作导致的并发问题，程序编写规则有误导致的数据准确性问题，业务处理过程中出现明显过失问题，如给予某个角色不应有的权限，等。

第三类是在稍具规模的项目中常会出现的错误。比如由脚本、样式、程序导致的网络延迟，脚本、程序执行效率导致的响应速度过慢，数据量过大导致的数据库查询速度过慢，等等，大都是和性能相关的问题。

第四类是新版本发布导致的问题。比如配置文件被不小心覆盖、替换或内容被手动更改，WEB项目中的附属安装程序包在发布新版本时不小心被不同版本替换，根据用户要求对功能进行修改之后出现新的BUG，等。

上面并未提到可能的安全性问题，这方面不是我触及的项目所考虑的问题。在列举的这四类BUG中，第一类最为常见，这部分一旦发现，改起来相对容易，不会导致大的问题。第二类最为致命，不常见也不易被测试发现，如若在产品发布使用之后才被发现，很可能已经酿成祸端，数据的准确性或许已被破坏。第三类在小规模项目中不多见，即便出现较大数据的表，也大都在可控范围内。第四类是让我最头疼的，频繁的又相对简单的修改要求在项目发布之初是很常见的，而又很难针对每次的修改都进行全面测试，可每个简单字段的增删改都有可能导致出现新的BUG，所以常会有不可测问题出现。

再来看下发现项目BUG的人员，第一类是项目开发者，在开发过程中发现并修正。第二类是非专业测试人员，比如项目正式发布前对项目进行测试的工程人员、其它项目的开发者等。第三类是专业测试人员，掌握系统性测试理论和实用测试技巧的专业测试者。第四类是项目最终的使用者，在使用项目的过程中发现并反馈新的BUG。

寄希望于专业测试人员对中小型项目进行系统化测试是不现实的，一来大部分小规模的软件团队都没有专门负责测试的成员，二来即便有测试人员，也根本谈不上专业。软件测试的目的就是在其被正式使用前消除尽可能多的BUG，所以到第四类人（项目最终使用者）那里再发现问题，就已经晚了。对于第二类人（非专业测试人员）又信不过，他们只能发现些表层问题，却很难测出与业务相关的深层次BUG。在这种情况下，只能要求项目经理、开发人员在设计、开发阶段做更多的工作。白盒测试、单元测试、集成测试，都是很耗时的细节测试方式，如果在设计开发阶段做的足够好，可将这几种测试方式忽略掉，而专注于黑盒测试、系统测试、验收测试。只要机器可以正常运作，不要问机器内部是如何运作的——尽管这种处理方式或许不适合大型的软件项目。

在项目设计阶段尽可能的把数据库、架构、框架设计的足够灵活、稳定，在开发阶段尽可能的用代码生成器来完成程序的编写，这样可以从根源上杜绝很多BUG。对自己写的程序还是比较自信的，不是说不会出问题，而是说一旦出了问题能很清楚的知道问题出在哪里，可以在第一时间完成修复，这就是得益于自己对架构、程序的把握。开发阶段，每次完成一个独立的功能模块，都应对这个独立模块进行黑盒测试。相互之间有业务联系的模块，对其中某个单独模块进行改动后，都应对整个业务做完整的黑盒测试。开发者在开发阶段对项目的测试是频繁的、模块化的、间歇性的、迭代的。如果做到这些，项目从开发者手里交付后，再出现明显BUG的机率就会很小了。

项目从开发者手里交付后，应该部署到尽可能贴尽实际运行环境的服务器中，然后由公司组织人员进行测试。应该征集尽量多的人对项目进行深入测试，每个人把测试出的问题按要求整理成统一格式的测试文档，交付给项目负责人处理。项目负责人把这些问题归类后，逐个解决，并将处理后的结果反馈到测试文档中，之后开始进行第二轮测试。如果第二轮测试出的一些问题并非是由于第一轮测试之后对项目进行的修改导致，那说明这些问题是在第一轮测试时就该被发现却没有被发现的，这就是测试者的失误。在过去的测试中，经常遇到这样的情况，重复测试发现的问题并非新问题，而是因为测试不严谨导致的本来在最初时该发现却没有被发现的问题。觉得有必要让测试者明白这个道理，让每一次的测试尽可能的仔细。

对于测试出的问题，通常会有两类。一类是明显的错误，这个无可厚非，直接改正过来就是了。还有一类“似是而非”的，是测试者的主观意见，比如他觉得这个地方字体太小了、他觉得这个地方这样操作不合理等等。前面就说过，对项目的最终展现有决定权的只能有两个人，一个是客户，一个是项目经理。测试人员反馈的这种似是而非的问题项目经理可以留意，但最终是改还是不改，并不由测试人员来决定，这一点应该明确给所有人。

项目被公司组织人员测试之后，正式部署到客户要求的服务器中。正式部署之后应该先试运行一段时间，没有大的问题，才能被正式使用。试运行阶段及正式运行初期，客户很可能会反馈不少新问题，有些是明显的错误。不过，如果前期测试严密的话，这时更多反馈的应该是修改意见，比如增删改些字段，变换下操作方式，等等类似于公司测试人员的“似是而非”的问题。对于这些“似是而非”的修改要求，项目经理应根据实际情况和客户之间商讨决定。每次更改之后、发布新版本之前，应该把更改过的相关业务从头到尾再测一遍，这的确比较耗时，尤其是客户频繁更改的情况。为了减少频繁的更改发布，应该想办法让客户尽可能的一次提出所有的更改要求——当然这不容易，不要今天提一点，明天想到了再提一点，频繁的更改发布会另出现新问题的概率大大增加。

正式部署之后的修改再发布就是版本更新了，发布时应该先检验新版本中配置文件的变化，有没有增加、修改或删除的内容，如果没有则不发布配置文件，如果有则和当前运行版本中的配置文件进行校对、整合。如果当前版本有要下载的程序包，注意要发布项目的程序包的版本和当前运行项目的程序包的版本的异同。还有，上传的文件应该存放在独立于项目之外的虚拟目录中，即能防止发布时不小心被覆盖或修改，又方便后期的文件备份。发布项目时要注意的问题应该整理成文档，发布操作严格依照文档说明进行，可有效避免发布导致的不必要问题。

本章节讲得并不是具体的测试技巧，甚至有好多和测试无关的内容，但目的都是一个——在项目正式运行之前将可能的BUG数量降到最底。这并非正规的测试方法，只是自己的经验，如果有可能在大型项目中做开发工作，到是很有兴趣了解下正规的测试如何进行。

八 运行维护

运行维护本来是两部分，但因为要讲的内容不多，所以这里将二者合在一起。

项目经过公司内部的循环测试之后正式发布，通常情况下，客户会提供给专门的服务器供我们部署。有的是现成的服务器，已经安装好系统，有的则是空服务器，这时往往是工程实施人员负责系统的安装。工程实施人员有时也会安装好要用的数据库，不过也有时候由开发人员自己安装。操作系统、数据库安装之后的工作大都由开发者自己来做了，比如特定版本的.NET Framework的安装、Oracle数据库客户端和操作工具的安装、IIS和FTP的部署等等。

其实工程实施人员能做的工作很少，大部分运行维护相关的工作还是要由开发者自己亲自动手，自己开发的项目当然自己最清楚。发布项目到服务器时，很少碰到一次性顺利部署成功的情况，总会出现各种各样的小问题，有时是系统、数据库的问题，有时是IIS的问题。应该跟工程人员事先交待好，务必按要求安装合适版本的系统和数据库，且必须是纯净版的，这可以减少很多不必要的麻烦。遇到多个项目部署在同一服务器中的情况，注意可能产生冲突的部署、可能产生冲突的软件，比如曾经在部署FTP服务器时怎么配置也不成功，后来才发现是因为和同事部署的“FileZilla Server”冲突。数据库和项目在相同服务器中和在不同的服务器中，也可能会出现不同的问题，尤其像Oracle这种大型数据库，客户端版本不同、配置不同都会出现很多恼人的问题，应该注意。

出现问题时也不要心急，如果在自己开发用的机器上、在公司的测试服务器上都能成功运行，而在正式服务器上却出现问题，大都还是因为运行环境而致。有可能是数据库或IIS配置有问题、也有可能是操作系统中有关键性文件缺失，比如过去就遇到系统中缺失msvcr100.dll文件的情况，最后将文件打包到项目的BIN目录才算解决。遇到问题先要明确问题、明确问题出现的原因，之后再寻求解决问题的办法，不要盲目的胡乱配置测试。

一旦项目在正式服务器上正式部署，则通知客户方的负责人，开始试运行。试运行阶段是必须的，即便经过非常严谨的测试，也不能保证项目绝对不会再出现错误，试运行也是为了进一步保证正式运行的稳定。再者，试运行阶段不仅仅是为了发现可能的新BUG，更多的是为了解系统用户对当前系统的意见。其实很不喜欢客户在系统运行之后没完没了的提出修改要求，尤其是系统的功能、界面在设计之处早就已经详细确认好了的情况，如今刚做完却又要变更。不过，即便如此，还是应该听一下意见，特别是比较大、比较重要的项目，甲乙双方都有责任让这个项目变得更好。

在项目试运行之前，必须有一份系统帮助文档，以供工程实施人员及系统用户查看。文档可以由开发者自己编写，也可以由负责系统测试或实施的人员编写。用Word编写后保存成网页格式，挂载到系统比较明显的位置，并提供源Word格式的下载链接。还应该注意一下操作文档的更新，当系统功能有修改变化时，帮助文档也应做出相应的变更。

系统试运行之后，开始正式运行，随着正式运行时间的增长，系统会愈来愈趋于稳定。系统用户会逐渐的熟悉适应当前的系统，不适应的会反馈到开发者那里，由开发者对系统进行修改让系统反过来去适应用户，在这个过程中系统使用者和系统本身之间配合的也会越来越默契。一旦系统运行稳定下来，再出新问题的可能性就不大了，不过再修改的可能性还是有的，因为客户的需求无限的。比如现实的需求或者是他们突然想起来要新增些什么功能、要修改些什么功能，这些新增、修改的要求都属于对系统的扩展升级，这部分下个章节详细介绍。

项目正式运行并趋于稳定之后，再出现明显的错误就是很特殊的情况了，为了方便的查找出现这些错误的原因，系统应该有自己的日志记录功能。在架构、程序的设计阶段就应该考虑好日志功能，登录日志、操作日志、异常日志都要做记录，以备出现万一时查看。后期设计的架构中都有日志记录功能，对用户登入系统后的每个动作都进行了详细记录，可以很方便的查看系统使用者对数据的增、删、改操作。查询操作较为频繁，用户在登入系统后的每个动作都有可能触发对数据库的查询，所以对这部分的记录处理的不是很好。不是不好记录，而是不好对查询记录进行分类。比如之前的架构中，在伪业务逻辑层都会有增删改查四类方法，同时会有四类方法的重载方法，这些重载方法会多一个是否记录日志的参数。如果要记录日志，直接调用默认方法即可，如果程序不要记录日志，则调用重载方法并传入false（不记录日志）参数。通常情况下，增删改这类写操作都要记录日志的，不过有些查询操作却没有记录日志，比如当用户在登录系统时，也是调用的查询方法，但有登录日志功能专门对这个操作进行记录，那这个查询操作实际并无必要记录在操作日志中，操作日志记录的都是已经登录系统的用户执行的操作，每个操作都要记录执行这个操作的用户的ID。再比如，用户在新增卡片信息时，系统可能要先判断一下这个卡号是否已经存在于数据库中，并给出相应的提示，那这个系统业务自身执行的操作还要不要记录在操作日志中呢？过去没有对这些查询进行记录，但是不是可以完整记录，然后对操作记录进行分类，哪些是用户直接解触发的、哪些是间接触发的由系统业务执行？可不可以把操作来自于哪一个页面哪一个控件、执行的哪一个动作都进行分类记录，以方便后期的查阅呢？对于异常日志，是不是要单独记录到本地文件中呢？因为系统一旦运行稳定，操作异常很有可能是由于数据库失联而导致的，这时如果仅凭操作日志怕是查不到原因的。这些都是非常具体的技术细节，是在系统设计阶段应该考虑的问题。总之，为了后期的运行维护，日志功能不可或缺，且必须设计的足够严谨灵活易用，可以藉此清楚的了解系统运行情况。

最后一个要讲的问题是数据备份，主要是数据库备份和上传文件备份。项目后期的维护过程中，数据备份是最重要的一个问题。假如服务器瘫痪掉，甚至是硬盘出现了物理损坏，你的项目还能否完好恢复？SQLServer数据库有定时备份机制，但使用起来不是很好，设置好后总是莫名其妙的终止，自己也没有尝试过这种备份文件是否可以成功恢复。至今不熟悉Oracle数据库的自动备份机制，即便有像SQLServer数据库那样的自动备份功能，如果仅仅是在本地硬盘上备份，还是无法应对服务器硬件损坏的情况。一旦硬盘损坏，所有数据的恢复就都不好弄了。再就是和数据库对应的，比如用户上传的一些图片文件，这个之前说过，用户上传的文件必须存放在独立于项目文件之外的虚拟目录中，这种文件的备份又该如何处理？如何建立完善的备份机制？

理想的情况，一个系统应该至少两台服务器，两台服务器之间的数据相互同步，可利用类似于MySQL数据库主从复制的功能来实现这种同步。这样如果一台服务器出现问题，还有另一台，但小型项目中不大可能为一个系统配置两台服务器。在过去的技术生涯中并未遇到过服务器硬件出现损坏的情况，但还是觉得没遇到并不到代表没有这种可能，一旦出现这种情况，如果系统比较重要，结局就会是灾难性的。目前网络上流传的对Oracle数据库自动备份的方法，大都是利用批处理脚本完成。具体导出方法和自己平时用的一样，也是执行的exp命令，不过加上批处理后隔段时间执行一下这个导出命令。对于系统用户上传的文件，可以用一些定时压缩备份工具进行备份。利用这些方法，把数据库和上传文件备份到一个特定的文件夹中，然后再利用FlashFXP这类FTP上传工具，定时将备份文件上传到FTP服务器中。一般情况下，项目所在的服务器都可以访问外网，而公司也都会有多台外网服务器，可以在上面搭建一个FTP供上传备份。也可以利用SoftEther搭建VPN，将备份数据保存到自己电脑或公司内部的源代码服务器，这是自己目前能想出的唯一可行的完美备份方案。

备份部分还有一个要提醒的问题，就是在发布新版本系统前，应该先对当前运行的版本进行备份，也就是说先备份在发布。这样做的目的是，如果发布的新版本出现问题，可以及时恢复到过去的版本。对于数据库的增删改等手工操作，也应该先对数据库进行备份，以防万一。

还有一个和项目的运行维护关系不大的、备份相关的问题，想在这里提一下，就是源代码管理器的备份。目前使用的源代码管理器是TFS，应该了解下对这个TFS的备份方法。项目的历史修改记录都在源代码管理器中，如果这个存放源代码的服务器有个三长两短，也是很要命的。

九 扩展升级

在自己看来，评价一个项目是否重要的核心因素只有一个，那就是项目被使用的频率。如果每天都有很多人在用它，它自然就很重要。项目在稳定运行之后，如果客户和公司有比较长的合作关系，且项目比较重要，那后期扩展升级的可能性就会非常大。自己负责开发的项目，简单的增改些功能到也算不上难题，真正另自己觉得麻烦的是另外一种情况，扩展升级别人开发的项目。

无论是别人开发的项目还是自己开发的项目，对项目的扩展升级都会分两种情况。第一种情况是，项目的核心业务没有多少变动，而只是做些简单修改或者是增加些附属业务。前段时间XX医院要求在现有会诊平台中加入转诊住院功能就属于这种情况，项目原有数据库结构不做大的变动，但会增加新的表结构来实现新增的附属业务。第二种情况是，项目的核心业务有了较大的改动，当前的数据库结构已经无法满足新业务要求，数据库必须重建。数据库一旦重建，程序以及前端就都要重写，也就是说整个项目都要重新开发，像之前的“YQZA系统”、“ZHJWBB系统”都属于这种情况。严格来讲，这种情况已经不算扩展升级了，这和重新开发一个新项目没多大区别。

针对第二种情况，无论之前的项目是谁开发的，到你这里都没有区别，都要重新开发。就把它当成一个全新的项目，按上面章节中所说的方法了解需求、分析、设计、开发、测试。因为是二次开发，也可以参考借鉴一下旧的项目。

针对第一种情况，如果是自己开发的项目，简单增加些功能并非难事，因为整个项目都是自己做的，自己对情况比较了解。可如果这个项目是别人做的呢？按理应该是谁的项目谁来负责扩展升级维护，那假如这个项目的负责人、开发者离职了呢？在中小型公司中，这种情况很常见。一个人负责一个项目，甚至是一个人负责多个项目，一旦这个人撂挑子不干了，他手下的项目就会很麻烦。管理者自然会将这样的项目交付给其他人，这个接手的人在维护修改一个完全不属于自己的项目，困难可想而知。接手的“远程医学平台项目”就是这样，前面几经人手，程序早已混乱不堪、错误百出，但迫于种种情况，数据库又不能重新设计，只能在原有的基础上进行修改。对于这个项目，考虑到现实情况和时间限制，没有对数据库、界面以及核心业务做大的调整，但把所有的程序、样式、脚本都进行了重写。就是说把房子重拆后又建了一遍，但没有改动地基，建完后的房子和之前的看起来一模一样，外面的人看不出来，其实里面用的材料已经完全不一样了。这是当时能想到的唯一比较可行的方法，现在想来其实也不甚好，公司的很多人，尤其是管理层，只看表层的界面都以为根本没做什么工作呢。

总结一下上面的介绍，把针对项目的扩展升级重新划分成四种类别：第一种是对自己开发的项目完全重写，第二种是对自己开发的项目进行部分修改，第三种是对别人开发的项目完全重写，第四种是对别人开发的项目进行部分修改。

到了项目扩展升级这一步，项目开发者能做的工作其实并不多，我们在这一步工作中的难易很大程度上依赖于项目早期设计、开发、用人的合理性等等一些因素。反推一下，为了项目后期扩展升级的方便，项目开发前期应该注意哪些问题。

第一个要注意的问题在项目具体的技术实现上。数据库设计、架构设计、程序设计务必要尽可能的稳定、灵活。灵活，什么是灵活？灵活就是开发者在后期可以很容易的对已经成型的项目进行修改扩展。为什么数据库表中一定要存外键、一定要存字典编码而不是相应的文本信息？为什么数据库表中大都有CREATETIME、UPDATETIME、CREATEUSER、UPDATEUSER四个字段？为什么要对架构做很多不必要的分层？为什么本来可以很容易写的程序要绕这么多弯来实现？这些很多看似不必要的工作都是为了项目的稳定及后期可能的修改。还有具体到用户、单位、字典等基本信息，角色权限等基本业务，都是一个项目基础又核心的功能，此部分的设计必须足够灵活，后期才可能方便的进行扩展升级，这也是我为什么要做通用权限管理系统的原因。

第二个要注意的问题在项目开发的用人上。虽然之前说在可能的情况下项目开发团队中人的质量应该越高越好、数量应该越少越好，但公司较为重要的、较为核心的项目不应该轻易的全都交付在某个人身上，一个人主负责没问题，但要让多个人参与其中，以防人员流失后项目不稳定。这个真正实施起来并不容易，中小型公司中的开发团队人手本来就紧张，在调动人员的过程中如果强制让部门中互相合不来的开发人员在一起共同开发项目，项目的质量很难保证。除非是部门的团队协作文化很好，任何的几个人之间都能良好配合工作。即便如此，管理者心中也应该有数，把重要项目全部交到一个不太可靠的人手里是非常危险的。

第三个要注意的问题是统一代码规范。如果部门中所有开发人员使用统一的架构、统一风格的代码，就无需担心接手不是自己负责项目的扩展升级工作了。文乃心声，文不一，说明心不一。如果文统一了，所有人同心协力做项目，沟通协调还能有什么困难，还有什么事做不成？可这个实施起来也是非常困难的，统一代码规范在某种程度上是要扼杀人的创造性的，没有哪个员工希望自己被束缚起来工作，尤其是被不合理的规范束缚。所以，如果要在开发团队中推行统一的代码规范，首先要制定出一套合理的规范，把大家叫到一起研究，听取每个人的意见，先在某个项目中试行，然后再全面推广。同时建立代码审查机制，用代码审查工具考核所有人的代码，逐步让这一制度深入人心。代码规范应该在统一和尽可能减少对人创造性的扼杀间找到一个平衡点，具体到代码规范的制定可以参考这篇文章：

。

第四个要注意的问题，由上两个问题延伸而来，有关团队的建设。把能力、品性参差不齐的人凝聚在一起不是件容易的事情，但从事实的角度来讲，一个人技术能力再强，能做的工作毕竟是有限的。况且，一个人也不可能精通所有技术的所有细节，必须要依赖于团队的力量。从个人来讲，不太喜欢和别人合作开发，尤其是在自己完全可以独立完成的情况下。是的，因为有人就会有意见不统一，有意见不统一就会有争执，有争执就要有磨合，磨合的过程是痛苦的。很多时候，不觉得经历这种痛苦是必要的。但是如果站在公司和管理者的角度，团队的磨合却是非常必要。一个人的性格不好塑造，但一个团队的性格却可以。部门内部一盘散沙，团队人员频繁变动，没有统一的开发套路，没有规章制度，没有默契，这样的团队怎么能做成事情？能不能成功在于两方面，第一是你选择的方向对不对，能不能选对要做的事情。在职场，具体到要做什么样的项目往往由公司的大方向决定，自己能左右的不多。第二方面是能不能把选对的事情做好，这一点是自己可以把握的，研发部门就是要有一个可以把任何项目都做能好的团队。为了训练出这样一支团队，部门管理者应该是懂技术的、懂管理的、强势的。为了让团队中的所有人使用统一的开发环境、统一的架构、统一的代码规范、统一的文档规范，管理者也应该独裁。只是现在管理者和员工并非君臣关系，游戏规则是由公司、公司的管理者来决定，但玩不玩却是由员工自己来决定的。强势的领导可能会让下属觉得不舒服，造成人员的流失。首先你的规则必须是合理的，别人才会同意跟你玩，结合实际情况制定合理的规则，推行时讲就技巧和方法。管理者必须是强势独裁的，但管理方法应该是民主的。再就是实战，成吉思汗的军队战无不胜不是因为他们武器先进，而是因为他们久经沙场。要不停的打仗，不断的接手新任务，在实战中锻炼队伍。再就是中小型公司的人员本来就不多，最好不要同时招收用不同编程语言的开发人员，要Java就全都招做Java的，要.NET就全都招做.NET的，这样也方便通力协作。用不同编程语言的开发人员，怎么好拧成一个团队？

上面四点都是在反推为了项目后期扩展升级的方便，项目开发前期应该注意哪些问题。在事情发生问题之后再想解决办法，已经输了，在发生问题之前就预料到可能要发生的问题并采取相应的预防措施才是真正高明的，所以说“上工治未病，不治已病”，与其亡羊之后再补牢，何不提早的未雨绸缪？项目到了扩展升级环节，工作的难易大都依赖于之前所做的工作，不过这里还是要讲一下这个环节要注意的几个问题。

第一个是先做决定。在接到扩展升级要求后，先根据实际情况来决定是对项目进行重写还是修改、是部分重写还是部分修改，决定的依据主要有：项目本身的重要性如何、项目是自己开发的还是别人开发的、扩展升级需求对核心业务的影响大不大、客户及公司允许的时间上限是多少、重写和修改的个人及公司的时间等成本各如何、重写和修改的对个人及公司的收益各如何、部门领导的意见如何，等等。对于别人开发的项目、核心业务变动需求较大的、改造时间充裕的情况，尽量直接重写；对于自己的项目、核心业务变动不大、改造时间较短、项目不是特别重要的，尽量只做简单修改。接手远程医学平台项目的修改工作时，我对所有程序做了重写，但没变动数据库和最终展现效果，依据就是：核心业务变动不大但程序是其它人开发已混乱不堪，没有专业美工不好做界面变动，公司允许的时间比较紧张。不过通常情况下，不会遇到这么复杂的情况，一般的扩展升级就是对自己负责的项目增加些功能。

第二个是对项目做简单修改时要注意的问题。扩展升级如何保证当前正运行版本不受干扰，如何不搞乱当前系统的主架构和核心业务？针对这一点，除了要依赖早期架构、程序的灵活外，自己在做修改时也应该注意，尽量不要删改原有的程序或数据库表、字段，如果在原有数据库表中增加字段、或在原有程序中增加新程序时，务必谨慎，并做好测试工作。尽可能的让自己新增的功能和原有的功能保持独立，如果不得以要修改原有的功能，注意被修改功能相关的其它模块可能受到的影响，最重要的还是做好测试工作。像远程医学平台这种项目，不同地方的核心业务相似但细节要求常有不同，比如申请会诊时有的要新增额外字段，如何处理定制部分、通用部分，另其互不影响，确保整个大平台的稳定统一？这些还是要依赖数据库、架构、程序的早期设计，项目设计者在技术能力之外还要对会诊业务有充分的了解，要有一定的行业经验。

第三个是重写项目要注意的问题。重写项目的决定必须要谨慎，考虑好彻底推翻重做的付出和收益如何，尤其是重写通用的、核心的项目，如果重写后的项目不能比重写前的优秀许多，重写意义是不大的的。重写应该借鉴原有系统的一些经验，可能的话，听听原有开发者及系统用户的建议，看看之前的工作有无可复用部分（估计有用的不会很多），或许会减少些自己的工作量。

关于扩展升级的介绍比较散乱，因为一直在倒推反思项目流程的前几个环节，设计、开发、用人，甚至是团队建设，觉得这些才是根本。也就是说，决定扩展升级工作的关键因素在扩展升级工作之外。

十 梳理总结

了解需求、需求分析、项目设计属于项目完整流程的前期阶段，项目开发属于中期阶段，测试、运行属于项目的后期阶段，维护、扩展升级属于附属阶段。合理的情况下，在一个项目调研开发的完整流程中：三分之一的时间进行计划分析、六分之一的时间进行编码、四分之一的时间进行构件测试和早期系统测试、四分之一的时间进行完整的系统测试。但是，自己过去的经验，接触过的项目的重点环节并不在测试上面，而是分析设计阶段和开发阶段，后期阶段及附属阶段工作的难易很大程度上由前期的设计开发工作所决定。一方面是由于自己接手项目的性质相对另类，另一方面自己过去的项目开发流程有确实要些不甚合理。

回过头来看文档中描述的整套流程的各个环节，这些环节的工作最终大都要落实在文档上。尤其是需求分析、确认、设计阶段，如果没有文档，所有的工作都只能停留在虚无缥缈之中。整套流程中涉及到的文档资料主要有：业务流程图、需求确认书、界面效果图、数据库结构图、数据库文档、描述人员安排和进度跟踪的甘特图、开发文档、程序文档、接口文档、测试文档、软件操作说明书。其中数据库结构图、数据库文档、程序文档、接口文档都可以借助工具自动生成，项目接口和项目测试可借助相应的平台管理工具进行管理，相应的文档即可省略，总之，这几项都无需耗费多少人工。如果在项目开发文档中描述了大致的人员安排及时间规划，可以省略掉描述人员安排和进度跟踪的甘特图，如果比较大的项目也可以用Project绘制出相应的甘特图，这一项是非必须的。业务流程图、需求确认书、界面效果图、项目开发文档、软件操作说明文档，这几项是必须的，尤其是项目开发文档，不可或缺。业务流程图大都由Visio绘制，但这个工具的局限性很大，自己不太喜欢，如果能熟练使用PotoShop绘制流程图，可表现形式会更丰富些，项目经理应该学习使用。当然最好的绘制方式就是纸和笔，但不好表现成电子文档。界面效果图由美工完成，项目经理无需费心。网上有很多需求确认书及开发文档的模板，自己可以借鉴整理出一套自己的模板，每次复用即可。项目操作说明文档写起来比较容易，可交给工程实施人员编写。

除去工具生成部分、美工负责的效果图、工程实施人员负责的软件操作说明书，项目经理要写的文档很少，只有业务流程图、需求确认书和开发文档，这些大都有模板可套。无论是工具生成的部分还是人工编写的部分，一定要清楚的是：这些文档不是招标书，不是为了应付形式而做，而是有实实在在作用的，是这个项目、是自己、是整个团队后续工作的依据，文档的编写应该是正式的、规范的、认真的、实用的。当你熟悉这些文档的编写时，也就熟悉整套软件开发的流程了。还有，我认为敏捷开发方式不是说不写文档，而是要尽可能减少不必要的文档，并借用工具把花费在必要文档上的时间降到最低，以期用最少的时间和精力把脑海中的模型表现出来。比起文档的编写核定，敏捷开发更重视团队间面对面的协调沟通。

在最早接触实际项目的开发工作时，认为一个好项目的评判标准主要依据这几个方面：安全性、稳定性、兼容性、易用性、可扩展性和其能完成的具体功能，等。好项目中的好程序则在于程序的健壮性、执行效率、高内聚低耦合不重复、易修改升级扩展、及规范化编写，等。现在看来这些评判未必全面、未必合适，但这着实竖立了自己早期的、针对软件的价值观。已经清楚的知道如何做一个好的项目，却不知道如何在最短的时间内花费最少的精力完成这样一个好的项目，所以才会有这篇文档。

熟悉建站CMS的人都清楚，一旦网站的整体风格设计完毕，可借助CMS在非常短的时间内完成整个网站建设的具体工作。因为CMS的开发者摸清了网站建设的一些通用规律，所以才会设计这样一种工具。也希望如此，把整套软件开发的流程流水化处理，不仅要借助工具把具体开发工作花费的时间降到最低，还要把分析、设计、测试、运行、维护等环节花费的时间进行压缩。

本文档中关于软件开发的整套流程以及各环节的关键点，已经介绍的比较详细。表面上看这些环节比较复杂，但如果你熟悉下来，实际工作花费的时间非常少。后面就是依据文档中的介绍，将每一个环节的工作都熟练掌握、了然于胸，在实践中摸索出一套自己的流程。大致的思路应该是和文档中的描述一样，但更适合自己。一旦知道如何将项目开发工作流水化处理，无论是业务比较复杂的还是相对简单的，软件开发的时间将不会有大的差别。要想让架构稳定灵活功能强大，其设计必然相对复杂，但软件本身的功能和架构的复杂度对开发时间的影响并不大，真正影响开发时间的是开发团队的技术熟练程度。如果你比较熟悉开发套路，复杂的项目也可以很快的开发完成，反之亦然。就像影响汽车生产速度的并不是汽车本身的复杂度，而是汽车生产流水线的先进程度，本篇文档就是在告诉你如何制造一个先进的软件开发流水线。

本文档中的所有记述都来自于实践，之前也说过，自己所接手的大都是中小型团队的中小型项目，大都是B/S的企业内部应用系统，所以文档中的经验并不是对所有类型的软件开发都适用。其实B/S和C/S并不重要，仅仅是表现层不同。自己开发过的、接触过的、见过的企业内部应用系统中，也没有能称得上“大型”的项目，在我看来，绝大部分企业内部应用系统都只能属于中小型的范畴，而真正的大型项目应该是微博、淘宝网、腾讯网易门户网站这类的互联网软件。就自己过去的了解，大型互联网项目的开发是和中小型企业内部应用系统的开发有本质区别的——在需求调研、人员分工、架构设计、开发测试等等各个环节，自己也没有更大规模的项目开发经验了，所以不敢对此枉谈。不过，我相信，对于绝大部分企业内部应用系统，本文档中的经验都是适用的，本文档中所描绘的软件生产流水线也足以应付绝大部分企业内部应用系统。

再要讲的是团队建设。几乎在上面的各个章节中都谈到人的问题，越来越清楚的意识到，从领导层和公司的角度来看，在集体中仅仅是做好自己，远远不够。在中小型公司中，一个研发部就算是一个小的团队。不停的在问自己，如果让你负责从零组建一个公司的研发部，你会怎么做？反思自己工作之后待过的诸多团队，认为优秀的团队应该至少具备下面四个要素：

第一是清晰的团队战略。研发部门的战略是和整个公司的战略密不可分的，首先是整个公司的战略目标明确，其次是公司交给研发部的任务战略明确。没有明确目标的团队是无法支撑下去的。

第二是优秀的团队领导人。团队领导人是团队建设的中坚力量，要求比较高，要懂技术、懂管理、平和有凝聚力、务实。只有优秀的领导人，才可能打造出优秀的开发团队。

第三是务实的团队氛围。氛围就是一种文化，只有务实，才能踏踏实实的做好事情。完善的制度、合理的规范、优秀的团队成员和团队领导人及公司的整体文化都在影响着团队的氛围，这是一种综合作用的结果。

第四是人才和技术的积累。优秀的成熟的团队应该具备优秀人才和行业核心技术的积累，优秀的人才是指在人品和技术上都过关、且在公司工作多年不会轻易流动的员工，他们是研发团队的核心力量，技术积累是指可复用项目、可复用架构、可复用代码、可复用文档、技术规范等的积累。人才和技术的积累是团队稳定运行的资本。

回过头来回答刚才的问题，如果让自己从零组建一个开发部。首先在招聘第一批团队成员时应该慎重，不仅是要技术过关，更要有责任心和团队协作能力，只是，面试时技术好考查，人品和能力就不好发掘了。团队组建完毕之后，剩下的就是在项目实战中塑造团队文化、完成人才和技术的积累——依照上面的标准。这说起来容易，做起来肯定会有各种各样的问题，但这些细节不是这里要讨论的内容，我们只要清楚的知道好的团队是怎样的，然后朝着这个方向努力就可以了，至于具体的细节方法，那就要在真实的工作中摸索了。

更多情况下，我们不是去从零开始组建一个团队，也不是进入一个空白的团队，而是进入一个已存在的团队。进入一个已存在的团队，如何成为这个团队的中坚力量，如何协助这个团队成为公司的中坚力量，如何在团队和公司中施加自己的影响力？这才是自己应该考虑的问题。在我看来，问题特别多、一塌糊涂的团队和特别优秀成熟的团队都不大适合自己，原因也很简单，一塌糊涂的团队中想做事太难，阻力太大，而优秀成熟的团队已经成型，自己能做的建设性事情又太少。真正适合自己的应该是，公司及部门战略目标都很清晰又尚未完成人才、技术积累的团队，这样的团队既有奔头，可做的事情又多。不过，人想找个合适的团队同团队想找个合适的人一样难，因为找不到绝对合适的，所以大家都凑合着过了。

之前提到，在团队中工作，很多项目都输在跟领导的关系上。自认为对具体工作的熟知远在领导层之上，正如领导层对整体部署的熟知远在我之上一样，但是因为种种原因，领导层会设法干涉我接手的具体工作，这是自己不能忍受的。就这样，在处理和上层的关系上经常会出现问题，接手的工作也会因此变黄。给自己定下的底线是，无论接手的是自己喜欢的还是不喜欢的工作，无论接到的是自己喜欢的还是不喜欢的命令，如果不能强迫自己全心去执行、去做好，至少不应该为此和上层产生矛盾。理想中的领导层会关注督促工作的执行结果，但不会干涉具体的工作，并能满足员工对公司资源调动的要求。这也是很少见的。

在工作中，从个人来讲，从管理者来讲，从公司领导者来讲，关注点是不一样的，看问题的角度也是不一样的。团队的成员、团队管理者和公司的领导者之间应该学会换位思考，站在自己的位置上做事情没问题，但应该综合思考问题，而不要仅凭一己之见。无论是领导层还是基层员工，都应该争取表达的权利。即便是对个人来讲，沉默寡言也是非常不好的习惯，在公众的场合下的表达描述技巧是一个人进取过程中的必备技能，这一点一定要记得。应该有比较畅通的沟通渠道，不要什么事都互相藏着，私底下互相埋怨，这对公司和个人来讲都是致命的。大家应该很清楚的认识到，没有哪个公司是绝对完美的，没有哪个团队是绝对完美的，没有哪个领导是绝对完美的，没有哪个员工是绝对完美的，没有哪个人是绝对完美的，正因为我们各有所长，才要在一起协作，各自的、不可避免的、性格上的缺点不应该成为这种协作的绊脚石。

这个世界上还有一种人，性格和专业技能上的优势使得他们无论在什么样的环境中都能如鱼得水。有些人就是头上长角，无论在什么地方都能崭露峥嵘。过去自己一直有一个错误的认识，觉得要想做成些事情，要么做事情的人非常优秀，要么做事情的人遇到的环境和机会非常好，但是人中龙凤毕竟只是极少数，大部分人都是普通人，所以环境和机会对我们来讲才非常重要了。也一直笃信李斯那句“人之贤不肖譬如鼠矣，在所自处耳！” 鼠在所居，人固择地，所以觉得选择对的环境要远比个人的努力重要得多，容易得多。这种认识只对了一小半，选择对的环境是很重要，但却并不容易。选择对的环境和等待好的机会都有太多的不确定性，里面有太多的不可测因素，与之比起来，从自身下手反而会更容易些。很清楚的知道身上阻碍进步的坏习惯，很清楚的知道性格中的弊端，改掉身上的坏毛病，把自己变得更加优秀，这些虽然也很难但却都是可行的。比起四处乱撞似的选择合适环境，守株待兔似的等好的机会，哪个更合算？再说，你也不可能一天换一个工作的这样去找、去碰吧，如果自身的问题不修正，到哪里去区别是不大的，因为绝大部分单位、绝大部分团队都是类似的，没有这方面的问题也会有那方面的问题，什么问题都没有的，也未必适合你。清楚的认识到这一点，就不要把希望寄托在四处乱撞、守株待兔这种事上了，而更多的关注自身，打造自己是第一位的，选择环境是第二位的，等待机会是第三位的。选择和等待都是不确定性的，就应该学会去把握、去创造，这些并不是冲突的，是可以并行的。

不过，我觉得想在职场上求得大的发展真的不是件容易的事情，必须进入一个合适的公司的合适的部门，在这个合适的部门中找到合适的位置，然后开始积攒人品，等到天时、人心、技能、势位都到齐了，才可能有个小小的跳跃。是小小的跳跃，中小型公司的规模放在那里呢，你再跳能跳到什么地方？想在职场中求锻炼是可能的，但想在职场中求发展很难，看看周围的人可以很清楚的明白这一点。如果你的心很大，就不应该把希望寄托在职场中，应该尝试其它可能的渠道成就自己。

文档编写和团队建设是贯穿项目开发流程中的每个环节的，所以做为整篇文章的总结，本章节先讲了文档和团队的问题，对前面的章节做一种概括。后面讲了个人在团队、在职场的一些感悟，算是对过去的自己的一种沉淀和交待，对未来的自己的一种启示和鞭策。

在写这篇文档的过程中，一直试图重现自己在项目开发时的状态，却仍有点书不尽言、言不尽心的感觉。既精简又深入的总结真得很难做到，所以文档有些部分比较啰嗦。

满纸荒唐言，谁解其中味。