IT博客-为了遗忘的记录-随笔分类-methodology

不把需求抽象，就会有无尽的需求

Raistlin — Fri, 17 Mar 2006 02:42:00 GMT

......
Ralin 说:
没有从需求中提炼出来究竟什么是实际需求。对需求一点抽象都没有。做什么通用产品啊。肯定会被这种无穷无尽的所谓需求搞死
icepeak 说:
是啊
Ralin 说:
我的神啊，那些用户要如何理解我们的概念啊。。。
icepeak 说:
我也面临着种问题
Ralin 说:
什么问题？
icepeak 说:
往往是时间很紧，不容我详细的去抽象
我的做法是先实现概念模型中的主要功能，实施的时候再逐步修改
Ralin 说:
你面对的和我们不一样，你可能是做项目，我们是做产品
产品的目的就是通用
不能把部分用户需要的概念强加给全部用户，这不是胡扯吗
icepeak 说:
你这种思想本身值得怀疑
Ralin 说:
怎么说？
icepeak 说:
产品的目的就是通用没错，但是你只说了一半
产品的核心部分是通用，但是面对用户部分是要个性化的
Ralin 说:
个别用户的需求不需要硬编码到数据库，到代码。这是我的看法
icepeak 说:
许多加大型的应用，他们实施的时间和开发的时间差，更有甚者，有很多是和使用单位联合开发
Ralin 说:
你所说的是项目。。不是产品
一个产品会面对千万个用户
一个项目的使用者一般是固定的，他的需求是具体的
icepeak 说:
我说的是产品，最典型的是企业应用类的系统
比如，我现在做的供应链管理系统，只能出功能模型，使是的时候50%的数据库结构会被更改或者取消
Ralin 说:
把会改变的东西和固定的东西分开来，这是程序设计的一个基本方法吧
icepeak 说:
很难啊
Ralin 说:
至少你可以把最抽象的东西独立出来。需要具体功能的时候再往这个框架上加东西。
icepeak 说:
打个比方：做客户关系管理软件，客户基本信息表是最基本的数据表
Ralin 说:
把固定的数据库设计独立出来
需要其它信息另建表，这种可以做到吧？
icepeak 说:
但是你的客户却告诉你，他们的erp系统中已经有了完整是客户基本信息表，现在的要求是把你们的系统靠上来
因为涉及同步维护的问题，新的系统中不可能建立客户基本信息表的副本
Ralin 说:
更改一下你获取基本信息的方法？
icepeak 说:
这种情况内核都会变的呀
Ralin 说:
如果你有个接口是用来获取基本信息的，有个基本信息的抽象类（只保存你需要的id）。就能比较灵活应对不同的基本信息
比如用Map来保存信息基本信息，灵活性就非常高
icepeak 说:
呵呵，理想是好的，肯定我们也应该这样努力，但是我觉得做到最后往往利这个目标挺远
写一个BasicInfo这样的类可能只是为了推广的系统能跑起来
Ralin 说:
你要有空去看看Shark的开源工作流，设计得非常灵活
icepeak 说:
那个是很多牛人的结晶啊
Ralin 说:
你可以写一个这样的类，但别写成
BasicInfo{
String name;
String phone....
}
用一个map来保存"phone"和05921234567 "name"和王xx 这样就不怕他们基本信息究竟要求些什么了
我是烦最近要改来改去YY的
icepeak 说:
用一个map来保存"phone"和0592...？？？？？？
为什么这么做呢？
Ralin 说:
这样做以后无论你想添加什么属性都无所谓。。。
客户要怎么改他的基本信息，代码都不用变
icepeak 说:
客户要改基本信息结构呢
Ralin 说:
比如说怎么改？
icepeak 说:
比如你设计是name做个key
现在客户的需求是用name+sex做为key
Ralin 说:
我指的是BasicInfo这个类的内部结构不需要因为客户的更改而更改
icepeak 说:
BasicInfo类比如有name等五个成员变量，现在按照需求多出来3个
Ralin 说:
没事...
你完全可以知道数据库里面有几个字段，字段名，值，类型
直接添加到map中就可以了
通过Recordset可以很方便获得表的信息吧？
象这种基本信息表，目的只是保存信息，显示信息。如果这样做可以实现，为什么非要硬编码到代码？每个用户需要变更的时候就要大动代码？
icepeak 说:
嗯
Ralin 说:
我现在就在想能不能在我的程序中这么做。但比较一下还是直接修改代码快。
icepeak 说:
一定程度上的适应性是要的
Ralin 说:
如果当时能够用比较灵活的方法，现在就不需要大改了，而且出错的可能性也会降低
icepeak 说:
这就是系统分析欠考虑的地方
Ralin 说:
我觉得这是具体编码上没考虑好.系统分析上也会存在这种问题。
不能把需求抽象化，肯定会有无穷无尽的需求。
icepeak 说:
是啊，系统分析的时候对需求估计的不足，经验问题

