邱俊涛 – ThoughtWorks洞见

如何成为优秀的程序员？

2017年9月19日2017年9月19日邱俊涛 3 条评论

作为一个从业快10年的程序员，我想给新入行的程序员们一些建议。这些建议是我希望自己可以在毕业时就读到的，也希望它们可以帮助你成为一个更好的程序员。

简单归纳一下，总共有7条：

保持健康
编程之外的爱好
持续学习
正确应对犯错
不要囿于角色
展示你的创意
刻意练习手速

下面我来详细说说每一点。

保持健康

三寸气在千般用，一旦无常万事休。

——《金瓶梅》

首先要说的当然是健康，脱离了这个本钱，一切都无从谈起。

久坐、不运动、睡眠不足、不注意及时补充水分、长期的伏案工作等都会对健康造成很大的影响，而不幸的是，程序员这几样全都占了。很多程序员往往年纪轻轻就已经有了各种各样的疾病：颈椎病、腰椎间盘突出、高血脂/高血压、胆结石、腱鞘炎等等，关于程序员过劳死的新闻更是隔一段时间就来刺激一下我们的神经。

研究表明，长期保持同一姿势（不论坐着还是站着）对身体都有不同程度的害处，而且这种害处是无法事后弥补的。也就是说，如果白天上班坐8个小时，那么就算你下班后去健身房练一个小时也于事无补。这几年很流行的“站立式办公”也是一样，如果你白天站立时间过久，会对膝关节造成较大的压力，同样会损害健康。比较推荐的方式是，写30-40分钟代码就起来走一走，喝杯水，远眺一会，跟同事聊聊天。

我知道，作为程序员我也常遇到那种写代码写High了连厕所也不想去的时候。不过为了长远的健康，还是要养成良好的习惯。

戒除不良习惯

除了长时间保持同一姿势之外，许多程序员还有各种不良习惯。比如：

吸烟
喝酒
嗜糖（碳酸饮料，其他高糖饮料）

这些习惯一般都会被美其名曰提神，大家都知道，程序员加班在业界算是比较常见的，萎靡不振是常态。然而这些号称提神的方法，其实没有一个是真正管用的。这些不良习惯说到底都是一种“毒瘾”，跟吸食大麻在本质上并无二致。不过好消息是你完全可以戒除这些不良习惯，只需要坚持一段时间，让“毒瘾”过去就好了（和真正的毒瘾一样，它们更多的是精神依赖，一旦你战胜了自己对它的精神依赖，就可以获得自由）。

我在大学和刚开始工作的前几年，也有烟瘾。写代码写累了就会去办公室外边冒一根，那种一氧化碳中毒带来的短暂微醺感确实令人有放松的错觉，但是抽完烟回来写代码会感觉更累。而且口中老感觉有异味，咽喉不适，最主要的是精神萎靡，终于有一天我受不了了，决定戒烟（事实上和很多人一样，之前也有过无数次的戒烟）。当烟瘾发作的时候，我就去喝杯水，晚上则站站桩（站完之后口齿生津，神清气爽）。刚开始的3天是最难的，一周之后我基本可以控制住去抽烟的欲望，然后就越来越轻松，完全感觉不到烟瘾对我的影响了。

碳酸饮料、高糖饮料也是一样。在饮食本来就不充裕的自然界，我们的祖先遇到了富含可以为身体提供能量的糖（比如蜂蜜），自然会大量摄入。这种嗜糖的基因在今天还在不断的产生作用，但是不同的是，我们现在可以很轻松的在食物、饮料中摄入比身体所需多得多的糖。这些糖会给健康带来很多问题，比如肥胖，高血糖，冠心病等等。

更多时候，我们想要喝饮料更多的是精神上的依赖，也就是上面说到的“毒瘾”。戒除对糖的依赖比烟和酒要困难一些，因为生活中有很多陷阱，比如酸奶、面包、饼干、水果等等。

零度可乐的陷阱

现在香烟的包装上印有焦油含量，有10mg的、有15mg的。焦油含量是影响一支烟口感的重要因素，通常说的“绵”其实是说焦油含量较低，这会让你感觉比较健康。然而陷阱是，一支烟抽完觉得不过瘾，神经感受到的刺激不够强烈，这会驱动你抽第二支，结果吸入的焦油反而更多。本来15mg焦油的一支烟就可以让你过瘾，现在两支10mg的才能达到同样的效果，相当于摄入了20mg。

零度可乐也是一样，那种无糖的有着甜味的添加剂会刺激你对糖的渴求，你需要摄入更多的糖来抵消这种虚幻的渴求，然后变得更不健康。

有人可能会说，没有这些嗜好，那活着有什么意思呢？相信我，当你戒除了这些“毒瘾”，有了一个健康的体魄，才真正能体会到活着的乐趣。当你为这些嗜好所控制，产生的那种病态的舒适感其实是虚无缥缈的。

一些建议

有规律的做一些运动可以缓解颈椎、腰椎的不适，可以加快新陈代谢的速度，消耗多余的、会沉积下来的能量。比如比较容易接触到、也容易上手的运动：

瑜伽/普拉提
乒乓球
跳绳

选择一个适合自己的运动方式，然后将其培养成一个习惯（比如坚持每周两次瑜伽，或者每天中午打30分钟的乒乓球）。如果这些和工作有冲突的话，比如公司要求长期晚上加班，那你可以考虑换一家公司。

培养一个编程之外的爱好

如果让不同的人对程序员打标签并排序，宅一定会排在前三。在任何的聚会上，程序员总是很容易被识别出来的：聪明、戴眼镜、话不多、略显闷骚、聊天容易冷场等等。也难怪，长期钻研技术，沉浸在非黑即白的二进制世界，爱刨根问底，这样很容易把天聊死。

我建议新手程序员可以找一个编程之外的爱好，一来可以拓展自己的社交圈，周末可以有个不一样的过法（而不是宅在家里写代码）；二来可以帮助你成为更好的程序员。

你肯定有过这样的经历：一个编程问题一直困扰着你，试了很久都找不到解决方法，结果出去散了会儿步，或者和别人唠家常，突然脑海里灵光一闪，想到了问题的答案。事实上，我们大脑的工作方式就是如此奇妙，换一个完全不同的上下文就可以让大脑得到很好的休息，而且往往可以产生1+1>2的效果。写代码写累了去听听音乐，或者打一会乒乓球就可以很好的缓解疲劳，甚至可以打开思路，产生新的灵感。

一些建议

学习一项与编程无关的技能，比如：

乐器（如吉他，架子鼓）
绘画（素描，水粉，水彩等）或者书法
制作美食
某一项武术（拳击，泰拳，空手道等）

这些看似毫不相干的爱好可以帮助大脑休息。另外需要注意的是，你无需真正成为某一项爱好的专家，不要有额外的压力：担心演奏不好、没有绘画天赋等等。没关系，它只是一个爱好而已。

我自己就尝试过很多不同的爱好，比如素描、书法等。

持续学习

软件开发是一个需要终身学习的行业（其实如果你不想做那种混吃等死的人的话，基本上每个行业都是这样）。我毕业的时候，SSH（Spring Struts Hibernate）是Web开发的主流，jQuery则是前端的新锐。有一些企业开始尝试Adobe的ActionScript，不过这个语言很快就消逝在了人们的视野中。基于jQUery，但是融入了MVC理念的Backbone.js提供更高级的抽象能力，成为了开发“大型”前端应用的首选；紧随其后的，大而全的Angular.js则通过内置的双向绑定、依赖注入、完善的测试支持等让前端开发变得和后端开发一样健全；再后来虚拟DOM，Reactive范式的React栈则又一次颠覆了前端的开发方式。虽然现在还不知道下一次的颠覆会在哪里发生，但是可以肯定的是它一定会发生。

除了基础框架之外，各种构建工具也是层出不穷，从最早和后端放在一起的maven，rake，到基于NodeJS的grunt，再到gulp，到webpack，最后又回归到npm script。

程序员被裹挟在技术演进的洪流中，不能自已。作为程序员，你不但要非常扎实的掌握基础知识（操作系统原理，计算机网络，数据结构，算法等），还需要有非常强的快速学习能力，以及愿意不断去学习的态度，而后者可能更重要。

一些建议

读书
通过视频/文本教程等学习新技术

建议新手每天抽出一个小时来读书，周末可以多读一些。ThoughtWorks有个读书雷达，是一个很不错的书单，包括了很多的经典书籍。读书之外，还可以在线学习一些教程，比如Tutorialplus和Egghead等，都非常值得经常去看看，如果有比较新鲜有趣的技术，不妨自己亲自动手试一试。

