这篇博客是近期读书的一些总结。虽然说是近期,但时间跨越了大约半年左右。主要是博客久未更新,虽然常有写点总结的想法,但到后来亏欠的越来越多,越来越不敢写了。终于在五一的时候抽空梳理了一下。主要简要写了以下几本书的读书总结:《网站运维:保持数据实时的秘籍》,《我编程,我快乐:程序员职业规划之道》,《项目百态:深入理解软件项目行为模式》,《项目百态:深入理解软件项目行为模式》,《精益开发实战:用看板管理大型项目》,《打造facebook》,《Go语言编程》,《三体》 等。

《网站运维:保持数据实时的秘籍》(Web Operations:Keeping the DAta on Time)

豆瓣读书

互联网运维相关的书能上升到“道”这个层面的书很少,这个算一本。对数据采集测量,持续部署,监控,容灾,故障分析等各主题都有涉及。尤其当前互联网服务越来越庞大,开发和运维的职责已经无法明确切割。业务应用与监控,数据采集,部署,配置管理等系统都需要精密结合,最后才能组合出一个完整的系统。文中对面向服务体系结构的几点总结:

  • 应该是模块化的 “做一件事情,并且做好”
  • 应该是协作的 “让我们成为一个村落” 每个服务都需要暴漏API供其他系统协作
  • 应该是可组合的 “应该一切准备就绪” 等准备好了模块化服务后即可组合出更复杂的服务

值得开发以及运维人员一读。

《我编程,我快乐:程序员职业规划之道》(The Passionate Programmer:Creating A Remarkable Career In Software Development)

豆瓣读书

这本读的是从豆瓣上买的电子版本。 去年十一放假时候读的。引起了我从另外一个角度思考职业规划:

职业规划以及对技术的投入,可以用商业的思维进行投入产出分析。

而自己以前学技术,做职业规划,全凭兴趣,以及际遇,缺少理性的分析。程序员往往有一些理想注意,可能往往怀着一腔热血,而缺少商业性思维分析。另外一个局限程序员思维的原因是心理学上的会影响大多数人的 禀赋效应:当个人一旦拥有某项物品,那么他对该物品价值的评价要比未拥有之前大大增加。对程序员来说,一旦掌握某项技能,那他对该技能的评价要大于未掌握的其他技能。这也是为啥争吵各语言优劣的话题往往成为各技术论坛的月经贴,同时也可以发现一般最激烈的言论来自只掌握其中某一种语言的开发者。这种心理对程序员的另外一种影响是锤子效应,当拥有一个锤子后往往会将所有问题看成钉子,试图用一种技术解决所有问题,导致技术选型上不能理性分析。

《项目百态:深入理解软件项目行为模式》(Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior)

豆瓣读书

这本也读的是从豆瓣上买的电子版本。 这本书类似技术书中的短篇散文集。每个模式自称一篇,无上下文关系,组织结构也相对零散,可以用来随意翻阅。往往发现作者描述的许多模式正是自己工作中遇到的。 有的你可能也觉得需要改进,但总有借口安慰自己,而作者会用他犀利的分析剥除你仅存的一些遮蔽物。

如:

模式32 加班预兆

经理认为,项目早期的加班表明项目的健康状况非常令人满意。他们把这视为一种信号,表明自己在团队鼓舞和个人激励方面做的很好。 但是,这也可能源于恐惧:

  • 基于恐惧的管理
  • 惧怕为了削减成本二裁员
  • 惧怕个人失败
  • 惧怕项目失败
  • 确信项目会失败,但惧怕个人承受责备

也有的条目看了会给你许多鼓励.

如:

模式67 十字槽螺丝帽

如果自己的流程改进建议没有被采纳,不要垂头丧气,因为组织本身会抗拒变化。想一想发明家亨利·菲利普斯在20世纪30年代发明了十字槽螺丝帽,而到二十世纪80年代才开始全面应用。要推动一个想法到付诸实践需要足够的耐心和毅力。

