当你在浏览器的地址栏上输入https开头的网址后，浏览器和服务器之间会在接下来的几百毫秒内进行大量的通信。InfoQ的这篇文章对此有非常详细的描述。这些复杂的步骤的第一步，就是浏览器与服务器之间协商一个在后续通信中使用的密钥算法。这个过程简单来说是这样的：浏览器把自身支持的一系列Cipher Suite（密钥算法套件，后文简称Cipher）[C1,C2,C3, …]发给服务器；服务器接收到浏览器的所有Cipher后，与自己支持的套件作对比，如果找到双方都支持的Cipher，则告知浏览器；浏览器与服务器使用匹配的Cipher进行后续通信。如果服务器没有找到匹配的算法，浏览器（以Firefox 30为例，后续例子中使用的浏览器均为此版本的Firefox）将给出错误信息:本文将讲述如何探究这一过程。1. 浏览器浏览器支持哪些Cipher？这取决于浏览器支持的SSL/TLS协议的版本。习惯上，我们通常把HTTPS与SSL协议放到一起；事实上，SSL协议是Netcape公司于上世纪90年代中期提出的协议，自身发展到3.0版本。1999年该协议由ITEL接管，进行了标准化，改名为TLS。可以说，TLS 1.0就是SSL 3.1版本。在Wikipedia上并没有SSL独立的条目，而是会重定向到TLS，可见两种协议关系之紧密。目前TLS最新版本是1.2。互联网上有超过99%的网站支持 ...继续阅读 (50)

文/ITValue 记者吴宁川从 2008 年开始进入公众视野，到亚马逊与微软于近期获得 1 亿美元的美国联邦管理局云计算合同，云计算整整走过了 7 年。7 年间，以第一代云计算技术为基础的移动计算、社交网络、大数据等新信息技术在全球商业领域掀起了一场新商业运动，这场商业运动创造出以消费者和用户为核心的个性化商业模式。从去年开始席卷云计算领域的 Docker 技术风潮，恰恰就是推动企业走近消费者和用户的一大步。本文通过深入分析，带你了解什么是 Docker 以及 Docker 将如何改变云计算，进而孵化出能够工业化生产个性化产品与服务的下一代商业模式。什么是 Docker？答案是：Docker 是下一代的云计算模式。Docker 翻译成中文是“码头搬运工”的意思，那么“码头搬运工”搬运的是什么？是标准化的“集装箱”，这个标准化“集装箱”里装的是应用程序。“码头搬运工”在世界上任何提供了标准化接驳的“码头”就可以接收标准化“集装箱”，然后快速安装、运行和管理“集装箱”里的应用程序，而提供标准化接驳“码头”的就是各类云服务商。借此，Docker 把云计算环境下的应用程序开发 ...继续阅读 (10)

本文摘自：《Web 全栈工程师的自我修养》野生程序员是指仅凭对计算机开发的兴趣进入这个行业，从前端到后台一手包揽，但各方面能力都不精通的人。野生程序员有很强大的单兵作战能力，但是在编入“正规军”之后，可能会不适应新的做事方法。遭遇“野生程序员”腾讯公司内部的团队很多，在团队管理上有项目和专业两个维度。也就是说，有些团队是项目维度的，整个团队共同维护一个产品，成员来自不同的职业岗位；有些团队是专业维度的，比如一个组都是前端工程师，维护不同的产品。因为前端组是设计部最接近后台技术的团队，所以团队平时的工作和技术交流分享，都不局限于前端技术领域，还包括很多服务器端或者移动端的技术。从前端到后端，一些技术问题都要我们自己来解决。在招聘前端工程师的时候，我们对应聘者的要求是，在掌握基本前端技术的前提下，最好有更为全面的技术。这样，即使我们的项目人力结构、平台和方向发生变化的时候，他也能够更加灵活地转移到其他角色中。而且技术的全面更能表现一个人对技术的热情以及较强的学习能力。从团队多样性来讲，多一些技术种类的话，大家在一起也能碰撞出新的火花。有一次，我在 QQ 群发布了一条简单的信息：“招聘前端工程师，全栈更佳。”随后有一个“全栈工程师”A君向我自荐。我仔细看了他的简历：“三年工作经验， ...继续阅读 (14)

有限状态机FSM思想广泛应用于硬件控制电路设计，也是软件上常用的一种处理方法（软件上称为FMM有限消息机）。它把复杂的控制逻辑分解成有限个稳定状态，在每个状态上判断事件，变连续处理为离散数字处理，符合计算机的工作特点。同时，因为有限状态机具有有限个状态，所以可以在实际的工程上实现。但这并不意味着其只能进行有限次的处理，相反，有限状态机是闭环系统，有限无穷，可以用有限的状态，处理无穷的事务。有限状态机的工作原理如图1所示，发生事件(event)后，根据当前状态(cur_state) ，决定执行的动作(action)，并设置下一个状态号(nxt_state)。图2为一个状态机实例的状态转移图，它的含义是：在s0状态，如果发生e0事件，那么就执行a0动作，并保持状态不变；如果发生e1事件，那么就执行a1动作，并将状态转移到s1态；如果发生e2事件，那么就执行a2动作，并将状态转移到s2态；在s1状态，如果发生e2事件，那么就执行a2动作，并将状态转移到s2态；在s2状态，如果发生e0事件，那么就执行a0动作，并将状态转移到s0态。有限状态机不仅能够用状态转移图表示，还可以用二维的表格代表。一般将当前状态号写在横行上，将事件写在纵列上，如表1所示。其中“--”表示空（不执行动作，也不进行状态转移），“an/sn”表示执行动作an，同 ...继续阅读 (19)

