技术负债，指的是为了实现客户的某个需求，而做出的一种短期见效快，长期有伤害的，在技术层面的决定。更通俗的讲，就是坐在代码面前，只顾现在，不管将来。代码满足了客户的需求，却写的很糟很乱，为以后进一步开发新功能，做了一个坑人的铺垫。

上面讲的是技术负债的大概意思，下面讲以一个亲身经历的故事，想说明的是，技术负债，如果你当时不还的话，一旦错过了那个村，以后就很难再找到那个店，想还就难了。

出于不能透露公司秘密的目的，我就只笼统的说一下，（其实和模拟金融产品的收益与亏损有关，;p）。那是一个规模挺大的开发，引入了不少新功能，用了基本一年的时间。出于模块复用的原则，也就是不再造车轮的原则，我们最大限度的重用了原有的模块。由于原有模块的使用情景和新功能的情景大有差别，在重用之前，我们先改了原有的，使它从不可以被重用改善到可以用。说实话，改的有点牵强。

新功能实现了之后，客户很开心。可我们，总感觉有些地方不太对，略加分析，发现，两个不同情景下的模块有不少共同之处，其实当初应该再往前走一步，把共同的部分隔离出来，写一个更加抽象的模块。把确实存在差异的部分放在不同的模块里。

我现在说的听起来容易，其实做抽象没那么显而易见。这要求你，从更深次的角度去分析两个不同的问题，融会贯通，找到它们的共同点。抽象，在编程的各种能力中，处于一个很靠前的地位。

问题发现了，可我们却作难了。为什么？因为新功能已经交付了，客户也很满意。你现在非得给客户说，能不能再给我两万块钱，让我好好抽象一下。哈哈，你不是在搞笑吧？给你钱让你抽象？！你抽不抽的好是一方面，万一把原有的东西也破坏了，你这不是让人家客户抽搐吗。

其实我们的客户不是那种不懂开发油盐不进的客户，他们也知道，现如今不抽，以后再开发新功能的时候可能就会更难。可是既然新功能好用，他们又有很多其他方面还没实现的想法要做，他们更倾向于立即着手于其他的项目，等以后有时间了，也有闲钱了，再让我们搞那些很抽象的工作。

可你仔细想想，谁会有时间，谁会有闲钱？所以技术负债，就像打尖住店一样，过了那个村，就没那个店了。

真的就没有解决方法了吗？我思来想去，结论是没有什么神奇的方法可以解决所有的问题。

你可能会说，留在那个村，别走，解决完问题，再走不就行了吗。我同意这个观点，留在那里不走可以，前提是你给客户预先说好，你需要多少时间，多少预算，才能把问题解决的好。可实际情况呢，很多潜在的问题，在项目初期很难被发现，很多问题都是在实践的过程中发现的。敏捷开发，有利于解决类似的问题。但是越是到后期，和技术负债相关的请求，就会越难被接受，因为的他们的投入产出比小，风险大。更糟糕的情况是，有一些东西，是需要事后的消化，后知后觉的，就像我上面遇到的情况一样。

设计重要，前期周全的设计更是重中之重。小的负债一定要在它的萌芽阶段就消灭掉，越早越容易说服别人。

谢谢您逗留阅读，我是热情洋溢的程序员，王辉。

前一段时间，人告诉我说，我在沟通方面的能力还可以进步。刚听说的时候，还伤感了一下，后来，明白了，就开始找一些可以提升这方面能力的书，
不知道是怎样顺水摸得鱼，糊里糊涂找到了一本很大气的书， How to Win Friends & Influence People， 只看了一下书评，就看到了其中的一条铁律，就是不要和人争吵。

仔细琢摸了一下，发现有的时候我还真是一个不错的辩手。有一次，一个做产品的哥们，问我能不能在某个模块里加一行日志，具体是什么给忘记了，我依然绝然的回绝了。当时的理由是，那条日志是一个底层模块应该写的日志，不能写在高层模块里。我们争得脸红脖子粗，他说，就一行日志，你加了得了，我怀着对软件设计的崇高敬仰，和对其他程序员高度负责的态度，据理力争，不依不饶。

