英文原文：The Little Printf（PDF电子书）第一章（推荐看完整篇文章，再回过头看一遍第一章）我非常幸运出生在一个电脑和电子游戏还没有普遍的时代。所以我可以和我的小伙伴们一起玩耍，同时发明属于我们的游戏。我们十分会玩：用树枝做成弓箭。我们可以用树枝做出任何东西，除’回旋镖’。因为你把树枝扔出去，你需要自己捡回来。（作者这个故事是活跃气氛吗？😓）当我们长大了，上面说的游戏变得很幼稚。你不能把一个松塔当成一个手榴弹；假装拥有神奇的魔法；当其他孩子觉得作为一个成年人很酷。你最终会迫于压力而长大。不过总的来说这也是一个非常幸运的童年。偶然的一次机会我接触了电子游戏和电脑。你可能想沉浸在这个虚拟的世界，这会毁了你。大多数电子游戏：你不能创造，只能反应，浪费你的时间。我在十多岁的时候，参加过’即兴表演’。在那里我可以发挥我的创造性。我大学的专业是’多媒体’，但是我最终却从事’编程’工作。我觉得编程is amazing！我可以发挥我的创造性，同时又可以挣钱！之后我做了我的第一个游戏。“这不是一个真正的电子游戏。”别人跟我说：“它只是一个html的表单，而且代码需要简化。”这席话使我有一些沮丧，它花费了很多心思和时间。但是，我意识到如果我想做 ...继续阅读 (6)

工作中，碰到一些这样的例子，总有人提出疑问，为什么一个同事工作勤勉，完成了很多事情，季度绩效评定很高，但晋升却碰壁了。之前已经写过一篇《技术晋升的评定与博弈》，基本就能解答这个问题。但隐藏在背后的更深层次的本质却是：工作、学习与绩效的关系。工作程序员的主要工作是：编程，产出代码，完成需求，交付软件系统。程序员按其工作技能和经验，大体又分为三个阶段：初、中、高级。三个级别的程序员的主要工作都是编程与产出代码，产出代码的数量也许相差不大，但产出代码的属性可能有明显差别。在曾经的文章中提出过一个代码属性：资产与负债。由大量初级程序员产出的代码并以此构建的软件系统，如果最终能完成交付，那么很可能资产和负债性基本持平。这是很多早期创业公司的特点，因为缺乏资金和足够的知名度，难以吸引到又多又好的中高级程序员加入。这样的系统多属于勉强满足业务需要，看不出明显的 bug，但一遇到特殊情况就容易宕机。整个系统虽然勉强能支撑公司运营，但其中欠下了大量的技术债，先活下来，未来再来慢慢还。若是完成了一个债务比资产还大的系统，会是个什么样的情况呢？那这就是一个还存在明显 bug 的系统，是基本无法完成交付和上线的。因此，现在主流都是先完成一个资产和负债刚好过平衡点的系统，发布上线，接受反馈，再快速迭代，在迭代中不断地提升其资产性，降低其负债性。在 Facebook 的著名标语激励下，奋力前行：Done is ...继续阅读 (9)

问题的分类最初在1999年被Dave Snowden开发出来的 Cynefin 框架尝试把世界上的问题划分到了5个域中（大类）：简单（Simple）问题，该域中的因果关系非常明显，解决这些问题的方法是感知-分类-响应（Sense-Categorise-Respond），有对应的最佳实践复合（Complicated）问题，该域中的因果关系需要分析，或者需要一些其他形式的调查和/或专业知识的应用，解决这些问题的方法是感知-分析-响应（Sense-Analyze-Respond），有对应的好的实践复杂（Complex）问题，该域中的因果关系仅能够从回顾中发现，解决这些问题的方法是探索-感知-响应（Probe-Sense-Respond），我们能够感知涌现实践（emergent practice）混乱（Chaotic）问题，该域中没有系统级别的因果关系，方法是行动-感知-响应（Act-Sense-Respond），我们能够发现新颖实践（novel practice）失序（Disorder）问题，该域中没有因果关系，不可感知，其中的问题也无法被解决显然，软件开发过程更多地是一个复杂（Complex）问题。在一个产品被开发出来之前，不确定性非常高，团队（包括业务人员和技术人员）对产品的知识也是最少的，而且需要大量的学习和尝试才可以明确下一步可能的方向。不幸的是，很多时候我们需要在一开始（不确定 ...继续阅读 (10)

1、业务架构：从单体式到微服务K歌亭是唱吧的一条新业务线，旨在提供线下便捷的快餐式K歌方式，用户可以在一个电话亭大小的空间里完成K歌体验。K歌亭在客户端有VOD、微信和Web共三个交互入口，业务复杂度较高，如长连接池服务、用户系统服务、商户系统、增量更新服务、ERP等。对于服务端的稳定性要求也很高，因为K歌亭摆放地点不固定，很多场所的运营活动会造成突发流量。为了快速开发上线，K歌亭项目最初采用的是传统的单体式架构，但是随着时间的推移，需求的迭代速度变得很快，代码冗余变多，经常会出现牵一发动全身的改动。重构不但会花费大量的时间，而且对运维和稳定性也会造成很大的压力；此外，代码的耦合度高，新人上手较困难，往往需要通读大量代码才不会踩进坑里。鉴于上述弊端，我们决定接下来的版本里采用微服务的架构模型。从单体式结构转向微服务架构中会持续碰到服务边界划分的问题：比如，我们有user服务来提供用户的基础信息，那么用户的头像和图片等是应该单独划分为一个新的service更好还是应该合并到user服务里呢？如果服务的粒度划分的过粗，那就回到了单体式的老路；如果过细，那服务间调用的开销就变得不可忽视了，管理难度也会指数级增加。目前为止还没有一个可以称之为服务边界划分的标准，只能根据不同的业务系统加以调节，目前K歌亭拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过2个的其他服务 ...继续阅读 (14)