状态机的概念状态机是软件编程中的一个重要概念，比这个概念更重要的是对它的灵活应用。在一个思路清晰而且高效的程序中，必然有状态机的身影浮现。比如说一个按键命令解析程序，就可以被看做状态机：本来在A状态下，触发一个按键后切换到了B状态，再触发另一个键后切换到C状态，或者返回到A状态。这就是最简单的按键状态机例子。实际的按键解析程序会比这更复杂些，但这不影响我们对状态机的认识。进一步看，击键动作本身也可以看做一个状态机。一个细小的击键动作包含了：释放、抖动、闭合、抖动和重新释放等状态。同样，一个串行通信的时序（不管它是遵循何种协议，标准串口也好、I2C也好；也不管它是有线的、还是红外的、无线的）也都可以看做由一系列有限的状态构成。显示扫描程序也是状态机；通信命令解析程序也是状态机；甚至连继电器的吸合/释放控制、发光管（LED）的亮/灭控制又何尝不是个状态机。当我们打开思路，把状态机作为一种思想导入到程序中去时，就会找到解决问题的一条有效的捷径。有时候用状态机的思维去思考程序该干什么，比用控制流程的思维去思考，可能会更有效。这样一来状态机便有了更实际的功用。程序其实就是状态机。也许你还不理解上面这句话。请想想看，计算机的大厦不就是建立在“0”和“1”两个基本状态的地基之上么？状态机的要素状态机可归纳为4个要素，即现态、条件、动作、次态。这样的 ...继续阅读 (9)

一、状态机描述状态机理论最初的发展在数字电路设计领域。在数字电路方面，根据输出是否与输入信号有关，状态机可以划分为Mealy型和Moore型状态机；根据输出是否与输入信号同步，状态机可以划分为异步和同步状态机。而在软件设计领域，状态机设计的理论俨然已经自成一体。Moore型状态机的输出只和当前状态有关，和输入无关，如果在软件设计领域设计出这种类型的状态机，则该状态机接受的事件都是无内蕴信息的事件（输入）。Mealy型状态机的输入是由当前状态和输入共同决定，对应到软件设计领域，则该状态机接收的事件含有内蕴信息，并且影响状态机的输出。显然，这种划分在软件设计领域毫无意义。虽然软件设计领域的状态机也有同步和异步的划分，但和数字电路方面的同步异步已经不同。除了《数字电路》，涉及到状态机的课程就是《编译原理》了（本人属计算机专业，其它专业是否涉及到状态机就不清楚了）。下面简单回顾一下《编译原理》里有关有限状态机的描述。在编译原理课程里面，对有限状态机的描述仅限在编译领域，特定状态，针对输入字符，发生状态改变，没有额外的行为，另编译原理里有限状态机的构成要素，还包含唯一的初始状态和一个终态集。数学语言描述如下：一个有限状态机M是一个五元组，M=(K,E,T,S,Z)。其中（1）K是一个有穷集，其中的每个元素称为状态；（2）E是一个有穷字母表，它的每个元素称为一个输入字符；（3）T是转换函数，是 ...继续阅读 (17)

简介团队的开发人员撇开需求沉浸在想象中的“完美”程序中；测试人员迷茫的点击着按钮试图搞明白这到底是个什么功能；设计师造出了没有尽头的楼梯，更糟的是，客户爱上了这个设计；团队领导四处救火，力有不逮。种种迹象表明，我们得打破分工带来的壁垒，建设全功能团队——大多数人能完成大多数种类工作的团队。在一次闲聊中，女友的母亲说起实习大夫必须轮岗一年才会进行分科学习，我质疑道：“对于致力于心脏病治疗的医生来说，他岂不是在不相干的学习上浪费了一年时间么？”，她母亲笑着说：“不这么做，你怎么确信病人的确患有心脏病呢？”。不知道为什么，我眼前突然浮现出这样的场景？测试人员在怯生生的询问：“这是一个缺陷么（而不是操作系统/浏览器的限制）？”。亚当与大头针工厂亚当·斯密于1973年在描述大头针工厂的专业化生产时提出了社会分工的好处：提高熟练程度、减少任务切换时的开销、便于机器的应用。我们似乎可以非常自然的推导出重复设计、重复编码、重复测试可以增加相应岗位员工技术熟练度，提升效率，并由此提升企业的盈利能力。然而市场的不断变化让重复生产的美梦不在，切换任务变得越来越频繁。IT公司不是大头针工厂，知识工作者毕竟有别于体力劳动者，在劳动主体发生变化的过程中有两件事情的差异被放大了： ...继续阅读 (12)

