两周前因为公司一次裁人，好几个人的活都被按在了我头上，这其中的一大部分是一系列REST API，撰写者号称基本完成，我测试了一下，发现尽管从功能的角度来说，这些API实现了spec的显式要求，但是从实际使用的角度，欠缺的东西太多（各种各样的隐式需求）。REST API是一个系统的backend和frontend（或者3rd party）打交道的通道，承前启后，有很多很多隐式需求，比如调用接口与RFC保持一致，API的内在和外在的安全性等等，并非提供几个endpoint，返回相应的json数据那么简单。仔细研究了原作者的代码，发现缺失的东西实在太多，每个API基本都在各自为战，与其修补，不如重写（并非是程序员相轻的缘故），于是我花了一整周，重写了所有的API。稍稍总结了些经验，在这篇文章里讲讲如何撰写「合格的」REST API。RFC一致性REST API一般用来将某种资源和允许的对资源的操作暴露给外界，使调用者能够以正确的方式操作资源。这里，在输入输出的处理上，要符合HTTP/1.1（不久的将来，要符合HTTP/2.0）的RFC，保证接口的一致性。这里主要讲输入的method/headers和输出的status code。MethodsHTTP协议提供了很多methods来操作数据：GET: 获取某个资源，GET操作应该是幂等（idempotence）的，且无副作用。POST: 创 ...继续阅读 (27)

英文原文：Inside NGINX: How We Designed for Performance & Scale为了更好地理解设计，你需要了解NGINX是如何工作的。NGINX之所以能在性能上如此优越，是由于其背后的设计。许多web服务器和应用服务器使用简单的线程的（threaded）、或基于流程的（process-based）架构， NGINX则以一种复杂的事件驱动（event-driven）的架构脱颖而出，这种架构能支持现代硬件上成千上万的并发连接。Inside NGINX infographic涉及了从高层次进程架构的挖掘，到NGINX的单进程处理多连接的图解。本篇文章讲解了这些工作细节。设置场景——NGINX进程模型为了更好地理解设计，你需要了解NGINX是如何工作的。NGINX有一个主进程（master process）（执行特权操作，如读取配置、绑定端口）和一系列工作进程（worker process）和辅助进程（helper process）。这个四核服务器内，NGINX主进程创建了4个工作进程和2个缓存辅助进程（cachehelper processes）来管理磁盘内容缓存（on-disk content cache）。为什么架构很重要?任何Unix应用程序的根本基础都是线程或进程（从Linux操作系统的角度看，线程和进程基本上是相同的， ...继续阅读 (15)

英文原文：Coding Culture: How To Build Better Products by Building Stronger Teams译/丛一软件开发人员通常会付出大量的时间和精力在如何构建最好的产品上。我们常会纠结应该使用哪种Web框架，是用NoSQL数据库还是SQL数据库？不过，尽管这些问题十分重要，开发人员通常会忽视掉软件开发过程中与这些问题同样重要的一个方面——文化。本文将与读者分享在Atlanssian公司中如何保持健壮的创新和协作文化氛围的经验。产品时刻都在发展变化。在之后的几年中，一个你倾注过血汗和眼泪的产品可能会不复存在。不过，如果你能同时专注于创造健壮的团队和编码文化，你就能够时刻准备着，抓住出现的机遇（克服障碍）。而且，发展强健的文化需要对团队所代表的立场达成共识，而这种凝聚力也会正向地反映到团队所构建的产品上。伟大的文化促成伟大的产品。那么什么是“伟大的文化”？人们通常会将文化可见的外部标志——免费食物、免费饮品、瑜伽课程、Aeron电脑椅、电视游戏、Nerf 玩具枪——错误地等同于文化。的确，许多公司，特别是科技企业都会提供这些很棒的福利，但是这与文化没有半点关系。文化是我们如何交流、工作、组织、荣辱与共。文化无法准确描述，但是它能够让员工更加快 ...继续阅读 (83)

