导航↓ 相册|收藏博客|加入友情链接|给博主留言
我要啦免费统计阅读使人充实,会谈使人敏捷,写作与笔记使人精确。史鉴使人明智;诗歌使人巧慧;数学使人精细;博物使人深沉;伦理之学使人庄重;逻辑与修辞使人善辩。-培根
黑猫大队长
2018-1-15 21:46

™™™
2017-10-18 10:12
™™™
2017-10-18 10:11
™™™
2017-10-18 9:52
Z浪迹天涯
2017-10-16 1:3
sunnyrl
2017-9-13 12:2
pangdan2007
2017-7-10 19:54
  • 创建:2007/2/23
  • 文章:973
  • 评论:5127
  • 访问:966498
  •  

2007-7-17 13:17 | 最近的一些杂感

1.差一分往往是差一大步
我们一生会经历无数次的考试,在没有达到分数线的时候很遗憾和懊恼,当往往又给自己找借口,觉得只差一两分了和别人的差距不大。有这种想法的人恐怕不在少 数,其关键还是没有理解学习曲线的真正含义,学习曲线告诉我们每个人在达到了知识学习的一个极限后往往要进步一两分都是很困难的事情。有太多的运动员 100米可以跑进11s,但要跑进10秒的人就微乎其微,有些运动员跑入11s可能1,2年就达到目标了,但可能付出一生的努力都无法达到10s内的目 标。量变的积累较为容易,但要出现质变却很困难。

2.考试和学习要按着100分的目标去准备
如果每次考试都按着60分的目标去准备,那很可能是Fail掉。考试过程中有太多的不确定因素你可能根本无法预测到。没有最好只有更好,但确应该按照最好的目标去准备。按着最好去准备可能最终结果的好,而如果按着好的目标去准备那就可能是不好了。

3.没有问题是最可怕的
没有问题就意味着能够成功,而往往结果却是失败。有问题代表我们在积极主动的去思考,思考后才能够在理解基础上去消化。提不出问题的往往很难说对一件事物 有了本质的理解。经常问题太多的人只能达到中等的水平,经常把问题提出的人可能解决问题的能力较弱。绝顶的高手可能并没有经常提出问题,但却是把问题提在 心里提给了自己,只是自问自答了而已。

4.察言观色
公司附近卖烟的老大爷是察言观色的高手。我每次要买烟的时候,远远还隔几十米他就会把我要的牌子的烟拿出来准备好。如果我先摸了烟,他又知道我平时不带火 机,而远远的把火机准备好递给我。而有时我虽朝他走去,大爷往往却没有任何动作,难道是否要买烟还会体现到我的眼神和表情上面?

编辑 | 阅读全文(1049) | 回复(0),人月&神话 发表于 2007-7-17 13:17

2007-7-17 13:17 | 游子吟

慈母手中线, 游子身上衣。

临行密密缝, 意恐迟迟归。

谁言寸草心, 报得三春晖。

编辑 | 阅读全文(780) | 回复(0),人月&神话 发表于 2007-7-17 13:17

2007-7-17 13:17 | 周易与人生哲理-转载

一、处理天人关系的三大法则:识天、顺天、乐天
 
《周易》关于吉凶祸福的判断在很大程度上依赖于自然规律。

《周易》有一个基本观点,就是自然规律与社会规律基本上是一致的。因此,它总是用自然现象来类比社会现象,用自然现象的己然性来论证社会现象的应然性。这 里,《周易》首先强调的是知天,即认识、掌握自然界变化的规律。《周易》用一整套特有的卦象系统,把自然界复杂的变化概括地予以表现,然后让人根据自然界 变化的规律去认识自己目前的处境,设计自己应该采取的行动。比如蒙卦,上艮下坎,从卦象上看,是一座高山把泉水蒙盖住了。《象传》云:“山下出泉,蒙。” 处在这种情况,就意味着,目前的局面较为蒙昧,但很有希望,只要能够启蒙、击蒙,让清泉流出来,就大吉了。再如晋卦上离下坤,离为火,为日,坤为大地,象 征太阳出于地上,象征事业兴旺发达,君子贤人在位。