关于英文能力

毫不夸张的说，英文能力是优秀程序员和普通程序员的华丽分割线。有了好的英文能力，可供你学习的资料库会立刻扩大数百甚至数千倍：海量的优质免费教程，视频，和优秀的中文教程一样，它们都深入浅出，通俗易懂，风趣幽默，只不过中文的会比较少，而且一般总是会滞后于英文版本而已。

英文能力不但可以帮你熟悉各种前端库、CSS框架等的介绍。还可以让你学习世界各国程序员对各种库的测评、框架的使用心得、踩过的坑等等。

我在2012年加入ThoughtWorks的时候，面试时磕磕绊绊的说不出话来。等到6个月试用期结束的时候，已经可以出差去澳洲和客户的OPs谈笑风生了。2013年的8月，在印度普内，我已经可以用英文给来自世界各国的学生讲课。

除了更顺畅的和不同文化的人交流、讨论问题之外，可以明显感觉到学习的速度变得更快，更有效率。

我自己实践过的一个比较有效的方法。我每天会花两个小时（早晚各一个小时）看澳洲之音上的视频，我会听写出视频中的每一句话，如果听不清就重复，有的句子可能会重复十遍。听到最后，视频中的每句话我都能听懂，而且能一边听一边写出来。这样坚持了差不多3个月，我基本上就可以听懂客户的需求澄清，开会的时候也可以比较完整的听明白每个人讨论的点。

其实诀窍就是坚持，这3个月中，每天两个小时，我没有一天间断。过了这一关之后，就很容易了，尽量多听多说就好。

另一个提高的方法是翻译书，我更建议你跟另外一个有经验的同事一起翻译，大家互相监督，也有个照应，比较不容易半途而废。

正确应对犯错

斯坦福大学的Carol Dweck教授通过一些实验和后续的研究提出了很有名的心智模型（Mindset）理论，简而言之，她发现不同的人们对待失败这件事有着完全不同的态度：有一类人害怕失败，失败后会变得不能接受，而且容易否定自身并影响进一步的尝试，Dweck教授称这类人为固定型思维模式（Fixed Mindset）；而另一类人则“喜欢”失败，视失败/犯错为学习的一种方式，他们更关注过程而不是结果，Dweck教授称其为成长型思维模式（Growth Mindset）。

Dweck在演讲中提到，通过向成长型思维模式的转变，关注从失败/犯错中学习，人们的潜力可以得到很好的发挥，也更容易获得理想的结果。

很多新人不敢尝试，又不愿意让同事知道自己的不足，这样的态度会导致他更倾向于选择更容易的工作，这样就可以避免暴露自己的不足，久而久之就会形成恶性循环。其实企业对于新人的期望一般都不会很高，对于新人犯错也是有容忍度的，新人要勇于承认自己的不足，勇于尝试新的事物，勇于犯错并从中学习。

承认自己的不足在刚开始是一件很困难的事情，不过在尝试过几次之后，你就会发现其实也没有那么恐怖。你慢慢会喜欢那种不带任何包袱的、全身心聚焦在学习本身上的快乐。

不要被角色限制

都梁在《血色浪漫》里有段描述陕北农民的文字：

钟跃民惊讶地发现，在如此贫困恶劣的生存状态下，村民们却很少愁眉苦脸，他们始终很乐观，他们最喜欢谈论的话题是饮食男女。在饮食方面，由于他们没见过更好的食品，所以坚持认为酸汤饺子和油泼辣子是天下最美味的食品，如果有人提出世上还有很多更好吃的东西，那大家会一致认为此人太没见过世面，这八成是没吃过酸汤饺子，才在这儿胡咧咧.

就像酸汤饺子并非天下最美味的食品一样，开发也不是世界上最牛逼的工作。任何一个良好的，健康的产品、项目都需要不同的角色共同配合，共同努力。如果仅仅将自己局限在程序员这一角色，时间久了未免会有坐井观天的狭隘。

作为程序员，既可以往上游去探索需求的梳理，用户痛点的分析，业务价值的挖掘，又可以向下游如测试的编写，产品的发布，运维监控。视野开拓了，才有可能对产品有整体的了解，也更容易在程序员这个角色上做的更好。

作为新人，能在自己擅长的方面发挥长处当然很好，但是如果仅仅局限在自己擅长的方面则未免太过单薄。如果你在前端非常有经验，那么除了将这些经验和知识分享给别人之外，你还可以向别的角色学习他们擅长的技能，比如向测试学习自动化、SBE等；向后端学习高性能，高可用服务器的技术、数据库设计及优化、API设计等；向DevOps学习运维技能，自动化provision技能等等。

这些不同的技术不但可以让你的视野更加开阔，也可以为自己以后尝试不同的角色和机会打好基础。以我自己为例，我刚工作的时候是一个Java开发，后来开始做产品的前端开发。换了工作后又跑到Linux下用C写服务。再后来加入ThoughtWorks后，正经职位是开发，不过在项目上还兼职过一段时间QA，在有些项目上，当UX不在场的时候还可以做些简单的设计，在技术社区当讲师，还在一些客户现场做过咨询顾问。我自己觉得在不同的角色上切换非常有意思，我自己也很享受整个过程。

展示你的创意

将一个创意、复杂概念或者想法简洁而准确的描述出来是一个非常重要的能力。我见过太多的程序员都是沉默寡言，讲东西声音又小，又紧张，即使有很好的想法也难以完整的表述出来。

不过这个能力是可以锻炼的，只需要借助原型的制作就可以了：

画图
静态原型
纸上原型

俗话说，一图胜千言。你只需要学习一些简单的绘画技巧就可以大大提高自己的表述能力。

通过用静态页面（HTML/CSS/JS），mock数据等方式，快速的将创意表达出来是程序员的一个优势，你可以用静态数据、数据文件等方式，通过一些简单的代码快速的作出可以做交互的原型，然后通过和用户不断确认的方式来渐进增强，这种做法可以避免太大的浪费，尽早的将客户价值交付。

原型并不局限在草图，可以工作的静态页面，还可以是一个清晰简洁的演讲。基于PPT的原型还可以用来分析目前产品痛点、对比方案的优劣、展示自己的看法等等。

纸上原型是另一种低成本，可供快速交流沟通的原型方式：

（图片来自我在ThoughtWorks的同事刘海生）

手速

关于程序员是否要求很快的手速是一个颇具争议的话题。支持者认为这属于基本功，每个程序员都应该打字都很快；反对者则认为程序员的价值在于思考并解决问题，追求速度快，那还不如招个打字员。我个人的观点是，好的程序员应该有很快的手速（包括打字的速度，但不局限于此）。

我在ThoughtWorks西安办公室组织过很多次提升手速的工作坊，比如三周三页面，闪电计划等。基本原则就是对一个具体的“作业”，不断的重复练习。

最近带两个新人，我给他们布置了一个简单的作业：

图片来源：dirbbble.com

基本要求是以最快的速度实现这个页面，并有一点微小的交互（比如选择联系人之后的checkbox会显示选中状态，剩余invites的数量减少等）。第一次做他们用了5个多小时（连同搭建环境，安装Node.js，npm包等），第二次用时2个半小时，第三次用时1个半小时，第四次用时50分钟。

对同一个页面的不断练习听起来是在做重复工作，其实可以联系到很多的内容：

命令行的熟悉程度
快捷键的使用
搜索引擎的使用
Stackoverflow的使用

当你真的可以熟极而流的时候，你才有时间来考虑如何优化，比如如何抽取模板工程（这样下次做同样的事情就会快很多），如何精简DOM结构，如何用命令行工具来帮助自己提速等。手速是大前提，没有速度，一切优化都是脑海中的意淫，无法真实落地。

总结

要成为一个厉害的程序员，首先当然是要有一个好的身体。此外需要培养一个编程之外的爱好，这样可以让你活的像一个正常人（而不是传统的工科书呆子）。程序员是一个需要不断学习，不断充实的职业，在学习的过程中，英文能力可以帮助你学的更快，更有效，另外正确的应对学习过程中必然会犯的错误，并将每次错误都当成学习的机会。

开发只是软件开发流程中的一环，程序员需要拓展自己的视野，和其他角色一起配合才能保证产品的交付。在日常的开发中，程序员还需要快速、准确的将自己的想法和创意表达出来。最后，更快速的完成手头的工作可以让你有更多的时间来思考，来改进那些低效的工作方式。

