员工年度总结 -云顶集团官方网站入口

郑旭2006.07—2007.07工作总结

首先感谢公司给了我这么好的机会以及这样的一个平台,让刚刚步入社会的我能够很快的适应工作和生活。这是我的第一份工作，在工作过程中，在完成工作任务的同时，也使自己的能力得到了很大的提高。感谢李总的栽培，也感谢公司同仁们给我的帮助。下面对我一年来的工作成绩进行总结。

一、设计模块的需求分析、设计和编码
这是进入公司后接到的第一个任务，刚开始时不知道如何下手，毕竟，刚从学校毕业，还真的不知道如何将所学能够很好的应用在现在的设计上。不过，我却坚信一点——以前应付学习难题中的那点精神是绝对可以派上用场的。
作需求分析，自己想象中是应该有一个对本行业很熟悉的人提出要求，然后从他的要求中提炼功能需求，经过反复的筛选，将合理的需求写成文档，为下一步的设计做好充分的准备。当然，这是一个很长的过程，目的是使需求尽量能够取得用户的赞同，为良好的设计做好充分的准备。而事实上，这个过程比想象中的要长久得多，也没有专家提出什么要求，有的是一个已有的样板，当时的感觉就是：软件上为什么会有那些功能？它们到底有什么用外？那些术语到底蕴涵着什么样的领域含义？
解决的方法很简单：不断地试验，不断地向更有经验的同事请教，不断地阅读中英文参考文献。也就是这样，在两个月之后，对于布管中的一些关系都摸得比较清楚。特别是对pdms中那种逻辑层次都有谱了。这段时间所得出的结论都已经写成文档在服务器上，遗憾的是这些东西都是即兴写的，没有形成规范。
在经过长期的需求分析之后便进入了设计阶段。当然中间间歇了段时间，主要是因为在本科阶段还没有接触过面向对象编程，而且用的c ，于是这段时间拼命的将不足的地方补上，刚好到项目经理安排说要开始设计的时候，我也刚好学完。挺幸运的，我被继续安排设计和实现，是和张阿苏合作，不过觉得挺好，他能力比我强，我对后面的路充满了信心。
也算即学即用吧，这期间我已经会使用rational rose绘制uml图了，当然也会将自己刚学的一些设计模式搬过来，但绝非照本宣科，有时候用得觉得挺好的，还节省了不少脑力。虽然自己设计的一些东西没被采纳，但我还是觉得挺开心的，毕竟，我曾经尝试过。而且也从别人那学到了其他的设计思路。
在经过张阿苏重构之后，大概模型已经出来了，与pdms的基本一致，这时我也深切体会到了需求分析对软件成型的重要性。这算是我为公司做的第一份贡献吧，但时间似乎有点长啊，差不多花了半年时间。

二、底层分析、维护、扩展与模块整合
底层分析是接到的第二个任务，其实我很乐意接受这样的任务，虽然是看那几千上万行代码，但一份好的代码绝对对自己水平的提高有好处，只是当时觉得自己这方面的思想还比较欠缺，怕不能胜任，不过还是接下了，哪怕时间花得再长也要搞定。
应该说这是学长给我留下的一笔巨大的财富吧。可能在那些专家看来并算不上是什么好代码，但我从中学到了很多东西，也明显感觉到，通过阅读这些代码，自己在编程思想以及c 的熟练程度上有了很大的提高。
学长走的时候跟我说了很多关于编程思想方面的东西，当时并不是很明白，现在唯一能记得的就是对于软件的分层——这是他特别强调的。在后来的代码阅读中也逐渐明白，分层主要是通过将接口和实现分离，以达到模块之间的解耦。这个经验在后来的一些设计中应用的比较多，也取得了很好的效果。
这时期的主要工作业绩就是熟悉了整个软件的框架，为下面的模块整合打下基础，并能够为其他模块的设计以及代码的重用起到很大的作用。进一步完善持久层，整合数据的封装，并将它应用到软件中，提高了软件的可维护性。添加了查询功能，但功能不是很强大。为等级库、应力分析模块提供参考意见。添加了事务管理模块，方便了设计库中的与当前节点相关操作的实现。
总之，在这个任务完成的过程中，自己的能力得到了很大的提升，给自己的评价是还算满意。