博主说：也许我们都不是天才的程序员，但至少我们都可以成为一个理想的程序员。 正文 我算是靠坑蒙拐骗进了程序员的门，然后一路狂奔。26岁之前几乎没有任何写代码的经验，研究生毕业却意外选择了一家不可能提供培训的初创公司，在每日担忧公司倒闭、害怕被炒鱿鱼以及同事冷落白眼的三重压力下逆流而上，一年半后离职，已是拥有500万用户产品的后台主程。从前我对计算机技术心怀畏惧，认定技术高人一定有佛光笼罩，昼夜不息运键如飞日吐代码上万行。现在也算见过一些世面了，回首那段忐忑不安宛如初夜的过程，我却不发觉有任何的励志意味，而是视为一种理所当然。理想的程序员，和理想的建筑师、理想的财务师、理想的按摩师没有任何的差别，他们本质上都是一群手艺人。我相信理想的程序员人人皆可成为。 近三年总在互联网圈厮混，我认识过一些程序员、共事过一些程序员、领导过一些程序员、又面试过一些程序员。他们学历不同，有的来自北大，有的来自北大青鸟，有的是博士，有的是高中肄业；资历也不同，有的来自 BAT，有的来自某破产基金公司（还是一个销售）；年限也从0到15年不等。但我认为程序员只需分三类：天才的程序员、理想的程序员、平庸的程序员。天才的程序员我只敢说接触过3个，这是天命7分由你是颗精子的时候就已决定，拥有绝佳的数学天赋、冷静致密的逻辑、为解决难题宁愿不眠不休而深以为乐的技术热情；3分来自起步要早早早，恨不 ...继续阅读 (12)

文/JoeyChen工程师该怎样才能突破自己的能力瓶颈？写 blog！工程师该怎样精进自己在职涯上所需要的能力？写 blog！工程师该怎样才能保持学习与成长的动能？写 blog！工程师该怎样才能证明自己的潜力与特质？写 blog！工程师该怎样才能发挥与养成影响力？写 blog！本文打算老生常谈，从几个很实务的方面来整理，写 blog 对你有什么好处。如果你不需要这样的好处，或是有更好的方法获得这些好处，Just do it！如果愿意分享让我可以跟着你一起学习，我将感激不尽。前言开始本文之前，我想先引用 Jeff Atwood 在2007年一篇文章《How To Achieve Ultimate Blog Success In One Easy Step》中的一段内容：When people ask me for advice on blogging, I always respond with yet another form of the same advice: pick a schedule you can live with, and stick to it. Until you do that, none of the other advice I could give you will matter. I don't care if you suck at writin ...继续阅读 (11)

js给初学者的印象总是那么的“杂而乱”，相信很多初学者都在找轻松学习js的途径。我试着总结自己学习多年js的经验，希望能给后来的学习者探索出一条“轻松学习js之路”。js给人那种感觉的原因多半是因为它如下的特点：A：本身知识很抽象、晦涩难懂，如：闭包、内置对象、DOM。B：本身内容很多，如函数库、对象库就一大堆。C：混合多种编程思想。它里面不但牵涉面向过程编程思想，又有面向对象编程思想，同时，它的面向对象还和别的编程语言（如：C++，JAVA，PHP）不大一样。就好像又是新的一样，让你对曾经学的面向对象产生了怀疑......D：辛苦学习后又看似和实际应用脱节。通常学了很久的js基础之后，变量、函数、对象你也都略知一二，但一到公司开发项目的时候，却又难以下手。因为公司在开发实际项目的时候通常都是直接用它的衍生库，如：jquery，angular，boostrap，amaze，layui，ueditor等，而这些库又多如牛毛，同时还有自己的难点。让你都不知道该学哪个好，甚至都怀疑自己学的是不是js了，好像有多个版本的js一样，总是学不完......那么，怎么才能在js领域内学的轻松甚至游刃有余呢？我总结了一些实战意义的js学习经验：首先要紧紧抓住它的地位 时刻都不能忘记，否则很容易犯“一叶障目不见泰山” ...继续阅读 (9)

一、前端游击战为哪般？小鹿乱撞，心花怒放。终于有机会在梦寐以求的团队博客的评论以外位置留下自己的痕迹啦，撒花撒花！淡定淡定，官博是严肃的地方，要是随便侃大山侃小山，拙文估计会被“里德尔”砍成袁姗姗。深吸一口气，闲话少说，放马入题。首先有必要回答这个问题：“何为前端游击战？”所谓“前端游击战”是相对“前端常规战”而言的。一般而言，一个前端会负责一个（也有多个）项目的开发、上线以及后期维护，精雕细琢产品。所谓一个team，一个团队，大致如此。比方说Qzone的前端er， 至少在一个很长的时期里面，都会泡在Qzone这个产品上，此为“常规战”，我想大部分的小伙伴都是这样子的，不只前端，设计师甚至后台开发也是如此。而“游击战”就大不一样了，打一枪，放一炮，点到为止然后基本上就放手拜拜啦！“我擦”，你可能会惊讶，“还有这样玩的，能做出高品质的产品吗？”无数的偶然可以造就生命，自然各种因素相互碰撞也会造就不一样的开发模式。腾讯社交用户体验设计的小伙伴们遍布祖国大江南北，为亿万网民设计优质体验、提升生活品质。自然，上海这边也有不少很Nice的小伙伴啦，都是国内顶尖的用研、交互与视觉。稍等…这里 ...继续阅读 (11)