Raistlin 2006-03-17 10:42 发表评论

需求的问题

Raistlin — Mon, 19 Dec 2005 01:29:00 GMT

最近为lp写了一个文本选择(学生评语选择)的程序，没解决什么问题，却带来了不少问题：1,一堆bug 2,虽然提供了定制，但不直观,用起来"很麻烦" 3,用户环境的一些问题比如写的权限等Word版本等。偶lp对计算机不怎么感兴趣对这个程序的兴趣也就是能方便的用。每次问她这个该怎么那个该怎么都没得到想要的答案。最近看了篇文章觉得很有趣:
Trying to get a user to decide between a tree control, a list control, or a group bar is like trying to get a 2 year old to pick what career he wants to take when he/she grows up. It's not that they aren't smart or don't understand their needs, but the question is beyond their scope of understanding.
想要让一个用户在树型控件、列表控件和group bar中做出选择,就像要求一个2岁的孩子决定他/她长大后得哪种癌症一样。不是因为他们不够聪明或者他们不知道自己的需求，这种问题超出了他们能理解的范畴。
然后她现在告诉我这个程序不好用可能是因为出发点本来就不对。在n多语句库中好不容易选择完后还是要修改修饰，让语句通顺贴切，速度比原来快不了多少...
Somehow, when most applications are designed a process is followed that inevitably leads to one or more nice and neat application programs. These may be Windows GUI applications, web apps, or whatever, but the scientist in us developers likes to see straight lines and nice and neat boundaries between systems with well defined lines of intersection, union or whatever.
一般人现在都会觉得windows，ie浏览器用起来就是这么简单这么自然，可是在我看来，这简直就是奇迹。就算是游戏比如Quake,diablo,wow如果和一般的应用程序比较的话真是云泥之别。除了质量上的差别，一般的应用程序和这些东东的重要区别是：编写windows,ie,quake,diablo,wow的人不用从客户那里知道他/她想怎么使用这个软件。同样，编写病毒的高手也不需要问别人希望病毒怎样破坏他的电脑。

Raistlin 2005-12-19 09:29 发表评论

广为流传的一个关于项目管理的通俗讲解[转]

Raistlin — Mon, 19 Dec 2005 00:46:00 GMT

古老虾发表于 2005-11-9 13:25:50