扩展阅读

更多精彩洞见，请关注微信公众号：思特沃克

从三明治到六边形

2017年6月5日2017年6月6日邱俊涛 1 条评论

软件项目的套路

如果你平时的工作是做各种项目（而不是产品），而且你工作的时间足够长，那么自然见识过很多不同类型的项目。在切换过多次上下文之后，作为程序员的你，自然而然的会感到一定程度的重复：稍加抽象，你会发现所有的业务系统都几乎做着同样的事情：

从某种渠道与用户交互，从而接受输入（Native App，Mobile Site，Web Site，桌面应用等等）
将用户输入的数据按照一定规则进行转换，然后保存起来（通常是关系型数据库）
将业务数据以某种形式展现（列表，卡片，地图上的Marker，时间线等）

稍加简化，你会发现大部分业务系统其实就是对某种形式的资源进行管理。所谓管理，也无非是增删查改（CRUD）操作。比如知乎是对“问题”这种资源的管理，LinkedIn是对“Profile”的管理，Jenkins对构建任务的管理等等，粗略的看起来都是这一个套路（当然，每个系统管理的资源类型可能不止一种，比如知乎还有时间线，Live，动态等等资源的管理）。

这些情况甚至会给开发者一种错觉：世界上所有的信息管理系统都是一样的，不同的仅仅是技术栈和操作的业务对象而已。如果写好一个模板，几乎都可以将开发过程自动化起来。事实上，有一些工具已经支持通过配置文件（比如yaml或者json/XML）的描述来生成对应的代码的功能。

如果真是这样的话，软件开发就简单多了，只需要知道客户业务的资源，然后写写配置文件，最后执行了一个命令来生成应用程序就好了。不过如果你和我一样生活在现实世界的话，还是趁早放弃这种完全自动化的想法吧。

复杂的业务

现实世界的软件开发是复杂的，复杂性并不体现在具体的技术栈上。如Java，Spring，Docker，MySQL等等具体的技术是可以学习很快就熟练掌握的。软件真正复杂的部分，往往是业务本身，比如航空公司的超售策略，在超售之后Remove乘客的策略等；比如亚马逊的打折策略，物流策略等。

用软件模型如何优雅而合理的反应复杂的业务（以便在未来业务发生变化时可以更快速，更低错误的作出响应）本身也是复杂的。要将复杂的业务规则转换成软件模型是软件活动中非常重要的一环，也是信息传递往往会失真的一环。业务人员说的A可能被软件开发者理解成Z，反过来也一样。

举个例子，我给租来的房子买了1年的联通宽带。可是过了6个月后，房东想要卖房子把我赶了出来，在搬家之后，我需要通知联通公司帮我做移机服务。

如果纯粹从开发者的角度出发，写出来的代码可能看起来是这样的：

public class Customer {
     private String address;

     public void setAddress(String address) {
         this.address = address;
     }

     public String getAddress() {
         return this.address;
     }
}

中规中矩，一个简单的值对象。作为对比，通过与领域专家的交流之后，写出来的代码会是这样：

public class Customer {
     private String address;

         public void movingHome(String address) {
         this.address = address;
     }
}

通过引入业务场景中的概念movingHome，代码就变得有了业务含义，除了可读性变强之外，这样的代码也便于和领域专家进行交流和讨论。Eric在领域驱动设计（Domain Drvien Design）中将统一语言视为实施DDD的先决条件。

层次架构（三明治）

All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections. — David Wheeler

上文提到，业务系统对外的呈现是对某种资源的管理，而且，现实世界里的业务系统往往要对多种资源进行管理。这些资源还会互相引用，互相交织。比如一个看板系统中的泳道、价值流、卡片等；LinkedIn中的公司，学校，个人，研究机构，项目，项目成员等，它们往往会有嵌套、依赖等关系。

为了管理庞大的资源种类和繁复的引用关系，人们自然而然的将做同样事情的代码放在了统一的地方。将不同职责的事物分类是人类在处理复杂问题时自然使用的一种方式，将复杂的、庞大的问题分解、降级成可以解决的问题，然后分而治之。

（图片来自：http://t.cn/RSNienv）

比如在实践中，展现部分的代码只负责将数据渲染出来，应用部分的代码只负责序列化/反序列化、组织并协调对业务服务的调用，数据访问层则负责屏蔽底层关系型数据库的差异，为上层提供数据。这就是层级架构的由来：上层的代码直接依赖于临近的下层，一般不对间接的下层产生依赖，层次之间通过精心设计的API来通信（依赖通常也是单向的）。

以现代的眼光来看，层次架构的出现似乎理所应当、自然而然，其实它也是经过了很多次的演进而来的。以JavaEE世界为例，早期人们会把应用程序中负责请求处理、文件IO、业务逻辑、结果生成都放在servlet中；后来发明了可以被Web容器翻译成servlet的JSP，这样数据和展现可以得到比较好的分离（当然中间还有一些迂回，比如JSTL、taglib的滥用又导致很多逻辑被泄露到了展现层）；数据存储则从JDBC演化到了各种ORM框架，最后再到JPA的大一统。

如果现在把一个Spring-Boot写的RESTful后端，和SSH（Spring-Struts-Hibernate）流行的年代的后端来做对比，除了代码量上会少很多以外，层次结构上基本上并无太大区别。不过当年在SSH中复杂的配置，比如大量的XML变成了代码中的注解，容器被内置到应用中，一些配置演变成了惯例，大致来看，应用的层次基本还是保留了：

展现层
应用层
数据访问层

在有些场景下，应用层内还可能划分出一个服务层。

前后端分离

随着智能设备的大爆发，移动端变成了展现层的主力，如何让应用程序很容易的适配新的展现层变成了新的挑战。这个新的挑战驱动出了前后端分离方式，即后端只提供数据（JSON或者XML），前端应用来展现这些数据。甚至很多时候，前端会成为一个独立的应用程序，有自己的MVC/MVP，只需要有一个HTTP后端就可以独立工作。

前后端分离可以很好的解决多端消费者的问题，后端应用现在不区分前端的消费者到底是谁，它既可以是通过4G网络连接的iOS上的Native App，也可以是iMac桌面上的Chrome浏览器，还可以是Android上的猎豹浏览器。甚至它还可以是另一个后台的应用程序：总之，只要可以消费HTTP协议的文本就可以了！

这不得不说是一个非常大的进步，一旦后端应用基本稳定，频繁改变的用户界面不会影响后端的发布计划，手机用户的体验改进也与后端的API设计没有任何关系，似乎一切都变的美好起来了。

业务与基础设施分离

不过，如果有一个消费者（一个业务系统），它根本不使用HTTP协议怎么办？比如使用消息队列，或者自定义的Socket协议来进行通信，应用程序如何处理这种场景？这种情况就好比你看到了这样一个函数：

httpService(request, response);

作为程序员，自然会做一次抽象，将协议作为参数传入：

service(request, response, protocol);

更进一步，protocol可以在service之外构造，并注入到应用中，这样代码就可以适配很多种协议（比如消息队列，或者其他自定义的Socket协议）。比如：

public interface Protocol {
  void transform(Request request, Response response);
}

public class HTTP implements Protocol {
}

public class MyProtocol implements Protocol {
}

public class Service {     
   public Service(Protocol protocol) {
         this.protocol = protocol;     
   }          

   public void service(request, response) {
         //business logic here
         protocol.transfrom(request, response);     
   }
}

类似的，对于数据的持久化，也可以使用同样的原则。对于代码中诸如这样的代码：

persisteToDatabase(data);

在修改之后会变成： persistenceTo(data, repository);

应用依赖倒置原则，我们会写出这样的形式：

public class DomainService {
     public BusinessLogic(Repository repository) {
           this.repository = repository
     }

      public void perform() {
           //perform business logic
           repository.save(record);
     }
}

对于Repository可能会有多种实现。根据不同的需求，我们可以自由的在各种实现中切换：

public class InMemoryRepository implements Repository {}
public class RDBMSRepository implements Repository {}

这样业务逻辑和外围的传输协议、持久化机制、安全、审计等等都隔离开来了，应用程序不再依赖具体的传输细节，持久化细节，这些具体的实现细节反过来会依赖于应用程序。

通过将传统内置在层次架构中的数据库访问层、通信机制等部分的剥离，应用程序可以简单的分为内部和外部两大部分。内部是业务的核心，也就是DDD（Domain Driven Design）中强调的领域模型（其中包含领域服务，对业务概念的建立的模型等）；外部则是类似RESTful API，SOAP，AMQP，或者数据库，内存，文件系统，以及自动化测试。