上面只是一个例子，很多时候，只要是我认定的是对的事情，我很难被人说服，达不成一致的时候，结局往往是争吵。后来，我开始慢慢体会到不要和人争吵的真正意思所在。那就是聆听，敞开胸怀聆听。有自己的信仰是无可厚非的事情。但因为有信仰就没耐心听完别人的话，就只能说明，嫩，太嫩。首先，我信的东西未必是完完全全对的，争吵我就错过了一个纠正自己看法的机会。其次，别人的想法也未必就一定和我有冲突，毕竟我听到的可能只是一部分。最后，即便是我真的是对了，人错了，听完想明白后给他发个邮件拯救一下也为时未晚。

不信？试一试，世界仿佛更美了。

今天谈年终总结，说到我在哪些方面还可以再进步的时候，被告知，我要学会控制我的激情。后来我一直在思考这个问题，难道有激情不是一件好事吗？

我当时就有些困惑，不明白我们所谈的激情是什么。详细的问过之后，才发现，原来是有人认为我对技术的热情极高，高到有很多新鲜的事物，看了就想尝试。

我当时的第一反应，是极为委屈的。我纳闷，我什么时候，愣头愣脑的不假思索，不问一二的就埋头做产品了。我的经验中，一向我都是多方面考量之后，才选择一个解决方案，并且明确它局限的地方。
被解释道，说你这个缺点指的是你在实验性的项目中，出手太快，太靠激情引导。我没有完全被这个理由给说服，因为我觉得，既然是实验性的项目，就应该勇于尝试，敢于失败。

可除此之外，确实有的时候，做的不够成熟，出口太快，以致所说的话，条理不清，不能完全让人明白。这一点，即便他们不说，我还是有体会的。记得有一次，我看到了一个关于如何测延迟的文章，为之叫好。结果没有
把概念完全吃透，就给别人说，说这个有多好多好，导致被问到深层次问题的时候，不知如何作答，给人一种只求一知半解的印象。

从上面两方面的角度考虑，我认为，激情是必须得有的，有激情才能有效率，才能更快乐，才能发现新想法。但如果激情过于热烈，而导致身边的同事不舒服的时候，就应该有所节制。毕竟工作生活中，接触的是人，服务的也是人，
人与人之间的交流和关系要处理好。其次，很重要的就是，不要被新鲜的事物，迷惑了双眼，但凡新鲜的想法，都要在脑子里多过几遍，以一种批判的眼光去看待。话不能说太多，一旦开说的时候，一定要有深度，有信服力。

这个节制激情的建议，看似有些令人匪夷所思，但抱着一种一日三省吾身的态度，去看，确实能够找到，自己能进步的地方。

只要功夫深，铁杵磨成针。在钻了好几个晚上和周末后，我没曾放弃过的布朗运动终于动起来了。怀着喜悦的心情，
给大家伙讲讲我看到的，学到的关于优先队列这个数据结构，ES6编程，和Canvas动画的事。

演示

原理

这个系统模拟的是小球在一个有限的空间里完全弹性碰撞的情况。上面的演示中大小不一的小球一共500个。实现这个系统有三个核心模块：

• 基础模块：两个小球之间的碰撞预测和碰撞后的响应解析
• 统筹模块：管理所有小球之间的碰撞顺序，以及任意两个小球碰撞后对系统的更新
• 动画模块：动态的描绘系统的状态

其中基础模块用到的是物理力学和矢量的知识，统筹模块靠的是优先级队列的数据结构，HTML Canvas帮助做动画。

动机

做这个程序，主要有两个企图。

1. 想切身感受一下优先队列这个数据结构的美妙。这个想法是在看完了Coursera上的算法课之后有的，毕竟一下高效的模拟这么多小球的相互碰撞不是一件容易的事。
2. 学习一下ES6这个编程语言。之前一直抗拒尝试ES6，是担心用到写不出优美的代码。后来看到最新的ES6，支持了模块，类，箭头函数等让大家期待已久的特性，手有点痒痒，决定试一下。

做完之后，别的先不提，单是把它真真切切，活生生的跑起来，就让我高兴了好几天，这便是程序员的最大的好处，创造东西有成就感。除此之外，收获还是蛮多的，下面稍微详细的侃侃从不同角度对ES6，和它周遭的生态系统的粗浅看法。

