《软件随想录》读书笔记

    近期读了一本书，名字叫做《软件随想录》。这本书的写作风格比较特别，特别之处在于它是由网志整理而成，因此在目录的排版方面不像一般的书籍那么有逻辑，它的目录更像是网志的一种归类。由于是网志，文章相对随意些，不一定会给你标准的答案或特定的结果，而更多的是引导读者去思考，或者给读者提供一个解决问题的思路。

    作者比较注重思考，而且有点偏激。他有着独特的思考方式，表达方式比较幽默，有些地方用了夸张的手法，经常用量化的方式进行论证。

    一句话，本书值得反复细读，理解并学习体会作者的思想与经验。

 

 

软件随想录

程序员部落酋长Joel谈软件

（美）Joel Spolsky 著

阮一峰 译

 

第一部分 人员管理

    那些优秀的程序员是不会出现在招聘市场上的。

    通常优秀的程序员在整个职业生涯中，可能会有4次求职。

 

    代码的世界是非常公正的，也是非常严格有序的。许许多多的人选择编程，首要的原因就是，他们宁愿将自己的时间花在一个公平有序的地方，一个严格的能者上庸者下的地方，一个只要你是对的就能赢得任何争论的地方。

 

    一定程度上，让程序员干有趣的活是吸引优秀程序员的最好方法之一。

    另一类程序员喜欢干的活是开发一些非常简单或者非常流行的东西。

    最后，许多程序员也会关注他们服务的公司的社会价值。

 

    我只是在说，如果你能找到办法让程序员有接触新的语言、框架和技术的经历，那么他们会感到更开心一些。

 

    三种管理方法：

    1）军事化管理法

    缺点：

    人们并不喜欢被这样管，尤其是那些对智商很自负的程序员。

    另一个缺点是操作层面的，没有足够的时间用在微观管理上，原因很简单，因为经理的人数不够。在军队中，通常情况是每个人都在做同一件事。在软件开发团队中，每个人干的活都不一样。

    在高科技公司中，负责干活的个人总是比“领导者”有更多的信息，所以他们其实是做决策的最佳人选。

 

    尤其要指出的是，软件开发团队中的优秀程序员可以去任何他们想去的地方工作。在这种前提下，如果被人当成士兵一样对待，他们会感到相当扫兴，因此你要是这样做，最后就只能成为“光杆司令”了。

 

    2）经济利益驱动法

    这种方法一个重大问题是，它将内部激励变为了外部激励。内部激励是指你内心想将事情做好的天然愿望。外部激励是指来自外界的激励，有人付钱让你干某事就是外部激励。

    经济利益驱动法的另一个大问题是，人们有追求局部利益最大化的倾向。他们会想出办法将你支付给他们的报酬尽量最大化，但是实际上却没有达到你真正想要的结果。

    内部激励比外部激励强得多。人们会为那些他们真正想做的事格外努力地工作。这一点并没有太大争议。

    “经济利益驱动法”的最大问题是，它其实根本不是一种管理，更像是管理的退位，或者说是一种设计精巧的推卸责任的方法，不愿承担责任找到办法将事情做得更好。它是一个信号，表明管理层根本不知道如何引导人们做出更好的工作，所以他们强迫每个雇员在制度框架下自己想办法将事情做好。

 

    3）认同法

    这种管理方法的目标是，使得人们认同你希望达到的目标。它实施起来比其他方法难得多，而且还需要一些很不简单的人际沟通的技巧。但是，如果你真地做到了，它的效果就比其他方法好得多。

    一般来说，认同法要求你创造一个有凝聚力的、像脱水一样粘在一起的团队，就好像家庭一样。这样一来，人们就会对他们的同事产生忠诚感和义务感。

 

    天底下有多少个经理，就有多少种不同的管理方法。

 

 

