摘要： 很多年来始终有一种声音：编码自身会逐渐消亡，软件开发会越来越像一种组装工作。也就是说，程序员会越来越像IT工程师，他们很少自己从头做什么，而是靠搭配来达成各种目标。我身边就有持这种观点的人。而在《代码整洁之道》一书中，RobertCMartin在开篇处加了这样一段文字：有人也许会以为，关于代码的书将有点落后于时代---代码不再是问题；我们应当关注的是模型和需求。确实有人说过我们正在临近代码的终结点。很快，代码就会自动产生出来，不需要再要人工编码。.......这段文字告诉我们编码会逐渐消亡这种观点即使在国外也有一定的市场。假使说这是真的，那程序员就必然是一个会逐渐消亡的职业。现在的关键问题是， 阅读全文

摘要： 大多情况下，并行对复杂度影响过大，并间接导致测试困难---多线程或多进程导致的问题往往是有时发生，有时不发生，一般的测试手段并不足以发现这类问题。所以原则上应该尽可能不用，除非收益足够大。或则说在满足需求的前提下，线程数和进程数应该尽可能少。以多线程和多进程而论，确定“什么时候适合使用这种技术”是比“怎么使用这项技术”困难的多的事情。现实中人们往往对事件，信号灯等同步处理手段关注过多，而对究竟应不应该启用多线程/进程关注的太少。这里来简单做个总结，对于下面这些场景，一般来讲启用多线程/进程是合适的：数据很容易分割，处理不同数据时彼此间没有什么交互。比如说：你有10万个文件需要处理，每个文件的处 阅读全文

摘要： 复用可以说是任何一个软件企业都不能漠视的课题，因为复用可能对软件的开发效能产生绝大影响，而开发效能直接影响利润，甚至生存。但复用本身将增加当前项目的成本，是一种以当前投入来换取远期收益的行为。与此同时远非所有代码都可以复用，复用本身也有自己内在的一些规律，让我们来试做一些分析。从结论上来说，只有满足下面两条原则的程序，才可能真正的被复用，否则的话只能采用代码级别的复用。第一条原则是，程序本身的职能非常独立与业务层面基本无关联，是功能型的模块（包）。代码中的逻辑表述的是一种关联性，当这种关联只在确定的方面存在的时候，通常我们可以切割出比较独立的模块，而这种模块可以成为复用的基础之一。这也就是常说 阅读全文

摘要： 众所周知，领导与管理意义不同，领导者要决定的是未来的走向和基本的原则策略。管理者则要使用具体的手段，达成既定的目标。但现实中的管理上的问题往往并不只类似于数学，只需要计算和推理，而更类似于社会学，需要许多判断，这也就意味着做管理的时候最终会涉及导向性的问题。软件项目的管理尤其如此。建造一栋房屋和构建一个软件，其不同在于建造房屋的工人需要的是按照设计图纸严格执行，因此纪律要比文化重要。但在软件开发过程中，由于工作和概念与逻辑相关，现场几乎就是一切，如果程序员被定位为被动执行者，那么一切创新和改善皆变的不在可能，因此文化比纪律重要。在塑造文化的过程中，融合在日常行为中的导向性至关重要。可以讲有怎么 阅读全文

摘要： 在《与熊共舞》中，作者列出了5项核心风险，它们分别是：进度安排的先天错误需求膨胀人员流失规约崩溃低生产率在这里，人员流动被列为第三号核心风险。在国内也许上述排名会有所变化，但不管怎样从短期视点来看，人员流失一定仍然是核心风险。从长期视点来看，人员流失的重要性则一定会排在第一位。在COCOMOII中，人员流动被认为会对生产效能产生1.59倍的影响。虽然没有统计数据，但我估计这个值被低估了，或者说在一定比率下才有意义。道理上讲，工作难度越高，团队越小，流动率影响越大。甚至很有可能流动率超过一定程度后，其对生产效能的影响会指数级放大。眼下，这个上缺乏数据支撑，如果那位知道那里有数据，请和我分享下。人 阅读全文