三、数据导出模块的实现
工作中充满了许多的未知，而将这些未知的东西一个一个击破之后，带来了却是无尽的快乐与成就感。而数据导出就是其中的一个未知。
这个项目需要的数据量很大，不可能用人工输入，现有的pdms有大量的可用数据，只是其表现形式与现在的软件不同，问题是如何将它转化过来为我们的软件所用呢？由于当初对pdms数据库的类型不熟悉，对其访问接口也是一无所知，感觉无从下手。
在整个过程中，应该说有两次质的飞跃：一是pdms的dars模块的试验成功；二是设计出合理的结构，使得各个数据库都能够顺利的导出。当然，在整个设计过程式中遇到了很多麻烦，但最终还是通过不断的试验得以成功。主要工作成绩如下：
1、组织封装了pdms各个节点的底层访问接口；
2、实现pdms位置、方向到autopdms位置、方向的转换；
3、实现连接匹配的解析算法；
4、设计导出模块的整体架构；
5、组织实现设计库、元件库、属性库等数据库数据的导出；
当然，这个模块有它的特殊的地方，这也是一直没有弄清楚的地方，即win console程序对扩展mfc dll的调用问题。需要改进。

四、持久层设计
在查了很多资料以后，给人感觉是：要做一个持久层，很难，一般都是购买（如果不是专门做持久层的），资料都是对设计持久层的一些思想进行介绍，离真正的实现差得很远。不过还好，这些对于熟悉持久层的整个运行过程大有裨益。
第一个难题是如何统一返回值？在参考hibernate时，可以发现java中所有的对象，不管是自定义对象还是计算机中的数据基本类型，都从一个类object派生，因此可以很方便的统一起来。而c 是静态语言，它的基本类型没有共同的基类，解决的方法只有一个，那就是自己封装。
解决了类型问题，可以说映射才迈开了一小步，怎样通过类型的统一然后实现反射机制又是一大难题。由于域对象已经设计好，不可能做太大的修改，那么就只好添加中间层用来统一接口。已达到下述目的：通过对象的属性名能给对象的某个属性设置或者得到它的值，而不管这个属性是对象集合还是简单数据类型。
之后就是怎样通过持久层来维护持久化对象之间的关系——当然，这里所说的关系只是包含之类的关系，而且是比较通用的。这是持久层中最关键的部分，当然也是最复杂的部分。自己曾经尝试着去理清这些关系，并且试图将自己的想法实现，但后来还是停下来了，因为考虑的过于复杂，那么实现起来的复杂度就更高了，并且若要实现，对持久层已经设计好了的部分需要做比较大的调整。于是便放弃了。
持久层关注的是如何将域对象按照他们之间的关系正确的存储到数据库中，要做的通用很难，那么有时候就只能根据已有的域对象来采取相应的对策，在框架出来后，整合又成了个棘手的问题，总希望能找到一个可以通过不维护id与类型对应关系而能创建对象的方法，设计库模块整合已经基本完成。

五、近期工作安排
主要是将新开发的持久层整合进现在的软件，设计库基本完成，内容主要是将所有具有聚合子节点的类中存储的子节点id改为子节点对象。当然，这牵涉到了域对象的超类的修改，因此这个影响比较大，与之相关的等级库、元件库的域对象，调用关系都作了相应的修改。现在主要测试应该集中在应用逻辑上的测试，因为持久层保存、读取、删除对象的操作都已经完成。另外，由于领域框架还维护了一个缓存，所以必须测试缓存读取的正确性。可能存在的问题是当传入id找对象时可能找不到所要节点，不过就目前的情况来说是不会发生的，如果缓存采取定容方式（即缓存中对象的个数最大值是确定的，目的是为了节省内存消耗），那么现在这种机制肯定存在问题，需要改进。
其次是数据导出模块，因为它依赖原来的持久层，所以若将新的持久层整合进去以后，将从pdms读出的数据保存到数据库的实现代码需要更正，不过这应该不是很麻烦的事；另外须注意的地方就是由于pdms访问接口实现（由pdms提供，无法改变）的特殊性，需要慎用mfc的扩展库，回此需要对globalshare模块重构，难度应该不是很大。