《打造facebook》

豆瓣读书

也是从豆瓣上买的电子版。在地铁上看完。书中对facebook的招聘,培训,工程师文化,团队管理,开发流程各方面都有阐述。语言朴实,虽然作者是工程师出身,但视角不仅局限在技术层面。值得一读。

《精益开发实战:用看板管理大型项目》(Lean from the Trenches: Managing Large-Scale Projects with Kanban

)

豆瓣读书

如副标题所示,这本书让我体会最深的是看板。 看板主要的好处有几个:

  1. 确定优先级 优先级一目了然,如果老板,领导,产品,有新的想法需要插入时请先看看当前的任务列表。这个一定程度上确保任务不会被头脑发热的想法或者临时事务打乱。
  2. 区分技术改造和功能开发 保证不要亏欠太多的技术债务,避免后期受技术债务拖累
  3. 清晰的掌握整个工作流的任务状况,快速发现影响交付周期的瓶颈点比如 开发功能太快,导致测试堆积,延长交付周期,这时候就需要重点进行技术改造,加快测试速度(如:提高单元测试覆盖率,完善自动化测试工具等)
  4. 协助开发人测试运维人员进行工作计划以及安排 虽然开发者个人进行工作计划或者写工作日报是个好习惯,但据我观察,能这样坚持的人如凤毛麟角。也有的公司强制开发人员写工作日报,但一般都流于形式,收益甚微。如果有看板每日早晨review,这个工作会简单许多,并且节省时间。
  5. 如果是大型团队,看板拆分,便于各小团队之间的沟通 很多大团队会通过周会等机制进行定期沟通,互通有无,协调工作。但这往往会导致冗长的会议,沟通也不能及时。如果各小组每日先行组内例会,然后再由teamleader进行大的项目同步例会,对于消除大会议以及及时沟通有非常大的意义。

总结,看板只是一个工具,需要和Scrum,XP,Sprint等思想结合。工具不是万能的,重点还是在团队的组织方式和开发交付的思维方式的改进。

《Go语言编程》

豆瓣读书

过年在老家的时候不能上网,通过文档抽空学了下go语言。后来又买了这本书。总体上这本书是当前的 go语言书中比较不错的一本。但缺点在于对go的并发机制以及内存回收机制这两个非常重要的话题介绍的不够深入。go的并发机制是其最大的亮点go的存在基础,而内存回收机制更是是否能革c和java命的根基。 既然说到了这个书,当然也需要说说对go语言的看法。

go语言除了go这个并行计算的亮点不说,其他的优点有:

  1. 非侵入式接口 习惯了java的侵入式接口,开始的时候这个我还不太接受。感觉这样设计,类的开发者不知道自己实现了那些接口,修改的时候如何确保不会影响使用方?没有了侵入接口的静态检查,会不会导致代码变更失控?但后来一想,java中流行的许多非侵入性框架不也通过代理模式实现了非侵入式接口。这个类似于流行的约定大于配置的概念。一些基本的,通用的接口比如Collection等,工具包中会前置约定或者由社区形成约定,大家遵循约定即可。

  2. go的面向工程的设计 由语言的进化可以看出,早期的语言一般只提供了语法规则以及编译器,甚至没有标准库。后来的语言都会提供一个内置的标准库。再后来的语言会提供包管理以及依赖管理机制。而go提供的不仅如此,提供包括工程管理,文档管理,内置的单元测试机制,源码格式化等一整套工具。

《三体》

这个是地铁上看的。没有找到正版电子书,下载了盗版(纸书实在太厚,携带不方便),等有了正版再支持作者吧。 可以说这个书出乎意料,国人在硬科幻领域少有建树。这本书兼顾小说的情景感,硬科幻的理论支撑,哲学的宏观思考,实为不易。不过到后期的时候由于时空跨越太大,个体对宇宙周期这样跨度的时空,缺少直观的体验,所以不太深刻。

《架构师》系列刊物以及科幻系列刊物

略。