好的

到处都是Javascript

Javascript吸引我的最大的一个原因，就是我可以把它给部署到任何一台有浏览器的电脑，分享给成千上万的人。这就是Web的魅力。这个程序完全可以用Java,Scala或者其他语言写，
但想分享给其他人，其他人必须得先安装JDK，然后再下载我这个程序，再运行，才能看见点什么。
Web的话，点一个网址即可。并且我软件的升级对网友来说是完全透明的，他看到的永远是最新的版本。

模块化

在我看来，模块化的支持将把Javascript的有效打击范围再推向一个更广阔的阶段。因为模块化是构建复杂系统最重要的工具。从我这四五年做软件开发的经验来看，模块化有很重要的意义。

大事化小，小事化了

大事化小，是毫无疑问的，小事化了，就是在谈理想了。模块化的这个好处，是从我们人类认识世界的角度来出发的。一个人在认识复杂事物的时候，不可能一下就抓住它的全部，而是先从一些容易理解的比较基础的地方开始，然后一点一点积累出来，最后看到全貌。
举个简单地例子，让你算个
12*5+(24/6 + 16)/2.5 - 2
等于多少，你不可能一下就知道结果，而是先把这个复杂的算式，分解分解，弄成最基本的加减乘除，然后一步一步得到最后的结果。

做软件是同样地道理。把复杂的系统，分割成稍微简单地子模块，依次往下走，子模块做好了，大的系统才可能见得天日。这一点和任何开发语言都没有关系。甚至和编程本身都没有关系，因为它是我们认识，发现世界的基本方法。

你变你的，别影响到我就行

这是模块化带来的第二个非常关键的好处，隔离变化所造成的影响。在软件这个领域里，我们最喜欢的是变化，最害怕的也是变化。为什么爱得也是它，恨的也是它？

爱它使因为它带来的是效益，有变化说明客户有新的需求，需求越多，变化越多。恨它，是因为变化不好控制，一不小心，就造出了Bug，并且有时候都不知道，为什么改了东墙，却倒了西墙。

模块化所扮演的角色，就是隔离，一个模块内部的变化，一定要内部消化，不管你怎么消化，别影响到别的模块就好。就像我上面分的模块，动画模块和基础模块是隔离的，小球怎么撞那是基础模块的事，不管怎么撞，动画模块画球的方式都不会受到影响。

拿来用用

吃别人嚼过的馍馍没味，但用别人已经做好的模块就很爽，因为这能给你节省时间和精力，让你专注于别人没有而你独有的东西。这是我认识到的模块化，激活的第三个非常关键的特点。
我的这个模块里，直接用到的别人做好的模块是优先级队列这个数据结构，在es-collesions里。我用得没有预期中的那么顺利，因为它由Bug，就像所有的拿来主义一样，要持有敢怀疑的态度。我是最后才怀疑的它，最后证明Bug就在他那里，我给他修了。

生态系统

这里我所谓的生态系统，是指的在Javascript这个语言周围的一些辅助开发的工具。

Atom

Atom是Github的一款文档编辑器，用Javascript/Coffeescript写的，但它早已超越了文档编辑器的范畴。琳琅满目的插件，多种多样的功能
完全可以使它成为一个开发的整合环境，你所需要的代码补齐，代码高亮，搜索替换，git，vim等等很多工具都可以在里边找到相应地插件。唯一不足的是，
缺少调试功能。

Webpack

我查得第一个工具就是构建工具，稍微一查，真是有点被吓到。构建工具太多了，虽说百家齐鸣是好事，但多了也麻烦，这就牵扯到标准方面的事情。大概看了一下，最老牌的是Grunt，相当于Java里地Maven,推崇的是Convention over Configuration，我很喜欢这种方式
，大家都用同样地东西，学了一样工具，就到处都可以用。比较新的有Gulp，我说它比较像Java里的Gradle和SBT,Code as Configuration,配置文件本身也是代码，它省了不少配置的复杂度，也很有吸引力。