总之，这一年的工作使我们进步了很多，无论是技术水平还是处世方面，所以再次感谢公司的领导和同仁，谢谢你们对我的呵护！
最后，祝产品上市取得开门红，公司销售业绩蒸蒸日上，同仁技术水平节节高升！

郑旭
2007.06.28

优易管道应力分析软件autopsa项目开发的一些经验和教训
2007.01.15
张书俊 陈百炼
长沙优易软件开发有限公司
[autopsa项目开发的一些经验和教训 张书俊]
caesar ii采用有限元方法计算管道应力，但与通用有限元程序不同，具有鲜明的行业特色。以前没有接触过管道应力分析这方面的知识，刚开始比较不习惯caesarii的设计风格，与自己的思路冲突很大。后来在李总的指导下，转为全面模仿，在模仿中理解它的设计思路。
比如caesar ii的计算工况设置，就是提供了弹簧设计、一次和二次应力验算以及推力计算的各种工况。还有一些我们的老版本没有要求输入的参数，后来才发现在一些规范或特殊材料有用到。多工况支吊架设计开始我们没有注意到，后来李总在论坛上发现了这个问题，经查找原来caesar ii早已具备这样的功能。因此，caesar ii一些看起来莫名其妙的模块，都不是空穴来风，是多年行业客户需求的反映。
像caesar ii这样的软件基本成熟，架构基本稳定，就是增加一些新功能也不会伤筋动骨。我们最重要学习他们的软件架构，同时我们的结构也要考虑到便于扩展。当然我们要与时间赛跑，要在软件稳定期内学习他们，积蓄力量，在某些方面超越他们，因为我们学习是为了全面超越。
模仿也存在风险。正所谓“条条大路通北京”，一些实现的途径千差万别。由于没有明确的规范要求，caesar ii有些实现采用非标准方法，如埋地管道模块，目前我们还没能知道他的精确的埋地单元划分规则，他的说明文档在重要的地方也语焉不详。支吊架中线选取方法，也不知道他的确切规则。毕竟不是开源软件，我们只能在比较中摸索，还好这些地方现在基本摸索清楚了。
模仿也有弊端，会吸收一些糟粕。在模仿学习和探索过程中，发现caesar ii有一些不足之处：膨胀节模块不能输入重量，需另外模拟一个刚性件，对厂商产品数据库支持得也不好，他的本质上是没有把补偿器作整体考虑(caesarii这样考虑膨胀节是否更符合实际情况呢？膨胀节当成离散的元件，似乎与实际模型更加吻合，而且它的重量应该是所有离散元件的重量之和，最好的办法是在离散模型中每个元件加重量并且保证重量之和等于膨胀节的总重量。这样虽然复杂了一点，应该更符合实际。没仔细研究，不一定对。)；还有，支吊架模块对不规则弹簧表支持不够。这表明，我们在理解、掌握的基础上，完全有可能在某些方面超越对手。当然caesar ii不是停滞不前的，他也在缓慢发展。最新的caesar ii5.0版，听取了客户呼声，添加了热态弹性模量、一致质量矩阵等功能。
因为我们对行业需求不了解，模仿比自己短时间探索更可靠，关键是能否实现。另外主流软件横行多年，他本身的做法也成了标准。模仿肯定是有利有弊，总的来说，利大于弊。毕竟架构比实现的细节更复杂一些，细节也容易变通而不影响整体设计结构。当然也可研究一下pro/e等通用三维平台的实现原理和方法，我不了解pro/e，但一般情况下通用软件比行业软件较早采用新技术，会领先一些，毕竟我们今后还是要超越对手的，至少是在软件的部分功能上(研究pro/e是一个好思路，值得尝试)。
以上总结不很全面，肯定存在偏颇之处，希望大家讨论。在autopsa开发过程中“逢山开路，遇水架桥”(软件开发成功最需要这种积极进取精神)，只有支离破碎的记载，没有完善系统的总结，现在不能给出一个严谨细致的参考，这也是一点教训吧。今后要多动手写作，提高驾驭文字的能力，为公司今后的开发提供有益的成功经验和失败教训借鉴。

[autopsa项目开发的一些经验和教训 陈百炼]