这种架构风格被称为六边形架构，也叫端口适配器架构。

六边形架构（端口适配器）

六边形架构最早由Alistair Cockburn提出。在DDD社区得到了发展和推广，然后IDDD（《实现领域驱动设计》）一书中，作者进行了比较深入的讨论。

（图片来自：slideshare.net ）

简而言之，在六边形架构风格中，应用程序的内部（中间的橙色六边形）包含业务规则，基于业务规则的计算，领域对象，领域事件等。这部分是企业应用的核心：比如在线商店里什么样的商品可以打折，对那种类型的用户进行80%的折扣；取消一个正在执行的流水线会需要发生什么动作，删除一个已经被别的Job依赖的Stage又应该如何处理。

而外部的，也是我们平时最熟悉的诸如REST，SOAP，NoSQL，SQL，Message Queue等，都通过一个端口接入，然后在内外之间有一个适配器组成的层，它负责将不同端口来的数据进行转换，翻译成领域内部可以识别的概念（领域对象，领域事件等）。

内部不关心数据从何而来，不关心数据如何存储，不关心输出时JSON还是XML，事实上它对调用者一无所知，它可以处理的数据已经是经过适配器转换过的领域对象了。

六边形架构的优点

业务领域的边界更加清晰
更好的可扩展性
对测试的友好支持
更容易实施DDD

要新添加一种数据库的支持，或者需要将RESTful的应用扩展为支持SOAP，我们只需要定义一组端口-适配器即可，对于业务逻辑部分无需触碰，而且对既有的端口-适配器也不会有影响。

由于业务之外的一切都属于外围，所以应用程序是真的跑在了Web容器中还是一个Java进程中其实是无所谓的，这时候自动化测试会容易很多，因为测试的重点：业务逻辑和复杂的计算都是简单对象，也无需容器，数据库之类的环境问题，单元级别的测试就可以覆盖大部分的业务场景。

这种架构模式甚至可能影响到团队的组成，对业务有深入理解的业务专家和技术专家一起来完成核心业务领域的建模及编码，而外围的则可以交给新人或者干脆外包出去。

在很多情况下，从开发者的角度进行的假设都会在事后被证明是错误的。人们在预测软件未来演进方向时往往会做很多错误的决定。比如对关系型数据库的选用，对前端框架的选用，对中间件的选用等等，六边形架构可以很好的帮助我们避免这一点。

小结

软件的核心复杂度在于业务本身，我们需要对业务本身非常熟悉才可能正确的为业务建模。通过统一的语言我们可以编写出表意而且易于和业务人员交流的模型。

另一方面模型应该尽可能的和基础设施（比如JSON/XML的，数据库存储，通信机制等）分离开。这样一来可以很容易用mock的方式来解耦模型和基础设施，从而更容易测试和修改，二来我们的领域模型也更独立，更精简，在适应新的需求时修改也会更容易。

这里有一段很微小的代码，有兴趣的同学可以看看。

更多精彩洞见，请关注微信公众号：思特沃克

一张漂亮的可视化图表背后

2017年5月18日2017年5月19日邱俊涛评论

可视化之根

多年前读过一篇非常震撼的文章，叫《Lisp之根》（英文版：The roots of Lisp），大意是Lisp仅仅通过一种数据结构（列表）和有限的几个函数，就构建出了一门极为简洁，且极具扩展性的编程语言。当时就深深的被这种设计哲学所震撼：一方面它足够简单，每个单独的函数都足够简单，另一方面它有非常复杂，像宏，高阶函数，递归等机制可以构建出任意复杂的程序，而复杂的机制又是由简单的组件组成的。

数据的可视化也是一样，组成一幅内容清晰、表达力强、美观的可视化信息图的也仅仅是一些基本的元素，这些元素的不同组合却可以产生出令人着迷的力量。

要列出“可视化元素之根”很容易：位置、长度、角度、形状、纹理、面积（体积）、色相、饱和度等几种有限的元素，邱南森在他的《数据之美》中提供了一张视觉元素的图，其中包含了大部分常用的元素。

令人振奋的是，这些元素可以自由组合，而且组合往往会产生1+1>2的效果。

心理学与认知系统

数据可视化其实是基于人类的视觉认知系统的，因此对人类视觉系统的工作方式有一些了解可以帮助我们设计出更为高效（更快的传递我们想要表达的信息给读者）的可视化作品。

心理物理学

在生活中，我们会遇到这样的场景：一件原价10元的商品，如果降价为5元，则消费者很容易购买；而一件原价100元的商品，降价为95元，则难以刺激消费者产生购买的冲动。这两个打折的绝对数字都是5元，但是效果是不一样的。

韦伯-费希纳定理描述的正是这种非理性的场景。这个定理的一个比较装逼的描述是：

感觉量与物理量的对数值成正比，也就是说，感觉量的增加落后于物理量的增加，物理量成几何级数增长，而心理量成算术级数增长，这个经验公式被称为费希纳定律或韦伯-费希纳定律。

– 摘自百度百科

这个现象由人类的大脑构造而固有，因此在设计可视化作品时也应该充分考虑，比如：

避免使用面积图作为对比
在做对比类图形时，当差异不明显时需要考虑采用非线性的视觉元素
选用多种颜色作为视觉编码时，差异应该足够大

比如：

如上图中，当面积增大之后，肉眼越来越难从形状的大小中解码出实际的数据差异，上边的三组矩形（每行的两个为一组），背后对应的数据如下，可以看到每组中的两个矩形的绝对差都是5:

var data = [
  {width: 5, height: 5},
  {width: 10, height: 10},

  {width: 50, height: 50},
  {width: 55, height: 55},

  {width: 100, height: 100},
  {width: 105, height: 105}
];

格式塔学派

格式塔学派是心理学中的一个重要流派，她强调整体认识，而不是结构主义的组成说。格式塔认为，人类在看到画面时，会优先将其简化为一个整体，然后再细化到每个部分；而不是先识别出各个部分，再拼接为整体。

比如那条著名的斑点狗：

我们的眼睛-大脑可以很容易的看出阴影中的斑点狗，而不是先识别出狗的四条腿或者尾巴（事实上在这张图中，人眼无法识别出各个独立的部分）。

格式塔理论有几个很重要的原理：

接近性原理
相似性原理
封闭性原理
连续性原理
主体/背景原理

当然，格式塔学派后续还有一些发展，总结出了更多的原理。工程上，这些原理还在大量使用，指导设计师设计各式各样的用户界面。鉴于网上已经有众多的格式塔理论及其应用的文章，这里就不在赘述。有兴趣的同学可以参考这几篇文章：

视觉设计的基本原则

《写给大家看的设计书》一书中，作者用通俗易懂的方式给出了几条设计的基本原则，这些原则完全可以直接用在数据可视化中的设计中：

亲密性（将有关联的信息物理上放在一起，而关联不大的则通过留白等手段分开）
对齐（将元素通过水平，垂直方向对齐，方便视觉识别）
重复（重复使用某一模式，比如标题1的字体颜色，标题2的字体颜色等，保持重复且一致）
对比（通过强烈的对比将不同的信息区分开）

如果稍加留意，就会发现现实世界中在大量的使用这几个原则。1，2，3三个标题的形式就是重复性的体现；每个标题的内容自成一体是因为组成它的元素（数字，两行文字）的距离比较近，根据亲密性原则，人眼会自动将其归为一类；超大的数字字体和较小的文字形成了对比；大标题的颜色和其他内容形成了对比等等。

这些原则其实跟上面提到的格式塔学派，以及韦伯-费希纳定理事实上是相关的，在理解了这些人类视觉识别的机制之后，使用这些原则就非常自然和得心应手了。

一些例子

淡化图表的网格（和数据图形产生对比）
通过深色来强调标尺（强烈的线条和其余部分产生对比）
离群点的高亮（通过不同颜色产生对比）
使用颜色（通过不同的颜色，利用亲密性原则方便读者对数据分组）
元素颜色和legend（使用重复性原则）
同一个页面上有多个图表，采取同样的图例，色彩选择（强调重复性原则）

实例

上篇文章提到我通过一个手机App收集到了女儿成长的一些记录，包括哺乳信息，换尿布记录，以及睡眠信息。这个例子中，我会一步步的介绍如何将这些信息可视化出来，并解释其中使用的视觉原理。

可视化的第一步是要明确你想要从数据中获取什么信息，我想要获取的信息是孩子的睡眠总量以及睡眠时间分布情况。