disclaimer: 本文所讲的设计，非UI/UE的设计，单单指软件代码/功能本身在技术上的设计。UI/UE的主题请出门右转找特赞（Tezign）。在如今这个Lean/Agile横扫一切的年代，设计似乎有了被边缘化的倾向，做事的周期如此之快，似乎已容不下人们更多的思考。MVP（Minimal Viable Produce）在很多团队里演化成一个形而上的图腾，于是工程师们找到了一个完美的借口：我先做个MVP，设计的事，以后再说。如果纯属个人玩票，有个点子，hack out还说得过去；但要严肃做一个项目，还是要下工夫设计一番，否则，没完没了的返工会让你无语泪千行。设计首先得搞懂要解决的问题工程师大多都是很聪明的人，聪明人有个最大的问题就是自负。很多人拿到一个需求，还没太搞明白其外延和内涵，代码就已经在脑袋里流转。这样做出来的系统，纵使再精妙，也免不了承受因需求理解不明确而导致的返工之苦。搞懂需求这事，说起来简单，做起来难。需求有正确的但表达错误的需求，有正确的但没表达出来的需求，还有过度表达的需求。所以，拿到需求后，先不忙寻找解决方案，多问问自己，工作伙伴，客户follow up questions来澄清需求模糊不清之处。搞懂需求，还需要了解需求对应的产品，公司，以及（潜在）竞争对手的现状，需求的上下文，以及需求的约束条件。人有二知二不知：I know that I knowI kn ...继续阅读 (13)

周日傍晚，天色早早的暗了下来，楼下某只狗子一直叫着；有种让人出神的宁静。我觉得我究其一生最终所要追求的恐怕就是这种宁静。亦或是说心里早已老去了。btw，有谁听过Guns N' Roses某张知名Bootleg拼盘没？也就是所谓的不插电专辑。我在2001年冬天差不多这个时候和Allen、祥子在南开后街买到的这张，同时还有Iggy Pop的Beat'em Up等若干。呼，突然想起这里根本不会有人知道我所指的究竟是谁。那各位会知道dianping.com，也就是我曾经工作了...说起来也是将近3个年头的地方(2010-2013)。可惜，好的时代终结掉了，fucking tw bitch。话说回来，也唯有那几年在工作中结识一帮老小伙伴们是至今仍然每天保持联系交流的。几年来，大家聊的无非是工作啊感情啊八卦啊一类，却也能感受到一种随着时间推移而产生的微妙变化。也许我能说的只有，you're not alone，对他们每一个人。而如今在鹅厂，则是另一则故事。你知道，在这里我真真实实感受到了什么叫做优秀与一流。工作这件事上，我是幸福的，我很多时候甚至认为这些幸福根本就超出我所应得的。几乎每天都能跟不同的人学到一些东西，这是种很棒的感觉。我甚至不知道为什么此时此刻想要聊起这些。只是想，念叨出来吧。进入译文正文：英文原文：Ideas for Pushing Beyond your Creative C ...继续阅读 (36)

英文原文：7 Things Your Boss Doesn’t Understand About Software Development你的老板是否不理解你的工作？本文将有助于你更好地理解为什么你的老板不理解软件开发。你的老板可能真的很棒。我在我自己的编程生涯中就遇到过几个真心棒的老板，但即使是最棒的老板似乎也常常总是不能理解软件开发。事实上，我想说的是当涉及到不止编程的几个元素时，大多数软件开发经理都有点目光短浅。所以，我编译了一个简短的清单，用来说明关于编程一些最让你老板、开发经理、技术大咖等等误解的方面。1. 技术债务最会拖累项目工作在一个满是技术债务的代码库上，就像是在烂泥堆中奔跑。起初，在泥浆还不是很厚的时候，勉勉强强走过去还没问题，但当有个 1 米深的时候，你就寸步难行了。我最喜欢的作家之一，《7 Habits of Highly Effective People》的作者，Steven Covey，称之为“P/PC 平衡”或“产量 vs 产能。”通常，管理人员和其他非技术性人员在推动生产力的时候，宁愿牺牲质量——就像杀掉了下金蛋的鹅一样——从而招致技术债务。当然，通过绞拧这只鹅的脖子，威胁它，你或许暂时可以得到更多的蛋，但用不了多少时间，死去的鹅就永远不会再产蛋 ...继续阅读 (12)

1. 摘要这是烂代码系列的第二篇，在文章中我会跟大家讨论一下如何尽可能高效和客观的评价代码的优劣。在发布了关于烂代码的那些事（上）之后，发现这篇文章竟然意外的很受欢迎，很多人也描(tu)述(cao)了各自代码中这样或者那样的问题。最近部门在组织bootcamp，正好我负责培训代码质量部分，在培训课程中让大家花了不少时间去讨论、改进、完善自己的代码。虽然刚毕业的同学对于代码质量都很用心，但最终呈现出来的质量仍然没能达到“十分优秀”的程度。 究其原因，主要是不了解好的代码“应该”是什么样的。2. 什么是好代码写代码的第一步是理解什么是好代码。在准备bootcamp课程的时候，我就为这个问题犯了难，我尝试着用一些精确的定义区分出“优等品”、“良品”、“不良品”，但是在总结的过程中，关于“什么是好代码”的描述却大多没有可操作性2.1. 好代码的定义随便从网上搜索了一下“优雅的代码”，找到了下面这样的定义:Bjarne Stroustrup，C++之父：逻辑应该是清晰的，bug难以隐藏；依赖最少，易于维护；错误处理完全根据一个明确的策略；性能接近最佳化，避免代码混乱和无原则的优化；整洁的代码只做一件事。Grady Booch， ...继续阅读 (20)