可最终我选择了，配置最简单，支持ES6最快捷，注重模块化的Webpack。几行配置文件就搞定了ES6的支持，并且自动生成一个Bundle整合文件，HTML只需要导入这个文件即可。很快就可以上手。它最有吸引力的是它关于Code Splitting的关注，可我后来意识到这里所说的
Code Splitting更像是Java 9里谈到的自动加载独立模块的概念，在我的项目里没用到。稍微细说一点，就是你有很多模块，当一个用户用你的应用的时候，未必一下子需要把这些模块都加载进去，提取给他有用的那些部分模块就好，简单地说是为了减少代码的下载量。

测试驱动

测试驱动，在使用像Javascript这样的松类型的开发语言的时候，所扮演的角色就更重要了。松类型的一个弱点就是不能在编译阶段找错，所以我们犯错误的概率就更大一点，所以早测试就尤为的重要了。
Webpack里有测试的Plugin，但是都是基于浏览器的。由于我的基础模块，和统筹模块都不操作DOM，完全可以脱离浏览器独立的测，所以我就选用了Mocha的单元测试，和Babel编译器相结合，单元测试非常快。试了一下Karma,是和浏览器结合的，太慢了。

Animation with Canvas

最后，说一说动画模块，一个简单地函数window.requestAnimationFrame，就天衣无缝的把网友计算机的屏幕刷新机制和代码联系了起来，
这真的让人叹服。我觉得这是Web的另一大魅力，几乎所有我们能想象到的应用都可以用Web的技术来实现，WebSQL, WebSocket, WebComponent…

可改进的

松类型（loose typing)

松类型是有好处，因为它给了你更多地灵活性。我在基础模块了就用到了这一点。可以和小球碰撞的物体有两种，一个是小球和小球撞，另外一个就是墙和小球撞。我在球和墙的代码里，都写了一个撞小球的方法，它们不用继承同一个父类，我可以直接把他们放到同一个集合里，
然后调用它们共同的方法和小球撞。这在Java，Scala或者Haskell这些强类型的语言里是不可能实现的。

但它也有它的缺点，首当其冲的是，松类型不利于在编译阶段发现错误，这个弱点可以用单元测试来弥补。但最让我头疼的是，一个函数所传达的信息是不完整地，它只告诉了你它接受什么参数，而不告诉你要返回什么。这对代码的可读性是一个非常大得影响。我想一个可能的
改善的方法，是把函数的名字，起的更详细完整一些，在函数的名字里，告诉别人它要返回的是什么。

下一步

Webstorm IDE

Intellij在Java中的体现是有目共睹的，相信WebStorm也可以做的很好。Webstorm相对于Atom，对我的吸引力体现在它对调试的支持上，
也许我应该写更多的单元测试，彻底地省去调试的需求。

JSHint

我看了两个Douglas Crockford的演讲，一个是比较老一点的JavaScript: The Good Parts,
另一个是新一点的The Better Parts,他都提到了如何用JSHint帮助我
们避免Javascript里地一些陷阱，只用它好的部分。

尾部递归

另外一个我没有提到的ES6的新功能便是对尾部递归的优化，这么一来，我就完完全全没有必要在代码里使用循环了。

这周的codingdojo玩了一道很有收获的题，终于搞明白了保龄球的计分方法。原题可以在reddit上的daily programmer上找到，这里我分享一下我的解题思路。

机制

保龄球的一局可以分成两个阶段，从第一轮到第九轮是一个阶段，第十轮是第二个阶段。

一到九

一到九的这九轮中，每一轮最多有两次掷球机会。如果一下全中的话，直接进入下一轮。

一击全中

如果一次就打中十个瓶的话，就得了一个Strike， 用X做标记。之所以用X标记，是为了表示它的最终得分还暂时未知。这是因为一击全中是有奖励的，除了先得十分之外，接下来的两次掷球的得分，也会加到这个X上。

两击全中

如果用两次机会打完，就得了一个Spare, 用第一个球的得分加”/“来标记。比如说第一个球得6分，第二球4分，那么就是6/。同样地道理，/表示暂时未知，两击全中也有奖励，但只会加入接下来一次掷球的得分。

没有全中

