软件随想录读书笔记

软件随想录读书笔记

1.        总体印象

    《软件随想录》是第15届JOLT大奖图书，被誉为堪比《人月神话》的经典软件项目管理文集。正是受这个光环的影响，我去借了一套回来看。

    看完之后，个人觉得这本书有点过誉了，它实际上就是一本软件方面的杂文集，这些文章反映了作者在软件领域的各种观点，由于时间比较早，有些观点已经过于陈旧了，当然还是有不少观点是非常有道理的，能够引起读者的共鸣。但是，既然是杂文集，所以就不够系统，看看还是可以的，但是也就这样了，不要期望太高。

    顺便说一句，这本书我看的有两卷，后面的内容主要基于卷1，卷2我也看了，但是实在没有太多印象深刻的东西，所以就没有记录。

2.        第一部分  比特和字节：编程实践

    整个这部分主要谈的就是软件开发的一些常用的实践，总体上没有什么太值得注意的东西，其中谈到的大部分内容都在目前业界流行的敏捷实践中包含了，而且敏捷实践更先进。

    其中有篇题为“干扰射击”的文章稍微有点意思，其中提到很多大公司，比如说微软，会故意不断的把其软件基础技术进行升级，并称之为新技术潮流，忽悠得很多一知半解的客户在购买软件产品的时候，会明确的要求软件产品必须符合这些所谓的新技术潮流，才愿意购买，虽然他们实际上根本就不懂这些新技术到底好在哪里。比如，微软推出的数据库连接技术，有ODBC RDO ADO OLEDB ADO.NET等等，搞得如果你的软件产品不支持这些东西，好像就拿不出手一样。但是，实际上这是这些大公司的一种高端战术，这种战术使得很多小公司为了跟上这些所谓的新技术潮流不得不疲于奔命，花了很多的精力去实现这些不得不实现，但是却没有什么太多用处，更无法体现自己产品特色的东西，反而忽略了对自己产品本身的改进，这样大公司自己的产品趁机就可以不断完善以继续保持领先地位了。这个现象我发现确实普遍存在，那些在某个领域处于领先的公司，经常会采用这种战术来保持自己的领先地位，实际上硬件产品比软件产品在这方面还要普遍。针对这种情况，对于小公司而言，作者的建议是，要排除这些干扰，把注意力集中在自己的客户那里，根据客户的实际需求来不断的完善自己的产品，并形成自己的产品特色，这样才能避免被大公司牵着鼻子走。

3.        第二部分  管理开发者

    这部分主要谈的是如何对开发人员管理的一些观点，大部分观点我个人是比较认同的。

3.1.       我认同的观点摘抄

（1）对开发人员进行各种所谓的绩效考核实际上是非常有害的，有几个方面的原因

    （a）对于真正优秀的开发人员而言，对自己份内的工作尽心尽责，精益求精，本来就是自己应该具有的职业素养，而给他们的各自所谓的考核和奖励，反而会让他们觉得受到了侮辱和贬低，似乎自己的努力只是为了奖赏，而非追求工作质量，就好像一条狗一样。对真正优秀的开发人员而言，最好的奖励其实是，产品的成功，团队以及个人的成长，还有一个光明的前景。

    （b）对于开发人员而言，要对其进行好的评价其实是很难的，开发人员的工作实际上很难用一些标准的、量化的指标去评价的（要知道，一个好的团队，每个人所起到的作用往往是不同的，这样才使得整个团队互补而形成一个整体），而如果评价不到位，只会让开发人员失望，士气低下，甚至伤心离开。

    （c）一个成功的团队，其中的每个团队成员实际上都是缺一不可的，没有高下之分。但是，如果非要通过绩效考核把他们分成几个等级的话，只会造成团队成员之间的隔阂和嫉妒，从而谋杀整个团队。

（2）必须要设置专业的测试人员对软件进行测试，注意，是专业的！

（3）尽可能不要让开发人员进行任务切换，永远不要把多于一项的任务指派给同一个人做

（4）如果没有特殊的理由，永远不要去从头开始重写一个软件的全部代码。比较好的做法是，部分重构，逐步改进。

3.2.       非正式面世指南

    这部分谈了作者对开发人员招聘的一些经验，个人觉得非常有用，现把精华部分摘抄如下：

3.2.1.       招聘流程

3.2.1.1.       筛选简历

    （a）扔掉有明显文字错误的简历

    （b）找到那种曾经经历了某种非常困难的选拔过程，并且通过了考验的人，比如毕业于某说录取率很低的大学，曾经到某些以招聘条件苛刻闻名的公司任职。等等

3.2.1.2.       电话筛选

    通过电话交流观察应聘者是否足够聪明，理解能力是否强（至少不会让应聘者反复解释同一件事情），是否有自己的观点，比如问他“如何实现一个XML解析器？”，看他怎么回答