想首先问大家一个问题：你觉得中国人聪明还是美国人聪明？
我见过最好的回答是美籍华人。
我们说美国人很愚蠢，为什么呢？
你们都考过T或G吧，他们经常会出这么一道题1/3+1/2=？
50%的人回答是2/5，这可是美国研究生入学考试的试题呀！
通常在这个问题之前还有一个1/2+1/2=？为什么？
他们怕太难了，先给个容易的热身一下。
我在美国的时候见过很多的PHD，对于美国人来说if...else...是逻辑，而if...if...else...就成了哲学，也是美国这么多哲学博士的原因：）
我们说美国人很愚蠢，那我们为什么还要学习他们呢？这个问题稍候我们会回答。
再问一个问题：如果你刚买了一个豪华的房子，可你三岁的儿子把整个墙壁上都写上“我爱长城永不到，我爱北京天安门”，你该怎么做？
有的女孩子说暴打，呵呵，这个答案从女生的嘴里说出来还是比较少见。
美国人怎么办？
他们会对孩子说：“你老人家真有绘画的天赋，简直就是毕加索的毕加索，你这一幅画至少能卖100万美金”你们知道美国人喜欢钱，用金钱来量化一定是效果明显。
但显而易见，您老人家把画画在墙壁上是不能永久保存的，所以我明天给你买一个画布，你就尽情的画吧。否则我们要损失多少个毕加索呀！
于是我们就可以看见我们的小宝贝在画布上快乐的滚来滚去。墙面也干净了。
中国人很聪明，从大家就可以看出来，但中国人聪明做工作就有了聪明的做法，他们往往是每个项目都是按照自己的见解来做。
而美国人如何来操作呢，他们就象洗澡，会在面前挂一张纸，上面写着先洗头，再洗耳朵，再细脸，，，这样做事情就有了一定的流程，渐渐的就形成了一套体系。
所以这也是我们今天来探讨项目管理的目的所在。
项目管理分九个知识领域，分别是成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理。
其中时间，质量和成本管理构成了三角形
大家在纸上画一个三角形
在各个边上标上时间、质量、成本（等边三角形）
任何一方的移动必定带动其他的变形，如果时间缩短，怎么样？就是我们常说的“献礼工程”，同时必定会影响质量和成本。问大家一个问题，这个三角形中间是什么东东？
对，是范围管理，也就是我们说的项目范围。这也就是我们常说的项目“项目管理三角形”
下面介绍一下项目管理的“项目管理三角形“
项目三角形中的成本，主要来自于所需资源的成本，自然也包括人力资源的成本。这个相信很好理解。
为了缩短项目时间，就需要增加项目成本（资源）或减少项目范围；
为了节约项目成本（资源），可以减少项目范围或延长项目时间；
如果需求变化导致增加项目范围，就需要增加项目成本（资源）或延长项目时间
通过“项目管理三角形“我们了解了项目成本、时间，质量和范围的简单定义。
我们说一个项目经理有多少时间是用来做沟通的工作的？
应该不少于75%的时间是用来沟通的，所以项目管理将项目沟通管理单独列了出来。
所有这些领域都有一个主线就是项目的整体管理来统一的。
由于时间的限制我们不详细讨论其他的知识领域，因为今天是入门的，哈哈
另外项目管理除了九个知识领域，还应该了解5个过程组
5个过程组就是：启动，计划，执行，控制，收尾。
这5个过程组贯穿于每个知识领域的始终，你们了解吗？
举个例子字来说：
某人（比喻）好不容易找了个女朋友，为了增进进一步的距离，他想来个欧亚8日游，于是他把自己多年的积蓄——3万元，一次性投入。
但在旅游过程中，他的MM看上了另外一个帅哥，于是人财两空，说明什么问题？
说明他的项目启动的时候就出现了问题，没有很好的做市场调研，结果过程就没有办法控制。
根据PMI的解释，接单之后项目自然转入启动阶段
于是他刻苦的工作，终于又攒了3万，这次他不和美女旅游了，考虑到自己的费用，他请这个姑娘看了场电影。
于是他带这个这个姑娘看了——《第一滴血》
看的那叫爽，姑娘看的也很爽，看看完后她觉得这个家伙有暴力倾向，于是又分手。说明什么问题？
对，没有进行有效的需求调查，也就是在计划的时候没有明确的需求定义。
于是他下次的时候知道了姑娘爱看歌舞剧，于是他就请一个靓女看了《天鹅湖》，可是以外有发生了——
进去后发现座位不在一起，等他们把位子换到一起的时候歌舞剧结束了，这说明什么？
对，说明没有很好的执行，起码在执行过程中没有进行有效的监督。
其他的过程不一一解释，我在这里强调的是收尾的重要性。
我们往往非常注重合同性收尾，却总是忽略管理性收尾。什么是管理性收尾呢？
某人同志吸取了所有的经验教训，终于领了结婚证，还应该干些什么呢？
对了，还应该把所有的经验教训总结一下，以书面的形式汇报给老妈，并张贴于门后。
然后在中堂挂一幅对联：欲谈恋爱者需先阅读门后之——《恋爱指南》
以后凡是自己的兄弟姐妹要谈恋爱的，必须先参阅门后的恋爱指南。
这样能起到什么效果呢，对，以后他们的恋爱项目操作至少能停留在这个水平。
这个过程怎样来保证呢，对，还需要我们的QA人员，也就是他的妈妈负责质量控制。
家规一条，不参阅者或不照此操作者不许谈恋爱！
大公司一般有质量管理部门（QA），QA的成员基本上都是由非常有经验的PM转型过来的老狐狸，是老总接班人的有力争夺者：）
这也是我们说一个失败的项目会培养一批优秀的项目经理的原因。
哪个门后的《恋爱指南》我们称之为文档，文档重要吗？我们说在电信科技处的同志们说重要，为什么因为他们管这个，但对于我们呢？
大家拿起你身边的一只笔，告诉我他多长？
有的说10厘米，有的说10。0987厘米。
我们说他的估算很精确，但不准确！！
这是我如果拿一只笔告诉你正好10厘米，然后和你的笔比对你是不是就比较容易得出测算？
这说明文档是非常重要的，有的人认为文档是最无聊的，项目结束后做个总结不就是了吗。
错，文档的整理应该贯穿于项目管理的始终。
文档的管理是对项目进行良好的跟踪和监控的一个手段，简单的讲就是根据你的项目计划进行你的文档管理。
一般档案分类主线是：立项、计划、执行、结束4大类；然后在每大类中，再根据任务或者团组分类管理，根据哪个需要根据你项目复杂程度和管理习惯，总之原则是方便你对整个项目进度的追踪。
以上我们讲了项目管理的九个知识领域，五大过程组，还有“项目管理三角形“，下面我们讲PMBOK。
PMBOK是项目管理圣经，也就是Project management body of knowledge，项目管理知识体系指南
它是美国项目管理协会（PMI）的核心指导出版物
但它象一本字典，往往你看到第三页会睡着：）
在此简单介绍美国项目管理协会（PMI）和国际项目管理协会（IPMA）
美国项目管理协会只有PMP一个证书，而IPMA有四级，你可以一毕业就可以考试，这个我们后面详细的讲。
下面讲几个名词，如果你掌握了，一和人讲项目管理你就抛出来，一定没有人敢小看你。
他们是WBS、甘特图、基准（BASELINE）、项目干系人和关键路径
WBS是WORK BREAKDOWN STRUCTRE ，工作分解结构
WBS的定义还是很麻烦的，PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式（BRAINING STORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。
比如我们要结婚了，怎么来分解呢
无非是办酒席，拍结婚照，，等等，这个在论坛上曾有人做了详细的分解，大家都可以找到。
我们说为什么WBS重要，而且大部分项目管理的咨询都是针对WBS的咨询
因为WBS做好了，以后工作就有了参考物，你就知道在不同的阶段你应该干什么，完成到什么进度。
其实WBS的划分是没有规则的，主要的考虑角度是方便你做各类的统计工作，为管理服务。
同样的一个项目其管理的侧重点不同，WBS结构的划分也可能是完全不同的。
衡量划分好坏的标准应该是看其是否满足你管理的需要。
甘特图也叫横道图等，很多名称，我们说它是甘特在第一次世界大战时开始使用，它就是在WBS的基础上将WBS形象化老控制进度
对于基准，我象举个例子。
我们在没有结婚之前，你脚踩几只船？
我们说法律允许但道德不允许，但你可以脚踩N只船：）
但当有一天你和你的朋友进了一个小黑屋子，然后带了两个盖章的本本的时候，你还可以脚踩N只船吗？
我们说此时就不允许了，因为你过了一个基准线（BASELINE）
如果你还想脚踩N只船就需要重新回小黑屋子再盖两个章就可以了。
那我们的项目要越轨怎么办，也就是项目变更？
我们说对这样的项目变更会影响各要素比如时间，成本，质量等
我们应该统一由项目管理办公室来进行控制，如果你要变更基准，必须要进行严格的限制。
在客户提出变更请求时，要建立变更申请登记表和变更申请表，并让客户签字。
有时候一些不是非常关键的模块PM也不至于一点不讲情面，该卖面子的时候还是要卖，尤其是当着对方领导的面，千万要卖面子，但是也别卖的太干脆，不要让他们得到的太容易。
PM在变更管理中需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
如果一个项目进行过程中，比如现在的点心的3G项目，你发现如果再多花一点时间就可以编写出对以后非常有用处的程序，但这个程序不在本项目范围之内，你要不要做？
对，我们说不能做，你可以重新起一个项目来做，但不能在这个项目里做，这样会是我们的项目成本超出，风险增加，而且和其他的项目缺少比对性和参照的价值。
这也是我们说现在有大约80%以上的项目失败的原因，我们说项目失败并不是项目进行不下去了，彻底破产，在PMI有明确的定义，凡是项目的成本超出预算，质量没有得到保证，时间超过预计等等都在失败的范围之内。
这个在华为做的很好，华为有个有名的增量开发的名声。
只用20%的功能先满足你80%的需求，其他的功能我可以开发升级的版本，于是就在小数点后平明的增加数字，于是就是了V1，V1.1，V1.11....等版本
它从来不一下子满足你所有的需求，我们大家想想，谁没有事情拿出自己的手机把所有的PING码都试用一下，我们说没有，我们大部分的需求是在打电话，发消息，打打游戏，对不对？
这点在项目管理中非常重要，请大家结合资料好好研究。
项目干系人是什么东东，谁给我举一个例子？
对，包括项目人员的老婆孩子，正确
我们说有的项目需要的时间很紧张，如果你的项目成功了，但项目的程序员们都成了光棍，那项目还是非常失败，至少不是丧心病狂的PM这么想。
合理解决项目干系人的冲突是个很累的问题，其中还包括你的只能经理们，你的董事长，你的客户，等等，等等，有的说没用？
好，如果你的项目进展不下去，你该怎么办？
对，开会，把你的高层找一个坐到会议室，不用他说话，只让他暧昧的看着大家，大家一定会想，这个家伙一定和领导有关系，我们还是好好的做这个项目，下一个项目再给他使拌子吧：）
所以为了不累死好好分析一下你的项目干系人吧
我们上次讲了一些基础的知识，包括什么是项目管理，项目管理包括什么？
你说项目管理有几个知识领域？
你说项目管理有几个过程组？
让我们想起了泡MM的例子是不是？
还有老母亲做QA的比喻
几天我们着重强调的是
项目是什么?人们常用“时间”，“资源(或缺乏资源)”，“某种工作努力”，“交付物或者产品”，“综合工程”，“缺乏凌驾其他班组的职权”，以及“预算”来给它下定义。实际上，项目是一种独特的工作努力，即遵照某种规范及应用标准去导入或生产某种新产品或某项新服务。这种工作努力应在限定的时间、成本费用、人力资源及资财等项目参数内完成。
首先给大家一个项目的定义，到底什么是项目？
根据PMPBOK的定义，项目是在一段时间内为完成某一独特的产品或提供独特的服务所进行努力的过程。
这个过程受到时间、人力、资源、成本、质量上的限制
项目有几个特征：1.临时性 2.独特性 3.一次性
下面大家告诉我下面哪个是项目：A惠普与康柏机构重组惠普与康柏机构重组。B建造一座新工厂 C改建道路 D工程材料采购 E开发软件包 F结婚典礼 G寻找拉登
有人说是寻找拉登，大家说寻找拉登有明确的结束时间吗？
当然我们可以假设寻找拉登50年如果找不到，项目就结束是不是？
所以说我们今天不讨论哪个到底是项目，所有的问题都要放到具体的环境下，否则没有意义。
下面大家可以开始提问了。
什么是WBS呢？
WBS是工作分解结构，就象一张道路交通图，它能够指引你如何从当前位置到达想去的地方。没有它，你可能就要迷路了。
怎样来做一个好的WBS呢？
有时候在接受新项目时前无例子可借鉴感觉分解时真困难, 因为每个人的解决问题思路不同,同一个项目不同的人有很多种分类, 因为可以按照工作的流程分解,也可以按照系统论的方法进行结构上的分解, 但我觉得有一条很重要的原则应该注意,那就是麦肯锡的精髓,他们在分解工作时非常强调的就是MECE, muturally exclusive, collectively exhaustive, 即相互独立,完全穷尽的原则, 也就是现在较流行的说法"横向到底,纵向到边" , 如果分解时坚持了这个原则, 我想一定会有Perfect 的WBS, 其实WBS并非是PMI的"真传", 只是被PMI起名为WBS, 有时候工作中我们也会用类似的方法解决问题无非是没有提升到理论高度, 但WBS确实是做事的核心步骤。
做一个WBS需要注意一些什么问题呢？
? 第一级通常与项目生命周期相同(如需求分析，设计，采购，施工……)
? 第一级应在项目进一步分解前完成
? WBS的每一级都是其上一级的片断(Segment)
? 一个工作单元只与一个上层单元相关
? 上层单元的工作内容应该等于其所有直接下层工作单元的总和
? 一个工作单元由一个人负责
? 在整个WBS中使用同一种定义，在整个组织中亦然
? 通过将人员包括进WBS来激励他去完成计划
什么是甘特图呢？
1.以图形或表格的形式显示活动。
2.现在是一种通用的显示进度的方法。
3.构造时应包括实际日历天和持续时间。不要将周末和节假日算在进度之内
什么是风险呢？
首先问一个问题
你们说在一个项目中，初始阶段和结束阶段哪个时候项目的风险大？
对，是开始的时候，因为在开始的时候有无数的不可控制的因素。
那什么阶段的损失大呢？
对，在结束的时候，所以说两者是相反的/
所以说在项目的启动阶段成功的可能性最小，风险发生的概率也就最高，但是这时候一旦预计的风险发生了，损失是最小的。
想想广州和深圳很多烂尾楼？损失会有多少？？？！！！！！
另外我们要明确几个定义：
1是确定性。具有明显的可能性，比如中国和韩国对抗赛，胜负是很明显的：）
2是风险。韩国队能赢中国队几个球是一种风险的预测。
3是未知性。中国和美国比赛门球那就是未知的：）

