Hegel2011的博客

读书 - 工作 - 生活 - 笔记

Joel 谈软件- 软件随想录

《Joel谈软件》,我一直是这么称呼《软件随想录》的。 倒是才注意到,原来黑客与画家、软件随想录都是阮一峰老师翻译的,而且翻译的真不错。与此同时,阮老师也很好地推销了一下自己。本书与《我编程我快乐》不同,是很有深度的书,所以决定边读边记笔记。尤其要说一句,阮老师的注解是很显功力的。

在2004年之前,Joel的网站文集就被按blook集合由Apress出版,而阮老师翻译的是集成了2004年之后发布的文章,英文名称《More Joel on Software》。但国内的出版顺序则是先引入了阮老师翻译的《More》,后来又有另一个译者翻译了04年的那本书作为了卷1. 所以,在中国很长时间只有《More》而没有第一本。考虑到时效性以及译者的知名度,04-09这本更值得关注就是必然的了。下面的笔记是两本合计的版本,并未区分来自哪里,毕竟原作者是一个人,所以基本是一脉相承。

人员管理

第一次Bill Gates 审查

微软程序经理(Program Manager):技术水平是程序员队伍里最高级别,能做最多且最难的工作,有人格魅力,程序员队伍中最聪明的那个家伙。

比尔盖茨通过不断问问题来确认对方是否有实现任务的把握。

怎么寻找优秀的程序员

  1. 优秀的程序员很少找工作
  2. 简历投的多的大部分是不怎么样的程序员
  3. 从应届生中招募是个发现美材的办法

从工作环境开始招募程序员

  1. 私人办公室:作者的公司在纽约,但程序员都有独立办公室,当然,这个在国外也是凤毛麟角
  2. Aeron出品的名牌电脑椅
  3. 大显示器
  4. 好的办公环境和园区
  5. 同事要好,管理层要有程序员出身的人,物以类聚
  6. 像代码一样公正、有序,严格的能者上庸者下的地方,对的就能赢得任何争论的地方
  7. 有趣的活,或者简单的或者流行的活
  8. 一定自由地使用新技术
  9. 编程框架体现美、幸福和激励

三种管理方法

团队、公司、军队、国家,问题:“使得人们去做你要他们做的事”,或者说如何使得所有人都向同一个方向前进。

军事化管理法

每个人做的事情都不同的情况下,军事化管理方法很难奏效,因为没有那么多经理实现微观管理。但对军队则是必须的。

经济利益驱动法

经济驱动把内部激励变成了外部激励。内部激励是发自内心想做好这件事情,内部激励通常比外部激励强。

经济驱动也容易陷入kpi骗局,鼓励大家和制度博弈。不能把铜板丢给鸡,让鸡自己去买吃的。创造一种制度的时候,不能放弃自己的职责。

认同法

一起干活的人要一起吃饭。团建,以及营造一致的目标,爱上这个城市和工作内容。第二部分是提供必要的信息,让下属感觉被尊重。

结论:hybrid根据时间和对象灵活运用各种方式。

面人指南

千万不要雇“可能”合适的人,招人标准:1,聪明 2,能干

测试人员

测试人员独立性的必要性

大学生技术学习建议

大学只教java的危害

危害主要是两点:1. 基础知识不够扎实 2.会有很多不达标的人浑水摸鱼通过,导致招聘困难。   但是,国内国外都这样。

耶鲁大学的演讲

技术派(the geek)和务实派(the suit,穿西装的)   消灭bug的边际报酬是递减的,即随着错误越来越少,解决bug带来的收益也在变少,务实派的理论

程序本身包含多少香农熵规格说明书也要包含同样的数量

作者在微软纽约的咨询部门做过一段时间的客户顾问

做外包软件开发不好之处:1.无法用正确的方法做事 2. 做不出优秀的产品,因为都是乙方外包,能用就行。

管理只是一种不得不做、让人讨厌的杂物活,之所以公司需要管理,只是为了不影响聪明人工作,真正的天才才能做出优秀的成果。

作者在大学里学会了写作,学会了从动态逻辑课里不要读研究生,进入了Unix这座宏伟的教堂,但其实作者也从微软身上获益良多,变得足够聪明,但还是没有学到怎么开发软件。

给计算机系的建议

  1. 写作
  2. C语言
  3. 微观经济学:供给和需求,竞争优势,净现值(NPV),贴现,边际效用
  4. GPA反应4年的总体表现

设计的作用

艺术性和实用性 form follow function

进入最后测试阶段就会变得特别挑剔

你之所以会有好运气,那是因为你寸土必争

设计不用太宏伟,但细节要跟上

太多的选择会损坏内心的幸福感

作者以自己软件论坛作为例子,说明了功能和倾向性方面取舍。

大型的项目管理

微软ie8.0的开发,雷克萨斯pk橄榄树,要不要向过去兼容的问题

标准也会引发误解、困惑甚至争议

一半是理想主义,一半是实用主义

项目管理其实就是做抉择

日程安排经验的主要依据是历史数据,但相应原则如下,不过这个前提是招的都是有能力和自我驱动程序员:

  1. 只有一线程序员才能提出完成日期的估计值,管理层制定的通常效果不好
  2. 发现错误就更新原来的计划
  3. 防止管理层向程序员施压,这样的产量至多提高10%,但埋下的隐患不少
  4. 一份日程规划就是一个装备积木的盒子,要么删功能要么拖延