阅读技术文章可以说是我们程序员的日常之一，Peak 君每天也会进行定量的阅读。特写一篇小文分享下心得，介绍下过去几年，在纠正阅读习惯上所做的一些努力和取得的成果，或许可以帮助一些朋友，节省少许阅读时间，提升一点学习效率。差不多两年前，我开始搭建 Android 相关的知识体系。最开始的想法是从基础知识的积累开始，正好这几年社区的技术分享盛行，「掘金」、「开发者头条」、「简书」等渠道上每天都有大量的新文章发布，文章主题五花八门，内容深浅不一，看上去都很不错。可坚持读了几天之后，深感自己踏进了错误的方向，读过的比较有代表性的一篇文章是：「关于 Service 你所需要知道的一切」，文章内容的质量远低于标题所勾起的预期，无非是把官方文档里的几个知识点做下摘录，有些地方反而因为摘录不全导致逻辑不连贯，顺藤摸瓜找到出处之后，发现官方文档才是我的救赎。最初学习 iOS 的时候，也走过类似的弯路，急于在短时间内掌握要点，急于能尽可能快的开始写代码，所以略过了看上去冗长繁琐的官方文档，转而搜索各类总结文章以求速成，结果是所有心存侥幸投机取巧跳过的知识点，都会在某一天变成一个个费时费力去填的坑。对于基础知识框架的搭建，没有比官方文档更好的起点了。当然官方文档太过全面，无法在一开始就通读一遍。正确的做法是，在计划深入某一块知识域之前，先读一遍与之相关的官方文档，如果还有疑惑再去其他渠道搜索相关知识点， ...继续阅读 (14)

你的朋友圈里总有一些人具有某种特殊的技能点。比如我的一位铁哥们——波仔——就是这样的人。波仔，江湖人送外号——波哥，是我认识的程序员里面最能跑的。国内的马拉松赛事，他几乎一次不落地参加。只要哪个城市举办马拉松比赛，不管多远，他都一路飞奔过去。这不，前两天刚冒雨跑完了无锡的马拉松。虽然淋得跟落汤鸡似的，但感觉就一个字——爽！波仔年轻的时候曾是专业运动员，有着令无数少女尖叫的健康体魄。后来做了程序员，虽然跑步从此成了业余爱好，但仍然威风不减当年，很随意地就跑能个半马，紧接着再跑个全马，都是小菜一碟。我们搞程序的，谁没经历过没日没夜加班的日子。常言道，身体是革命的本钱。这说起来，好的身体也是程序员的核心竞争力之一呢。意大利「文艺复兴之父」彼特拉克曾经说过：「肉体和心智的能力必须大到足以满足文学活动和妻子两方面的需要。」如果换做程序员的角度，这句话应该修正一下：肉体和心智的能力必须大到足以满足熬夜写代码和女朋友两方面的需要。当然啦，这个说法也还远没有表达出生活真实的复杂性和严峻性。所以，跑步是锻炼身体很好的手段。但是马拉松，除了锻炼身体，同时也是对人性的考验。一件接近身心极限的事情，你的身体能否承受，你的精神能否坚持下来。波仔多次邀请我一起去跑个马拉松，都被我毫不犹豫地拒绝了。这身体条件，咱不能 ...继续阅读 (12)

“不可能啊”、“一定是服务器的原因”、“我的程序不应该有问题啊”，这些年工作听到的最多的就是这些话了，程序员都是比较自信的，总是觉得自己的程序肯定没问题。程序就是程序员的自我延伸，花了几个小时甚至几天时间构建的结果，最后它以“正确”的形象印入你的意识里，你自然不希望别人找出什么纰漏，即便找出什么纰漏了，自己也意识到了“不足”，感情上很难接受，所以大部分人都会习惯性的“辩护”，甚至试图找一些迂回手段证明自己是对的。实际上很多时候，只要我们稍微回归一下，跳出自我守护的那一亩田地，也许我门就会很轻易的发现：我们的确错了。心理学上有一个学术名词叫做“认知失调”，所谓认知失调就是指在一个人的认知系统里即将出现新的认知与就旧认知（旧的信念，自我建立的理论）产生冲突引起的心理上的不适，为了调节这种不适感，一方面为旧的认知辩护，另一方面希望在新的认知和旧的认知上找到共存的平衡。例如，你告诉吸烟者吸烟有害健康，应该要戒烟，吸烟者就会出现认知失调，但是他们很快就会从中解脱出来，因为他们会以“吸烟能减轻压力，令他们轻松”的理由来说服自己。认知失调是一种很常见的心理现象。在我们设计到实现我们的程序的过程中，我们在心理 ...继续阅读 (16)

1前段时间面试了一位三年工作经验的程序员，期望薪资10k。在程序员这行业，三年工作经验，又是一线城市，这期望薪资算是一般。面谈了一会，觉得该程序员技术水平一般，对多线程，线程池，动画属性这些并没有掌握牢固。虽然这三年期间做了好多项目，但大都是类似的，普遍是一些增删改查，项目核心技术较少，其技术含量实际相当一年工作经验的水平。很多时候，我们会误以为工作时间越长，工作经验就越丰富，薪资待遇也应该会越好。其实不然，薪水的高低不仅要依据工龄，还需要依据技能、经验、薪酬体系等多方面因素，高薪一般都是在积累了丰富的经验后才能拥有，除非你有过人之处亦或是显赫的家族地位，那另当别论。2为什么有的人工作了三五年，甚至十年以上，工作经验并没有像想象中丰富？几年前，我在某集团工作那会儿，公司规模比较大，有三栋大厦，公司每层楼都设有前台，前台的工作主要内容大家应该都清楚，一般是接待来访，做好接待，登记，接听电话传真，展示公司良好形象等一些琐碎零散的事。那时我所在的部门是技术部，属于职能系。主要是负责公司内部系统开发与维护，与业务系沟通就相对比较频繁，常在职能系和业务系两层楼层之间跑，对这两层的前台人员也比较熟悉。我们姑且称呼这两位前台为L小姐，B小姐。L小姐所在的楼层是职能系，B小姐在业务系楼层。每当我去B小姐楼层沟通业务需求时，B小姐都会面带微笑，开玩笑说，“又来我们这考察需求了&rdquo ...继续阅读 (12)

