做项目的公司如何做技术积累——对以前工作的一些回想

转自:http://www.cnblogs.com/lane_cn/archive/2006/06/11/423212.html

我的第一个工作是在一家软件公司写程序，主要的客户是一家省级电力公司。工作主要是以项目的形式，项目签下来了，忙几个月，从需求调研到设计，编码，测试，然后现场调试，现场维护。做完了以后通常有一个空闲时间，然后进入下一个项目。每个项目的需求都有一定的差异，但是都是在同一家电力公司里，尽管具体的客户不同，解决的问题也不同，但是都属于同一个大的商业范围。

现在已经离开这家公司近一年了。有时候思考以前的经历，更能摆脱那种身在此山中的迷惑，也能够在技术方面有一些回忆和反思。虽然已经是马后炮，毕竟工作还在继续，总结以前的经验对以后也是一种财富。对于其他人来说，也许能够有一些借鉴作用。也希望一代一代的程序员能够积累自己的经验，减少新人在黑夜中摸索的时间。

以前的工作经常是项目性质的，一个项目做完，再做另一个。每个项目都有不同之处，解决的是特定的需求。每个项目都是新的，很难形成技术上的积累。因此，造成开发人员也是比较痛苦的，在dead line之前苦苦挣扎，加班熬夜是普遍现象。

现在想起来，虽然以前做的每一个东西的具体情况是有差异的，但是总的来说，客户范围都是在电力公司里面，具有很大的共性。如果细细规划，还是能够形成一些有延续性的构架的。

首先我们抛开具体的项目，更要抛开具体的技术，来考虑电力公司的基本业务需求：

电力公司的业务需求最主要是围绕着电网展开的，每一个系统都是围绕着电网开发的，只是关注的侧面有所不同。因此要做一个有延续性的框架，电网的模型是必不可少的，可以说是处于核心的地位。这个模型应该包括：电网的拓扑结构、各种网元设备（比如：输电线路、变压器、开关、发电机、用电负荷、等等）。

这个模型中还应该包括：电力公司的内部组织关系。比如：电力公司内的各部门、组之间的关系，以及他们与电网相关的一些重要的职能。

还应该包括：省级电力公司和合作组织之间的关系模型，比如：和各地市电力公司之间的关系模型、和发电站之间的关系模型、和变电站之间的关系模型、和用电单位之间的关系模型。

就像下面这样：



构建这些模型，完全是和具体的技术无关的，可以采用合适的任何技术。可以选用java，也可以用c++，也可以用.net，或者其他合适的东西，要考虑技术的成熟性和未来的发展趋势。

这些模型在电力公司的业务中是相对比较稳定的。有了这个东西，开发工作就不会每次都是从零开始，可以建立在一个稳固的基础上面。

比如，我们现在需要建立一个系统，对电网设备的实时运行数据进行监控。那么我们可以把系统建立在电网模型上面，主要关注设备的实时数据、控制命令。对于监控的工作还有一些职权流程方面的控制，那么内部的组织模型也能发挥作用。对于一些监控工作，需要各地的电力公司、电厂、变电站、用电单位采取配合措施，那么可以使用合作组织模型。

于是，这个系统的开发可以是下面这样的情况：



再比如，我们现在需要开发一个设备检修工作的控制系统。这个系统需要了解网元设备的拓扑结构，以确定某些设备可以一起检修，某些设备不能同时断电，安排检修工作，对检修期间的电网稳定性进行评估。这个系统可以建立在电网模型的基础上，主要关注电网的拓扑结构。客户需要对检修任务做具体安排，那么可以使用合作关系模型。于是系统是下面这样：



可以看出，各个系统都是把底层的几个模型拿来，关注其中的一些侧面，然后再加上个性化的需求。这样就能够加快开发的速度，减少公司开发新系统的成本和时间。

这个模型该如何得到呢？

首先应该借鉴一切可以得到的知识。比如：行业内的标准，国家颁布的规范。了解这些东西可以简化我们的分析过程，也能避免走弯路，犯错误。或者借鉴其他公司的相似产品，博采众长。

更加重要的是，要在开发项目的过程中要对这个模型不断的建立、完善，要把图纸上的构思切切实实的落实到代码里。

比如，我们在最初开发上面所说的那个设备监控系统的时候，首先应该考虑设计一个电网模型，建立网元设备的对象关系，实现电网的拓扑结构。而不应该急于进行数据库设计这样的细节工作。在建立电网模型之后，结合具体的项目需求进行分析，增强基础模型的健壮性。然后在这个基础上做具体的项目开发工作。

通过这样一个过程，电网模型就能够很好的建立起来，为以后的开发工作所用。

再比如，我们现在需要为电力公司做一个系统，对电网设备的资产情况进行管理。这时候我们需要充实电网模型，加入设备的资产属性的部分：



加入这个属性的时候需要注意，这个属性要和其他的一些属性相分离（比如实时运行数据），以免对互相的发展和应用造成以不良影响。在此基础上，开发项目的实际功能就比较容易了。

在这个过程中，需要处理一个难题，就是“急用为先”和“构架为先”之间的矛盾。关于这个话题，各个公司的情况千差万别，就不好说了。我只能说：即使在急用为先的压力下，也应该适当的考虑遵守底层模型的规定，并且一旦有条件，就应该把以前不符合构架的部分慢慢的并入一个正常的轨道。

下面谈一些自己对于技术学习的看法。对于一个程序员来说，掌握先进的技术是必须的。当技术达到一定程度之后，对于各种设计方式都有了一定的认识，然后会产生一种困惑：这些先进的技术，他们到底应该如何应用？.net和java哪个更好、linux和windows哪个更强、struts应该怎么用、spring是什么东西、orm有啥好处、设计模式该怎么用……

其实，要回答这些问题，不能只在技术上考虑，要跳出技术的圈子。站在用户的角度、业务的角度，自上而下的进行分析，就能够了解哪些东西才是重要的环节，那些问题其实是可以忽略不计的。技术本身没有优劣之分，要结合具体的需要，才好做出决定。程序员应该掌握技术，然后要跳出技术，专注于特定领域的业务（也许这个业务就是开发本身，例如你需要开发一个IDE，或者正在开发操作系统），真正为客户、也为公司做一些有价值的事情。