ThoughtWorks读书雷达-编码实践篇

标签: thoughtworks 读书 雷达 | 发表时间:2013-04-27 16:03 | 作者:
出处:http://agiledon.github.com/

期望通过四分之一的读书雷达图就能将与编码实践有关的优秀书籍一网打尽,自然是不现实的打算。因此,我们希望就我们的侧重点来推荐书籍。对于编码实践而言,我们共同认为培养良好的编码习惯,编写整洁简单而又合理的代码,是一名好程序员的基本要求。因此,这里我们更强调与程序员基本编码技能相关的知识。我们并没有给出与算法直接有关的书籍,虽然我们认为算法知识同样属于编码实践的范畴,虽然我们认为诸如《计算机程序设计的艺术》、《编程珠玑》、《算法导论》之类的书籍同样很重要很优秀;然而,我们取舍再三,仍然将它们划出了读书雷达的范围。我们认为:算法知识更应该划定到大学教育的范畴,若工作需要,则又偏向于更为专精的领域,并不适合读书雷达这种普适性的推荐。相对于具体的算法,或许我们更看重程序员的逻辑思维以及抽象建模的能力。

在Coding Practice维度的Fundamental圈中,我们强烈推荐了Robert Martin的Clean Code《 代码整洁之道》与 The Clean Coder程序员的职业素养》,以及Martin Fowler的Refactoring《 重构:改善既有代码的设计》。我不知道有多少人是阅读了Clean Code之后,才开始自己的整洁代码之旅;至少在我身边,这样的例子不胜枚举。把代码写成像散文那样美好,不仅仅是对美学的追求,更重要的是它能够极大地降低维护成本。在某种程度上讲,代码可以说是软件系统的质量基石。虽然重构的重要性被一直不断地提起,但我们发现真正掌握了重构手法的程序员,仍然屈指可数。通过对Refactoring一书的阅读,弄清楚什么是代码的坏味道,继而运用正确的重构手法,就能保证代码足够的整洁,甚至优雅。Robert Martin的另一本书Clean Coder与Clean Code一字之差,内容却大相径庭。它更多地是对程序员自身修养的关注。我们之所以强烈推荐它,并将其放入Fundamental圈中,是因为它介绍的知识,能够有效地帮助新入职场的程序员从一开始就能建立良好的编码习惯与意识。我们认为,这种好的习惯与意识,甚至比掌握某种开发技能显得更为重要。

我们仍然要推荐Kent Beck的Test-Driven Development By Example《 测试驱动开发》以及Andy Hunt的Pragmatic Unit Testing《 单元测试之道》,固然源于我们对测试驱动开发以及提高单元测试覆盖率抱有强烈的热忱,还在于我们认为目前中国软件开发的现状,测试不足仍然是普遍现象。姑且不谈测试驱动开发的优劣,至少我们认为这种测试驱动的理念对于提高开发与设计质量颇有可观之处。我们也看到了太多测试不足的遗留系统,在希望通过重构来改善结构时的举步维艰。我们还选择了Neal Ford的著作The Productive Programmer《 卓有成效的程序员》,它与Robert Martin的The Clean Coder颇有相似之处。我们喜欢本书的理由在于,如果我们能践行该书提到的方法与理念,确乎能够提高我们的开发效率,成为一名高效的程序员。我们一直认为中国的读者低估了本书的重要性,是因为该书涵盖的理念,其实可以扩充为好几本高文厚册。对于书中提到的设计原则,我们不是了解得太多,而是太少。选入Dustin Boswell等人的著作The Art of Readable Code《 编写可读代码的艺术》,主要因为该书讨论的可读性代码,包含了Clean Code没有涉及的其他语言,例如C++、PHP、Javascript。要写出可读性良好的代码,了解多种语言是有必要的,且不同语言的编码风格总有不同之处。

对于Medium层次的程序员而言,我们希望能开拓程序员的眼界,至少要将编码实践的技能纳入到整个软件开发生命周期中。因此,我们推荐了David Thomas与Andy Hunt的著作The Pragmatic Programmer《 程序员修炼之道》以及Steve McConnell的著作Code Complete《 代码大全》。这两本书都获得了广泛的赞誉,前者是对程序员综合技能的整体梳理,后者则是对软件开发过程的高度提炼。The Pragmatic Programmer一书既有战略层面的思想与决策,又有战术层面的技巧与招式。整体而言,它提供了程序员修炼的法则,努力遵循这些法则,你就有机会成为编程专家。Code Complet则为我们展示了一幅巨细无靡的软件开发画面,牵涉到了架构、设计、编码、测试、构建等诸多内容,内容全面但并不肤浅。唯一不足之处在于,它实在太厚了。