摘要本文尝试一步步还原HTTPS的设计过程，以理解为什么HTTPS最终会是这副模样。但是这并不代表HTTPS的真实设计过程。在阅读本文时，你可以尝试放下已有的对HTTPS的理解，这样更利于“还原”过程。我们先不了聊HTTP，HTTPS，我们先从一个聊天软件说起，我们要实现A能发一个hello消息给B：如果我们要实现这个聊天软件，本文只考虑安全性问题，要实现A发给B的hello消息包，即使被中间人拦截到了，也无法得知消息的内容如何做到真正的安全？这个问题，很多人马上就想到了各种加密算法，什么对称加密、非对称加密、DES、RSA、XX、噼里啪啦~而我想说，加密算法只是解决方案，我们首先要做的是理解我们的问题域——什么是安全？我个人的理解是：A与B通信的内容，有且只有A和B有能力看到通信的真正内容好，问题域已经定义好了（现实中当然不止这一种定义）。对于解决方案，很容易就想到了对消息进行加密。题外话，但是只有这一种方法吗？我看未必，说不定在将来会出现一种物质打破当前世界的通信假设，实现真正意义上的保密。对于A与B这样的简单通信模型，我们很容易做出选择：这就是对称加密算法，其中图中的密钥S同时扮演加密和解密的角色。具体细节不是本文范畴。只要这个密钥S不公开给第三者，同时密钥S足够安全，我们就解决了我们一开始所定问题域了。因为世界上有且只有A与B ...继续阅读 (15)

IT技术的发展日新月异，新技术层出不穷，具有良好的学习能力，能及时获取新知识、随时补充和丰富自己，已成为程序员职业发展的核心竞争力。本文中，作者结合多年的学习经验总结出了提高程序员学习能力的三个要点。众所周知，现在是一个知识爆炸的时代，知识更新非常快。据测算，一个大学毕业生所学到的知识，在毕业之后2年内，有效的不过剩下5%。对于软件行业而言，这种形势更为明显，我们赖以立足的，不在于我们现在掌握了多少知识，而是我们有多强的学习能力。学习人人都会，但不同的人学习效果却千差万别。一个善于学习的人，首先应该是一个善于读书的人，懂得如何高效地学习，并且拥有良好的心态。唯有如此，才能成为一个卓有成效的学习者，成就卓越的程序人生。要善于读书买书是最划算的投资古人云：“书中自有黄金屋，书中自有颜如玉。”这说明先贤们早认识到，买书是最划算的投资。我刚出道时，拿着非常微薄的工资。有一次向主管抱怨道：“现在的书真贵啊，这点工资连饭都吃不起，更别说买书了！”主管对我说：“不要吝惜买书的钱，宁可忍着不吃饭，也不要忍着不买书，因为买书是回报率最高的投资。”主管的话让我非常震动。后来，我看到喜欢的书时，再也没有手软过。通过不断学习，我的开发能力不断提高，工资水平也大幅提高。一年后，我一个月工资的涨幅，就足够买两年的书了。你说，还有比这更划算 ...继续阅读 (13)

打破牢笼，展望更高层次的世界-------------------------------------------------------------- 笔者袁永福是一个十多年的老程序猿出来创业多年，期间经历许多曲折和磨难，成功的在炮火连天的商业战场上活了下来，并持续发展中。其中不少体会，于是提出本文的主题--打破牢笼，展望更高层次的世界。 回顾过去，我认为每个程序猿都关在一个透明的牢笼中，限制了思维、蒙蔽了眼界、蹉跎了岁月而不自知，如果不尝试走出去是一辈子都不能感知到牢笼的存在。这个牢笼就是技术本身。 一些程序员就要说，我们就是靠技术吃饭的，天天考虑各种编程技巧，技术怎么成为束缚我们的牢笼呢？那是因为很多人只是看到软件技术的表象而没看到本质。[袁永福原创] 孙子兵法说：不知兵之害者不能尽用兵之利也。套过来说，不知技术之害者不能尽用技术之利也。技术也存在有害的一面，它是程序猿谋生的工具，同时也是关着程序猿的牢笼。为什么是牢笼呢，这就涉及到技术的两个本质：社会本质和价值本质。 现在信息化社会是分裂的，一边是普通的自然人，一边是计算机，也就是机器。普通人类和机器之间存在着巨大的壁垒；人类擅长思考、创新、情感；[袁永福原创]机器擅长记忆和精确计算。人类不能理解机器，机器不能理解人类。而我们程序猿就是帮助沟通人类和机器，各种软件就是人类和机器中间挖掘出来的管道 ...继续阅读 (12)