2011年3月份还在华为夜以继日的时候，买过一本《领域驱动设计：软件核心复杂性应对之道》，虽然努力的看过一次，没看懂，觉得都距离我很遥远。2014年4月，在ThoughtWorks还不到一年，买了一本腾老板的《实现领域驱动设计》，看了一遍，似乎理解了一些，但还是有些摸不着头脑。做IT的一方面白天要鼓足干劲干好那8小时，回家每天抽时间陪小孩玩耍一两个小时，另一方面又要在9点半之后尽快的吸取最新的营养，实乃不容易。回想起老婆回娘家的那段时间以及自己出差的一个月，真是非常难得，可以抓紧时间读书、试验新的技术。ThougtWorks的读书文化我很欣赏，别个同事每年读个50本书，我却用Training Budget买了很多书回来，就放在那里了。这并不是说我费钱，主要是中国的出版业很奇葩，你不买可能过段时间就成绝版了，想买也买不到了。我每过一段时间就要清理了一下，感叹一下书非借不能读也，真想静下心来重新读书。读书，别开电脑，离开你的手机，摒弃一切的，拿上一支记号笔，开始吧。重新读《领域驱动设计：软件核心复杂性应对之道》正是由于做到了项目的后期，觉得整个项目已经开始凌乱。大家对业务知识不了解，也没问，只求赶紧将东西搞出来；对技术只见树木不见森林，虽然有很精巧的重构，但无法反映出真实的业务场景；有多个的Micro Service但有些职责显得混乱不堪。团队在一个混沌的情况下越来越晕，我真是想找个时 ...继续阅读 (15)

英文原文：Your Developers Aren’t Bricklayers, They’re Writers如果你有 10 个程序员，最好的那个可能至少比最差的那个好 5 倍。这绝对不是胡扯。我们这样定义“更好”：工作速度更快，产生的 bug 更少，代码更具可读性、逻辑性和可维护性。程序员不是砌砖工人，但他们往往被当成是砌砖工人。 （我并不是说歧视这些职业）“为什么我需要高级程序员，要知道同样的薪酬我可以雇两个初级的了？”“这个功能一个程序员做需要三个月的时间，那就只需要再加两个，就可以在一个月内搞定了。”为什么说上面的想法很荒谬？因为我们没有一种简单又有效的方法来衡量程序员的生产力。一旦碰到我们无法衡量的东西，我们就会忽略它。我这样问你好了：你是愿意让两个新手来照顾你的宝宝，维修你的车，给你做腰椎穿刺，还是宁愿找一个资深的？相关研究表明，最好程序员的生产力最高可比最差程序员的高 28 倍。但是用在这些最好程序员身上的成本肯定不会有这么多，所以他们是软件领域中最划算的“特价商品”。ROBERT GLASS，《FACTS AND FALLACIES OF SOFTWARE ENGINEERING》如果你一定要比较的话，那么其实程序员更像是作家。有些作家写出的东西 ...继续阅读 (9)

英文原文：Technical Debt: A Repayment Plan什么是技术债务？许多团队都受技术债务困扰，不过，很少有团队能真正地设计一个计划从中挣脱出来。为了更好的理解如何才能摆脱债务，我们首先要正确地理解什么是技术债务。技术债务是由团队为了短期的项目利益故意做了欠佳的技术决策而招致的。例如，为了使一个产品更快的投放市场，团队可能不会像面对一段棘手的代码那样，编写深入的自动化测试。或者，他们可能会决定基于一个很快就会过时的框架构建项目，而不是花钱购买那个框架的一个经过升级、服务支持更好的版本。不管决策是什么，关键是要认识到，真正的技术债务是团队为了获得短期利益故意做了会招致长远债务的决策。这意味着，许多我们通常归咎于“技术债务”的事情实际上根本就不是债务。例如，随着系统使用年限增加，团队会无法一直保持最佳编码实践，在那种情况下出现“位衰减（bit dot）”是正常的，不是债务。或者，团队自愿做出的技术决策在随后实现时竟然发现是不正确的，这也不是技术债务。在任何一种情况下，团队都不是为了获得短期利益而故意做了欠佳的长远决策。这种差别很重要，因为我们只有在究竟是什么组成了技术债务的问题上达成一致，我们才能针对如何减少技术债务做出最佳决策。考虑我们在无意间引入代码库的债务所带来的影响也很重要。不过，由于这类债务不是有意承担的，所 ...继续阅读 (21)