Kent Beck的Implementation Patterns《 实现模式》提到的模式,似乎更近于惯用法与设计模式之间。Kent Beck是真正将Java与设计精髓吃透,并能编写出好代码的大师,他的著作总是显得那么睿智而又简练,内容直指本质,没有多余的废话。我们要强烈推荐本书的理由只是因为它的内容太精彩了,尤其对于Java程序员而言,你需要再三阅读。我们还将Joshua Kerievsky的Refactoring to Patterns《 重构与模式》放到了这个维度,是因为我们更愿意从编码以及重构的角度去看待设计。本书填补了Martin Fowler著作的空白,书中介绍的重构手法与设计理念,可以帮助我们更好地理解何谓“简单设计”,时刻警惕“过度设计”的陷阱。

我们之所以将Michael Feathers的著作Working Effectively with Legacy Code《 修改代码的艺术》放到Coding Practice的Advanced圈中,是因为我们充分考虑了遗留代码的复杂性。面对这种复杂性,不能仅仅靠纸上谈兵的方式,寄希望于书中介绍的手法就能处理这些纠缠不清的糟糕代码。因此,我们认为阅读本书的前提是具有相当的处理遗留代码的经验,至少曾经经历过那种无从下手的茫然。当然,我们也不能狭隘地根据书名得出结论,认为这本书专为遗留代码服务。书中介绍的诸多解除依赖的技术,事实上也可以作为通用的设计手法。

在Coding Practice维度中,我们唯一推荐了一本似乎与工程实践无直接关联的书籍,即Harold Abelson与Gerald Jay Sussman的著作Structure and Interpretation of Computer Programs《 计算机程序的构造和解释》(即SICP)。作为MIT(曾经的)计算机系第一门编程课的教材,这本书没有像诸多基于C或者Java的编程入门教材那样纠结于语法和库——LISP的语法确实也没什么可以纠结的。本书讲的是一些最基本的问题,比如什么是计算、什么是抽象、什么是模块化、乃至什么是时间和什么是自然数。一个以软件开发为业的程序员,或早或晚终归要想透这些问题,然后才能看破各种琳琅满目的编程语言所提供的五花八门的语法糖,以不变应万变地坦然面对一切不涉及并发的程序设计问题。把这本书当做第一本编程教材或许有些激进(MIT也已经不再这样做),但你早晚会遇到它。有人不无夸张但相当在理地说:自SICP以降,【无并发的】编程没有任何新鲜问题;如果你觉得自己有了新发现,要么是SICP已经写过只是你不知道,要么是你想错了。

相关 [thoughtworks 读书 雷达] 推荐:

ThoughtWorks读书雷达-编码实践篇

- - 简单文本
期望通过四分之一的读书雷达图就能将与编码实践有关的优秀书籍一网打尽,自然是不现实的打算. 因此,我们希望就我们的侧重点来推荐书籍. 对于编码实践而言,我们共同认为培养良好的编码习惯,编写整洁简单而又合理的代码,是一名好程序员的基本要求. 因此,这里我们更强调与程序员基本编码技能相关的知识. 我们并没有给出与算法直接有关的书籍,虽然我们认为算法知识同样属于编码实践的范畴,虽然我们认为诸如《计算机程序设计的艺术》、《编程珠玑》、《算法导论》之类的书籍同样很重要很优秀;然而,我们取舍再三,仍然将它们划出了读书雷达的范围.

ThoughtWorks读书雷达方法学篇-张逸

- - 人月神话的BLOG
原文: http://agiledon.github.io/blog/2013/08/06/methodologies-of-reading-radar/. 方法学(Methodology)看似与开发技能无关,常为程序员忽略. 忽略意味着未曾察觉,却不等于它的无关紧要. 我们每时每刻呼吸的空气同样会被我们忽略,但空气不重要么.