摘要： 在实际软件开发过程中，在中国，可能很多项目管理人员第一头痛的事就是，团队成员工作热情不高，投入程度不够。这个问题成因可能有很多，比如：可能原因之一，在于人。假设每个人都自觉遵守职场里的规则，那管理难度要相对较低。但很多时候团队成员有可能缺乏一些基本的共识。对于很多人来讲，可能基本思路是：打工不过是谋生的一种手段，明天我还不知道在那里？这也就导致了，团队成员对公司没有归属感，进而责任感及主动性这类东西相对欠缺。可能原因之二，在于环境。中国的软件产业处于整个产业链的下游。外包和系统集成是软件产业的主题。这个大背景就决定了很多工作确实无聊。就好比微软不可能把内核外包出来一样，很多时候外包出来的东西， 阅读全文

摘要： 恰如标题，第二定律表示为：在思维可以精确量化前，量化管理在程序员身上永无可能。这次估计会有争议，所以这里给出具体的逻辑链以及对应的分析。逻辑链：软件是一种固化的思维→思维的本质是概念和逻辑→概念和逻辑无法直接度量和精确度量→度量过程中需要很多的主观判断→以目标为导向的，个人中心的量化管理（相关的激励和惩罚）将崩溃具体分析：公平公正是管理的基石，为达成这一目的很多人会想到量化管理，但量化管理的基石却往往被忽略。对人进行量化管理的基石是：量化后的数字主要受个人表现这一个因素的影响，否则将产生巨大的不公正，并对个人工作意愿产生不良影响，是真正的事与愿违。好比说，不同的工人在同等条件下生产杯子，一个人 阅读全文

摘要： 在软件这个行业里有些规则是很有杀伤力的，比如很有名的摩尔定律。总结出这些规则的意义在于可以大致的照明方向，免得努力来努力去却走到了阴沟里。现实中种种利益纷争、观点之争看似纷繁，但在大时间尺度下来看却都是规则的实现手段。这就好比下围棋，每一手都要为谋得利益而计算，但结局却只有三种：赢、输或和，这就是规则的力量。民以食为天，所以第一定律从收入开始。程序员第一定律可以表述为：程序员的收入是技能复杂度和技能实现可能程度的函数。如果程序员的工资是S，社会平均水平的工资为A，程序员掌握的技能复杂度为C，实现程度为P。那么S=AxCxP。这里面的实现程度P不太好理解，额外做点说明。好比说有人在东北种了很多白 阅读全文

摘要： （接前一篇，继续）第五重：技术变化快，积累上不去设想一下，一个10年前的高手，这10年他什么也不学，那他今天会是什么样的一个状况。我个人估计是快被淘汰了。这是个极端的例子，但回顾一下软件的发展历程你会发现，新技术的出现是爆炸式的。在DOS的时代里，软硬件的距离非常近，你只要会一种语言，了解基本算法和数据结构，再了解计算机硬件的知识，你就可以写大部分的程序。接下来软件和硬件间的层次越来越多，Windows加上一层，Java虚拟机加上一层，浏览器加上一层，Flash等再加上一层，诸如此类。每多一层技术的种类就增加一些。这就导致软件开发人员同时面对两类压力：一是项目上的时间压力，一是技术更迭上的学习 阅读全文

摘要： 软件开发这个行业无疑的是有快乐的，但这篇文章里，我们先不关注他，而是要来看看那些让人痛苦的地方。有时候想想，人作为一种生物还是挺有意思的。快乐的东西快乐过了，也就忘了，记的牢的的反倒是些让人不快乐的东西。第一重：垃圾代码佛家总讲成住坏空，软件亦莫能外。唯一有点特别的是，软件“住”的阶段短，“坏”的阶段来的快。要想软件保持不“腐败”，其实要花的精力远比想的多，这导致在商业利益比较强势的世界里，大多时候有的只是“能用就行”的软件，而不是“好”的软件。“能用就行”的软件里，大多时候到处都是垃圾代码。如果说超过100行的方法/函数让人痛苦的话，那么时有出现的超过200行的方法/函数就是让人绝望了。不改 阅读全文