我觉得编程的框架应该分为：直接用->抛弃->重拾框架（framework）是一个基本概念上的结构，用于去解决或者处理复杂的问题。这个广泛的定义使用的十分流行，尤其在软件概念。框架也能用于机械结构。其实说白了使用框架就是使用别人造好的轮子。在软件开发里面就是command+C/command+V。先自我介绍一下，我是一名信管专业的大学生，从我的专业可以看出我就是以后大家嘴里的程序员。洋洋洒洒写了一些代码，用了一些主流的框架，现在有一些体会分享给大家。作为一个程序员学习一门新技术是让人感到兴奋的，随之而来的问题就是如何快速的掌握语言呐？很多技术的过来人都不约而同的说：用别人已经造好的轮子呗，你看，多省力，在很久以前我也是他们的一员，也喜欢使用大量的框架(js有jQuery、Express、socket.io.js等；PHP有phpword、Yii、laravel；html里面有bootstrap、bootcss、normal)。曾几何时，我觉得很兴奋，在如此短的时间内就可以做到这样的高度，让我十分的开心。开发出的内容也完全符合校内应用的需求。我变成了一个别人眼中的“大师”。但事情并没有往想象的地方发展。框架用的时间久了之后就发现了一个问题：我真的有学习过吗？我学的内容真的有用嘛，这些框架内的东西能对我今后有帮助吗，当然，这种想法不是一天形成的，还有一个小的故事。 ...继续阅读 (13)

最近想复习一下JVM的知识。然后发现网上不少文章在写JVM的垃圾回收算法时，都比较偏向于具体实现，而少有站在更高角度来看垃圾回收算法的文章。而我本人想对垃圾回收算法有个全景的认识，所以，就找到了这本《垃圾回收的算法与实现》（以下简称《垃圾回收》）。本篇博客就是尝试对“全景”的总结。以下为方便讨论，垃圾回收缩写成GC。为什么要有GC我时而听到C++程序员说我们是被GC惯坏了的一代。的确是这样的，我本人在学习GC算法时，大脑里第一问题就是为什么需要GC这样的东西。说明我已经认为GC是理所当然了。总的一句话：没有GC的世界，我们需要手动进行内存管理，而手动内存管理是纯技术活，又容易出错。既然我们写的大多程序都是为了解决现实业务问题，那么，我们为什么不把这种纯技术活自动化呢？但是自动化，也是有代价的。这是我的个人理解，不代表John McCarthy本人的理解。“垃圾”的定义首先，我们要给个“垃圾”的定义，才能进行回收吧。书中给出的定义：把分配到堆中那些不能通过程序引用的对象称为非活动对象，也就是死掉的对象，我们称为“垃圾”。GC的定义因为我们期望让内存管理变得自动（只管用内存，不管内存的回收），我们就必须做两件事情： 1. 找到内存空间里的垃圾；2. 回收垃圾，让程序员能再次利用这部分空间 。 ...继续阅读 (10)

去年底看到陈皓（酷壳博主）写了篇很好的文章《技术人员的发展之路》，里面提及职业发展的一定阶段，也许你会碰上一些复杂的人和事，这种情况下他写道：这个时候再也不是 talk is cheap, show me the code! 而是，code is cheap, talk is the matter!这里的 talk 其实就是沟通，近年来发现沟通越发成为一件重要的事。在近期的工作中也会观察到一些沟通问题，比如跨团队开会沟通时发生的一些分歧与争论。作为程序员的我感觉沟通一直是一个痛点，所以近年来一直在思考关于沟通的问题，下面就写写我的观察与思考吧。木讷与沉默这两个名词似乎已变成了程序员的标签，它们形象地体现了程序员在沟通中的表现。在程序员的世界里，沟通可能包括：与产品经理沟通需求、与同行交流技术、与外行交谈，还有与同事分享工作与生活的趣闻等。有些程序员在分享趣闻与谈需求或技术时的表现大相径庭，刚才还是一个开朗的小伙突然就变得沉默不语了。沉默有时是不想说，特别在沟通需求时，程序员心里想着：与其扯那么多，哥代码都写完了。不就是一个小功能吗，默默无言，笑而不语的就接下了，想着赶快结束去写代码了。程序员写出的代码本应该是公司的资产，但现实是代码这东西是同时带有资产和负债双属性的。Linus 写的 Linux 或者 @antirez 贡献的 Redis 里面包含的代码是极好的资产，但大部分我们沟 ...继续阅读 (11)

上一篇文章我尽管表达了自己的一些想法，但却有些观点写得不够清楚，部分细节让人误解（比如对自信的理解）。所以，我决定重新写一篇专门讲如何写技术文章的博文，来与大家交流我的写作体会。本文适合有一定技术积累愿意与他人分享技术心得的读者。由于并未涉及具体技术，愿意写作的读者均可以阅读。技术文章如何写作能让读者有较好的阅读体验，是一个仁者见仁，智者见智的问题。甚至很多人都认为根本不需要考虑读者的感受，把技术写好写准确就可以了，这其实就是一大误区，你的写作如果只是给自己看，当然我也就不多说什么，但如果你的写作是给别人看，就一定要考虑如何写的问题，因为这是一个信息传递的过程而不是简单的记录。事实上，对于一个准备开始写作的人来说，通常是会认为自己写的东西一定是对的。如果一定要完全正确才可以写文章的话，那就会让绝大多数人裹足不前。因此，写得对不对虽然是作者应该首先要把握的，但是无论作者自己还是别人都无法在写出文章公布之前知道这一点，因此这不是我本文要谈的重点。我的核心观点是：好的技术文章，是让符合阅读条件的读者，在良好阅读体验的情况下，看懂学会甚至掌握文章要传达的信息。因此，需要写作中不断思考，这样写，读者会有什么感受。如果你的写作不能让读者有一种收获的喜悦，或者阅读体验不佳，那么你的写作就是有问题的。问题可能会有很多方面，我们一点点分析。要告知读者文章适合什么人读首先要告知你写的文章适合什么人读， ...继续阅读 (15)

