2005年11月30日
#
昨天，11：54从北京出发，经过三个小时的飞行，排了一些空中的蓝天白云，在14:54到达了福州，福建分公司的同事陪同我们在福州城里兜了一下， 我仿佛有回到了熟悉的南国，沿长乐海岸线，一片片茂密的九莲和椰子树，口气种尽是海腥的味道，恰似心情里的沮丧使得心肝腐败的味道；一阵阵海风，风里携带着南方的湿润和绿色的芬芳，好似隐隐作痛的潮湿心情，凝神那些在风中摇摆的柳树，我也不自然的翩翩起舞，很紧张，怕那生机从眼角溜走，想紧紧的拽着它，馈赠予你们。离市区远远的是散布着的不规则的民居，大多数都没有修完，依稀看到暗红的转头和灰白的水泥缝条条纹，据说，只有你看到没有修完的房屋，一般他们的主人都在外打拼，等挣了更多的钱后再回来修筑。福州的女孩并不好看，肤色黑黑的，跟广东一样，也不高，但是，她们那半生半熟的普通话，再加上本地口音，跟你说话的时，使你舍不得抽身离开，很甜很圆润的候音。
到福州有“美食一条街”的古泉支路吃了刚开业的日本菜，虽然味道很好，但心情并不乐观，因为平素，在内部论坛上不少见抵制日货的帖子，冥冥中，那味道就开始变了。
饭后，驱车到火车站，搭乘了福州到上海的列车，我们要到南平去。火车上的味道是丰富的，汉味，脚臭味，泡面味熏得人难受，到也觉得是久违得味道。列车上是吵咱的，有阳无气的交谈，并无情愿的吆喝买卖。我想静静，看的窗外是山，福建是个多山的省，我不停的在这群山绿水中搜索四川及巴中的影子，倒不是有意的。这搜索是不自然的，因为它们太象我的家乡了。这搜索的引子是明显的，因为家乡里有我永远也忘不了的人，影响我的生生世世。看着看着，睡着了，又醒了，又睡着了，好不容易到南平。南平更象是重庆，除了上，就是下，也没几个骑单车的。这里的女孩是一道风景，虽然骨子里土里土气的，但一点也疏远时髦，她们穿得很性感，经常向路人放一点电，我更喜欢她们那些乱崩乱跳的野性，她们有得人穿得很淑女的样子。
一起吃了饭，是选在很简陋的楼房里，木头做的楼，一闪一闪的。这里习惯吃跳跳鸡，水煮活鱼，还有竹笋，是我最喜欢吃的东西了，后来才发现这里的山上全是竹子。
喝酒了，她们也只卖她们推荐的啤酒，啤酒女郎跟其他地方一样，也穿得超短，陪上还算自然的笑容。
然后就到了我们的客户，南平南孚电池，南孚是南平，也是中国最大的电池生产厂商，它有日本人的股份，最高的年销售额有近六亿RMB，在南平最繁华的地段买下了20层高楼，公司为一些优秀员工修建高级住房，在国内算是比较优厚的待遇。
南平有几南，南孚，南铝，南纸，南缆，都算得上是国内同行业的旗舰企业，为南平增加了近5万个就业机会。
很快，我们跟南孚信息中心的朋友和南孚的第三方物流公司的朋友碰头，研究了基于EDI标准的数据交互方案，南孚软件的效率和其他的为决问题的预计解决方案，临近今天下班的时候，南府信息中心和生产中心的朋友带我们去参观了他们的车间，因为很少去过车间，所以感觉很新奇。南孚有同类行业中世界最大的电池生成车间。回想起前些时候参观的上海大众公司的汽车流水线，南孚电池生成流水线竟然跟它有惊人的相似（从非行业内人看来应该是这样的吧）。小小的电池有近30道生成工序，每一道工序都是全自动化的，生成员工只处理生成的一场状况。参观了电池从原材料到产成品的全过程，我仿佛清醒的看到了什人生命的全过程。参观的过程是快乐的，一面有南孚公司的朋友减少，一面在生成车间里，看到了很多穿着淡红色工作服装的女孩，妇女也不少。不论是女孩还是妇女都不少有恰似村姑的淳朴，有些还憨憨的，看着我们，一路看她们的劳作，眼神里有矜持，也有得意，虽然也有分心，可一点也不影响她们的熟练的手法。她们有一些有规则的座成一排，有的凌乱的散步在机器之间，还能依稀看到她们的头发，这里，并不管制她们的发型，甚至不用盘头，说是她们反对这样，她们对美的追求也是坚定的。
末了，南孚的朋友送给我们每人好几板电池，有为PHILIPS,SUMSUN做的，也有他们为自己做的。我们开玩笑说，以后用电池一定卖南孚的，他们称，软件一定用我们的，算是回报，^_^。
末了，南孚高层陪我们一起吃饭，在南平最好的饭店里，这里的海鲜很便宜，似乎除了海鲜，就没什么别的菜了。吃的过程是快乐的，也是麻烦的，比如吃菜，喝酒有很多讲究。菜里只有有整支鱼，谁先动鱼头和鱼尾，得先喝光他（她）自己的酒，不喝酒的也先喝酒才能吃。这里的人喝酒都用是啤酒杯一般大小的酒杯。有干红，加桔汁的干白，有啤酒。这里的规矩是三杯啤酒敬一杯干白喝干红，干白跟干红等量。我选了干白。交叉敬酒，喝了一二十杯，头也晕了，思路十清晰的。十几个人聊得话题很广，有继续说工作的，比如讲我们公司如何做到世界级软件规模，南孚，频敬酒的。。。，我每一个都参与一下，感觉舒服但不算最自然，因为，你不可以说：他妈的之类的粗话，^_^。
饭后，南孚的朋友说十不够尽兴，其实是尽兴了，喝了那么多，个个都歪歪斜斜的，又要去玩玩，算是尽主人之宜，说是玩的主题很多，要什么有什么，相互征求意见，我想回来了，打算敲点东西，大家草草告别。吃饭的过程的不乏看到人的很多性格，比如：城府，虚伪，憨厚，矜持，张扬。。。，我想起了一句话：男人只有在交际场合才能发现他存在的真实意义。
你的阅历丰富得足以让很多人（比如成千上晚的人）成为你的听众，或者也根本不需要听众，你算是什么呢？^_^。
末了，我打算休息了，明天，对了，是今天了，还要做事儿，再辗转到厦门。。。
2005年11月29日
#
昨下午看了DTR的分析模型和设计模型之后，我总结了一些对它们的改进建议：
l 要明确化所有方法的返回类型，及如何消费返回对象！
l 要明确化类与类间的关联类型及关联维度。
l 要明确化设计元素的属性定义。
l 在分析模型中应该有分析类的关联类图。
l 在分析模型、设计模型中包含（ChannelProcessor）的配置信息的对象模型。
l 修正模型，在模型中添加“直接编码”新增的类。
l 类、属性等的命名要一致、统一。
l 方法参数的命名要一致、统一，类型要明确。
l 在设计模型中要表达Processor Chain的设计。
今天来公司时，想了想，昨天跟王振骞聊了一会，我在想，有一种正确的态度叫做认真设计，事实上，做设计从来不等于是“闲”。平台产品更要要求按规范的软件过程来开发，我们越是在设计上下功夫，我们的工作产品才越是设计良好和架构良好的。
我们最先要的不是一打又一打的代码，而是思路，清晰的思路和有条理的模型，当然，表达这思路和条理也有多种方式，这跟项目规范直接相关。
同样也是在跟王振骞聊的过程中，我想到了“自己知道”和“能表达（绘制有条理的模型或者其它方式）清楚”的区别，就象是“学生自己懂”和“老师要把别人讲懂”之间的区别一样。试想，当我们是学生时，我们知道“平衡树”的概念，以为自己懂了“平衡树”，假如我们要做老师，单是“知道”的水平是不能让学生真正懂得“平衡树”的。所以，在软件研发过程中，类似的情况是，我们单是“自己知道”还远远不够，除非你能非常清楚规范的表达出来。
避免让代码出现臭味，（自认为）有经验的程序员常常越过设计直接编码，当有这一想法的一刹那，他（她）先前写的代码就已经出现了臭味。
如果说软件开发是艺术的话，分析、设计和编码的工作产品就是“雅俗共赏”的艺术品。“雅”就是“设计之美和架构之美”，“俗”就是“浅显易懂”，假使我们分析、设计和编码的工作产品变成了“印象派”作品，就只能让人去随意想象作品的内涵了，或者也要等到多年之后才能想明白，可是，对于要求严谨和浅显的软件开发来说，“印象派”作品绝对不受欢迎！
我在想，倘若我们在主张和（或）首倡“什么过程流程(XP、RUP)”、“什么方法论（OOP、SOA、AOP)”的问题上煞费苦心，我们常常有些劳民伤财，因为，当你在软件研发领域耕耘多年以后，你“渐行渐远”的回头去看，它们（不论是过程流程，还是方法论）都是一脉相承的。
比较理想的情况是，我们对分析、设计、编码的细心程度要求得就象是跟心仪已久的女孩初次约会前整理衣装、修理边幅时那般在意，我们端庄或潇洒、靓丽或帅气，我们（分析、设计、编码）的工作产品也会美不胜收（请参考《软件涅槃》之软件之美）。我们对“工作”的重视也恰似对那女孩的重视一样，跟那女孩相处是极乐，看我们优美的工作成果也是快乐！
我觉得，在工作中，如果可能，就面对面去交流吧，因为面对面时传递的不仅仅是声音！
希望大家指正，欢迎反馈！
今天，我想谈谈原型构造。在实际工作中，我们重视原型吗？当我深入研读原型的很多论文，再结合自己的项目实践，发现原型在软件研发过程中有举足轻重的作用。编写原型可以作为技术探索、可行性验证和辅助理清思路的手段。但是，显然，选择“编写原型”的时机往往比编写原型本身难，那是因为，我们常常都没有在规范的软件研发流程指导下工作。在我总结的软件研发核心工作流程中，我把原型构造放在全局设计阶段之后是有特殊的原因：第一，经历一次或多次的迭代后，每一次迭代，一个“分析局部”都演化为一个“设计局部”。第二，全局设计阶段着眼于总的视图， 归纳了多个 “设计局部”，这一阶段的设计模型有以下特点：
l 层次架构稳健。
l 包与包的关联关系稳定。
l 类与包的关联关系稳定。
l 类与类的关系基本稳定，但是，关联关系的强弱还不确定。
l 类的职责是明确的，但是，类的职责还不是具有严格语义的方法签名。
因此基于全局设计阶段而构造的原型有以下特点：
l 层次架构稳健。
l 命名空间与命名空间的关联关系稳定。
l 类与命名空间的关联关系稳定。
l 类与类关联关系不稳定，原型程序员根据需要可以调整关联关系的强弱，比如：把聚合调整为依赖。
l 类的方法签名不稳定，原型程序员根据需要可以调整方法的名称、参数及返回类型等。
在另一个时间要求苛刻的项目中，我总结了选取原型的策略，
第一：舍弃原型，依据法则有：
l 开发原型是技术探索的手段，
l 开发原型进行可行性验证，
l 把开发原型作为辅助理清思路的手段。
结果，这种我们最终能从这种原型进行代码级复用。
第二：沿用原型，依据法则有：
l 开发原型并但并不进行技术探索，
l 开发原型也不是要进行可行性验证，
l 开发原型无助于辅助理清思路
l 基于规范的设计来编写原型。
结果，这种原型是我们工作产品的一部分，只是处于 “原型”阶段而已。我们能从这种原型复用以下内容：
l 原型的层次架构。
l 原型的命名空间与命名空间的稳定的关联关系。
l 原型类与命名空间的稳定的关联关系。
l 原型类与类的稳定的关联关系。
l 原型类的方法实现逻辑。
希望对大家有所帮助，欢迎反馈！
当研发流程推荐到了原型构造阶段后，我们有了基础的原型工作产品，原型构建工作使我们理清了思路，验证了技术的可行性。
理想的（在全局设计阶段后的）原型工作产品的特点是：
层次架构稳健。
命名空间与命名空间的关联关系稳定。
类与命名空间的关联关系稳定。
类与类关联关系不稳定，原型程序员根据需要可以调整关联关系的强弱，比如：把聚合调整为依赖。
类的方法签名不稳定，原型程序员根据需要可以调整方法的名称、参数及返回类型等。
事实上，我们清楚，当前的原型工作产品就连以上的一些特点都不具备，或者不完全具备，于是，我们需要用更完善的更系统的模型工作产品来指导我们的编码工作，比如：从模型中我们发掘包与包的关系、类与包的关系、类与类的关系、类的详细实现...。
从另外一个层面，调整模型一定必调整代码更快，尤其当我们的产品很复杂的时候，“孰快孰慢”非常明显。可是，相反呢？我们的时间到哪里去了？哦，那里少了一个方法、接口里要添加一个属性、那个参数是简单类型还不够、改吧，改吧，反反复复，反反复复，我们也乐此不疲，^_^！
还有一个层面，如果我们宣称我们自己有非常良好的职业习惯，有人来与我们交流同类工作产品的时候，我们恭敬的请他们坐下来，找到笔墨、白板，画画我们的设计、勾勾我们的思想，接着打开我们的代码，一页一页的翻码，或者根本也不翻，叫他（她们）自己去读吧，这就是所有我们能做的了，当然我们还能张开嘴，^_^。这时候，我们会为“我们自己的宣称”而汗颜吗？
与其那样，我们还要设计吗？还需要搭建设计模型吗？几张纸（白纸、黑纸）、几支笔（铅笔、油笔）不就足够了吗？
也于是，还需要软件开发流程吗？不需要了，我们有嘴、有脑啊，也足够了，^_^，我问你那个方法参数是什么意思？你说它是字符串类型，而且只能不能为空云云，我们都悻悻的，^_^。
昨晚，我系统的学习了Crystal Report 9，发现Crystal Report 9超级强大，它当之无愧是报表瑰宝。如果你是编程高手，你可以在使用Crystal内置功能之余编写Crystal或Basic程序进行自定义。如果你是程序玩家，你甚至可以全部用程序来实现你想要的展现和计算。如果你根本不会写程序，Crystal Report 9也为你准备好了文本对象以进行丰富单元格表现、排序、平面或层次分组、公式工厂、公式专家、IIF和SELECT CASE逻辑构造、存储库、格式化段和格式化区、基于参数字段的用户交互、报表导入导出服务等。
Crystal报表向Web发布标准HTML页面，向Windows应用发布标准Windows界面。
很多、很多值得我们学习的地方，我的思路是沿袭Crystal的灵活性、摈弃Crystal的复杂性来研发我们自己的报表！
2005年11月25日
#
经过了两个小时的飞行，我们安全的降落在浙江萧山国际机场了，又是一次外出，跟上次的外出不太一样，我知道，我们这一行，日子并不“好过”，在杭州分公司停留了一个多小时，我们粗略的讨论了一下如何跟用户交涉的方案，之后，我们启程出发到浙江台州市，台州医药公司是公司的客户，在北京准备出发的时候，我了解了这一行的背景，台州医药公司还没有上线，就已经遇到了“可怕”的效率问题，也是因为效率的“可怕”，迟迟未能上线。随同SCM的两位开发人员，我们这一次要尽可能完美的完成任务。
又经过四个小时的路程，我们终于到了台州，台州是浙江省的一个市，因为我们到达台州的时候已经是晚上了，所以，看不清楚的是这里的景色，事实上，即使能看到，我已经对窗外的景色丝毫没有什么兴趣了，我的肚子很饿，从早上到现在就没有吃过饭了，我觉得有些亏欠自己的肚子。如以往的程序，到了台州以后，我们应约跟台州医药公司的领导一起吃饭。商务合同是去年12月初签订的了，直到现在还没有上线，他们讲，用友公司的办事效率也是差强人意。先是台药（是台州医药公司的简称）的财务总监来陪酒，她是一个典型的南方女人，一眼看得出点什么明堂的，精明、细腻、因为是领导，所以，言谈中也不乏“领导”的成分，吩咐一下左膀右臂，很快，她就离开了我们这一席，去陪另外的客人了，我对她的印象不深。接着，是台药的老总，他似乎是一路“杀”进来的，也象是在吼，自己找了个位子座下来，显然是喝了不少酒，但是，他的思路很清晰，他是一个幽默风趣的人，讲了很多，诚然，我们都是听众，专心的听他的讲话，或者说是严厉的批评更合适了。
之后，我颇有感触。
如果我们能把客户当成是我们自己人，象办自己的事一样来对待我们客户的事情，还有什么问题不能解决呢？
我们与客户的关系不是甲方和乙方的关系，我们两方都是在种树，种菜虽然快捷，但收获短暂，种树即使漫长，但收获也长久。
俗话说，榜样的力量是无穷的，因此，典型客户对我们产品的认可可以是无价之宝。
我在想，任何公司，如果它在每一笔生意是否赚钱这一问题上“纠缠不休”，那样的公司也不会走得很远，而不是相反，我们真正需要的是要赢取整个客户链。
如果我们的客户要借助类似“呐喊”的手段（引用台药的一位老总的话）来寻求我们的帮助的话，我们的“快速响应能力”是不是有些“颜面扫地”呢？
如果一个客户是要真诚的跟我们交心的话，我们就很应该静静的坐下来跟他们谈心。我理解，台药公司对用友公司的选择是相当理性的，引用台药公司一位老总的话，台药公司选择用友公司不是拍出来的（一般来说，一个感性的人在做一个感性的决定时有三拍，一拍后脑勺，二拍胸脯，三拍桌子，于是就有了决定），台药公司经过走访同行，四方比较才发现用友公司是最棒的（在这里，我发现了一种很好的外交策略，如果你要肯定一个“人”或者一件“事”，一定要有根有据，可以让“人”让“事”心悦诚服）。
“控制”一个行业的最好办法就是“控制“那个或者即将进入那个行业的人 ，老周有一个方案正在向北京方面呈报，他打算在浙江省高校里宣传用友ERP，免费提供很多针对大学生（被培训的学历可以有学士、博士）的ERP培训，去培养他们的针对管理的思考方式，去培养他们的针对管理的操作习惯，这不禁让我联想到了美国微软公司，微软公司在这方面有过之而无不及，微软公司可以向美国很多学校免费发送OS、OFFICE软件，供他（她）们使用，以期培养他（她）们的操作习惯，它可以把它的触角伸到小学生，我们一样可以把用友公司及其产品的影响扩散到所有的学生。
2005年11月15日
#
在那之后，结合自己在实际项目中的经验，我编写了《改错和功能增强 设计过程》的姊妹片《新产品研发 分析设计过程》，我区分了在经典软件设计过程中的两个视角，一个是构建时（Buildtime)，一个是运行时（Runtime)，一般来说，如果不是纯粹的后台服务，软件都会有人机交互界面，人机交互界面又分为两种，一种是在软件运行时需要人参与或干预的界面，比如：在此界面上录入数据，设置过滤条件等。另一种是在开发时（也即是我上面说的构建时）需要开发人员参与进行部分预定义的界面，比如：通过此界面上预制数据等。我通常都是从这两个不同的角度来分析软件，基于此，我能最大限度的挖掘跟拟建系统发生交互的外部角色（外部系统也是一种角色），随后，我能根据需求分析出外部角色相对于拟建系统的请求序列、拟建系统的响应和执行序列。不难看出来，实际上，我是在进行用例建模，随着分析设计工作的继续推进，我能深入分析拟建系统内部的功能的实现序列，这也相当于进行用例实现（Realize Use Case)......,大概就说到这里，附件提供了分析设计过程的中间工件，比如：构建时和运行时中间文档模板。“设计过程和工件规范”培训文稿中包含了实践过程的指导原则和检查点。“工件范例”包含了遵循这一过程的实践范例。
没有能在所有软件项目中都行之有效的方法论或过程，当我们遇到好的方法或过程时，好的做法去剪裁它，而不是简单复制。我希望我的贡献对大家的工作及自身能力的提高有帮助。如果你打算在你的项目中去应用这样的过程，你一样要经历一些剪裁。/Files/edgard/新产品研发 分析设计过程.rar
前一段时间，为能整理出适合我所在产品线几乎所有项目的“改错和功能增强详细设计”的模板熬了不少夜，随后招集了很多专家一起商讨和验证，然后定稿。现在分享给大家，希望对你们所有人有所帮助。
/Files/edgard/改错和功能增强 设计过程.rar
为 ERP客户化开发系列丛书（U8部分） 写序
今天，企业种类多样，业务流程更加复杂，ERP包含的功能越来越多，长期以来，ERP厂商一直都在努力，试图开发一个能满足各种企业的各种业务的ERP系统，但是，客户的业务流程总是会变，客户的需求总是层出不穷，变化的速度远远超过了ERP厂商推出新版本或开发新产品的速度，ERP厂商疲于奔命，即使使尽浑身解数也吃力不讨好。经过冷静思考，我们可以从低级的生物生态链找到卸掉ERP厂商多年包袱的原型办法，ERP厂商、增值开发商、集成开发商和ERP最终用户形成了企业应用软件的链条，他们承担了不同的职责，获得不同的利益。ERP厂商集中精力开发标准产品，负责提供功能强大的二次开发平台和集成开发平台，为支持灵活的客户化工作提供技术支持。客户化有三个级别，第一个级别是系统配置客户化，ERP软件支持通过配置用户接口和业务操作来满足客户的业务要求；第二个级别是允许客户修改，在软件许可的情况下，把部分ERP软件模块的代码开放给用户，ERP内置的系统部件拥有特殊的代码容器，容器可以大大简化对客户修改代码的管理、升级和测试；第三个级别是提供修改服务，不用做很大的客户化工作，ERP软件就能满足客户的大部分需求。因为独特的业务环境，客户还是有个性化的需求，ERP软件厂商提供开发工具或开发平台，充分利用客户或增值开发商的技术资源来实现客户的个性要求，只要客户化工作严格遵循ERP软件的编程规范，产品兼容性和集成就不是问题。
用友不遗余力，一直想探索好的科学的客户化工程，曾经开放过部分U8的源代码，因为无法或不能很好的升级客户化产品，只好作罢。U8已经能支持第一个级别的客户化工程，通过参数配置可以满足一部分客户要求，但是，U8真正灵活的客户化能力支持却要体现在第三个级别，U8呈现给用户的要是强大的二次开发平台。我们已经暴露了部分控件（比如：登录控件、参照控件、打印控件、自定义报表控件、单据控件和凭证控件）的部分编程接口，我们也支持在U8门户挂接二次开发接点，支持简单的用户权限查询等。显然，我们做得还远远不够，这只是开始，我们努力使下半年即将投入研发的二次开发平台能给所有关心它的人一个惊喜，一个大大的惊喜！
2004年10月12日
#
全局分析
－－－－－－－－－－
有一段时间了，我不遗余力的去探索时候特定项目规模的软件开发流程，实践表明多于两个大型项目遵循这样的核心工作流程都成功的交互了，现把它发布给大家以作参考：
•
•选择架构型别
– 我们通常会采用层次结构。
•抽取关键抽象
– 寻找在问题领域和方案领域都具有普遍意义的概念点。
•标记分析机制
– 把那些和问题领域(应用逻辑)没有直接关联的计算机概念和复杂的行为表述为分析工作的”占位符号” 。
•选择分析局部
– 对于拟建系统，选取具有高风险的局部作为此次迭代的内容。
•架构型别
– 架构型别为后续活动设立了一个共有的基础框架，用以承载逐步演进和累加的设计类容。
– 架构型别本身的重要性远远超过了架构中内容的重要性。
– 架构型别的核心是按照某种规则将关注点在宏观上作一个隔离，目的是确保架构在后续活动中稳定的被充实，同时促进架构中的内容更容易的被复用。
•选择架构型别
– 选择层次架构
• 层次架构特别适合中，大型系统 。
– 选择层次架构的动机
• 在设计时，层次架构对构件的依赖性进行了分组。
• 在运行时，层次架构为构件的可替换提供了支撑。
•定义与应用逻辑相关的架构
– 定义层次架构中的较高层。
– 在全局分析阶段存在很多的未知因素，因而只需要相对明确的界定层次架构中的较高层，比如“特定应用层”和“一般应用层”，它们承载跟应用逻辑直接相关的要素。
– 层次的界定将在后续的分析和设计活动中得到验证和调整。
– 在全局分析阶段不宜对较低层次作界定，因为较低层次往往依赖较高层次对它的服务要求，所以，我们很容易作一些无用功。
•选择架构型别－经验
– 元素间的关系：某一层内的元素只是跟同层元素以及相邻层元素之间有依赖关系，否则，我们的层次架构将很难扩展和维护。
– 元素的稳定性：层次越高，元素的稳定性越低，越直接反映问题域（应用逻辑）的内容及其变化。相反，越低层的那些对应于软件概念的元素要稳定很多。