优秀的项目经理会让开发者觉得所有重要的设计工作都是开发者在做,而项目经理只负责打打酱油,和一些非常官僚主义的事情周旋,比如应付客户写写规范。

软件开发-冰山之谜,你能看见的永远只是实现的一部分,如同冰山露出水面的部分,而水底的部分可能还有90%

每日编译发展到现在就是持续集成

排计划

  1. 使用excel,不要用project,后者是为建造办公楼设计的  
  2. 保持简单,7列:feature、task、优先级、预估、现在预估、已流逝、剩余工时,最终完成时剩余工时==0,现在预估==已流逝
  3. 每个功能点要分解任务列表  
  4. 只有负责些代码的程序员才能预估时间
  5. 细分任务到小时单位,作者理解的设计就是决定要做什么  
  6. 记录原始和当前的时间估计,实现不断练习估算时间  
  7. 每天更新消耗时间栏  
  8. 考虑假期  
  9. 考虑调试代码的时间,考虑修复bug的时间  
  10. 考虑集成时间,就是几个人的工作拼接起来  
  11. 预留缓冲时间:第一预估可能有延时,第二可能有新任务,第三可能有冰山  
  12. 永远不要让开发经理压缩程序员预估的开发时间  
  13. 计划就像积木:通过强迫做减法(挑出不要的积木),你将开发出更强、更好、功能配比更优秀的产品,避免延期避免交付了还有很多鸡肋的功能  

软件世界的分类(5类)

作者把基于网络的web应用列为盒装软件,咨询软件(SAP德勤)这样的介于盒装和内部软件之间。
如果只有一个企业使用其实就是内部软件,由于边际成本的原因,内部软件通常不用质量很好。
嵌入式软件
游戏和嵌入式软件一样,对软件的质量要求高,因为一般来讲游戏和嵌入式软件很少升级,也很少会出2.0版。即往往只有一个版本。
临时性软件,比如一段脚本。

编程建议

应用型匈牙利命名法 vs 系统型匈牙利命名法,后者臭名昭著,前者其实意图是表明变量的用途而不是type。

开软件公司

做生意就像看植物增长,是一种乐趣

如果你想压低程序员的工资,那么你就会得到质量很垃圾的软件,而这实际上也不会为你省下很多的钱。举了耶鲁大学的例子说明程序员的生产率差距有5-10倍。

此外,生产率不同的同事而是“普通”程序员根本做不到优秀程序员所做的事情,“飙不出高音”

Seinfeld中Soup Nazi一集很看好

作者的程序员价值论断是针对生产最终产品的公司,如果只是为了内部使用,配合运营而不是销售,那么只要够用就行了,不需要特别优秀

Jonathan Ive, 苹果的设计师

办公室的租金成本是2004年人均700美金/月,人均建筑面积40平米,所以每个人有自己的办公室,目的就是招募到优秀的程序员

对你最重要最关键的部分,你一定要使用更原始的工具

客服不外包有利于永久性地解决问题

面向整个市场的软件(产品)和定制化软件

一家软件公司要想成功,必须要有一名程序员执掌大权

只有招聪明的人,才能充分授权。

“麦当劳的”厨师 pk 真正的大厨,军事化标准化的流程只能产出麦当劳,大厨都是随意的。

NIH(Nothing in Here)对于关键部分,要坚持自己的研发

慢慢发展和烧钱发展的适用场合

兼容性是先有鸡还是先有蛋问题的一大解法

用户粘度和离开的门槛是要在你占据优势地位之后的,在此之前,最好的办法是降低用户使用门槛。

开源软件的策略:是使得硬件标准化、商品化,02年就列举了sun公司的错误

FUD战术,就是欺骗和恐吓的意思了。所谓雾件,就是对各种功能特性和产品作出口头许诺。但实际上根本拿不出可以卖的东西。把微软黑的厉害。 因为含糊其辞,大家会产生微软与自己的观点不谋而合的错觉。

.net缺少链接器(linker)。把编译后版本和程序中所有函数库的编译后版本合并起来,然后剔除掉所有不需要的库函数,生成一个二进制文件。

发新股不分红是为了让报表的利润好看

以最终用户为主和以程序员为主构成了windows和unix两类不同的文化,然而实际上以最终用户为主的文化来源于Apple

关于规格说明书

规格说明书体现的是写作能力,他的规格说明书写的让人很容易阅读。

待解决的问题需要在说明书里确定,不要觉得可以先让程序员做简单的部分,之后再慢慢思考并解决剩下的难题,这不是好主意,因为在实现代码的过程中会冒出许多新问题。

项目经理/产品经理没有权利让程序员听命,必须努力争取大家的认同才行,这种方式才能确保团队永远在做正确的事情。

规格说明书古今中外其实都不太有人爱读,因此写好很难。所以要写出引人入胜的规格书可以遵循一下几点:

  1. 要幽默  
  2. 像编写用大脑执行的代码一样写规格书,仅仅做到正确不够还要易于理解  
  3. 写的尽可能简单, 并擅用排版  
  4. 重读并修改几遍  
  5. 尽量不要套用模板