每天，都会有人在微博上私信我，问我关于学习和成长的问题。这种问题我一般都不会回复某个j，毕竟每个人的情况不一样，每个人对待事物的性格也不一样，我不能夸下海口的说，你看某本书几个月就能如何如何，我能做的多数时候只是鼓励鼓励，其次我也从不认为我已经成长到一个多高的境界上，让我去给别人做指导，我还是当之有愧的。但是，有时候看到大家私信我的时候，确实是处于一种很痛苦或是需要帮助的状态上。最近晚上有空，就想写写自己从第一次接触程序，到一路颠簸学到今天的一些故事和经验，希望对大家有所帮助。学习的三个阶段第一阶段：消费者阶段我在快上高中的时候，开始接触的程序。那会儿家里有一本 Visual Basic 的书，30 多页左右，也是家里唯一一本计算机类书籍，是我哥学校发的一本课外书，他对计算机貌似没有什么兴趣，就一直堆在家里，直到无意中被我翻到。书里的程序格外的简单，几行简单的英语代码，就能让计算机弹出一个对话框，当时看到简直神奇极了！跃跃欲试的在老妈店里的电脑上一步一步的敲下代码，弹出一个简单的对话框，那一瞬间，感觉像是推开了新世界的大门，从此一发不可收拾。实践完 VB 后，又在小书摊，看到了一本 《黑客 X 档案》，看着各路高深的入侵，木马，盗号，试图努力学会这些技能，然后去跟朋友们炫耀，但一直都无法入门。因为需要太多计算机的基础知识了，不是写个弹框，或者计算器水平的人能搞定的。那会儿家里也没有 ...继续阅读 (13)

可能是因为正当校招季，最近关于程序媛（女性程序员）的话题很火，朋友圈里一下就冒出很多相关文章，有的写自己求职入职的心路历程，有的从客观数据角度分析女性优劣势，也有过来人分享自己和周围人的看法，加之几天前我所在的公司ThoughtWorks赢得了2016最佳女性科技人员雇主，忽然间，”程序媛”成了每天都会被提起的热门话题。女性究竟能不能以写代码为生？相信每个人都有自己的答案。我刚毕业时也曾自问过：你能不能做程序员？你能在这个行业坚持下去吗？如此等等。很遗憾，那时的我并不像现在这般坚定，甚至产生过放弃的想法。但是，在经历了这几年的历练后，这种看法已被逐渐改变。现在让我再做选择，我会无比坚定的选择继续。因为这是我所热爱的，无关性别。如果此时你也在犹豫，也在担忧，那么请听我聊一聊，聊一聊你心里可能有的那些担忧。“我似乎不那么有热情”毕业时站在IT业大门前踟蹰不前的你，之前四年学的肯定是计算机相关专业，作为一个不打游戏、生活单一的女大学生，人生最好的大部分时光一定都消耗在了课程的学习上。那段时间里，大多数时候你都秉着刻苦认真的学习态度，把不喜欢的专业坚持读下来，并且保持成绩优秀。可是要毕业了，你却开始犹豫，时常感到迷茫，很有可能会因为一个偶然的事件而换角色或改行。如果你是这样的姑娘，那么请再坚持一下。对于从大学一路走来的我们，一般会面临高中毕业 ...继续阅读 (19)

之所以想起写这篇文章，是因为最近看到的一个著名的开源项目在内部使用时的各种问题，不得不说，很多的开源的东西思想是不错的，但离真正工程化都有不小的距离，所以没什么商业公司采用的开源产品如果要引入的话一定要慎重，通常会有N多的坑等着你去填，而比较成功的开源项目的背后多数都会有商业公司在背后不断的改进。遥想我2000年开始学习写asp代码时，觉得写代码也不难呀，无非就是学学语法规则、库就可以写出来，记得有一次我实习面试的时候是让我在一个下午左右的时间写一个完整的留言板，那也就是刷刷刷就写好了，但随着后来工作，尤其是加入阿里以后，越来越明白高质量的工程代码为什么难写。在写代码初期，最关注的是如何用代码实现需求，如果是仅仅实现业务需求的话，即使是刚上手的程序员，只要解题能力还OK，基本上都是可以写出代码来的。所以我自己一直认为数学成绩是程序员的一个非常重要的要求，数学好的人通常解题和逻辑思维能力是还不错的。上面的这个基本的写代码的过程中，写的更好的同学的体现会在对业务的深刻理解以及抽象上，写出的代码会具备一定的复用能力，这个在这里不多加探讨。但代码是不是实现了业务需求就结束了呢，其实远没有，这其实只是写代码的开始，除了正向的逻辑实现外，任何一个点的异常的分支逻辑怎么处理才是工程化的代码中更难处理的部分，这个问题在单机式的系统中会相对还好处理，在分布式的环境会变得非常的复杂，例如调用其他机器的 ...继续阅读 (14)