也许在有些人看来,这些类比有些简单,失之牵强,但是这在几千年来的古人已经难能可贵的了。更为深刻的是六十四卦的整体排列所体现的宇宙变化,特别是伏羲 六十四卦的排列,这个排列可以用来表示一年三百六十五天的阴阳递转,显示春夏秋冬,二十四个节气;也可以用来描述天象的变化,把斗转星移囊括其中。更奇妙 的是,这种排列不仅概括了中国特有的太极思维的规律,而且符合二进位制。因而发明了二进位制的莱布尼兹不能不承认,早在他之前数千年的中国古人已经知道了 二进位制。有关六十四卦整体模型的系统研究目前已经相当深入,人们从这个复杂而又有序的动态系统发现了相当多的宇观规律。不仅六十四卦是一个系统,囊括了 许多自然的规律,堪称宇宙的一个科学图式,就是一个卦,虽说只有六爻,其阴阳关系的“承”、 “应”乘”比”据”的演变也是一个运动着的微型宇宙的抽象概括。很好地认识掌握这套符号系统,深入地灵活地操纵这具宇宙的动态模型,也就是知天了。
……
编辑 | 阅读全文(1220) | 回复(1),人月&神话 发表于 2007-7-17 13:17

2007-7-17 13:17 | 念亲恩

长夜空虚使我怀旧事,明月朗相对念母亲,父母亲爱心,柔善像碧月,怀念怎不悲莫禁

长夜空虚枕冷夜半泣,遥路远碧海示我心,父母亲爱心,柔善像碧月,常在心里问何日报

亲恩应该报,应该惜取孝道,惟独我离别,无法慰亲旁,轻弹曲韵梦中送

编辑 | 阅读全文(797) | 回复(0),人月&神话 发表于 2007-7-17 13:17

2007-7-17 13:17 | 数据库设计指南-整理

数据库设计之前

在数据库设计之前首先应该有明确的数据库设计规范,包括表,视图,字段等的命名规范,设计约束和存储过程等的编码规范。同时数据库设计应该遵守从逻辑设计 到物理设计的实现思路,在充分了解客户需求的情况下,创建数据字典和ER模型,遵守数据库的设计范式等基本要求进行设计。

设计表和字段

对于复杂的业务系统数据库设计,首先从ER图入手从逻辑模型转入物理模型后可得到相应的数据库表,数据库的表和字段的命名都能够规范和确切的表达数据项的 含义。表的设计和划分标准一般要达到第三范式,3NF也通常被认为在性能,扩展性和数据库完整性方面得到良好的平衡。但3NF又不是绝对的准则,当有时存 在性能方面的考虑时候,我们又适当冗余而提高性能。

对于Oracle ERP系统而言,每个数据表都默认有创建人,创建时间,更新人,更新时间和是否有效五个字段。这是我们可以借鉴的重要内容。另外在数据库设计字段名称的选 择上要小心和数据库系统的保留字发生冲突,如Type,Name,DESC等都可能是数据库重要的保留字。

在表中包含一个“删除标记”字段,这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。另外在 设计数据库时候有时候常利用表的触发器来保证某些参照完整性,但触发器往往影响到程序的调试,而且是不容易被别人察觉到的业务规则,所以进来通过其他方式 来实现触发器的功能。对于表字段的容量也是进行设计的时候要考虑的问题,一般在设计时候都需要对字段长度留一定的余量以方便后期的扩展。

选择键和索引