进阶版的条形图

确定了可视化的目的之后，第二步是选取合适的视觉编码。上面提到过，对于人眼来说，最精确的视觉编码方式是长度。我们可以将睡眠时间转化为长度来展现，最简单的方式是按天聚合，然后化成柱状图。比如：

2016/11/21,768
2016/11/22,760
2016/11/23,700

不过这种图无法看出时间的分布。我们可以考虑通过条形图的变体来满足前面提到的两个核心诉求。先来在纸上画一个简单的草图。纵轴是24小时，横轴是日期。和普通的条形图不一样的是，每个条形的总长度是固定的，而且条形代表的不是简单非数据类型，而是24小时。在草稿中，每个画斜线的方块表示孩子在睡眠状态，而虚线部分表示她醒着。

原始数据

name,date,length,note
心心,2016/11/21 19:23,119,
心心,2016/11/21 22:04,211,
心心,2016/11/22 02:03,19,
心心,2016/11/22 02:23,118,
心心,2016/11/22 05:58,242,
心心,2016/11/22 10:57,128,
心心,2016/11/22 14:35,127,
心心,2016/11/22 17:15,127,
心心,2016/11/22 20:02,177,
心心,2016/11/23 01:27,197,

这里有个问题，我们的纵轴是24小时，如果她晚上23点开始睡觉，睡了3个小时，那么这个条形就回超出24格的轴。我写了一个函数来做数据转换:

require 'csv'
require 'active_support/all'
require 'json'

csv = CSV.read('./visualization/data/sleeping_data_refined.csv', :headers => :first_row)

data = []
csv.each do |row|
    date = DateTime.parse(row['date'], "%Y/%m/%d %H:%M")

    mins_until_end_of_day = date.seconds_until_end_of_day / 60
    diff = mins_until_end_of_day - row['length'].to_i

    if (diff >= 0) then
        data << {
            :name => row['name'],
            :date => row['date'],
            :length => row['length'],
            :note => row['note']
        }
    else
        data << {
            :name => row['name'],
            :date => date.strftime("%Y/%m/%d %H:%M"),
            :length => mins_until_end_of_day,
            :note => row['note']
        }

        data << {
            :name => row['name'],
            :date => (date.beginning_of_day + 1.day).strftime("%Y/%m/%d %H:%M"),
            :length => diff.abs,
            :note => row['note']
        }
    end
end

有了干净的数据之后，我们可以编写一些前端的代码来绘制条形图了。画图的时候有几个要注意的点：

每天内的时间段对应的矩形需要有相同的X坐标
不同的睡眠长度要有颜色区分（睡眠时间越长，颜色越深）

var dateRange = _.uniq(data, function(d) {
  var date = d.date;
  return [date.getYear(), date.getMonth(), date.getDate()].join("/");
});

xScale.domain(dateRange.map(function(d) { return d.date; }));

function getFirstInDomain(date) {
  var domain = xScale.domain();

  var index = _.findIndex(domain, function(d) {
      return date.getYear() === d.getYear()
          && date.getMonth() === d.getMonth()
          && date.getDate() === d.getDate();
  });

  return domain[index];
}

函数getFirstInDomain可以根据一个日期值返回一个X坐标，这样2016/11/21 19:23和2016/11/21 22:04都会返回一个整数值（借助d3提供的标尺函数）。

另外，我们根据每次睡觉的分钟数将睡眠质量划分为5个等级：

var level = d3.scale.threshold()
  .domain([60, 120, 180, 240, 300])
  .range(["low", "fine", "medium", "good", "great", "prefect"]);

然后在绘制过程中，根据实际数据值来确定不同的CSS Class：

svg.selectAll(".bar")
  .data(data)
  .enter()
  .append("rect")
  .attr("class", function(d) {
      return level(d.length)+" bar";
  })
//...

实现之后，看起来是这个样子的。事实上这个图标可以比较清楚的看出大部分睡眠集中在0-6点，而中午的10-13点以及黄昏18-20点基本上只有一些零星的睡眠。

星空图

上面的图有一个缺点，是当日期很多的时候（上图差不多有100天的数据），X轴会比较难画，如果缩减成按周，或者按月，又会增加很多额外的复杂度。

另外一个尝试是变形：既然这个统计是和时间相关的，那么圆形的钟表形象是一个很好的隐喻，每天24小时自然的可以映射为一个圆。而睡眠时间可以通过弧长来表示，睡眠时间越长，弧长越大：

角度转弧度

我们首先将整个圆（360度）按照分钟划分，则每分钟对应的角度数为：360/(24*60)，再将角度转化为弧度：degree * π/180：

var perAngle = (360 / (24 * 60)) * (Math.PI/180);

那么对于指定的时间，比如10:20，先计算出其分钟数：10*60+20，再乘以preAngle，就可以得出起始弧度；起始时间的分钟数加上睡眠时长，再乘以preAngle，就是结束弧度。

function startAngle(date) {
    var start = (date.getHours() * 60 + date.getMinutes()) * perAngle;
    return Math.floor(start*1000)/1000;
}

function endAngle(date, length) {
    var end = (date.getHours() * 60 + date.getMinutes() + length) * perAngle;
    return Math.floor(end*1000)/1000;
}

实现的结果是这样的：

初看起来，它像是星空图，但是图中的不同颜色含义没有那么直观，我们需要在图上补充一个图例。通过使用d3的线性标尺和定义svg的渐变来实现，定义好渐变和渐变的颜色取值范围之后，就可以来绘制图例了。

图上的每段弧都会有鼠标移动上去的tooltip，这样可以很好的和读者大脑中的钟表隐喻对照起来，使得图表更容易理解。

由于我将整个圆分成了24份，这点和普通的钟表事实上有差异，那么如果加上钟表的刻度，会不会更好一些呢？从结果来看，这样的标线反而有点画蛇添足，所以我在最后的版本中去掉了钟表的标线。

可以看到，我们通过圆形的钟表隐喻来体现每一天的睡眠分布，然后用颜色的深浅来表示每次睡眠的时长。由于钟表的形象已经深入人心，因此读者很容易发现0点在圆环群的正上方。中心的黄色实心圆帮助读者视线先聚焦在最内侧的圆上，然后逐渐向外，这和日期的分布方向正好一致。

最终的结果在这里：心心的睡眠记录，完整的代码在这里。

更进一步

一个完整的可视化作品，不但要运用各种视觉编码来将数据转换为视觉元素，背景信息也同样重要。既然这个星空图是关于睡眠主题的，那么一个包含她在睡觉的图片集合则会加强这种视觉暗示，帮助读者快速理解。

制作背景图

我从相册中选取了很多女儿睡觉时拍的照片，现在需要有个工具将这些照片缩小成合适大小，然后拼接成一个大的图片。这其中有很多有趣的地方，比如图片有横屏、竖屏之分，有的还是正方形的，我需要让缩放的结果是正方形的，这样容易拼接一些。

好在有imagemagick这种神器，只需要一条命令就可以做到：

$ montage *.jpg -geometry +0+0 -resize 128x128^ \
-gravity center -crop 128x128+0+0 xinxin-sleeping.jpg

这条命令将当前目录下的所有的jpg文件缩放成128×128像素，并从中间开始裁剪-gravity center，+0+0表示图片之间的缝隙，最后将结果写入到xinxin-sleeping.jpg中。

拼接好图片之后，就可以通过CSS或者图片编辑器为其添加模糊效果，并设置深灰色半透明遮罩。

body {
  background-image:url('/xinxin-sleeping.png');
  background-size:cover;
  background-position:center;
}

当然，背景信息只是补充作用，需要避免喧宾夺主。因此图片做了模糊处理，且加上了深灰色的半透明Mask（此处应用了格式塔理论中的主体/背景原理）。

小结

这篇文章讨论了可视化作品背后的一些视觉元素理论，以及人类的视觉识别机制。在这些机制的基础上，介绍了如何运用常用的设计原则来进行视觉编码。最后，通过一个实例来介绍如何运用这些元素 – 以及更重要的，这些元素的组合 – 来制作一个漂亮的、有意义的可视化图表。

参考资料

这里有一些关于认知系统和设计原则的书籍，如果你感兴趣的话，可以用来参考

更多精彩洞见，请关注微信公众号：思特沃克

为什么优秀的程序员喜欢命令行？

2017年3月24日2017年3月27日邱俊涛评论

优秀的程序员