2013年的技术趋势 — ThoughtWorks技术雷达阅读笔记

- - I am Hu Kai
边界正在变的更加模糊,传统上办公室是工作发生的地方,我们需要内部网络来登陆邮件系统,访问公司的知识库,利用电话会议系统和处于世界各地的同事交流. 随着移动设备的普及,网络速度的提升以及越来越多的内部系统被迁移到同时提供外部访问的云平台上,工作正在从办公室扩展到生活的每一处,在出租车上,我们用手机阅读和回复邮件;在机场,我们使用Goto Meeting来和各地的同事举行电话会议;在客户现场,我们用手机访问Jive.

再见ThoughtWorks!

- lnsoso - Happy Hacking
最近的几个月时间里我的工作和生活都发生了较大的变化:因为家庭原因,我离开了生活了六年之久的北京,来到了上海和妻子团聚;同时,我也因此而离开了 ThoughtWorks ,加入了设计软件公司 Autodesk. 回首过去的几年时间,我能很清晰地感觉到自己对软件开发的认识不断地发生着有趣的变化:. 眼中只有C#/.NET/Windows,“外面"的世界.

聊聊ThoughtWorks面试

- - 梦想风暴
最近有几篇关于科技公司面试的新闻,这篇格外受瞩目,因为竟然有公司力压Google,成了面试最难的公司,而这个公司居然是ThoughtWorks. 这个结果真的让我有些惊讶,作为一个面试过许多人的ThoughtWorker,我之前还真没想过我们的面试到底有多难. 既然有人关心ThoughtWorks面试,我就不妨在此分享一下我的“面经”.

如何快速读Paper – ThoughtWorks洞见

- -
去哪里找paper之后,大家问我的问题就常常变成了:. 如何快速阅读一篇paper并准确的提取其中有用的信息. 在本文中,我将试图为大家简要解答这个问题,争取告诉大家如何在短时间内通过阅读文献的方式了解一个新的领域. 阅读一篇paper通常见的目的有四种:. 面对一个新的领域,我要快速把握这个领域的研究方向和state-of-the-art方法,来给自己或者团队设计一个大致的技术方案.

再谈敏捷和ThoughtWorks中国咨询师

- lishali - 酷壳 - CoolShell.cn
之所以用了“再”,是因为之前的两篇文章——. 我在《那些炒作过度的技术和概念》中批评了ThoughtWorks中国咨询师的咨询方法是以一种接近于教条、炒作、洗脑和电视购物的方法(虽然我心底觉得有时候有时候更像传销),当然,批评是没有意义的,所以我也给了中国ThoughtWorks那些年轻的咨询师们一些我认为有建设性的建议.

Serverless实战:打造个人阅读追踪系统 – ThoughtWorks洞见

- -
阅读习惯和个人知识管理体系. 进入互联网时代,知识的获取成本变得前所未有的低廉,但是无论再好的知识,若是没有对个人产生价值的话,那也只不过是一种信息噪音而已. 我在《个人知识管理:知识的三种形态》这篇文章中使用“材料 -> 资料 -> 知识”这样的路径来诠释信息的流通,如何方便快捷并且有效地收集材料,再将其整理转化为有价值的个人知识体系结构,在这个信息极度碎片化的时代变得尤为重要.

微服务分布式一致性模式 – ThoughtWorks洞见

- -
微服务拆分后遇到的一个麻烦是分布后的一致性问题. 单体架构的业务处理和数据都在一个进程里面,一致性保障很成熟,开发人员基本上不用关心. 当把业务系统拆分到不同进程时,就遇到了技术性一致性问题. 这带来了纠结,我们希望有一颗银弹,一把解决问题. 但由于分布式一致性在(CAP)理论上没有完美的解决方案,我们所能选择的方案是在特定业务场景下的选择.

用DDD指导微服务拆分 - ThoughtWorks洞见

- -
对于服务拆分的逻辑来说,是先设计高内聚低耦合的领域模型,再实现相应的分布式系统. 服务的划分有一些基本的方法和原则,通过这些方法能让微服务划分更有操作性. 最终在微服务落地实施时也能按图索骥,无论是对遗留系统改造还是全新系统的架构都能游刃有余. 开发者在刚开始尝试实现自己的微服务架构时,往往会产生一系列问题 :.