相关文章：关于烂代码的那些事（中）1. 摘要最近写了不少代码，review了不少代码，也做了不少重构，总之是对着烂代码工作了几周。为了抒发一下这几周里好几次到达崩溃边缘的情绪，我决定写一篇文章谈一谈烂代码的那些事。这里是上篇，谈一谈烂代码产生的原因和现象。2. 写烂代码很容易刚入程序员这行的时候经常听到一个观点：你要把精力放在ABCD（需求文档/功能设计/架构设计/理解原理）上，写代码只是把想法翻译成编程语言而已，是一个没什么技术含量的事情。当时的我在听到这种观点时会有一种近似于高冷的不屑：你们就是一群傻X，根本不懂代码质量的重要性，这么下去迟早有一天会踩坑，呸。可是几个月之后，他们似乎也没怎么踩坑。而随着编程技术一直在不断发展，带来了更多的我以前认为是傻X的人加入到程序员这个行业中来。语言越来越高级、封装越来越完善，各种技术都在帮助程序员提高生产代码的效率，依靠层层封装，程序员真的不需要了解一丁点技术细节，只要把需求里的内容逐行翻译出来就可以了？很多程序员不知道要怎么组织代码、怎么提升运行效率、底层是基于什么原理，他们写出来的是在我心目中烂成一坨翔一样的代码。但是那一坨翔一样代码竟然他妈的能正常工作。即使我认为他们写的代码是坨翔，但是从不接触代码的人的视角来看（比如说你的boss），代码编译过了，测试过了，上线运行了一个月都没出问题，你还想要奢求什么？所以，即使不情愿，也必须承认 ...继续阅读 (17)

在程序员这个行业，坚持做技术写作的人一直比较少。我和身边的朋友沟通后，发现他们除了借口没有时间外，大多没有意识到写作带来的收益。在他们看来，将自己学到的知识简单记录下来就足够自己需要的时候回顾了。而技术写作通常需要花更多时间，因为需要将技术的细节以及来龙去脉讲清楚。不得不承认，这的确是一个事实，通常情况下，把一个知识讲清楚比理解它更难。那我们为什么要花时间写作呢？我想写作至少有以下好处。提高自己对知识的掌握层次美国教育心理学家Bloom将知识认知分为了两个维度，其中认知历程维度又分为6个层次，分别为：记忆、理解、应用、分析、评鉴、创造。如下图所示，层次越高，表示对知识的掌握程度越深。对于写作者来说，在写作过程中，因为需要对知识进行精确地表述，常常要对知识的细节再次的探索。在这个过程中，写作者可能会发现自己的观点不清晰的地方，通过二次学习，使自己的理解更加完善。写作者也可能会发现自己观点中的错误，从而改正自己的曲解。在经历过这段过程后，通常对于自己所写的知识的掌握程度，都上升了一个层次。我自己的每次技术写作都经历了这样的提高过程。所以，我更多时候是把写作当成学习的一种方式。这种学习方式比普通的学习方式更加深入，效果更好。当然，花费的时间也更多。提高表达和沟通的能力作为一个程序员，日常的工作大部分时间都是面对电脑。许多人周末也喜欢当一个技术宅，待在家里上网、看电影或者玩游戏来消遣。长时 ...继续阅读 (15)

一艘货轮满载着货物从港口启航，向浩瀚的大海深处破水而去。海面平静，微微皱起波浪，从容而显得宽容。然而，货轮的步履却有些蹒跚，发动机“轰轰轰”地嘶吼着，不堪重负，却无法让船只游得更快，倒像是海水咬住了船底往下在拖曳。“嘟——嘟——嘟”，突然警报声响起，甲板上变得喧闹起来，一个水手模样的年轻人声嘶力竭地呐喊：“船超重了，快快快……快卸货！”声音急迫，甚至能听到哭音。然后，又是一阵喧嚷，似乎是在争吵甚么，就看到一个胖胖的中年人冲了出来。看他那肥胖的体型，真难想到他的身手竟然如此敏捷，如海豹一般破开人群，两手挥舞，大声喊道：“怎么了？怎么了？”，他停下来，吼道：“我看哪个不长眼的家伙敢卸我的货！谁敢！”船长走了过来，略带恭敬地对那中年人说道：“老板，你看，这船超载了，船身吃紧，已经发出超重警报了。倘若不减轻船的重量，这船开不了多久就得沉了啊！”“他奶奶的，这船可真秀气啊！”中年人一边骂骂咧咧，却也知道形势紧迫，容不得自己不下决断。可是心里总存着侥幸心理，突然灵机一动，一把拉过船长，指着这艘货轮问道：“既然这船超重，那我问你，除了货物，这船 ...继续阅读 (19)

好些人来信问我，要成为一个好的程序员，数学基础要达到什么样的程度？十八年前，当我成为大学计算机系新生的时候，也为同样的问题所困扰。面对学数学，物理等学科的同学，我感到自卑。经常有人说那些专业的知识更加精华一些，难度更高一些，那些专业的人毕业之后如果做编程工作，水平其实比计算机系毕业的还要高。直到几年前深入研究程序语言之后，对这个问题我才得到了答案和解脱。由于好多编程新手遇到同样的困扰，所以我想在这里把这个问题详细的阐述一下。数学并不是计算机科学的基础很多人都错误的认为，计算机科学是数学的一个分支，数学是计算机科学的基础，数学是更加博大精深的科学。这些人以为只要学会了数学，编程的事情全都不在话下，然而事实却并非如此。事实其实是这样的：计算机科学其实根本不是数学，它只不过借用了非常少、非常基础的数学，比高中数学还要容易一点。所谓“高等数学”，在计算机科学里面基本用不上。计算机是比数学更加基础的工具，就像纸和笔一样。计算机可以用来解决数学的问题，也可以用来解决不是数学的问题，比如工程的问题，艺术的问题，经济的问题，社会的问题等等。计算机科学是完全独立的学科。学习了数学和物理，并不能代替对计算机科学的学习。你必须针对计算机科学进行学习，才有可能成为好的程序员。数学家所用的语言，比起常见的程序语言（比如C++，Java）来说，其实是非常落后而糟糕的设计。所谓&ldqu ...继续阅读 (19)