要给优秀的程序员下一个明确的定义无疑是一件非常困难的事情。擅长抽象思维、动手能力强、追求效率、喜欢自动化、愿意持续学习、对代码质量有很高的追求等等，这些维度都有其合理性，不过又都略显抽象和主观。

（图片来自：http://t.cn/R6I1yhJ）

我对于一个程序员是否优秀，也有自己的标准，那就是TA对命令行的熟悉／喜爱程度。这个特点可以很好的看出TA是否是一个优秀的（或者潜在优秀的）程序员。我周围就有很多非常牛的程序员，无一例外都非常擅长在命令行中工作。那什么叫熟悉命令行呢？简单来说，就是90%的日常工作内容可以在命令行完成。

当然，喜欢／习惯使用命令行可能只是表象，其背后包含的实质才是优秀的程序员之所以优秀的原因。

自动化

Perl语言的发明者Larry Wall有一句名言：

The three chief virtues of a programmer are: Laziness, Impatience and Hubris. – Larry Wall

懒惰（Laziness）这个特点位于程序员的三大美德之首：唯有懒惰才会驱动程序员尽可能的将日常工作自动化起来，解放自己的双手，节省自己的时间。相比较而言，不得不说，GUI应用天然就是为了让自动化变得困难的一种设计（此处并非贬义，GUI有着自己完全不同的目标群体）。

（图片来自：http://t.cn/R6IBgYV）

GUI更强调的是与人类的直接交互：通过视觉手段将信息以多层次的方式呈现，使用视觉元素进行指引，最后系统在后台进行实际的处理，并将最终结果以视觉手段展现出来。

这种更强调交互过程的设计初衷使得自动化变得非常困难。另一方面，由于GUI是为交互而设计的，它的响应就不能太快，至少要留给操作者反应时间（甚至有些用户操作需要人为的加入一些延迟，以提升用户体验）。

程序员的日常工作

程序员除了写代码之外，还有很多事情要做，比如自动化测试、基础设施的配置和管理、持续集成/持续发布环境，甚至有些团队还需要做一些与运维相关的事情（线上问题监控，环境监控等）。

开发/测试
基础设施管理
持续集成/持续发布
运维（监控）工作
娱乐

而这一系列的工作背后，都隐含了一个自动化的需求。在做上述工作时，优秀的程序员会努力将其自动化，如果有工具就使用工具；如果没有，就开发一个新的工具。这种努力让一切都尽可能自动化起来的哲学起源于UNIX世界。

而UNIX哲学的实际体现则是通过命令行来完成的。

Where there is a shell, there is a way.

UNIX编程哲学

关于UNIX哲学，其实坊间有多个版本，这里有一个比较详细的清单。虽然有不同的版本，但是有很多一致的地方：

小即是美
让程序只做好一件事
尽可能早地创建原型(然后逐步演进)
数据应该保存为文本文件
避免使用可定制性低下的用户界面

审视这些条目，我们会发现它们事实上促成了自动化一切的可能性。这里列举一些小的例子，我们来看看命令行工具是如何通过应用这些哲学来简化工作、提高效率的。一旦你熟练掌握这些技能，就再也无法离开它，也再也忍受不了低效而复杂的各种GUI工具了。

命令行如何提升效率

一个高阶计算器

在我的编程生涯早期，读过的最为振奋的一本书是《UNIX编程环境》，和其他基本UNIX世界的大部头比起来，这本书其实还是比较小众的。我读大二的时候这本书已经出版了差不多22年(中文版也已经有7年了)，有一些内容已经过时了，比如没有返回值的main函数、外置的参数列表等等，不过在学习到HOC(High Order Calculator)的全部开发过程时，我依然被深深的震撼到了。

简而言之，这个HOC语言的开发过程需要这样几个组件：

词法分析器lex
语法分析器yacc
标准数学库stdlib

另外还有一些自定义的函数等，最后通过make连接在一起。我跟着书上的讲解，对着书把所有代码都敲了一遍。所有的操作都是在一台很老的IBM的ThinkPad T20上完成的，而且全部都在命令行中进行（当然，还在命令行里听着歌）。

这也是我第一次彻底被UNIX的哲学所折服的体验：

每个工具只做且做好一件事
工具可以协作起来
一切面向文本

下面是书中的Makefile脚本，通过简单的配置，就将一些各司其职的小工具协作起来，完成一个编程语言程序的预编译、编译、链接、二进制生成的动作。

YFLAGS = -d
OBJS = hoc.o code.o init.o math.o symbol.o

hoc5:    $(OBJS)
    cc $(OBJS) -lm -o hoc5

hoc.o code.o init.o symbol.o: hoc.h

code.o init.o symbol.o: x.tab.h

x.tab.h: y.tab.h
    -cmp -s x.tab.h y.tab.h || cp y.tab.h x.tab.h

pr:    hoc.y hoc.h code.c init.c math.c symbol.c
    @pr $?
    @touch pr

clean:
    rm -f $(OBJS) [xy].tab.[ch]

虽然现在来看，这本书的很多内容已经过期（特别是离它第一次出版已经过去了近30年），有兴趣的朋友可以读一读。这里有一个Lex/Yacc的小例子的小例子，有兴趣的朋友可以看看。

当然，如果你使用现在最先进的IDE（典型的GUI工具），其背后做的事情也是同样的原理：生成一个Makefile，然后在幕后调用它。

基础设施自动化

开发过程中，工程师还需要关注的一个问题是：软件运行的环境。我在学生时代刚开始学习Linux的时候，会在Windows机器上装一个虚拟机软件VMWare，然后在VMWare中安装一个Redhat Linux 9。

（图片来自：http://t.cn/R6IBSAu）

这样当我不小心把Linux玩坏了之后，只需要重装一下就行了，不影响我的其他数据（比如课程作业、文档之类）。不过每次重装也挺麻烦，需要找到iso镜像文件，再挂载到本地的虚拟光驱上，然后再用VMWare来安装。

而且这些动作都是在GUI里完成的，每次都要做很多重复的事情：找镜像文件，使用虚拟光驱软件挂载，启动VMWare，安装Linux，配置个人偏好，配置用户名/密码等等。熟练之后，我可以在30 － 60分钟内安装和配置好一个新的环境。

Vagrant

后来我就发现了Vagrant，它支持开发者通过配置的方式将机器描述出来，然后通过命令行的方式来安装并启动，比如下面这个配置：

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "precise64"
  config.vm.network "private_network", :ip => "192.168.2.100"
end

它定义了一个虚拟机，使用Ubuntu Precise 64的镜像，然后为其配置一个网络地址192.168.2.100，定义好之后，我只需要执行：

$ vagrant up

我的机器就可以在几分钟内装好，因为这个动作是命令行里完成的，我可以在持续集成环境里做同样的事情 – 只需要一条命令。定义好的这个文件可以在团队内共享，可以放入版本管理，团队里的任何一个成员都可以在几分钟内得到一个和我一样的环境。

Ansible

一般，对于一个软件项目而言，一个全新的操作系统基本上没有任何用处。为了让应用跑起来，我们还需要很多东西。比如Web服务器、Java环境、cgi路径等，除了安装一些软件之外，还有大量的配置工作要做，比如apache httpd服务器的文档根路径，JAVA_HOME环境变量等等。

（图片来自：http://t.cn/R6IBZKm）

这些工作做好了，一个环境才算就绪。我记得在上一个项目上，不小心把测试环境的Tomcat目录给删除了，结果害的另外一位同事花了三四个小时才把环境恢复回来（包括重新安装Tomcat，配置一些JAVA_OPTS，应用的部署等）。

不过好在我们有很多工具可以帮助开发者完成环境的自动化准备，比如：Chef、 Puppet、Ansible。只需要一些简单的配置，然后结合一个命令行应用，整个过程就可以自动化起来了：

- name: setup custom repo
  apt: pkg=python-pycurl state=present

- name: enable carbon
  copy: dest=/etc/default/graphite-carbon content='CARBON_CACHE_ENABLED=true'

- name: install graphite and deps
  apt: name={{ item }} state=present
  with_items: packages

- name: install graphite and deps
  pip: name={{ item }} state=present
  with_items: python_packages

- name: setup apache
  copy: src=apache2-graphite.conf dest=/etc/apache2/sites-available/default
  notify: restart apache

- name: configure wsgi
  file: path=/etc/apache2/wsgi state=directory

上边的配置描述了安装graphite-carbon、配置apahce等很多手工的劳动，开发者现在只需要执行：

$ ansible

就可以将整个过程自动化起来。现在如果我不小心把Tomcat删了，只需要几分钟就可以重新配置一个全新的，当然整个过程还是自动的。这在GUI下完全无法想象，特别是在有如此多的定制内容的场景下。