英文原文：Refactoring -- Not on the backlog!对于如何进行代码重构，一直有着很多种说法。很多人都认为应该将重构代码放在backlog里。但是其实，这并不是一个理想的方法。在项目刚刚开始的时候，你的代码很干净。即使有的时候需要小小的绕一下路，但是这个时候我们可以轻松、平稳的添加功能。这个阶段一般都不会出现问题，而且由于我们比较着急，所以即使出现了一些小问题，我们也不会注意到。然而，随着项目做的时间变长，这些小的问题就会累计起来。这就是人们所说的“技术债务”。其本质，就是并不算特别好的代码，但是这个时候其问题还没有完全显现出来。但是，随着我们一直添加新功能，这些问题就会逐渐显现出来，我们不得不小心翼翼的绕开他们。不可避免的，我们的开发速度会被拖慢。但是为了追求速度，我们开始变得越来越不小心，不久之后，问题也会越来越多。这些问题会像积木一样累计起来，层层叠叠，让我们的开发速度变得更慢。虽然我们终于意识到了问题的存在，但是没有时间彻底解决它。我们只能继续小心翼翼的绕开它们。很快，我们会发现半数以上的代码都与那些小问题有交集，它们无时无刻不在影响我们的开发速度。直到有一天，你发现自己没法继续绕开它们。不得不做点事情了。我们必须要进行复杂的代码重构，让我们重新获得干净的代码。你不得不向上级申请时间进行代码重构。其实这种工作方式并不好，我们 ...继续阅读 (12)

黄衫女子的武功似乎与周芷若乃是一路，飘忽灵动，变幻无方，但举手抬足之间却是正而不邪，如说周芷若形似鬼魅，那黄衫女子便是态拟神仙。这段描写出自《倚天屠龙记》第三十八回。“九阴神抓”本是《九阴真经》中的上乘武功，但当初梅超风夫妇由于拿到的《九阴真经》不完整，学不到里面的内功心法，硬是把这门上乘武功练到了邪路上，于是就成了“九阴白骨爪”。周芷若为求速成，也练就了这门邪功。但黄衫女子乃出身武林名门（相传是杨过和小龙女的后人），自然修炼的是正宗的《九阴真经》。虽然武功路数与周芷若本同属一脉，但更加“醇真深厚”，自然也更胜一筹。这是金庸武侠中“正宗”武功胜过“野路子”的一个典型案例。那么，这是否能够说明，“正宗”一定强于“野路子”呢？且慢！喜欢金庸武侠的朋友，可还记得《越女剑》中的阿青？阿青本是一名牧羊女，却在牧羊时巧遇一头会使竹棒的白猿。在与白猿的玩耍嬉闹中，她硬是悟得了高超的剑法，竟能以一人之力敌两千越甲！就是这样一个从野路子练出来的柔弱女子，即使按广大金庸迷的保守估计，她也能在整个金庸武侠图谱中至少排名前五！做技术，犹如修习一门武功。历数我周围的技术牛人（牛不到一定程度的先不算），他们中既有名牌大学计算机科班毕业的，也有半 ...继续阅读 (8)

四年前，我在 QCon 上演讲了一个《建一支强大的小团队》（整理后的PPT 分享于这里）提到了工程师文化，今天，我想在这里再写一篇关于工程师文化的文章，一方面是因为我又有了一些想法和体会，另一方面，因为我也正走在创业的道路，毫无疑问，要建一个有浓重的工程师文化的团队或公司，所以有必要把自己的相关想法开有成白底黑字的“字据”，以供打自己的脸——“要是未来没有做到，这篇文章就打我未来的脸” “这篇文章太幼稚了，未来的我会打我现在的脸”，我希望是前者。Again，这篇文章不是招人的贴子，因为我觉得，招聘第一重要的事，不是发招聘广告或是找猎头挖人，而是先得让自己变成一个能配得上真正工程师的公司，然后再谈吸引人的事。为什么要工程师文化看看最近二十年来社会的发展，计算机和互联网已经渗透到了这个社会的每一个角落，各式各样的计算机技术成为了整个世界发展的强大引擎，各式各样的创新，无论是业务创新还是技术创新，都是依托于技术的快速演进，技术成了解放生产力提高社会运作的效率的中坚力量。以美帝国主义为首的技术创新公司着着实实的改变着这个世界和人类的生活和生产习惯。今天，每个从事计算机行业的技术人员都应该感到幸运，因为，我们不但选对了行业，也出生在了正确的时代，可能感受到前所未有的刺激和变化，相比起我们的父辈，我 ...继续阅读 (13)

什么是设计模式？曾有人调侃，设计模式是工程师用于跟别人显摆的，显得高大上；也曾有人这么说，不是设计模式没用，是你还没有到能懂它，会用它的时候。先来看一下比较官方的解释：“设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。”今天我们来聊聊CSS的设计模式。设计模式，这个词汇我们常见，几乎所有的编程语言都会有几套，但深入研究的人不多，原因如下：1、似乎没有太大必要性去强调它，有问题了改一下或者按团队规范来就行；2、不去使用一些既有的模式也无伤大雅；3、不少人所接触的业务量级还没有达到需要规划和组织的程度，光写布局，写特效，照顾兼容，就够喝一壶的了，没有意识去思考一些方法论的问题。当然，这三者都是我经历过的，相信你也是~我们都会长大，都会慢慢的做更多、更大、更复杂的项目，这个时候，就需要自上而下，全流程的去思考一些问题。后台不说，只讲前端，比如：风格的制定、色调、模块、布局方式、交互方式、逻辑等等，如果再加上团队合作，若再没有一个规划的话，要不了多久，那些看起来没问题的代码，就会暴露出各种问题，模块命名、类的命名、文 ...继续阅读 (22)