英文原文：Finding awesome developers in programming interviews我曾在一次面试中要求一个很有经验的嵌入式软件开发人员写出一个反转一段字符串并输出到屏幕上的程序。他在这个题目上挣扎了很久。这个家伙是个很神奇的人。你给他一些没用的零件，他能建造一个机器人，并能用程序控制它在屋里走来走去。他曾经参与过研制卫星，并且这个卫星现在正在轨运行。他只用左脑都比我能干。但是对于这个题目他却从来、从来没机会干过：在屏幕上显示什么东西。有些人就有这种技能，能在面试中问出正确的问题，发现优秀的程序员。而有些人却害怕提问，畏首畏尾，问一些从网上拷贝下来的问题，自己没主见，只会跟随其他面试官的意见。但面试对于大多数开发人员来说是一项很基本的技能。一次失败的招聘会给一个组织造成很严重的长期的后果，因为很水的雇员会把其他很水的人也带进公司。另一方面，把优秀的应聘者拒之门外对公司也是一种伤害。一场技术性的面试至少包括三个部分。在第一部分里，我们要做的是看应聘者的简历上写的是否符合实际情况。在第二部分里，我们要评估一下候选者究竟有多少实际经验。最后，我们要用一些问答选项或编程问题来测试这些经验。第一部分：测试简历的真实性有一次我跟一位同事面试一个候选人。当面试完之后，我觉得这个候选人还可以，但不是十分出色。可我的同事看起来很不满意。“他撒谎，他说他会XX ...继续阅读 (12)

前言本文上篇主要介绍了解决问题的心理过程以及问题表征阶段影响问题解决的一些心理因素，并分享了另外相关案例和指导意见。本文继续介绍影响问题解决的其它心理因素。影响问题解决的心理因素自我监控技能大胆假设，小心求证––– 胡适在设计好解题计划后，问题解决者并不是简单地执行解题计划，而是要时刻自己监控自己对解题计划的执行是否正确、解题计划本身是否正确。这有点类似行车过程中，GPS导航软件时刻检查车辆当前的行车路线与之事先规划的路线是否吻合。若不吻合，则导航软件会提示车主车辆已偏离规划的路线。。问题解决者自我监控技能的强弱可能对问题解决的效果和效率产生决定性的影响。例如，解决某道数学题时，解题过程中需要计算出某事件出现的概率，然后再以此数据继续解题。若经过很多步骤才算出这个事件的概率是1.02，通过自我监控则可以发现这个概率值的计算显然是错误的。那么，应该重新计算这个概率值，而不是继续执行其它解题步骤。相反，此时若未觉察到这个错误，继续执行其它解题步骤，最终的答案很可能是错的。专家在解决问题过程倾向于更加频繁地进行自我监控，并且其自我监控的效果比新手更好。专家在解决问题，尤其是一些难题，往往更加频繁地提出各种假设，并通过逻辑推理和寻找数据证据对其进行检验，然后再根据检验的结果提出新的假设，再对这些新假设逐一验证，通过这样的自我监控逐步向解决方案靠近。就好比 ...继续阅读 (11)

相关文章： 通过心理学知识提高问题定位与解决能力（下）前言软件开发工作无论是从宏观还是微观上看，都可以看作一个问题解决的过程。从宏观上看，软件开发，简单来说，就是弄清楚客户的需求是什么，然后通过分析、设计、编码和测试等一系列活动解决如何将需求转换为代码的问题。从微观上看，开发人员的日常工作中也面临各式各样的问题。比如，用于调试代码的Web服务器突然启动不了，开发人员必须先解决这个问题，否则手头上的工作可能无法进展。作为开发人员，与其抱怨加班，不如去反思下自己的时间都去哪里了。我相信开发人员的大部分时间都花在解决各种各样的问题上了。不管是资深的开发者、还是新手，在日常的工作中都会遇到各式各样的问题。所不同的是，资深开发者可以在几秒内解决的问题，新手却可能要花上几个小时，甚至一两天的时间！可见，提高开发者的问题解决能力，无论对于个人还是对于团队，都有着重要的意义。其实，心理学作为一门独立的学科，对于问题解决有其专门的研究。其研究成果值得我们借鉴，以提高我们自身以及团队中的其他成员的问题解决能力。本文将为读者介绍心理学关于问题解决方面的知识，并结合软件开发工作的特点给出提高问题解决能力的相关指导意见。没有心理学背景的读者，也不必担心“隔行如隔山”，本文所涉及到的一些心理学术语，大多都是浅显易懂的。重新审视什么是“问题”提高问题解决能力，首先 ...继续阅读 (16)