持续集成/持续发布

日常开发任务中，除了实际的编码和环境配置之外，另一大部分内容就是持续集成/持续发布了。借助于命令行，这个动作也可以非常高效和自动化。

Jenkins

持续集成/持续发布已经是很多企业IT的基本配置了。各个团队通过持续集成环境来编译代码、静态检查、执行单元测试、端到端测试、生成报告、打包、部署到测试环境等等。

比如在Jenkins环境中，在最前的版本中，要配置一个构建任务需要很多的GUI操作，不过在新版本中，大部分操作都已经可以写成脚本。

这样的方式，使得自动化变成了可能，要复制一个已有的pipline，或者要修改一些配置、命令、变量等等，再也不需要用鼠标点来点去了。而且这些代码可以纳入项目代码库中，和其他代码一起被管理、维护，变更历史也更容易追踪和回滚（在GUI上，特别是基于Web的，回滚操作基本上属于不可能）。

node {
   def mvnHome

   stage('Preparation') { // for display purposes
      git 'https://github.com/jglick/simple-maven-project-with-tests.git'
      mvnHome = tool 'M3'
   }

   stage('Build') {
      sh "'${mvnHome}/bin/mvn' -Dmaven.test.failure.ignore clean package"
   }

   stage('Results') {
      junit '*/target/surefire-reports/TEST-.xml'
      archive 'target/*.jar'
   }
}

上面这段groovy脚本定义了三个阶段，每个阶段中分别有自己的命令，这种以代码来控制的方式显然比GUI编辑的方式更加高效，自动化也变成了可能。

运维工作

自动化监控

Graphite是一个功能强大的监控工具，不过其背后的理念倒是很简单：

存储基于时间线的数据
将数据渲染成图，并定期刷新

用户只需要将数据按照一定格式定期发送给Graphite，剩下的事情就交给Graphite了，比如它可以消费这样的数据：

instance.prod.cpu.load 40 1484638635
instance.prod.cpu.load 35 1484638754
instance.prod.cpu.load 23 1484638812

第一个字段表示数据的名称，比如此处instance.prod.cpu.load表示prod实例的CPU负载，第二个字段表示数据的值，最后一个字段表示时间戳。

这样，Graphite就会将所有同一名称下的值按照时间顺序画成图。

（图片来自：http://t.cn/R6IxKYL）

默认地，Graphite会监听一个网络端口，用户通过网络将信息发送给这个端口，然后Graphite会将信息持久化起来，然后定期刷新。简而言之，只需要一条命令就可以做到发送数据：

echo "instance.prod.cpu.load 23 </span>date +%s<span class="pl-pds">" | nc -q0 graphite.server 2003

date +%s会生成当前时间戳，然后通过echo命令将其拼成一个完整的字符串，比如：

instance.prod.cpu.load 23 1484638812

然后通过管道|将这个字符串通过网络发送给graphite.server这台机器的2003端口。这样数据就被记录在graphite.server上了。

定时任务

如果我们要自动的将数据每隔几秒就发送给graphite.server，只需要改造一下这行命令：

获取当前CPU的load
获取当前时间戳
拼成一个字符串
发送给graphite.server的2003端口
每隔5分钟做重复一下1-4

获取CPU的load在大多数系统中都很容易：

ps -A -o %cpu

这里的参数:

-A表示统计所有当前进程
-o %cpu表示仅显示%cpu列的数值

这样可以得到每个进程占用CPU负载的数字：

%CPU
  12.0
  8.2
  1.2
  ...

下一步是将这些数字加起来。通过awk命令，可以很容易做到这一点：

$ awk '{s+=$1} END {print s}'

比如要计算1 2 3的和：

$ echo "1\n2\n3" | awk '{s+=$1} END {print s}'
6

通过管道可以讲两者连起来：

$ ps -A -o %cpu | awk '{s+=$1} END {print s}'

我们测试一下效果：

$ ps -A -o %cpu | awk '{s+=$1} END {print s}'
28.6

看来还不错，有个这个脚本，通过crontab来定期调用即可：

#!/bin/bash
SERVER=graphite.server
PORT=2003
LOAD=</span>ps -A -o %cpu <span class="pl-k">|</span> awk <span class="pl-s"><span class="pl-pds">'</span>{s+=$1} END {print s}<span class="pl-pds">'</span></span><span class="pl-pds">

echo "instance.prod.cpu.load ${LOAD} </span>date +%s<span class="pl-pds">" | nc -q0 ${SERVER} ${PORT}

当然，如果使用Grafana等强调UI的工具，可以很容易的做的更加酷炫：

（图片来自：http://t.cn/R6IxsFu）

想想用GUI应用如何做到这些工作。

娱乐

命令行的MP3播放器

最早的时候，有一个叫做mpg123的命令行工具，用来播放MP3文件。不过这个工具是商用的，于是就有人写了一个工具，叫mpg321，基本上是mpg123的开源克隆。不过后来mpg123自己也开源了，这是后话不提。

将我的所有mp3文件的路径保存成一个文件，相当于我的歌单：