第二部分 写给未来程序员的建议

    经理存在的唯一理由就是把家具的位置摆好，不要挡道，只有这样，真正的天才才能做出优秀的成果。

    有一件事我是非常确定的，那就是管理层获得的技术问题的信息是所有人中最少的。

 

    能不能清晰地写出技术内容的文章决定了你是一个口齿不清的程序员还是一个领袖。

    我注意到，微软公司中那些真正优秀的程序经理都是具有优秀写作能力的人。

 

    如果你喜欢编程，那么你真是受到了上天的眷顾。你是非常幸运的少数人之一，能够以自己喜欢的事谋生。大多数人没有这么幸运。

 

    一个普通程序员与一个优秀程序员的区别，不在于他们懂得的编程语言谁多谁少，也不在于他们喜欢用Python语言还是喜欢Java语言，而在于他们能否与他人交流思想。

 

    你还可以动手写日记或网志。你写得越多，写作就会变得越容易。写起来越容易，你就会越写越多。这是一个良性循环。

 

 

第三部分 设计的作用

    苹果公司的用户喜欢苹果的方法，微软公司的用户喜欢微软的方法。这并不完全都是粉丝情节。它反映了一个事实，如果你问人们喜欢什么样的风格和设计，除非这些人受过专门训练，否则他们一般会选择自己最熟悉的品种。在最常见的品味这个问题上，如果你做一个偏好调查，你会发现大多数人根本不知道应该怎么选择，他们只好选一个自己最熟悉的答案。

 

    Dave Winer说过：“创造一个有使用价值的软件，你必须时时刻刻都在奋斗，每一次的修补，每一个功能，每一处小小的改进，你都在奋斗，目的只是为了再多创造一点空间，可以再多吸引一个用户加入。没有捷径可走，你需要一点运气，但是这不取决于你是否幸运。你之所以会有好运气，那是因为你寸土必争。”

 

    你给用户的选择越多，他们就越难选择，就会感到越不开心。

 

    软件实现上的小细节会导致在线社区发展、运作、用户体验上的大差异。

 

 

第四部分 管理大型项目

    标准当然是很重要的，但是你不能迷信标准，你必须理解由于人会犯错，所以标准有时候会引发误解、困惑，甚至是争议。

 

    DOCTYPE是一个神话。

    一个平庸的网页设计师在网页头部加上DOCTYPE说明，然后就声称“这是一个标准HTML网页”。这是盲目自大。

 

    Jon Postel提出了鲁棒性原则（robustness principle）：“对于己方的行为要保守，对于他方的行为要宽容”。他想说的意思是，让一个协议健壮地运行的最好方法就是，每个人都要非常非常小心地让自己的行为符合规范，而且同时在与合作伙伴进行信息交换时，又要采取极端宽容的态度。也就是说，只要你能猜出对方的意思是什么就可以了，不可苛求对方的行为一定要符合规范。

 

    回顾整个历史，程序员无时不刻不想做出正确的事情，但是有时候你不得向现实屈服。

 

 

第五部分 编程建议

    你的目的是最有效率、最物有所值地使用你的时间。但是，如果你不知道每项任务所要花费的时间，你就不可能找出最经济的工作方式。

 

    如果你马马虎虎，没有仔细想过你要做什么，没有在细节上想清楚详细的工作步骤，就在日程规划上为一个大型任务(比如“完成Ajax照片编辑器”)分配了3个星期，那么你其实不知道它究竟要花费多少时间，因为你没有仔细想过你要做什么。

 

    只有真正负责开发的程序员才能估计出完成任务需要哪些步骤。

 

    如果你不搞一个日程规划，程序员就会首先将容易的/有趣的功能做出来。然后，他们剩下的时间就不够了，你别无选择，只好推迟日程来开发有用的或重要的功能。

 

    有效的日程规划是创造优秀软件的钥匙。它强迫你首先完成最重要的功能，让你做出正确的选择，思考要开发一个怎样的软件。这会使你的产品变得更出色，使你的老板感到更高兴，使你的客户感到更满意，以及最重要的一点，那就是使你下午5点能够准时下班。

 

    当开发一个互联网应用程序时，你一定要小心，绝不能信任用户通过表单发送的任何字符串，绝不能直接就拿来使用。

 

    我强烈赞成制定代码书写规范，最起码这会让错误的代码更容易被发现。

 

 