英文原文：Debug like a doctor“现在的编程工作就像是对你需要解决处理的部分做科学研究。”——Gerald Sussman设计和维护好的软件就像是一个抵制复杂度的永无止境的奋斗过程。任何足够大小的应用程序的代码路径和组件都能迅速成长成令人眼花缭乱的组合爆炸。一点都不简单。当部署类似于Heroku和AWS的平台时，单服务器的Web应用程序成为了分布式系统。现代浏览器模糊了客户端和服务器之间的界线。当简单程序在多个CPU内核上运行时，它们就会成为复杂的协调问题。虽然像测试驱动开发等实践和SOLID原则等指导，可以帮助我们模拟问题，简化解决方案，但大多数软件应用程序都是一些复杂的系统，每个组件也会以意想不到的方式进行交互和组合。当软件系统中发生意外情况时，会造成很严重的后果。幸运的是，软件开发人员可以借鉴另一门更古老的学科，来应对对于复杂系统的关注、维护和调试，这门学科就是——医学。鉴别诊断是医生用来匹配系列症状及其可能病因的系统化方法。一个好的鉴别诊断包括以下4个步骤：列出所有观察到的症状。列出可能的病因。按轻重缓急给这些病因排名。按照优先顺序进行测试，以排除病因。虽然上面这4个步骤是为医生而整理的，但是我们同样可以像一个医生一样思考，用一种强有力的方式来找到并消除软件缺陷。将诊断过程分解为一个一个 ...继续阅读 (20)

对于很多公司来说，代码审查是开发人员日常工作中的重要环节。通过代码审查，可以及早发现项目中存在的问题、促进同事之间的沟通与交流，并且可以在讨论中迸发出智慧的火花。但要想成功实施代码审查却并不是一件轻松的事情，为什么要进行代码审查、何时做、如何做，这是摆在我们面前的3个重要问题。针对于这3个问题，开发者Lisa Tjapkes撰文谈到了自己的经验与教训。在我最近的项目经历中，我们进行了广泛且正式的代码审查。这个过程极大地改进了项目的代码质量，降低了项目中新特性开发的等待时间，同时还促进了知识在整个团队间的传播与共享。我还发现代码审查并不会延误项目开发的时间，反而会提升开发人员的生产力。代码审查的好处我们发现代码审查对于项目的各个阶段都会带来很多好处：在项目起始阶段进行代码审查会帮助我们更好地使用已经建立起来的代码基，因为如果我们没有使用过某些现有代码，那么可以从当前的开发者中获得反馈信息。在项目进行过程中，我们会时不时地向团队增加新的开发人员，代码审查可以极大地降低这些新加入人员的熟悉时间。特别地，我们可以让新加入的开发人员很有信心地开发新特性，因为我们可以在合并前审查代码并且对于他们所编写的任何代码提供有价值的反馈信息。对于我们这个分布式团队来说，代码审查更加具有实际意义。团队协同在构建协作环境上会带来很大的帮助作用，我们可以即时提出想法，然后讨论，再进行开发。虽然由于不在同一地点 ...继续阅读 (13)

英文原文：11 Rules All Programmers Should Live By我是一个倾向于生活在规则下的人。现在，这些规则大部分是我本人为自己设立的，但它们依然是规则。我发现为自己创建规则可以让我过得更好，因为这样做可以提前决定一些事情，而不是要在匆忙中做出所有的决定。我今天早上应该去健身房吗？我的规则告诉我说我要在周三前往健身房，今天是周三，因此我要去健身房，就这么办了！这周，当我正在思考那些对我施加有影响的规则时，我想到了去制定一系列软件开发者都应该遵守的规则，我认为这可能是一个好主意。现在，我承认，这里面的大多数规则比那些“指导方针”要求的要多，它们是：1: 技术是用来让你获取解决方案的，但它本身并不是解决方案Technology is how you get to the solution, it is not THE solution.我们带来了最新的JavaScript框架，IoC容器，编程语言或者甚至是操作系统，但是所有这些并没有实际解决我们作为一个尝试解决问题的程序员的问题，取而代之的是更简单的工具帮助我们解决问题。我们对于特定的技术必须非常谨慎不要太疯狂，不是我们碰巧喜欢或者碰巧现在很流行，而是要考虑运行他们所带来的风险，要思考这个问题是不是就是那个钉子，而我们是不是碰巧拿着锤子，那么我们就要学习它。2: 对代码而言，&ldqu ...继续阅读 (12)

1. 什么是RESTREST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到：“我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。” 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。2. 理解RESTful要理解RESTful架构，需要理解Representational State Transfer这个词组到底是什么意思，它的每一个词都有些什么涵义。 下面我们结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加 ...继续阅读 (28)

有多少程序员，就有多少定义。所以我只询问了一些非常知名且经验丰富的程序员。Bjarne Stroustrup，C++语言发明者，C++ Programming Language（中译版《C++程序设计语言》）一书作者。我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。Bjarne用了“优雅”一词。说得好！我MacBook上的词典提供了如下定义：外表或举止上令人愉悦的优美和雅观；令人愉悦的精致和简单。注意对“愉悦”一词的强调。Bjarne显然认为整洁的代码读起来令人愉悦。读这种代码，就像见到手工精美的音乐盒或者设计精良的汽车一般，让你会心一笑。Bjarne也提到效率——而且两次提及。这话出自C++发明者之口，或许并不出奇；不过我认为并非是在单纯追求速度。被浪费掉的运算周期并不雅观，并不令人愉悦。留意Bjarne怎么描述那种不雅观的结果。他用了“引诱”这个词。诚哉斯言。糟糕的代码引发混乱！别人修改糟糕的代码时，往往会越改越烂。务实的Dave Thomas和Andy Hunt从另一角度阐述了这种情况。他们提到破窗理论4。窗户破损了的建筑 ...继续阅读 (16)