程序源代码中的注释经常是一个卧虎藏龙的地方，有人就很喜欢写幽默搞笑的注释内容。解释代码含义的同时，也带给人轻松神经的机会，确实是很有意思的风格，来看看这一辑国外某公司产品中的注释。注意：看的时候严禁喝水或进食。1、亲爱的代码维护人员当您尝试优化这段代码但发现这是一个极端错误的决定的时候，请修改下面的计时器，以便警示后人。总计浪费在这段代码的时间 = 16 小时2、真的很有问题3、谨以此代码献给我的妻子达琳，感谢她一直支持我，还有我三个孩子和一只狗。4、神奇代码，请勿改动5、喝醉啦，迟些再弄6、你可能会认为你读得懂以下的代码。但是你不会懂的，相信我吧。要是你尝试玩弄这段代码的话，你将会在无尽的通宵中不断地咒骂自己为什么会认为自己聪明到可以优化这段代码。好了，现在请关闭这个文件去玩点别的吧。7、程序员1(于 2002 年 6 月 7 日)：在登陆界面临时加入一些调试代码程序员2(于 2007 年 5 月 22 日)：临你个屁啊8、反正这个办法就修复了问题，我也不知道为什么会这样9、要理解什么是递归的话，请参考本文件的底部(在文件的底部)要理解什么是递归的话，请参考本文件的顶部10、狂插两下; //痛啊11、亲爱的未来的我自己，请原谅我。我有着难以表达的歉意。12、我不对以下代码负责。是他们逼我写的，是违背我意愿的。13、疯了吗?欢迎来到斯巴达。14、要是你能修正这个问题的话，我会送给你 ...继续阅读 (19)