在设计数据库时候往往可以使用具有唯一性特点的某些编号字段做为数据表的主键,但推荐的做法则是通过数据库自增长或自动生成的无意义字段作为数据表的主键。这样就很好的控制了数据库索引的完整性和效率,而且当……
编辑 | 阅读全文(1067) | 回复(0),人月&神话 发表于 2007-7-17 13:17
关键字:理论探讨 PLM
瀑布模型/改进的瀑布模型
虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段进行,每一个阶段都可以定义明确的产出物和验证准则.瀑布模型在每一个阶段完成后都可以组织相关的评审和验证,只有在评审通过后才能够进入到下一个阶段.
 
由于需要对每一个阶段进行验证,瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠,而应该是在评审通过,相关的产出物都已经基线后才能够进入到下一个阶段.
 
 
瀑布模型的优点仍然是可以保证整个软件产品较高的质量,保证缺陷能够提前的被发现和解决.采用瀑布模型可以保证系统在整体上的充分把握,使系统具备良好的扩展性和可维护性.但对于前期需求不明确,而又很难短时间明确清楚的项目则很难很好的利用瀑布模型.另外对于中小型的项目,需求设计和开发人员往往在项目开始后就会全部投入到项目中,而不是分阶段投入,因此采用瀑布模型会导致项目人力资源过多的闲置的情况,这也是必须要考虑的问题.
 
很多人往往会以进度约束而不选择瀑布模型,这往往是一个错误的观点.导致这种情况的一个关键因素往往是概念需求阶段人力不足.因此在概念需求阶段人力能够得到充分保证的情况下,瀑布模型和迭代模型在开发周期上并不会存在太大的差别.反而是很多项目对于迭代或敏捷模型用不好,为了赶进度在前期需求不明确,没有经过一个总体的架构设计情况下就开始编码,后期出现大量的返工而严重影响进度.

架构设计是软件开发中一个重……
编辑 | 阅读全文(2104) | 回复(1),人月&神话 发表于 2007-7-17 13:17
1.可维护性
代码的可维护性和可扩展性的第一责任在架构,因为架构要做相关的分析模型,划分相关的单元模块和接口,考虑组件和复用等各方面的问题. 架构设计是高层次的往往只抽象出相关的类和包,对于每一个类中应该设计哪些方法和函数,并如何组织这些方法和子函数的调用关系,还必须进行详细设计,这是编码的可维护性和可扩展性的两个最基础的内容.
 
能够准确表达代码实现意图的言简意骇的注释是源代码可读性的一个重要内容.好的源代码应该是可以自解释的,因此注释不应该太多也不应该全是些照字面翻译语句的垃圾注释.注释的量一般占代码总量的10-20%就可以了(如果注释量超过30%说明垃圾注释太多,代码的自解释性不好很多应该拆分为子函数的没有拆分等原因).源代码文件的文件头要有注释说明整个类的实现功能和流程,调用多个子函数的主方法方法头要有明确的实现意图和调用步骤的注释(很重要),以方便维护人员和自己阅读代码.
 
方法和变量命名等要严格遵守相关的编码规范进行命名.名称不要怕长,名称要能够完全的体现出方法所实现的功能.如根据某一客户编号查询其的所有定单,则GetInfo,GetOrderInfo等不是最好的方法名.而应该采用GetOrderInfoByCustomerNo,通过这种方法名称即使不加任何注释其它人员也可以很好的阅读你写的代码.
 
一个类文件建立代码行不易超过2000行,超过2000行都应该拆分相关的扩展类或Helper类.在一个类文件中一个方法或函数不易超过50行,超过50行的可以考虑拆分相关的子函数.但这个规则也需要灵活考虑,比如对于一些数据有效性或完整性判断的函数,超过50行一般不会存在任何问题.
 