这个时代对于学 IT 的人来说是幸运的。一个普通的程序员可以相对轻易地找到工作，可以轻易拿到比其他行业高得多的工资，甚至自己创建世界级的企业亦非空想。马云、马化腾等企业家的成功，似乎时刻提醒人们：即便是草莽出身的人，也能通过努力令世界瞩目。马云自己也说过：“如果我能成功，那么中国 80% 的人都能成功”。美国有科学研究表明，95% 的男人认为自己比其他人聪明。更何况中国人从小就耳濡目染“王侯将相宁有种乎”、“诚如是，则霸业可成，汉室可兴矣”，恐怕无人不梦想着有一天自己便是名扬天下的马云，大有“秦失其鹿，天下共逐之”的豪情。更何况，时代让 IT 人士看到了这种可能性，于是各种创业的队伍前赴后继。这种现象，我认为对国家是有利的，也常为此感到高兴。市场在优胜劣汰中脱颖出最棒的企业，人们也因此获得更好的服务。但是，有一种现象让我陷入了沉思。那就是在网络上出现了越来越多的“强人”，一般会附带上令人震撼的个人简介。让很多人不自觉地想要与他进行比较。如果真的按照这些简介与自己对比，会发现自己这也不行那也不行，似乎一无是处。于是，会产生两种人：一种是气馁的人，一种是奋起直追的人。对于前者，没什么好说的。对于后者，是做到了“见贤思齐，见不贤而内自省”的。但是 ...继续阅读 (10)

英文原文：The Case for Slow Programming人和人之间编程速度的差异还是很大的，有的程序猿写代码非常快，有的却常常是龟速。Jeffrey Ventrella最近在一篇文章里探讨了这种编程速度的差异，他是绝对的龟速派代表，来看看他对编程速度的看法。我爸常跟我说的一句话是，慢一点码，才能快点把程序写完。我在旧金山很多家互联网公司工作过，现在已经 52 岁了，对于程序猿这个职业来说，我的年龄算偏大的。我写代码的速度近乎龟速，事实上，我更像是一个会写代码的设计师。以前有一次，我和一些比较年轻的程序猿一起工作，他们信奉的编程宗旨是“速度快、更迭少”。我们在同一个 codebase 里合作，就像在共同煮一大锅汤一样。如果我们每个人都持续不间断的贡献代码的话，未来这个工程应该就会很美很壮观的呈现出来。但是并没有。问题在于，这些年轻的程序猿们在心里其实有这么一种思想，他们觉得：1、每个人都是可替代的；2、没人应该对某一部分的具体代码负责；3、所有人应该都可以任意修改整个工程的代码。他们觉得，现在已经有了github这种神器用来管理异步时间内的代码贡献，只要每个人都持之以恒的贡献代码，工程和产品就会顺理成章的出炉了。事实不是这样的。编程从来就不应该是拿工具来减少软件开发的时间的。编程应该是一项有节奏感有韵律的运动。我倾向于把工程依照不同的规模和时间度量 ...继续阅读 (11)

我相信，所有程序员都需要在下面两点之间找到一个良好的平衡：1. 把自己关在一间私密的办公室里，针对你的程序与编译器展开一次亲密对话。2. 出入公众场合，与其他人公开谈论你的程序。关于这个话题，我已经谈过几次了，在此不再赘述。大部分程序员是内向的。因此，他们通常不需要任何鼓励就会避开人群，然后与他们的电脑独处。这对他们来说是很自然的。奔着自己的设备而去，那是他们的心之所向。我不怪他们，因为电脑比人类要理性得多！那也是我们中的大部分人被吸引进入这个领域的原因。不过，也有可能在另一个方向走出去太远。这种情况极其罕见，因为它与大部分软件开发者与生俱来的内向性格不符，但它确实会发生。拿我来说吧，有时候我为自己花在谈论编程上的时间比实际写代码的时间多而感到担心。在我把所有的时间都花在谈论编程而几乎没时间自己写代码的那一刻，我感到了极度的恐惧：我变成了一个专职的评论家。而这个世界最讨厌的就是评论家泛滥。评论家只会给世界带来昙花一现般的见解，而不是什么真真正正、实实在在的东西。他们并没有身体力行地参与人类的制造活动，而是置身事外，观察其他人在那里干活，然后喋喋不休、措辞巧妙地提出一堆意见和批评。真是可悲！我有那样的心结，而当我读到SEO Black Hat的这篇博文时更觉备受鼓舞：你TMD现在就做！别等待！别磨蹭！在这世上，成功者不是那些明知赚钱之法还要推三阻四的人。成功者知道轻重缓急，善于把握今 ...继续阅读 (18)