英文原文：Give your code some space!最近在几个不同的团队中发现他们的编码规范中对空格的用法大不相同。这激起了我的好奇心，因为我一直觉得，对于代码格式中的空格的使用，应该有一个大家都公认的最好的习惯。但是在现实开发中，似乎没有出现这样的统一。现状首先，我们看看在大多数Java IDE中Java代码的风格习惯。下面是一个例子：publicclassExample {publicstaticvoidmain(String[] args) {intanswer = 2 + 4 * 6;for(inti = 0; i < 5; i++) {doSomething();}System.out.println("The answer is " +answer);}privatestaticvoiddoSomething() {//something}}请注意，这是Java开发者中和其它类似C语言的语言中最常见的一种风格。在括号内部两边没有留空格。只有当括号前面有关键字for或while等时，空格才会出现在它们之间，但在方法名和其之后的括号间没有空格。然而，在左大括号前总会有空格(这个左大括号一般会出现在一行的最后)。数学操作符总有空格包围。而分号前不会有空格。如果你经常阅读代码，也许认为这是很自然的安排，但如果你不是一个程序员，可能会认为这些规则太随意，有很多不统一、特 ...继续阅读 (12)

上一篇文章作为一个引子，说明了领域驱动设计的优势，从本篇文章开始，笔者将会结合自己的实际经验，谈及领域驱动设计的应用。本篇文章主要讨论一下我们经常会用到的一些对象：VO、DTO、DO和PO。由于不同的项目和开发人员有不同的命名习惯，这里我首先对上述的概念进行一个简单描述，名字只是个标识，我们重点关注其概念：概念：VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。模型：下面以一个时序图建立简单模型来描述上述对象在三层架构应用中的位置：用户发出请求（可能是填写表单），表单的数据在展示层被匹配为VO。展示层把VO转换为服务层对应方法所要求的DTO，传送给服 ...继续阅读 (62)

英文链接：What are the best ways for a complete beginner to learn programming回答这个问题是我最近两年来唯一的关注点。我觉得此处提及的许多资源尽管都很不错，然而我却注意到，成功的学生，无论使用哪种资源，往往都会在以下三个方面，比其他人有着更好的表现。聚焦习惯而不是目标独自学习非常痛苦项目实践聚焦习惯而不是目标聚焦习惯而不是目标听起来似乎不合常理，但是请听我把话说完 - 这是一个有关平衡的问题。凡是和我共过事的人都知道，我有时就像傻子一样，在一天内，引用《蝙蝠侠：侠影之谜》中 Ra's Al Ghul 的话多达 3-4 次。Bloc 公司的投资者们对于我在董事会上频繁地引用《蝙蝠侠：侠影之谜》中的片段作为开始，早已经烦透了。R'As 告诉 Bruce:“（当你的胳膊快要冻僵的时候，）按摩你的胸口，你的胳膊自然会暖和起来。”如果你将精力放在在每星期编程 20-30 个小时的习惯培养上，成为一名 Web 开发者的目标很快就可以实现。如果你将目标设定为在数月内成为一名 Web 开发者，在什么时候能可以达成目标以及距离目标还有多远等不确定性的压力之下，你反而可能会一无所获。聚焦于习惯而不是目标。按摩你的胸口，你的胳膊自然会暖和起来。因此，你现在应该做的是：在你的日程安排上，每天花15分钟时间用于编程。不 ...继续阅读 (23)

曾经参与过系统维护或是在现有系统中进行迭代开发的软件工程师们，你们是否有过这样的痛苦经历：当需要修改一个Bug的时候，面对一个类中成百上千行的代码，没有注释，千奇百怪的方法和变量名字，层层嵌套的方法调用，混乱不堪的结构，不要说准确找到Bug所在的位置，就是要清晰知道一段代码究竟是做了什么也非常困难。最终，改对了一个Bug，却多冒出N个新Bug。同样的情况，当你拿到一份新的需求，需要在现有系统中添加功能的时候，面对一行行完全过程式的代码，需要使用一个功能时，不知道是应该自己编写，还是应该寻找是否已经存在的方法，编写一个非常简单的新、删、改功能，却要费尽九牛二虎之力。最终发现，系统存在着太多的重复逻辑，阅读、测试、修改非常困难。在经历了这些痛苦之后，你们是否会不约而同的发出一个感慨：与其进行系统维护和迭代开发，还不如重新设计开发一个新的系统来得痛快？面对这一系列让软件陷入无底泥潭的问题，基于面向对象思想的领域驱动设计方法是一个很好的解决方法。从事过系统设计的富有经验的设计师们，对职责单一原则、信息专家、充血/贫血模型、模型驱动设计这些名词或概念应该不会感到陌生。面向对象的设计大师Martin Fowler不止一次的在他的Blog和著作《企业应用架构模式》中倡导过上述概念在设计中的巨大威力，而另外一位领域模型的出色专家Eric Evans的著作《领域驱动设计》也为我们提供了不少宝贵的经验 ...继续阅读 (22)

英文原文：How a course in operating systems changed me在普林斯顿大学有很多课程改变了我，就像COS 318（操作系统课程）。它极有挑战，耗时耗力，但是当我学完后回头想想，我很庆幸我选了这门课。我当初选择这门课程的时候很犹豫，因为周围的人都这么说：操作系统课程听起来非常难操作系统课程是为那些喜欢计算机底层的人设计的操作系统课程非常浪费时间，而且你平常很少用到这方面的知识这门课毫无疑问非常难，但是不妨暂时放下你之前听到的对它的偏见。不学它并不会毁掉你软件工程师的生涯，但是如果你真的学过了它，你将会在很多方面获得启发。我选择操作系统课程之前其实十分讨厌系统底层编程，也很害怕参加这门课程。但是现在来看，我觉得选择它是我做过最正确的决定之一。下面是我认为这门课程对我作为学生，作为软件工程师和作为问题解决者所带来的启发：我的经验和启发都是基于普林斯顿2013年秋季的COS 318课程来说的，但是这对其他本科操作系统课程也都适用。1. 操作系统课程让我更善于调试代码错误（debug）毫无疑问，在写一个操作系统的时候，我们需要非常非常多的调试。如果你觉得你在算法课上的调试已经够难了，那你可以想想如果两次调试会产生完全不同的结果该是多么令你抓狂。当你写的操作系统慢慢变得异常复杂了之后，你就不得不去寻找顺手的调试（debug）工具和一套科学合理的调试方法了。 ...继续阅读 (12)

英文原文：Introduction to Microservices这篇文章作者是Chris Richardson，他是早期基于Java的Amazonite EC2 PaaS平台CloudFoundry.com的创始人。现在他为企业提供如何开发和部署应用的咨询服务。他也经常在http://microservices.io上发表有关微服务的文章。微服务正在博客、社交媒体讨论组和会议演讲中获得越来越多的关注，在Gartner的2014 Hype Cycle上它的排名非常靠前。同时，软件社区中也有不少持怀疑论者，认为微服务不是什么新东西。Naysayers认为这就是SOA架构的重新包装。然而，尽管存在着不同的争论，微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供巨大的帮助。这篇博客是关于如何设计、开发和部署微服务的七篇系列文章中的第一篇。读者将会从中学到方法，并且和单体式架构模式（译者注：本文中会将 Monolithic翻译为单体）进行对比。这一系列文章将描述微服务架构中不同元素。你将了解到微服务架构模式的优缺点，以便决定是否更好的将微服务架构应用到自己的项目中，以及如何应用这一模式。首先我们看看为什么要考虑使用微服务。开发单体式应用假设你正准备开发一款与Uber和Hailo竞争的出租车调度软件，经过初步会议和需求分析，你可能会手动或者使用基于Rails、Spring Boot、P ...继续阅读 (16)