设计的核心任务之三：确保正交性
摘要：写面向对象设计原则的文章很多，但在我看来面向对象的一些原则是虽然是对的，但不够精练。大多面向原则其实可以用三个支撑点推导出来：确保正交，控制层次，信息隐藏。这一篇里谈一下确保正交性。抽象是设计工作的起点，而抽象的结果可以是一个具体的概念，也可以是一段逻辑。正交性则与抽象的结果有关联。为了理解正交性，我们先来看一下这个词的几何解释：当两根直线互相垂直的时候，我们认为这两根直线是正交的，否则的话这两根直线就是不正交的。这似乎和软件没什么关联。但如果我们假设相交的不是两根直线，而是两根圆柱的话，那么我们就可以看出来正交和非正交的差别所在。在正交的情况下，两根圆柱的最大接触面积始终会等于圆柱截面的面积
阅读全文
posted @
2012-05-30 00:29
理想流
阅读(2678)
推荐(1) 编辑
编码质量与命名
摘要：很多人以为提高编码质量，需要很多激动人心的创新，需要明显的飞跃，这也许对，但我个人感觉项目中提高编码质量是个水磨功夫，要一步步积累，方法论大多时候帮助不大。这次先从命名说起。当我们看到一份设计图或一份代码时，大多数人会【望文生义】。但使人【望文生义】却正是语言文字的根本使命。因此，如果一个函数被命名为Add()，但内部实际做的是减法，那么这份设计或者这份代码，一定是很难理解的。于是一个非常现实的问题就摆在了我们的面前：我们究竟应该如何为类，为方法等等命名？以命名而论，有两个较大的陷阱：一个是名实不符，一个是词义混淆。名实不符的常见情形又有两类。比如：以偏概全。假设说一个方法被命名为Output
阅读全文
posted @
2012-04-23 00:17
理想流
阅读(2928)
推荐(5) 编辑
设计的核心任务之二：信息隐藏
摘要：假使说我们认同软件的构造是一个复杂的过程，那么管理这种复杂度必然需要一些技巧。而为了找出这些技巧，则需要先瞄一眼这种复杂度的基本构成。软件的构造过程牵涉了两个最为基本的要素：一是软件，一是构造软件的人。假设说存在着一个标准的人，这个人智力水平恒定，创新能力恒定，技能水平恒定。那么软件的复杂度只决定于其自身，比如软件所需要面对的业务规则，所需要的计算水平等。应对这类复杂度的有效手段是优化方法，好比说快速排序的效率大多时候就是比冒泡排序好。当我们开始考虑人的可变因素时，复杂度的来源则发生了变化。人是有着许多与生俱来的特质的，比如说：人是会犯错的，人同一时间可以处理的事情是有限度的。因为这些特性，人
阅读全文
posted @
2012-04-18 00:03
理想流
阅读(2201)
推荐(4) 编辑
设计的核心任务之一：层次的控制
摘要：对于软件而言，层次是让人又爱又恨的东西。很多问题是通过增加层次解决的，但另外一部分问题也是因为层次而导入的。我们来分别看几个例子。例1：很多时候我们并不希望最终的应用绑定于某个指定平台，比如:Windows。为了达成这种跨平台的目的，就需要在OS和应用之间加入一个中间层，这个中间层负责屏蔽不同OS的差异。实际上，Java虚拟机等走的都是这样一条路线。例2：当使用XML文件保存配置信息的时候，我们并不希望XML的结构在整个程序中随处可见。比如说：现在我们在Configuration/OutputFolder节点下保存了缺省保存目录，但将来很可能节点变成了Configuration/OutputF
阅读全文
posted @
2012-04-09 00:03
理想流
阅读(2106)
推荐(2) 编辑
软件工厂是否真的可能存在？
摘要：一点说明：作为程序员，通常心里是讨厌软件工厂的，但很多时候问题自身皆有其内在理性，并不以个人的偏好而改变其发展的轨迹。所以程序员一旦谈及和自身喜好相关的问题时，尤其要摒绝个人好恶，否则就会离问题的真相越来越远，而只有一腔情绪。就我个人观察软件工厂大致处在这样一种地位：经营管理者迫于成本的压力，总是潜在的期望其可能实现；而程序员群体自身则总是对其嗤之以鼻。为什么在经营层面软件工厂有如此大的诱惑力？这不难理解，如果软件可以用工厂的模式来运作，那么程序员的可替换性将被无限强化，这样软件开发的成本就可以大幅度降低。看看近二十年来中国制造的影响，就可以理解这种廉价劳动力所蕴含的巨大杀伤力。经营层面话题可
阅读全文
posted @
2012-03-28 00:08
理想流
阅读(2053)
推荐(1) 编辑
【设计 = 编码】 VS 【设计 ≠ 编码】
摘要：在1992年，JackW.Reeves发表了一篇名为：CodeasDesign的文章，这篇文章可以在《敏捷软件开发原则、模式与实践》一书的附录中找到。这篇文章的核心观点是：编码也是设计，而软件开发中与建筑行业中的施工所对等的工作，已经被编译器代理了。这是几近20年前的文章，但时至今日，类似的争论仍未休止。好像是在《软件架构设计》里，在讨论架构设计时，作者就点了一句：这总不能说是设计就是编码了吧。解释这一问题并不复杂，但需要用到一点辩证法。我们可以讲：设计即是编码，也不是编码。在别的文章里我们曾经提及，软件是一种固化的思维。从这一角度看，软件构建的核心步骤只有两个：一是明确固化什么，二是对思维进
阅读全文
posted @
2012-03-21 00:16
理想流
阅读(1826)
推荐(2) 编辑
国内外软件开发上的差距与分析
摘要：--愿与勇于正视现实的人共勉在开始任何其他文字之前，首先有必要正视一个根本现实：国内外软件开发的水平是有差距的。这一结论的最直接证据是每一轮新技术的发起者基本上都是国外的人或公司：从方法论（CMMI，敏捷等）到各种框架（近来很热的Hadoop等）再到新的编程语言都是如此。总的来看这类差距似乎可以概括为“原创的缺失”，大多时候，我们只是处在一种“跟随者”的角色上。RUP出来后我们跟谁RUP，敏捷出来我们跟谁敏捷，云计算出来后我们跟随云计算，大致如此。年纪小的时候，会单纯的以为造成这种局面的主要原因是个人技术能力不足或努力不够。但现在想来，这反倒是次要原因。单以单兵能力来看，国内外的程序员群体未必
阅读全文
posted @
2012-03-19 00:06
理想流
阅读(4740)
推荐(3) 编辑
编码会不会逐渐消亡？
摘要：很多年来始终有一种声音：编码自身会逐渐消亡，软件开发会越来越像一种组装工作。也就是说，程序员会越来越像IT工程师，他们很少自己从头做什么，而是靠搭配来达成各种目标。我身边就有持这种观点的人。而在《代码整洁之道》一书中，RobertCMartin在开篇处加了这样一段文字：有人也许会以为，关于代码的书将有点落后于时代---代码不再是问题；我们应当关注的是模型和需求。确实有人说过我们正在临近代码的终结点。很快，代码就会自动产生出来，不需要再要人工编码。.......这段文字告诉我们编码会逐渐消亡这种观点即使在国外也有一定的市场。假使说这是真的，那程序员就必然是一个会逐渐消亡的职业。现在的关键问题是，
阅读全文
posted @
2012-03-14 00:04
理想流
阅读(2345)
推荐(4) 编辑
并行中的正负两面
摘要：大多情况下，并行对复杂度影响过大，并间接导致测试困难---多线程或多进程导致的问题往往是有时发生，有时不发生，一般的测试手段并不足以发现这类问题。所以原则上应该尽可能不用，除非收益足够大。或则说在满足需求的前提下，线程数和进程数应该尽可能少。以多线程和多进程而论，确定“什么时候适合使用这种技术”是比“怎么使用这项技术”困难的多的事情。现实中人们往往对事件，信号灯等同步处理手段关注过多，而对究竟应不应该启用多线程/进程关注的太少。这里来简单做个总结，对于下面这些场景，一般来讲启用多线程/进程是合适的：数据很容易分割，处理不同数据时彼此间没有什么交互。比如说：你有10万个文件需要处理，每个文件的处
阅读全文
posted @
2012-03-12 00:08
理想流
阅读(1526)
推荐(0) 编辑
代码复用的考察
摘要：复用可以说是任何一个软件企业都不能漠视的课题，因为复用可能对软件的开发效能产生绝大影响，而开发效能直接影响利润，甚至生存。但复用本身将增加当前项目的成本，是一种以当前投入来换取远期收益的行为。与此同时远非所有代码都可以复用，复用本身也有自己内在的一些规律，让我们来试做一些分析。从结论上来说，只有满足下面两条原则的程序，才可能真正的被复用，否则的话只能采用代码级别的复用。第一条原则是，程序本身的职能非常独立与业务层面基本无关联，是功能型的模块（包）。代码中的逻辑表述的是一种关联性，当这种关联只在确定的方面存在的时候，通常我们可以切割出比较独立的模块，而这种模块可以成为复用的基础之一。这也就是常说
阅读全文
posted @
2012-03-07 07:44
理想流
阅读(2830)
推荐(1) 编辑
项目管理中的导向性
摘要：众所周知，领导与管理意义不同，领导者要决定的是未来的走向和基本的原则策略。管理者则要使用具体的手段，达成既定的目标。但现实中的管理上的问题往往并不只类似于数学，只需要计算和推理，而更类似于社会学，需要许多判断，这也就意味着做管理的时候最终会涉及导向性的问题。软件项目的管理尤其如此。建造一栋房屋和构建一个软件，其不同在于建造房屋的工人需要的是按照设计图纸严格执行，因此纪律要比文化重要。但在软件开发过程中，由于工作和概念与逻辑相关，现场几乎就是一切，如果程序员被定位为被动执行者，那么一切创新和改善皆变的不在可能，因此文化比纪律重要。在塑造文化的过程中，融合在日常行为中的导向性至关重要。可以讲有怎么
阅读全文
posted @
2012-03-05 00:36
理想流
阅读(2339)
推荐(2) 编辑
管理之困：居高不下的流动率
摘要：在《与熊共舞》中，作者列出了5项核心风险，它们分别是：进度安排的先天错误需求膨胀人员流失规约崩溃低生产率在这里，人员流动被列为第三号核心风险。在国内也许上述排名会有所变化，但不管怎样从短期视点来看，人员流失一定仍然是核心风险。从长期视点来看，人员流失的重要性则一定会排在第一位。在COCOMOII中，人员流动被认为会对生产效能产生1.59倍的影响。虽然没有统计数据，但我估计这个值被低估了，或者说在一定比率下才有意义。道理上讲，工作难度越高，团队越小，流动率影响越大。甚至很有可能流动率超过一定程度后，其对生产效能的影响会指数级放大。眼下，这个上缺乏数据支撑，如果那位知道那里有数据，请和我分享下。人
阅读全文
posted @
2012-02-23 00:09
理想流
阅读(2655)
推荐(1) 编辑
管理之困：消逝的工作热情
摘要：在实际软件开发过程中，在中国，可能很多项目管理人员第一头痛的事就是，团队成员工作热情不高，投入程度不够。这个问题成因可能有很多，比如：可能原因之一，在于人。假设每个人都自觉遵守职场里的规则，那管理难度要相对较低。但很多时候团队成员有可能缺乏一些基本的共识。对于很多人来讲，可能基本思路是：打工不过是谋生的一种手段，明天我还不知道在那里？这也就导致了，团队成员对公司没有归属感，进而责任感及主动性这类东西相对欠缺。可能原因之二，在于环境。中国的软件产业处于整个产业链的下游。外包和系统集成是软件产业的主题。这个大背景就决定了很多工作确实无聊。就好比微软不可能把内核外包出来一样，很多时候外包出来的东西，
阅读全文
posted @
2012-02-20 07:28
理想流
阅读(2722)
推荐(8) 编辑
程序员第二定律：量化管理在程序员身上永无可能
摘要：恰如标题，第二定律表示为：在思维可以精确量化前，量化管理在程序员身上永无可能。这次估计会有争议，所以这里给出具体的逻辑链以及对应的分析。逻辑链：软件是一种固化的思维→思维的本质是概念和逻辑→概念和逻辑无法直接度量和精确度量→度量过程中需要很多的主观判断→以目标为导向的，个人中心的量化管理（相关的激励和惩罚）将崩溃具体分析：公平公正是管理的基石，为达成这一目的很多人会想到量化管理，但量化管理的基石却往往被忽略。对人进行量化管理的基石是：量化后的数字主要受个人表现这一个因素的影响，否则将产生巨大的不公正，并对个人工作意愿产生不良影响，是真正的事与愿违。好比说，不同的工人在同等条件下生产杯子，一个人
阅读全文
posted @
2012-02-15 00:21
理想流
阅读(2693)
推荐(2) 编辑
软件开发人员的“七重苦”（2）
摘要：（接前一篇，继续）第五重：技术变化快，积累上不去设想一下，一个10年前的高手，这10年他什么也不学，那他今天会是什么样的一个状况。我个人估计是快被淘汰了。这是个极端的例子，但回顾一下软件的发展历程你会发现，新技术的出现是爆炸式的。在DOS的时代里，软硬件的距离非常近，你只要会一种语言，了解基本算法和数据结构，再了解计算机硬件的知识，你就可以写大部分的程序。接下来软件和硬件间的层次越来越多，Windows加上一层，Java虚拟机加上一层，浏览器加上一层，Flash等再加上一层，诸如此类。每多一层技术的种类就增加一些。这就导致软件开发人员同时面对两类压力：一是项目上的时间压力，一是技术更迭上的学习
阅读全文
posted @
2012-02-07 00:46
理想流
阅读(3138)
推荐(2) 编辑
软件开发人员的“七重苦”（1）
摘要：软件开发这个行业无疑的是有快乐的，但这篇文章里，我们先不关注他，而是要来看看那些让人痛苦的地方。有时候想想，人作为一种生物还是挺有意思的。快乐的东西快乐过了，也就忘了，记的牢的的反倒是些让人不快乐的东西。第一重：垃圾代码佛家总讲成住坏空，软件亦莫能外。唯一有点特别的是，软件“住”的阶段短，“坏”的阶段来的快。要想软件保持不“腐败”，其实要花的精力远比想的多，这导致在商业利益比较强势的世界里，大多时候有的只是“能用就行”的软件，而不是“好”的软件。“能用就行”的软件里，大多时候到处都是垃圾代码。如果说超过100行的方法/函数让人痛苦的话，那么时有出现的超过200行的方法/函数就是让人绝望了。不改
阅读全文
posted @
2012-02-06 00:10
理想流
阅读(2638)
推荐(4) 编辑
如何评价软件写的好还是坏？
摘要：软件自身是一种固化的思维，因此从本质上来看，软件是不可度量的。但这并不意味着软件不需要度量，而只是说软件中的度量大多都有一定限度。应用各种度量数据的时候一旦跨过这种限度，结果就会适得其反。在这篇文章里，我们将考查一下现有的，对软件进行度量的方法(注意：这篇里主要考察别人的方法，不是我自己的)。可能不全面，不足的地方欢迎大家进行补充。对软件“直观可见的质量属性”的度量比较简单，比如：Bug率，性能等，这里就不提了。这里主要关注的是软件的内在的，不直观可见的质量属性。圈复杂度圈复杂度主要用于度量函数或方法，从《代码大全》中可以找到圈复杂度的描述。关于圈复杂度：TomMcCabe曾经建议使用下面的方
阅读全文
posted @
2012-01-15 23:48
理想流
阅读(3246)
推荐(0) 编辑
程序员每天到底可以写几行代码？
摘要：对于特定的人，在大致时间段里他所能写的、确定质量的代码基本上应该是个确定值。这点似乎显而易见，但事实上大多时候却总是被忽视。如果项目负责人总是认可上面的基本点，那么任何项目的日程就应该以此为前提，而不是以此为变量。假设说一个项目被估计为1万行(SLOC)，团队平均每人每天可以写100行代码，如果团队中有5个人，那么就应该至少为编码保留20整天。说到这里，为避免误解，要区分一下编码速度和生产率这两个概念。项目管理中常用的一个数据被称为生产率，用代码行计算时，会被表示为SLOC/MM。这个值用于表示平均每人月的代码产出。其基本算法是规模除以项目所用的人月，而项目所用的人月中包含了设计、测试、修Bu
阅读全文
posted @
2012-01-02 19:48
理想流
阅读(20813)
推荐(0) 编辑
软件开发还远不是一种“科学”
摘要：很多大学里是把软件开发相关的专业划入工科的，这给人一种错觉，让人认为软件开发也是一个工程学科，就像土木建筑，动力机械那样。但这从根本上错了，土木建筑，动力机械的背后有确实的科学定律作为支撑，而软件开发的背后基本上什么都没有，远不是一种“科学”。也正因此，“软件工程”的现实意义也就远不如“土木工程”，“动力工程”。每个人对“科学”的定义可能不同，但在这里，我们可以做一个简化版的定义：当有一组在限定条件下颠扑不破的定律做支撑时，相应的知识，我们可以称之为科学，科学自身可以体现为一种确定性。比如说：牛顿的力学定律在低速时是不容违反的，是一种铁则，那基于此的各种知识就可以成为科学。从这个视角出发，我们
阅读全文
posted @
2011-12-26 00:05
理想流
阅读(3449)
推荐(8) 编辑
国内的知名产品及其开发语言v0.0.1
摘要：首先要声明的是：这个列表既不权威，也不全面，所有信息仅供参考，本人也不对由此导致的任何后果负任何责任。建立这个列表的初衷来自三个方面：一个是很多人在加入程序员这个行业前，需要对编程语言有一个大致的认知。一个是如果有人要从头开发一个产品终究需要类似的信息做些参考最后一个则是自己的好奇心，在看了国外那张表后，我自己也挺想知道国内的状况究竟是什么样。编程语言是程序员必备诸多技能中的一个，你既不能漠视它的影响，也不能过高估计它的影响。假设说你掌握C++用了7年，无疑的转向Java时，这7年时间不会完全浪费，但损失1~2年是再所难免的。细想起来，人这一生究竟又有多少个1~2年，程序员的职业生涯又有多少个
阅读全文
posted @
2011-12-19 02:15
理想流
阅读(6990)
推荐(20) 编辑