如果两次机会用完，都还没有全中，那么这一轮的得分就直接知道了，第一球加第二球的得分。比如先得了6分，又得了2分，那么就记为62， 6+2得8分。如果的零分的话，用一横杠表示。

第十轮

第十轮比较特殊。这一轮至少有两次机会，最多可以有三次。如果在前两次之内能全中的话，那么就可以再掷第三球，否则的话，两次就完事。

除此之外，第十轮的每个球都单独计分，没有奖励机制。

举例

讲完了这些规则之后，大家可以猜一猜，保龄球一局的最高得分是多少？怎样才能的最高分呢，那就是每次都一击全中，由下表可见，最高分能达到300分。

下面这个例子的总得分应该140分。

算法

一旦理解了计分机制，算法就很直观了。建模的时候，主要有两个重点：

• 计分应该分成两个阶段，前九轮和第十轮
• 计分单位应该以球为单位，而不是以轮为单位

Scala很简洁很直观地实现了这个计分算法

计算前第九轮成绩的时候，一定不要忘记把第十轮的前两球考虑进去，以便奖励第九轮可能出现的全打

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

object Solution {

  def score(frames: Array[String]) = {
    val oneToNine = frames.init.flatMap(_.toCharArray)
    val ten = frames.last.toCharArray
    val scoreDictOneToTen = ScoreDict(oneToNine ++ ten.take(2))
    val scoreOneToNine = oneToNine.zip(0 until oneToNine.size).map({ case (c, i) =>
      c match {
        case 'X' =>
          scoreDictOneToTen.score(i) + scoreDictOneToTen.score(i + 1) + scoreDictOneToTen.score(i + 2)
        case '/' =>
          scoreDictOneToTen.score(i) + scoreDictOneToTen.score(i + 1)
        case _ =>
          scoreDictOneToTen.score(i)
      }
    }).sum

    val scoreDictTen = ScoreDict(ten)
    val scoreTen = ten.zip(0 until ten.size).map({ case (c, i) => scoreDictTen.score(i)}).sum
    scoreOneToNine + scoreTen
  }

  case class ScoreDict(chars: Array[Char]) {
    def score(i: Int): Int = toScore(if (i == 0) '*' else chars(i - 1), chars(i))

    private def toScore(first: Char, second: Char): Int = second match {
      case 'X' => 10
      case '-' => 0
      case '/' => 10 - toScore('*', first)
      case num => num - '0'
    }
  }
}

如果你需要训练算法，或者准备面试，推荐你破解这些题目：https://github.com/huiwang/cracking-the-coding-interview

这是看完Aeron的设计原则之后的感触。关键的不是看他们设计原则本身是在讲什么，而是这些原则如何指导，对各种冲突的权衡与取舍。

不仅仅是在软件设计中，即便是生活里，冲突随处可见。拿出一个解决办法，满意了小明，却顾不上小红。另一个方案，取悦了小红，却委屈了小明。何去何从，我们需要取舍。

取舍要有原则，可原则怎么定？像Aeron里做的那样，把你考虑到系统的各个方面按他们的重要性排序。如果说小明比小红重要，两个有冲突的解决方案的取舍，就应该从小明的角度来定。

软件的架构，最核心的步骤，就是定义这些取舍的原则，原则清晰了，系统的设计也就差不多了。

Rift，这是我既Pokerchips之后，参加的第二个codingame组织的比赛，淋漓尽致的释放了我对编程的热爱的同时，收获颇丰。

除了获得了，在1028名来自世界各地的参赛者中，名列前2%的成绩之外，这次参赛经历，首先使我对Scala有了更加实际的应用，加深了对这个语言的了解，也体会到了面相函数式编程在人工智能方面的优势。

其次，更加意识到，单元测试，特别是行为驱动开发（BDD），在软件开发中所发挥的巨大作用。再然后，就是大大培养了对人工智能游戏开发的兴趣，也慢慢开始开窍了。

最后，从学习方发方式来讲，更加深信不疑，一个好的学习习惯可以帮助一个人以最快的速度获取事物的本质和他们的内在联系，进而抓住解决问题的突破口。

Scala

从上一年接触了Scala之后，就一直想练练手。只是苦于一直没有找到能吸引我的项目。这次经历，通过实战运用，使我对这个语言有了更加深入的认识。