3.2.1.3.       现场真人面试

3.2.1.3.1.      面试官制度

    （a）应该派真正的程序员，最好是被面试者未来的同事去面试，最好5个以上

    （b）实行两票否决制，不要一票否决

    （c）聘用或者不聘用，别无他选，绝不聘用一个不够好的人

    （d）面试官的职责有一部分就是创造一个环境，让面试者充分展现自己的聪明才智

    （e）面试官切忌不要成为话痨，自己说个不停，不给面试者说话机会

    （f）面试官也不要问面试者一些细枝末节的编程问题，特别是那些百度一下几分钟就可以知道的问题，而应该是问一些开放式的问题，让面试者来主导谈话（记住你要招聘的不是记忆超强的机器，而是聪明的人）

3.2.1.3.2.      要聘用哪种人

    （a）那种具有超强适应能力，随便什么开发任务都能胜任的人，如果他只是对某个很具体的领域，如sql编写熟悉，但是对其它领域一窍不通的话，不聘用

    （b）聪明并且能干的人

    （c）聪明人不需要你反复解释同一件事情，沟通非常顺畅，并且经常妙语连珠，显露出独到的见解，深刻的思维或敏锐的知觉

    （d）有些人很聪明，但不一定能干，比如一些喜欢高谈阔论搞理论研究的人，喜欢在一些问题上钻牛角尖，却不能按时交付代码

    （e）有些人很能干，但不一定聪明，这类人最具迷惑性，他们虽然非常努力，但是经常不经过思考就做出一些蠢事，导致其他人来给他擦屁股，反而拖了团队的后腿

3.2.1.3.3.      要问哪些问题

    （a）对面试者进行介绍：

    介绍的目的是让面试者放松下来，比如可以向面试者介绍下自己以及面试的基本流程等。比较重要的是，要告诉面试者，其实也应该告诉自己，不要太在意答案的对错，跟重要的是面试者解决问题的方法

    （b）最近做过的项目

    让面试者详细介绍最近做过的某个项目或者课程，多问开放式问题，是希望寻找面试者的以下特征

        （I）激情自信：聪明的面试者对做过的项目饱含激情，谈论起来后非常投入而不

                      再紧张，像是忘记了自己在面试。面试官甚至可以尝试假装对他讲             

                 述的内容进行质疑，看看面试者是如何捍卫自己的

        （II）善于表达：聪明的面试者善于用常人易于理解的语言来向别人介绍自己的项

                      目，特别是一些专用术语和概念

        （III）有领导潜质：有领导潜质的面试者在项目过程中遇到障碍时，通常能够采取

                      各种手段，比如组织团队讨论等等，来克服这个障碍，而不是两手

                      一摊，唉声叹气的说：没有办法。面试时可以尝试引导面试者谈谈

                      类似情况他的处理经验

    （c）问一些不可能的问题

    尝试问一些不在面试者知识范围内的，他们很难找到合适回答方式的问题，看他如何面对。比如：如果请你来规划重庆市的加油站，你觉得应该建设多少个加油站？聪明的面试者遇到这种情况会积极思考，尽可能通过某种逻辑关心来推导答案，哪怕他推导过程中使用的一些知识实际上是错误的，但是重要的是看他处理问题的过程和激情。而不聪明的面试者，遇到这种问题常常一筹莫展，只能等着你来推导他前行。

    （d）问一些编程问题

    请面试者编写一个小函数，注意代码行数不要超过10行，注意并不要太关注面试者在这个过程中的书写是否潦草，以及写出来的代码是否有bug，而是应该关注以下几个方面

        （I）是否理解了这门编程语言的精髓，比如，C语言的精髓就是指针和内存

        （II）是否注意了一些编程老手通常会注意到的细节，比如：性能，比如：通用性。面试官也可以尝试引导面试者对函数进行优化，或者重构，看看他的表现

        （III）是否下意识的遵循了一些好的编程规范，这些都是老手的特征

    （e）让面试者问问题，同时宣传自己公司

    注意面试通常也是双向的，所以，真正的优秀人才，通常会问一些他关心的自己公司的一些信息，即使他不问，面试官也应该主动做一些宣传来宣传自己公司和提供的工作机会

4.        第三部分  乔尔语录：中心明确的胡思乱想

    如同标题，这部分内容比较乱，有意思的内容不是很多，我这里摘抄一些印象比较深的观点：

（1）如果希望客户喜欢使用自己的产品，首先得让自己喜欢使用自己的产品，否则你凭什么认为别人会喜欢？

（2）如果你觉得有什么好的最佳实践可以改善团队的工作效率，任何人都可以进行推动，即使你没有行政权力，方法很简单，先自己实践并深刻理解其带来的好处，再逐渐向其他团队成员推广