Raistlin 2005-12-19 08:46 发表评论

数据的版本管理

Raistlin — Mon, 25 Jul 2005 01:19:00 GMT

刚刚碰到数据的版本管理问题，以前看《深入潜出MFC》的时候看到serialize的Schema的时候就跳过，因为没意识到自己可能会碰到数据的版本问题。软件产品的版本管理应该是一件让人头疼的事情，其中也许有很多问题需要考虑，我想对旧版本数据的支持是很重要的。

    如果新的系统提供了对最新环境的支持，比如对最新数据库的支持以提高效率，也许用户并没有升级数据库的打算，那系统必须支持原有的环境。这是对运行环境的支持。还有就是是对旧版本数据的支持。

    数据也许保存在文件中，也许保存在数据库。对文件的升级比较容易，只要原来保存了版本信息，以旧版本的格式读入数据，按照新版本的格式保存就可以了。数据库的情况比较麻烦，需要改变数据库设计，如果数据库的设计需要大的改动:比如连主键都替换掉，这种情况数据库升级就麻烦了...

    在数据库和文件里面保存版本信息还是很有必要的，读取保存数据的时候先判断版本。设计数据库的时候尽量考虑以后版本升级的问题。这样软件的升级会比较容易。

Raistlin 2005-07-25 09:19 发表评论