十一年前我和程序猿第一次见面，还是大一军训期间。我甚至不确定程序猿是否记得那是第一次见面。当时不小心装伪文艺参加了吉他社，想借一本吉他入门书，然后同在吉他社热心的海哥说他一同学有，就带着我去拿书了。于是我们第一次“见面”了，我只看见一个对着电脑，佝偻着背的背影......严重怀疑程序猿根本没抬头看一眼那个已经晒得像反转熊猫一样的妹子，因为他递过来书以后，又迅速投入到了电脑的怀抱，相对应的，我也不记得他长什么样了。我从来没有读懂过这个上天用那个背影给我的预警，于是堕入了一生的深渊。当时的我对计算机、程序猿一无所知，只知道这些计算机系的，天然呆居多，玩游戏，不学习，民工气质愈演愈烈，穿着黄色民工拖鞋上课，在食堂和民工大哥们一起吃饭，头发不洗戴帽子遮，没衣服穿了从脏衣服堆里找，喝水的杯子长时间没刷竟然被蜜蜂筑了巢，天天拆别人电脑、烧别人电脑CPU或者对着电脑研究大便（debian）或者聚众看片儿..即使程序猿后来文艺了一把还加入了一个乐队，当贝屎手，还是乐队里面最天然呆的，只会低头猛弹，不像主唱和吉他风骚。经过初步了解，配电脑、修电脑、装系统等都可以找程序猿来干。而且程序猿不会油嘴滑舌的。很多妹子也都这么想的，于是大学四年，程序猿钻了不少次各种妹子宿舍，一去就一下午，他说装系统太慢，我暂且就信了吧。程序猿大四差点没毕业，挂科十几门，从基础课的英语、高数、大物，到专 ...继续阅读 (29)

本来你一个姑娘，可以去做一双贴满水晶的blingbling美甲更显十指纤纤，不用担心敲键盘不方便；可以不时到健身房练练瑜珈来磨练心性，而不是通过看着满屏代码调bug；可以洗完泡泡浴早早躺下睡个美容觉，而不是深夜赶紧贴上面膜，多少有些自欺欺人地告诉自己，刚才电脑的辐射才不会摧毁皮肤的水当当。... ...可是突然有一天，你开始发现代码这个东西的魔力：在安安静静码代码，认认真真调代码之后，运行结果展示那一瞬间...功能实现了，那是能上天的一种感受。于是，你开始了从“网络失足女青年”到“勤奋刻苦程序媛”的跨越。我几乎确定，你想象中程序媛的日常：是家人视你为改变世界的Suprewoman，从此“别人家的孩子”是路人；是集领导、同事万千宠爱于一身的“代码小公举”，特别是在大姨妈到访时谁见都怜；是程序猿们待你如坠落屌丝界的天使，左拥右围，众猩捧月。然而现实却是家人听闻你的职业后，满脸大写的：“好好一个姑娘，长得也挺漂亮，做什么程序员？！”工作时完全没有优待，该写代码写代码，该调bug调bug，该撕逼撕逼；每天混迹在众多男程序员当中，确实还有那么一点儿优越感，但前提是你司并没有多余的钱花在传说中的鼓励师身上。作为程序媛的你，经常感受着他们不明来历的恶意。代码写的没他们好，他们说 ...继续阅读 (9)

原文发表于2008年其实下文的绝大部分内容对所有学习都是同理的。只不过最近在正儿巴经地学算法，而后者又不是好啃的骨头，所以平时思考总结得就自然要比学其它东西要多一些。问题：目前几乎所有的算法书的讲解方式都是欧几里德式的、瀑布式的、自上而下的、每一个推导步骤都是精准制导直接面向目标的。由因到果，定义、引理、定理、证明一样不少，井井有条一丝不乱毫无赘肉。而实际上，这完全把人类大脑创造发明的步骤给反过来了。看起来是阳关大道，实际上车马不通。而对读者来说，这就等于直接告诉你答案&做法了，然后让你去验证这个答案&做法是可行&成立的。而关于答案&做法到底是怎么来的，从问题到答案之间经历了怎样的思维过程。却鲜有书能够很好的阐释。就我有限的阅（算法）书经验，除了波利亚的《怎样解题》还算合格之外（也并非最理想），其它的（包括有名的《算法导论》、《如何解题：现代启发式方法》、《Algorithms》、《编程珠玑》，甚至TAOCP——公平地说由于高老大对算法领域历史了解得非常通透，所以许多地方能够从原始脉络来讲述一个问题，譬如令人印象深刻的从竞赛树到堆的讲解就寥寥一页纸道出了堆这个数据结构的本质来，而像刚才列的几本有名的书却都没有做到），在思维的讲述上都算不上合格（当然不是说这些书没有价值，作为知识性的参考书籍，它们将知识整理出系统结构，极大的便利 ...继续阅读 (20)

湾区日报上分享的一篇文章，文章的作者在Google设计Dart语言，就变量命名方面给了4点建议，文中也列出了好变量名、坏变量名的对比。不管作者的看法与你实际中的命名习惯是否一致，看完这篇文章，相信可以在变量命名方面有一些新的思考。英文原文：Long Names Are Long译/GiraffeGoogle做的最明智的规定之一就是严格执行code review。每一个改动在上线之前，都要经过两种形式的review。首先，团队中的人会进行常规的review，以确保代码完成了它应该完成的功能。接下来还会进行可读性层面的review。顾名思义，它是为了确保代码是可读性高的：是否利于理解和维护？是否符合该编程语言的一些惯例？是否有良好的文档？Dart已经开始Google内部使用，所以我有幸参与了n次上面类型的code review。作为该语言的设计者，这是一项令人着迷的工作。我可以直接看到人们是如何使用Dart的，这对语言的进一步发展很有帮助。在reivew的同时，我也能够清晰的了解到那些比较常见的错误和使用最多的特性，我就好像是一个记录本地居民生活的人类学者。当然，上面说的与本文的主旨无关，这并不是一篇关于Dart的文章。本文主要是想讨论我看到过的一些令人抓狂的代码：这些代码的变量命名实在是太尼玛的长了。。。是的，变量的名称可以很短。回到当C语言中外部标识符仅需要由前六个字符来唯一的区分 ...继续阅读 (27)