每个软件开发项目开发前都应该定义相关的编码约定或规范,该文件包含了命名,缩进,注释,布局等各方面的内容,在……
编辑 | 阅读全文(869) | 回复(0),人月&神话 发表于 2007-7-17 13:17
组织或项目既可能是买方,也可能是卖方,还可能同时充当买方和卖方的角色.当你是买方的时候你要进行采购规划,准备采购文件,发起招标,选择供应商,进行询价和洽谈,签订合同并对合同进行管理和收尾.当你是卖方的时候要准备项目建议书,应标文件,进行投标,当中标后还要进行商务上的洽谈并准备签署合同,合同签署完成后对其进行管理和收尾.
 
因此PMBOK的采购管理包括了采购规划,发包规划,询价,选择卖方,合同管理和合同收尾6个过程组.其中合同是具有法律效力的文件,卖方有义务根据合同提供相关的产品,服务或成果.而买方则有义务提供货币或其它有价值的对价.复杂项目要求同时或先后对多个合同或分包合同进行管理.这种情况下,单项合同的生命期可以在项目生命期的任何阶段结束.
 
对于采购规划过程,项目范围说明书,WBS和项目管理计划是重要的输入.范围说明和WBS重点是用来确定需要采购的东西,分析是自制还是采购.另外采购计划制定时候需要参考项目管理计划中的分析登记册,分析采购和合同协议相关的风险.另外再来考虑采购计划要决定采购什么产品或服务,具体或大概的数量要求,什么时候要,要多少钱等相关信息.要获取这些信息就必须参考项目管理计划中的资源要求,进度计划,费用估算和基准.采购管理计划和合同工作说明书是两个重要的输出内容,采购管理计划是确定整个采购6大过程的标准,流程和如何做.而合同工作说明书则是确定究竟要提供的产品和服务的范围,具体的规格型号特征,数量,交期,质量和性能要求等.如果一项工件确定是自制了就谈不上后面的相关过程了,因此自制或外购决策也是计划阶段的一个重要输出.
 
对于合同类型一般分为固定总价合同,成本偿还合同和时间材料合同.按买方的风险由大到小排序为CPPC->CPFF->CPIF->FPIF->FP.固定总价合……
编辑 | 阅读全文(1273) | 回复(1),人月&神话 发表于 2007-7-17 13:17
分层在英文里面有Tier和Layer两方面的含义。Tier主要是只硬件上的分层,如客户端,应用服务器和数据库服务器。而Layer主要是指软件系统结构下的分层。而这里谈的主要还是软件体系结构上的分层。
  
最近经常看到的DotNet多层架构,七层架构等词语。归根到底其核心还是数据资源层,逻辑层和表现层三个层次。其它层次基本上都是基于这三个层次所做的扩展。在做一个软件系统的时候,具体如何分层跟要采用的系统架构有密切关系,而要采用何种系统架构又和业务需求密切相关。因此,是业务需求在驱动具体解决方案的分层,分层和独立新的子项目都绝对不是越多越好,而应该有充足的需求来支持。
  
1.高效开发的分层方案(数据库存储过程+DA数据访问层+UI层)
是否应该使用存储过程或者说业务逻辑是否应该放在存储过程中一直是争论的一个焦点问题。但不可否认的是使用存储过程,并将业务逻辑放在存储过程中是一种值得推荐的高效开发模式。存储过程的可移植性和可维护性一直是一个问题,但只要我们注意了包,函数和子存储过程的划分,存储过程一样是很容易维护的。
  
从2001年开始使用DotNet开始,我们就一直借鉴了IBuySpy的案例采用这种开发模式,开发的仅存储过程代码可能就超过50万行,2003年后台数据库要移植到Oracle数据库是遇到的最大一次挑战,整个项目组花了3个多月的时间完成了迁移。但经过实践证明,这种简洁的开发模式和分层方式是完全值得中小型项目推广和使用,以获得最大化的开发效率。
  
由于业务逻辑放在存储过程中,因此没有专门的业务逻辑层,仅仅保留了数据访问层,而且采用存储过程这种方式的时候整个DA层都完全通过代码生成器或数据访问组件来实现。对于数据处理和传输也没有……
编辑 | 阅读全文(1933) | 回复(0),人月&神话 发表于 2007-7-17 13:17