第六部分 开办软件公司

    人们喜欢一项不断成长的生意，同喜欢园艺是一个道理。这是一种真正的乐趣，将一个小小的种子埋在地里，每天浇水、除草，眼看着一个微小的新芽长成枝繁叶茂、华美耐寒的大株菊花（如果你幸运的话），或者长成大荨麻（如果你不明白这种长得像野草一样的植物有什么用，请不要失去希望，你可以把荨麻用来做茶，只是要小心，别碰到它们）。

 

    我猜想你会读这本书，是因为你也想开一家小型的软件公司。这是一本这方面的好书，但是既然让我在这里说话，我就提供给你我的3点个人意见，你应该先做到这3点：

    第一点。如果你说不清楚你的软件解决了什么棘手的问题，就不要去开软件公司。

    第二点。不要独自一个人创办公司。我知道很多人单枪匹马创业成功，但是失败的例子更多。

    第三点。一开始不要抱太高期望。当产品上市的第一个月，没有人知道未来会赚多少钱。

 

    总结一下，我所认为的创办软件公司的真正乐趣就是，创造一些东西，自己参与整个过程，悉心培育，不间断地劳作，不断地投入，看着它成长，看着自己一步步得到报偿。这是世界上最带劲的旅程，无论如何，我都不想错过它。

 

    让我来告诉你原因，根本的一点就是软件的复制成本为0。这意味着，程序员的劳动力成本分摊在你销售出去的所有软件中。对软件来说，如果销售量很大，质量的改进并不会造成单位软件成本的上升。

    本质上，软件质量的改进会创造出新价值，而且价值创造的速度要快于成本提升的速度。

 

    还记得布鲁克斯法则（Brooks'Law）吗？——向一个已经延误的软件项目增加人手，只会使它更加延误——这就是原因。一个优秀的程序员独自完成一项任务，就不需要额外的沟通和协调。如果同样的任务让5个程序员一起完成，他们之间就必须沟通和协调。这会花掉大量时间。开发团队越小，就越能获得额外的收益。人力与工时的互换真的是一个神话。

    

    用许多平庸的程序员取代少数优秀的程序员，这种做法的真正问题在于，不管平庸的程序员工作多长时间，他们做出来的东西都无法像优秀程序员做得那样好。

    5个Antonio Salieri也写不出莫扎特的《安魂曲》。永远也写不出，埋头写100年也没用。

 

 

第七部分 经营软件公司

    暂略

 

 

第八部分 发布软件

    所以，我有几条软件开发周期的基本规则。

    （1）确定发布日期，这个日期可以根据客观情况也可以根据主观愿望进行选择。

    （2）列出软件要实现的功能，然后按照优先顺序排序。

    （3）每当你落后于预定进程时，就把排在最后的功能砍掉。

    如果上面的每一步你都做到了，那么你很快就会发现，那些被你砍掉的功能根本不会让你感到后悔。

 

    怎么来挑选发布日期呢？你可以考虑采用三种方法。

    （1）经常发布稍作改进的版本。

    （2）每12到18个月发布一次。

    （3）每3年到5年发布一次。

 

    如果你的顾客人数较少，那么你最好经常性地发布小幅修改的新版本。

    如果你已经有了（或者想要有）大量的付费用户，那么你最好不要太频繁地发布新版本。

 

 

第九部分 修订软件

    日本丰田公司创始人丰田佐吉（Sakichi Toyoda）的思想，他提出了五个为什么。当某个地方出错的时候，你就问为什么，一遍遍地追问，直到你找到根本性的原因为止。然后，你就针对根本性的原因开始着手解决问题，你要从根本上解决这个问题，而不是只解决一些表面的症状。

 

    如果你想把所有事情都做完，最后只会一事无成。

 

 

最后再说两句：

    感觉Joel真花了不少时间去做各种研究，用数据和实例做证明，对问题的分析思路比较清晰、系统性。

    由于国内外环境毕竟有些不同，有些观点不一定适合国内的情况，但内容仍然值得借鉴与思考。

    本文的内容是读完书籍的部分笔记，为避免断章取义，如果大家对本书的内容感兴趣的话，还是建议去读一读。

 

（转载请注明来源：http://zhanjia.iteye.com/blog/1830739）