相对于Java来说，Scala有几个让我爱不释手的特点。

宣告式编程（Declarative programming）

宣告式编程，是一种编程方式。它给解释计算机想解决什么问题，而不是简单的给计算发送一条又一条的控制指令，告诉它如何解决问题。宣告式编程的最大好处，就是它帮助写一些没有副作用的优美函数，这对程序的确定性及可预见性有特别大的帮助。这个我可以另开一帖专门讨论。

不可变性 （Immutability）

不可变性，说的是一旦一个物体被创建了，他就不会再变了。这样做的好处是你把一个创建的对象，放在哪里，不管你把它给了谁，也不管你多长时间之后再来看它，它都会像你创建时的那样，纹丝不动。

简洁

Scala去除了一切不必要的冗繁的代码。我们可以把更多的精力放在问题本身，而不是语言本身。就像case class， type infer 等种种功能。

单元测试

有人说Codingame应该开发一个调试的功能，我觉得是完全没有必要的。反而是不应该受到鼓励的。正确的方法是写测试，写测试有很多好处，特别是在Codingame比赛的这个环境下，更应该写单元测试。

高效的反馈

为了验证程序设计的正确与否，很多人都是把它跑起来，然后看看结果对不对。这样以来，就大大延长了反馈的时间，比赛的长短先不说，从把代码粘贴过去，到跑起来，再到最后得到结果，也得花近一分钟的时间。而单元测试，则是实时的。特别是Scala的SBT工具，测试是持续在跑的，只要发现代码变化，测试就会重新跑一遍。

回归测试

单元测试的另外一个好处，就是有了它，你可以毫无后顾之忧的搞重构。重构是为了，优化代码的结构，使得它更灵活的朝更有利的方向发展，既不加新功能，也不能破坏已有的行为。不破坏已有的行为，是单元测试来保证的。

除了重构之外，无法避免的就要加新的行为，一个新的行为加入，是要保证回归测试的，不能拾个芝麻，留个西瓜。

不论是重构，还是要加新功能，我们关注的都是对已有行为的保护，所以这就要求测试要以测试行为为主。测试行为，不仅可以从行为的层面清晰的阐明问题的需求，又可以避免受到细节的变化对测试的影响。

具体结合Rift本身来讲，比赛进展到中程的时候，地图变了，游戏的策略也必须与时俱进。之前只关注1v1的竞赛着，之后就必须考虑1v2和1v3了。如此一来，就会有重构，有新行为的添加，但又得保证之前的1v1策略不受影响。测试就发挥的巨大的作用。

人工智能

两个比赛比完之后，我对人工智能产生了浓厚的兴趣。之前我之所以很痴迷于电脑游戏，是因为在游戏里我可以发挥我的创造性，自由的尝试我的各种想法。人工智能，有同样的魅力，并且有更大的空间去发挥想象力，去尝试和探索不同的策略，就像玩游戏一样。不同的是，人工智能的策略，不是玩出来的，是自己用手和大脑，一行一行，编出来的，就像你在开发一个机器人，机器人会完全服从你，执行你的想法。

同样，我想在写一篇文章来谈我对制定人工智能游戏策略的体会。

学习方式方法

这是我体会最为深刻的一点。又让我想起了之前的一些困惑，上大学的时候，我总是在问学那么多课，做那么多将来都用不上的光学试验，究竟是为了什么。现在我开始慢慢明白了，那是为了锻炼我们学习的方式方法，锻炼我门的观察能力，锻炼我门发现问题的能力，提高我门推断事物内部联系的能力，进而找到问题的关键点。

编好Rift这种多人人工智能对战游戏，就必须有这些能力。知己知彼，百战不怠。了解别人，要从观察它门的行为开始，之后要对他们的行为进行分析，进而推敲出来他们的战法和策略。好的策略，要学来自己用，不好的要抓住他们的弱点，一举拿下。

结语

收获和体会是多方面的，有很多都需要做更详细的解释。接下来，我会分享我在这个对战游戏里，所用的策略，以及如何更加高效的参加Codingame的比赛。最后，能顺利的参加完这个比赛，特别需要感谢小微的大力支持，小微，谢谢你。