2007-7-17 13:17 | 死亡之旅之摘录

快乐在于能够长时间的为自己认为值得的事情努力工作,不管它是什么.一个人也许会在照顾妻儿中找到快乐,而另一个人可能在打劫银行中找到它.很有可能还有人热衷于数年投身于没有明显成果的纯粹的研究工作之中.

请注意每种情形的独特个性.任何情形都不会完全相同,而且你也没有理由有此期望.每个人都必须为自己找到虽然需要付出艰苦努力却能够令自己快乐的工作.反 之,如果你在为自己寻求假期悠长而且能够及早退休的轻松工作,那么你就已经选错了职业.也许你应该去表演杂耍,甚至还可以投身政治.
--Jubal Harshaw

你永远都不会致力于完全有信心之事.没有人会狂热的呼喊"太阳明天会升起".因为他们知道,太阳明天必将升起.一旦人们狂热的沉迷于政治,宗教,信仰或目标,无一例外都是因为他们并不能完全确信这些信仰或目标能够完全实现.
--Robert Pirsig

任何首席指挥官都不应该去执行连自己都认为有缺陷的计划,他必须提出自己的理由并坚持对计划进行修改.而且为了不成为导致自己军队失败的工具要不惜最终提出辞职.
--拿破仑

你无法强迫团队凝聚在一起.你只能期望他们会凝聚,你可以祈祷好运,你也可以采取行动增加团队凝聚的可能性.但你不能安排凝聚发生.这个过程极其脆弱以至于根本不可能控制.
--Tom Demarco

尽其所能的找出最优秀的人才来辅佐你,然后进行授权,而且不要干扰他们.

传统的科学方法一直有最佳的后见之明.对看清楚你所到过之处很有帮助,对你自己已经知道的真相进行检验也很重要.但它并不能告诉你应该做什么.
--Robert M.Pirsig

系统动态学是研究我们周围世界的一种方法.与那些通过把世界分解为越来越小的部分进行研究的科学家不同,系统动态学家会从整体的角度来看待事物.系统动态 学的核心思想是理解系统中……
编辑 | 阅读全文(1092) | 回复(0),人月&神话 发表于 2007-7-17 13:17
最佳实践:不要盲目的将最佳实践作为必须遵守的戒律,但可以作为生成自己最佳方法的起点。

1.正式的风险管理

2.对接口达成一致的意见。包括硬件接口,软件接口已经你的系统同外部系统之间的接

3.同行评审。包括检查,走查,评审等等。虽然这些概念众所周知,但团队由于这些活动将减慢项目的速度,因此它们在死亡之旅项目中常常被忽略。虽然大多数人在理智上都同意同行评审非常有用,但在死亡之旅项目的那种沉重压力下,每个人都会考虑尽快的完成自己的工作,而压根想不起需要其它团队成员来评审自己的工作产品。

4.基于度量的进度和管理。这就是我们应该依据以往项目的度量结果来安排进度和进行估算。但当我们没有出现死亡之旅项目的时候,很少有人去注意和记录这些有用的度量历史数据。没有这些历史数据的记录,我们就很难在新的项目中做出准确和客观的估算。

5.多设置短周期的检查点和里程碑。与其每隔两三个月设置一个里程碑,还不如按星期或天来设置短期的里程碑或检查点。迭代开发或Daily Build可以帮助我们达到此目的。

6.项目计划和项目的实际进度在整个项目范围内保持透明。

7.针对质量目标进行错误跟踪。这种观点重点在于尽早的在开发过程中发现,跟踪和记录问题。不仅能够预测最终系统的缺陷水平,还可以用最小的花费来解决问题,而不用一直等到项目的系统测试阶段。

8.配置管理。不管是被称为版本控制或源代码管理,配置管理在大多数压力巨大的项目中都是必须的。