英文链接：Code Review Processes对我而言，把代码产品化而没有合适的审查流程，就像是一场抽抽乐游戏。代码当然也有可能会挺好，不过总还是有一定概率某人的哪块积木没抽好，然后一切就轰然崩塌。无论是采用持续集成服务、结对审查、QA审查，还是所有这些方案的组合，都可以大大降低引入风险的概率。编程团队规模已经超过了你的掌控能力我在Think Through Math（下文简称 TTM）的工作有18个开发者组成的工程团队，其中有两位是QA专家。这算是有挺多人（相对而言）在同时编码了。我们的架构中有好几种不同的服务，所以不是每个人都能对代码的每个角落了如指掌。我们中有些人偏重于前端的工作，有些人侧重于数据仓库和报表，还有些人则在后端折腾Ruby代码。我们都会经常重新搭配分组以相互传播知识，不过始终还是有相当多的人在为不同的项目工作，而没有一个人能把整个系统吃透。我知道在这种事上我们并不孤单——有其他开发者也处于差不多的情况。一些人只是按部就班开发着应用，一些人则尝试把庞大的Rails应用拆分成小粒度的服务，还有一些人在处理遗留代码拯救项目。不管是什么类型的项目，都可以从某种恰当的代码审查流程获得很大收益。对按部就班的开发项目而言，可以确保做修改，添加新特性时一切正常；对大型系统拆分而言，是可以在代码质量改进并正确分解的时候确保每个新服务都仍保持功能；而对 ...继续阅读 (10)

很多编程的人包括我，头衔叫做“软件工程师”（software engineer），然而我却不喜欢这个名字。我喜欢把自己叫做“程序员”（programmer）或者“计算机科学家”（computer scientist）。这是为什么呢？这需要从“软件工程”（software engineering）在现实中的涵义谈起。有人把软件工程这个领域的本质总结为：“How to program if you cannot？”（如果你不会编程，那么你如何编程？）我觉得这句话说得很好，因为我发现软件工程这整个领域，基本就是吹牛扯淡卖“减肥药”的。软件行业的大部分莫名其妙的愚昧行为，很多是由所谓“软件工程专家”发明的。总有人提出一套套的所谓“方法论”或者“原则”，比如Extreme Programming，Design Patterns，Agile，Pair Programming，Test Driven Development（TDD），DRY principle，…… 他们把这些所谓方法论兜售给各个软件公司，鼓吹它们的各种好处，说使用这些方法，就可以用一些平 ...继续阅读 (16)

近来翻译了不少国外的创业产品类文章到简书和虎嗅以及 36 氪等。承蒙大家错爱，很多网友都觉得鄙人翻译的水平挺高的，然后速度也挺快的－基本上每天靠着晚上那点点时间都能有一篇文章出来。不少人开始问我英语应该怎么学？这里可能大家都只是在文章中了解到本人的英语还算有点水平，其实我个人的口语水平应该比书面英语更好，所以我今天就打算综合起来说说我是怎么学习英语的。当然，每个人都有自己的学习方法，但是，正如我的微信公众号所宣称的，他山之石可以攻玉！也许我的方法也有大家可以借鉴的地方，我们不妨互相借鉴下。简要的说，我觉得学习英语要解决这么几个问题：兴趣词汇量语感使用下面我们尝试逐个击破。兴趣是最好的老师，但兴趣不会从天而降首先，我非常认同一句话“兴趣是最好的老师！”。但是，兴趣像馅饼一样，不会从天上直接掉下来砸中你的脑袋。经过我近来对自己的迷茫人生的一些探索，我领悟到更深层次的一些东西。兴趣还真的是可以培养的！有些东西如果我们只是处于想的阶段，那么可能我们想破了脑袋也只是在想而已。你要去做，万事开头难，无论一开始你是多么的痛苦，只要你能坚持下去，慢慢你就会从中发掘到相应的乐趣的。 在创业界有一句话我觉得在这里也非常适用：“创意离开了执行力，将是分文不值！”之前看过一篇文章，描述说兴趣/激情其实就是你在做一个事情的过程中发现自己比别人做的好点，然后就会 ...继续阅读 (17)

前言前后端分离已经是业界所共识的一种开发/部署模式了。所谓的前后端分离，并不是传统行业中的按部门划分，一部分人纯做前端（HTML/CSS/JavaScript/Flex），另一部分人纯做后端，因为这种方式是不工作的：比如很多团队采取了后端的模板技术（JSP, FreeMarker, ERB等等），前端的开发和调试需要一个后台Web容器的支持，从而无法做到真正的分离（更不用提在部署的时候，由于动态内容和静态内容混在一起，当设计动态静态分流的时候，处理起来非常麻烦）。关于前后端开发的另一个讨论可以参考这里。即使通过API来解耦前端和后端开发过程，前后端通过RESTFul的接口来通信，前端的静态内容和后端的动态计算分别开发，分别部署，集成仍然是一个绕不开的问题 — 前端/后端的应用都可以独立的运行，但是集成起来却不工作。我们需要花费大量的精力来调试，直到上线前仍然没有人有信心所有的接口都是工作的。一点背景一个典型的Web应用的布局看起来是这样的：前后端都各自有自己的开发流程，构建工具，测试集合等等。前后端仅仅通过接口来编程，这个接口可能是JSON格式的RESTFul的接口，也可能是XML的，重点是后台只负责数据的提供和计算，而完全不处理展现。而前端则负责拿到数据，组织数据并展现的工作。这样结构清晰，关注点分离，前后端会变得相对独立并松耦合。上述的场景还是比较理想，我们事实上在 ...继续阅读 (29)