简单的代价

Raistlin — Mon, 25 Jul 2005 01:18:00 GMT

在一个小安装程序上花了很多时间，本以为是很简单的:创建数据库，修改一些数据，拷贝文件，注册一个服务。为了实现功能，做出一个老板可接受的界面(界面都是俺先做，老大们再来定)

首先，我用MFC来创建这个工程，因为是安装程序所有使用静态链接库，项目中原来那些共用的mfc扩展dll就不能用了。而那些mfc扩展dll的工程直接使用了宏AFX_EXT_CLASS，要在其基础建一个静态库版本的工程的话，要改半天，而且我又没权限改，干脆直接拿过来修改。建议读者们在写mfc扩展dll的时候不要直接使用AFX_EXT_CLASS 而是使用自定义的宏，方便以后改成静态链接库，比如(从profuis的工程文件中copy而来)

#if (defined __PROF_UIS_IMPL__)
        #if (defined _AFXDLL && !defined __STATPROFUIS_WITH_DLLMFC__)
                #define __PROF_UIS_API _declspec(dllexport)
        #else
                #define __PROF_UIS_API
        #endif // _AFXDLL
#else
        #if (defined _AFXDLL && !defined __STATPROFUIS_WITH_DLLMFC__)
                #define __PROF_UIS_API _declspec(dllimport)
        #else
                #define __PROF_UIS_API
        #endif // _AFXDLL

        #pragma message("   Automatically linking with ProfUIS223 library")
        #pragma message("      (Professional User Interface Suite)")
        #pragma comment( lib, __PROF_UIS_LIB_NAME )
#endif

其次，关于安装程序的界面一直不能定下来，已有三个版本被枪毙，最近这个总算大概定下来。程序员看待程序的方式和老总、客户差别很大，最保险的方法是模仿典型的安装程序的界面。

再次，我想抽取出几个有用的类，功能独立了，但和界面的交互麻烦了很多。简单的事情反而变复杂了。一个类的功能如何强大如何独立，总是为某个工程服务的？在写这个工程的时候还为这个类考虑太多前途，等于拿石头砸自己的脚。还有看到一些代码被拆分成一大堆函数，一大堆异常，一大堆数据库Rollback..有的事情本来是简单的，我们把它给复杂化了，有的事情本来就是复杂的，随便想给它简单化反而会更复杂。

看到mfc example和网上下的代码的时候我经常会想:什么时候我才能写得那么漂亮，把握得那么准确！

Raistlin 2005-07-25 09:18 发表评论