9.以人为本。必须要对项目和团队成员给予足够的重视。
 
最差实践:相对最佳实践而言,往往惨痛的教训更让我们记忆犹新。避免灾难往往比追求完美更加重要

1.如果采用相似项目的统计结果来作为比较标准,不要期望进度的压缩程度大于10%。

2.不要为了压缩进度而接受新……
编辑 | 阅读全文(1051) | 回复(0),人月&神话 发表于 2007-7-17 13:17
系统思维始终和动态过程是联系在一起的。系统动态学从整体的角度来看待事务,考虑系统中各个对象和因子间的相互影响和作用。当系统中各个因子间的相互作用力达到一致的时候,系统处于一种动态平衡的状态,当任何一个因子由于外界环境因素影响而改变都会打破这种平衡,动态的系统在这种平衡被打破后由会去不断的去调整各因子的值和相互作用,直到下一次动态平衡。

I Think,I see.对于基于这种思想的动态思维建模和模拟软件iThink能够为我们很好的将我们头脑里的想法用模型记录下来。我们相信直觉,直觉也经常帮助我们做出准确的判断,但对于多于复杂的多因素影响的系统直觉则往往是错误的。即使直觉正确也经常只能够告诉我们是或否,但具体的数量级的概率或精确点的数据则是无法得到的。经验或直觉在没有通过模型固化下来之前是没有很好的传递性和继承性的,只有通过模型将思维固化下来才能够形成相关的理论或方法。

对于软件团队中人员流动问题在《最后期限》一书中也专门进行了模型的模拟。在这里将根据自己的思路对该模型重新进行整理和建模。首先我们需要得到一个在人员不流动,其项目团队成员都是熟练员工的情况下的一个平衡模型。在这个平衡模型下堆积100个功能点的需求,每天流入新需求约5个功能点,项目团队成员 10人,每周工作40h,每小时的生产率为0.0125FPS/h,在这种情况下项目以迭代方式进行多版本发布,每个版本持续时间为8周,因此新提交的需求一般在2个月后就可以上线运行。在这种情况下我们得到一个平衡的模型,在这个模型模拟Running的过程中,堆积需求始终保持在100FPS.




对于每周40h是……
编辑 | 阅读全文(2208) | 回复(0),人月&神话 发表于 2007-7-17 13:17
对于这三个词既可以形容企业和员工间的关系,也可以形容管理者和成员间的关系。

员工对企业的认同&归属感体现在公司的企业文化,因此没有企业文化的公司很难形成跟随者的关系,员工在企业中看不到自己发展机会,个人与企业处于一种完全雇佣与被雇佣的经济利益关系,一种剥削和被剥削关系。好的企业重视企业和员工的共同成长,形成企业自身的企业文化,员工有一定的归属感,但属于一种有福同享而有难难以同当的跟随者关系,一旦企业出现危机则做鸟兽散。患难见真情,真正的追随着是能够共患难的员工,但前提是企业始终高度重视员工的利益和个人发展,员工对公司企业文化的高度认同。

对于管理者和成员间,我们却往往要做的跟随者都很难。管理者&被管理者关系是基于公司的企业文化和管理规程,如果成员对这个客观因素都不认同,那则只能停留在服从的状态。管理者既要考虑最大化实现公司的价值,又要考虑团队成员自我发展,同时管理者自身素质和技能必须得到成员的认可,因为管理者很多时候扮演角色是教练而不是领导。

小说《输赢》中周锐的团队是值得我们学习的,但只能说是跟随者。《亮剑》中李云龙和张大彪,魏和尚关系可以真正称之为追随者,因为这是用命换来的。只有管理者为了成员甘于牺牲自身利益时候才可能真正朝追随者发展。



 
编辑 | 阅读全文(1308) | 回复(0),人月&神话 发表于 2007-7-17 13:17
(共 973 条) 1 2 ... 38 39 40 41 42 ... 64 65 翻页至

仅列出标题