（3）好的管理者所做的就是把聪明人招来公司，给他们好的工作环境，然后充分信任他们，放心的把事情交给他们来做，切忌对他们的工作领域指手画脚，要让他感受到，在他所负责的领域，他就是神，他永远是对的，哪怕是公司老总也不能对其质疑。（哎，当年的微软居然能做到这一点，真是没有想到）

（4）软件开发是一种艺术，是需要天分的，虽然也许按照业界的一些所谓的方法论可以让普通人都开发出勉强过得去的软件来，但是对于真正的软件大师来讲，这些方法论是一种沉重的负担，限制了他的发展。所以，真正优秀的软件，都是一些天才搞出来的，无论什么方法论都搞不出真正优秀的软件出来

（5）对于一个产品而言，不管是硬件还是软件，只要是其核心价值所在的部分，一定要自己来搞，无论多么困难。所以现在手机厂家都想自己搞手机芯片，所以以3D特效为卖点的游戏公司都有自己的3D游戏引擎

（6）企业发展有两种模式，这里分别进行描述：

    （a）本杰瑞模式：其特点是企业从小处着眼，一步一个脚印的逐步稳步发展，从一开始就考虑盈利

    （b）亚马逊模式：其特点是先募集一大笔资金，然后尽可能扩大公司规模，前期完全不考虑盈利。

     可以用一个表格来对这两种模式进行对比

本杰瑞模式	亚马逊模式
行业中有很多的老牌竞争对手，必须从竞争对手手中夺取客户	新技术，最开始没有竞争对手，所以有可能在抢占地盘中大获全胜，尽快的获取尽可能多的客户，以提高后续竞争者的准入门槛
没有网络效应，只有较低的用户黏度 网络效应：拥有的客户越多，得到的客户也就越多，一个网络的价值等于其用户数量的平方	有较强的网络效应，较高的用户黏度 用户黏度：某种商业服务的特性，使得用户一旦使用，就很难更换，可能是因为更换的成本太高，也有可能是网络效应的缘故，根本无法更换 例如：微信，淘宝，就具有非常强的网络效应和用户黏度
启动资金很少，很快可以实现收支平衡	需要大笔启动资金，需要多年才能盈利
公司文化非常重要	几乎不可能形成公司文化
善于中错误中吸取教训 这种模式不能犯太多错误，犯太多错误就意味着死亡	错误通常会被忽略 比如互联网公司经常会挥霍大量的钱去做一些尝试，即使失败了也无所谓
可能会成功，肯定不会赔太多的钱	有极小的概率成功，极大的概率会失败 其实就是赌

     切记：最错误的发展模式，就是在上述两种模式间摇摆

（7）对于很多软件，尤其是平台类软件，经常会遇到一个先有鸡还是先有蛋的问题，一方面，只有平台上存在很多可用的优秀软件，客户才会来买这个产品，但是另一方面，除非这个平台的装机量很大，否则没有人愿意为它开发软件。这个问题很典型，微软的手机操作系统就死在这个上面了。要解决这个问题，其实很简单，找到对应行业的老大，对其向后兼容就OK了。比如，微软的手机操作系统，要是能够同时兼容安卓和苹果，我估计也买。

（8）任何新产品，如果希望客户接受的话，必须考虑客户的迁移成本，即客户放弃当前使用的产品，迁移到你的新产品时，需要付出的代价，注意，更好的是，还要关注客户试用你的新产品后，如果不满意，希望迁移回老产品的代价。如果代价太大，大部分客户是不愿意使用你的新产品的，除非你的产品太酷使得客户愿意付出任何代价迁移（这通常很难，但不是不可能，比如你肯定愿意花大代价学习和购买汽车以取代自行车）

（9）有条看上去有点道理的法制是：80%的人只会使用20%的产品功能特性，所以只需要实现20%的功能特性，还是能卖出80%的软件。可惜他是错的，你得注意一个事实：不同的人使用的20%的功能特性，是不相同的！

（10）市面上的所有产品都有配套产品，配套产品就是你通常会和另一种产品一起购买的产品，比如：汽车和汽油，电脑和操作系统等等。有个重要规则是：在其他条件对等的前提下，配套产品价格降低会导致原产品的需求上升！所以，聪明的公司会致力于让其产品的配套产品变得商业化，唾手可得，价格低廉，这样对自己产品的需求就会上升，公司就可以提高定价，获取更多的利润

    例如：IBM通过设计标准的PC架构，让PC配件市场商品化，从而提高了PC的需求。微软让PC市场商品化，PC价格降低，而大大提高了对操作系统的需求。现在很多商业公司支之所以支持开源软件，背后多半都是因为类似的原因