$ ls /Users/jtqiu/Music/*.mp3 > favorites.list
$ cat favorites.list
...
/Users/jtqiu/Music/Rolling In The Deep-Adele.mp3
/Users/jtqiu/Music/Wavin' Flag-K'Naan.mp3
/Users/jtqiu/Music/蓝莲花-许巍.mp3
...

然后我将这个歌单交给mpg321去在后台播放：

$ mpg321 -q --list favorites.list &
[1] 10268

这样我就可以一边写代码一边听音乐，如果听烦了，只需要将这个后台任务切换到前台fg，然后就可以关掉了：

$ fg
[1]  + 10268 running    mpg321 -q --list favorites.list

小结

综上，优秀的程序员借助命令行的特性，可以成倍（有时候是跨越数量级的）提高工作效率，从而有更多的时间进行思考、学习新的技能，或者开发新的工具帮助某项工作的自动化。这也是优秀的程序员之所以优秀的原因。而面向手工的、原始的图形界面会拖慢这个过程，很多原本可以自动化起来的工作被淹没在“简单的GUI”之中。

（图片来自：http://cargocollective.com/）

最后补充一点，本文的关键在于强调优秀的程序员与命令行的关系，而不在GUI程序和命令行的优劣对比。GUI程序当然有其使用场景，比如做3D建模、GIS系统、设计师的创作、图文并茂的字处理软件、电影播放器、网页浏览器等等。

应该说，命令行和优秀的程序员之间更多是关联关系，而不是因果关系。在程序员日常的工作中，涉及到的更多的是一些需要命令行工具来做支持的场景。如果走极端，在不适合的场景中强行使用命令行，而置效率于不顾，则未免有点矫枉过正，南辕北辙了。

更多精彩洞见，请关注微信公众号：思特沃克

PM是大傻叉吗？

2016年12月29日2016年12月29日邱俊涛评论

一些背景故事

坊间流传着很多关于PM（Project Manager，项目经理）的笑话，在这些不无刻薄的笑话中，PM往往被描述成一个盲目应承客户，不了解实际情况而又喜欢指手画脚、专门坑开发的家伙。毋庸置疑，这些笑话当然出自那些“聪明的”开发（不过你得承认，这些笑话并非空穴来风）。

在智力工作中，对于开发的实际进度、开发速率等问题，具体着手做的人永远比在背后指手画脚的人更有发言权。软件开发正是一项智力活动，优秀的软件无法通过人力的堆积而产生。一个关于PM的经典的讽刺是：PM就是那些指望着9个女人在1个月内生出1个小孩的二货。乍看上去，这个笑话还真是一针见血。

我记得在刚加入ThoughtWorks的时候，私底下经常听到这种论调：PM基本就是项目上被人鄙视的角色，基本上负责团队建设去哪儿这种杂事儿就行了，团队的其他人员可以高度自治，并不需要被管理，项目就会如预期般按时交付。

这些论调在某些情况下可能是对的。但是如果放在国内项目的这个上下文里，倘若没有一个专业的PM来协助项目、控制需求、划定项目范围、与客户谈判等等，没有任何一个项目是可以真正成功交付的，指望高度自治的开发们来完成项目？咱们还是现实一些吧。

一个悲剧的事实是，开发人员往往都恃才傲物，有时还会带着一幅要拯救世界的心态做项目，这事实上和客户以及PM的期望是有很大出入的。在项目启动之初，PM会面临重重困难：首先，团队里的每个人都不好管，而且每个人都认为自己不需要被管理（当然这种想法在大多都是错误的）；其次，PM需要和客户快速建立信任，并推动项目进入正轨；最后，他们也需要了解大量与项目相关的上下文（业务上下文，人员关系，资源协调等），最后留给自己的时间也非常有限。

除了催进度，PM平时还干点啥？

本质上来说，PM其实就是一个轮询器：识别所有的项目风险，然后不断跟进。项目风险可能是技术风险，比如某个技术上压根搞不定的问题。也可能资源风险，比如人手不够，或者开发者很多，但是没有足够的设计师协助，这些风险都会导致项目无法按时交付。一个客观事实是，所有项目都会变化，从售前到需求分析结束，项目的需求都在持续变化，如果不对报价做相应的调整，极有可能会亏本。

PM的一个重要职责就是在项目之初将项目范围定下来，这个范围的划分非常依赖经验：划得少了团队得天天加班，累得跟狗一样才能保证交付（据我的经验，虽然项目一般不会天天加班，但是总会有一些攻关、打补丁的事儿，最后还是会累成狗），划得多了客户不买单，意思是就这个小功能你要做两个月，绝对不行。PM需要协调这些不一致，还需要和销售、客户等方面不断谈判、写方案、排计划，简而言之，也是累的跟狗一样。在此过程中，还可能被那些天真幼稚的开发坑 — 开发经常会高估自己的开发速度，反正我还没遇到过低估的，你见过吗？

我们每天看到的PM干的最多的事情就是：元芳，那个接口怎么样了？什么时候能做完，有什么blocker？李柯，昨天说的代理的事情怎么样了？小波，高保真什么时候出？何方，我们周三下午要showcase，麻烦你订一下会议室吧……

除了写代码，Dev平时还干点啥？

如果脱离PM的角度，做为一个孤傲的开发，时常会觉得“PM为什么老是问我进度？是不是怀疑我的能力？为什么监视我的工作？”相信我，其实他才不想监视你。但是你设想一下：如果你不参与代码编写，每天只是看旁边的哥们写，你如何知道他实际的进度呢？而且众所周知，开发很难准确更新自己的工作进度，而且遇到问题也很少积极主动的报告，通常都会自己埋头尝试解决。那么，轮询显然是一种成本最低，反馈最快的方法。

不主动更新进度是一个大问题，这个得单独说。关于更新进度，典型的场景是：早上站会的时候，开发目光呆滞的盯着某个卡片，努力回忆其中的验收条件以及自己当前的进度，如果恰好脑海中的技术细节和卡片描述在某个点上匹配了，他会迅速的告诉你，目前进展良好，今天上午应该就可以做完。开发在更新进度时，要么盲目乐观，要么就跳进太细节的地方进行讨论，最后的结果就是：跟没更新一样，白白浪费了10分钟。但是别忘了，PM会在15分钟之后再来轮询一次。

PM每周都需要汇总很多数字，比如本迭代完成的点数、剩余的点数、总体进度如何、有没有人准备请假、遇到什么blocker、每个blocker的具体原因、每个风险点的最终日期是何时等等等等。他肯定不能记住这些数字，所以可能一天之内向你询问数次。

PM的其他职责/技能

上边说到的其实只是描述PM的辛苦，而最微妙，最考验PM的是其“察言观色”的技能。这绝对是一个工作经验在10年之内完全无法获得的技能（而且是在国内项目上工作10年）。比如，在showcase的时候，有个客户说，“嗯，挺好，整个流程就是这样的，后续你们的UI是不是还会美化？”如果你遇到这个情况，请问，这个客户是什么意思？

如果你能回答上这个问题（而不是提出问题），那说明你还离PM差十万八千里。成熟的PM会先判断，提出这个问题的人是什么角色，以及他在系统中的话语权如何，还有其他人就此问题的反应如何等，然后找到一个合适的答案。

PM另一个绝技是扯皮（不是贬义），开发会花一个下午（我是说10分钟）去跟客户讨论需求的范围吗？或者会为5个人天来讨价还价吗？我想开发大概会说，“尼玛，找其他供应商吧，老子不伺候了。”

一个项目的成功，需要多方合作，这里说的合作并不局限在甲方和乙方之间，即使在乙方的团队之中，也需要很紧密的合作。比如项目经理和开发、设计师之间的合作。如果仅仅从开发的角度来看，PM有时候看起来就像和客户站在一起来整开发的一样，比如催进度，过分保守的估算人天（导致团队加班赶工）。PM需要释放团队中的负面情绪，保证团队士气，还需要做一些开发不屑于做的琐碎事情。

设身处地，替他人着想

从本质来说，每个项目都是一次生意。在去掉那些繁杂的流程和形式之后，做一个项目和你去菜市场买菜其实并无二致。根据传统，软件开发界特别喜欢找建筑行业做类比，我也找个建筑方面例子。装修房子的时候，我们会要求施工方提供图纸（水电改造，基本设计等），按期交付（确定工期），同时会界定项目范围（比如刷墙，贴地砖，吊顶，封阳台等等），会要求工人按时来上班，正常出勤，认真工作，直到项目结束。过程中我们还会讨价还价，比如捎带着把栏杆拆除，捎带着敲掉一面隔离墙等等。在过程中，我们还会敲敲地砖，检查过门石，检查吊顶，测试水电等等。作为甲方，这些活动相信没有人会觉得过分。

但是一旦我们做乙方，也就是施工方的时候，情况就全变了。比如客户要求打卡，有人会觉得不爽，客户要求代码review，有人会觉得不爽，要求代码有设计文档，有人会觉得不爽，要求设计有多个备选方案，有人会觉得不爽。大多数情况下，这都是虚无缥缈的虚荣在作祟，这种情况在所难免，不过还不致命。一旦涉及到讨价还价（不是商务上的讨价还价，而是和客户就工作量达不成一致，或者就某个技术方案达不成一致之后），开发全部歇菜，一言不合，转身就走，压根不具备讨价换件的能力，这样还怎么做生意啊？设身处地想一下，如果你是甲方，当提出了一些合理的要求（比如需要一方提供验收标准，通过验收测试等），结果施工方还一脸的“我不跟你说了，你就是以大傻B”，你能乐意吗？

如何合作？

说了这么多，这两种角色在同一个项目上要如何合作呢？我想，作为开发来说，有这样几点可能：

首先，理解PM的工作。在很多时候，开发会有莫名其妙的优越感（其实每个角色都会有，比如销售看不上技术人员，技术Lead看不上PM等等），主要原因是坐井观天，对其他角色的辛苦和工作内容不清楚，错误的认为别人的工作都很low。

之前听一个同事讲过一个小session，里面有一点我印象非常深刻：不要因为一个人不会某个技术而鄙视他。就好比你不应该因为不会弹钢琴，而被一个会弹钢琴的人鄙视一样。道理很简单，但是开发在长期的“宅”生涯或者坐井观天中，进化出了这种非理性的观点：如果一个人连vim（此处的vim可以换成任何其他技术）都不会，就压根不足以谈人生。

其次，学习如何报告进度。PM催你的根本原因是进度不明确，如果每一个潜在的风险都清楚的显示着进度，而且有明确的负责人，PM就会降低轮询的频率。这需要开发经过刻苦的练习才能达到：

站会前自己花3分钟整理一下昨天做的工作
根据story的验收条件（最好有和BA/QA一起的讨论需求），进行合理的任务划分（tasking技能）
可以借助便签纸等工具，帮助自己明确进度（划分了5个子任务，昨天完成了3个，那么可以粗略的估计为60%）

再次，合理估算。有些时候，新人（来自于传统管理环境的新人）可能会误以为PM是一个管理的角色，或者处于某些考虑会在PM询问进度时做出一些错误的回答。比如PM在迭代启动会议上是问“这个迭代我们有没有可能做完所有计划内的任务？”作为一个负责任的开发，你需要在第一时间指出那些“非理性”的期望，以便PM进行更加准确的计划。

明确告诉PM，有哪些需求是不可能按时交付的，PM会根据实际情况来重新定计划，并和客户确认
明确告诉PM一些可能的风险，团队整体对交付负责，而不是PM，或者开发

按照经验，项目从来就不会按照计划进行，在做好一个粗略的计划之后，PM的职责更多的是进行动态调整。所以团队内部至少需要保持信息的流通，虽然可能短期来看可能会影响开发速度，但是从整体上来看，可以减少很多不必要的浪费。

简而言之，要站在别人的角度考虑问题：如果换做是你，你会怎么做？