如果没有caesarii 做参考，autopsa7.0可能还没有达到现在层次。在这里谈谈autopsa7.0仿照caesarii的中间文件格式.cii的想法。
autopsa1.1autopsa7.0文件结构的改版经历了两个阶级：
一:开始存放文件结构没有仿照cii文件结构(把新加功能的数据存放到*.exp文件中)，新加功能以前的界面也没有仿照caesarii。完全是自已按照对autopsa1.1的了解和对部分客户反馈的意见，进行设计。当时以为这样做已经完全可以满足客户的需求了,结果慢慢的发现还有很多问题没有考虑,又要重新设计*.exp文件的结构,这样反反复复的修改感觉非常麻烦;因为当时对caesarii只是表面使用上的了解,对它的一些选项到底为什么那样做还没有真正的搞清楚。再加上autopsa1.1在autopsa1.0的基础上加的一些功能数据也是存放到另外一个文件(*.pes格式文件)中，所以当时第一种思路就是多加一个文件存放新的功能所要的数据。其实这时的新功能只是我们在这个阶段了解的一些功能，根本不知道以后还要加哪些功能，所以设计出的文件结构很难方便地实现以后的扩展；
二：在这个时候，李总提出以caesarii的中间文件格式*.cii文件做为autopsa7.0的输入文件格式，当时就觉得cii文件存放的数据太多，好像存放了许多不必要的数据（现在想起来，只是当时对应力分析软件的理解还没达到这一种程度，其实它的文件结构已经考虑了我们还没想到的一些问题）。不过当时我们还是按照李总的想法去做了。我们首先搞清楚autopsa所要数据的存放位置，至于其它的数据我们都以默认值存放在文件中。这样就把autopsa1.1所要的数据和当时我们要增加的一些功能数据都以cii的格式存放好了。这一阶级完成之后，再去了解autopsa7.0还没有用到的数据目的何在。在这过程中就发现了它的设计很有道理，并且编写程序读文件、写文件、扩展功能很方便。比如：最近张博士说要加多工况弹簧设计功能，我只要在界面加一个选项就可以了，文件结构、读写文件代码根本就不需要任何改动。当时就觉得李总的决定非常地正确。如果开始是自已设计文件格式的话，每加一个功能就要思考半天，最终设计出来的不一定比cii文件好。现在发现它的结构有些细节地方也不是很合理，但是它的总体结构是非常有道理的，正因为我们利用它的结构才能完全了解它的不足之处，再改正它的不足，这才能真正实现超越。现阶段的autopsa7.0还有很多caesarii中的功能没实现，但是现在增加功能，修改比以前容易得多了。
所以自我感觉仿照成功软件做风险更小，因为成功软件已经为我们做了大部分需求分析,我们通过它的功能，可以快速了解客户的需求（就比如autopd来说，大家都认为它的结构不好。结构确实不好，那是因为全部是照抄过来的代码，我们没有进行任何的框架设计。但是如果要我们自已在那么短的时间内，根本不懂需求的情况下开发一个那样的软件，那肯定很难成功，所以autopd从时间、费用、功能的关系分析还是一个成功的软件。小陈的看法是非常全面、客观、辩证的，我也觉得autopd是满足了金三角关系的极好例子。没有autopd/autopsa和autophs这些软件，我们今天哪有资金投入autopdms开发？所有那些对这些软件的嘲讽，都将会被证明为幼稚和不智之举。一事当前，不是积极地去逢山开路遇水架桥，一旦自己的意见被否定就消极抵抗，这是典型的极端个人主义的表现。我们说尊重人才尊重个性，但一定要批判极端个人主义思想，防止它们对团队造成危害。当然，也要注意防止管理人员搞一言堂，损害创新者的积极性，损害我们的事业），成功的软件结构设计是围绕它的功能，所以仿照成功软件的结构设计可以减少需求到设计的变更。虽然只要有足够的时间、费用，软件的功能肯定会实现功能、时间、费用三角关系的平衡，但是在这一过程中要反反复复的变更、修改。按照自已的想法设计，最后取得成功可能更有成就感。如果仿照成功的软件对设计、开发人员来说成就感就不会那么明显，但是可以缩短开发部分的反复变更的过程，节省时间、费用，提高公司的效益。