在和我的Sponsor（就是可以帮助你成长的人） Review完这一年的事情的时候，我发现还是做了许多事。接着又到一年一度吹NB的时间了，唯一可以吹的是我在年初过了试用期，年底需要开始去帮助别人成长。
尽管没有什么特别大的收获，但是还是发现了一些有意思的东西，值得分享一下。
翻译与写作
去年年底到今年年初审阅的《Learning Internet of Things 》终于是出版了，然后收到英文原版的书籍。不得吐槽一下这个EMS从西安市到我们公司的时间，比英国到西安的时间还长。收到书之前就已经接到出版社的联系开始翻译这本书，然后厚颜无耻地在审阅者一页又改了一下我的简介。谁让我是审阅者，又是译者呢。尽管在审阅的时候已经意识到会翻译这本书，但是还是没有在当时做。
翻译是一个漫长又乏味的过程，特别是你已经看了这本书一遍了。翻译到底还是一件很难入门的事，在最开始的时候很难去把握作者的思想，会出现各种各样的翻译问题。当我那学中文的女友帮我过了一遍后，我才意识到我写的东西很多时候因为看了很多书籍，而变得有些翻译化。随后在渐渐地把握了一些节奏后，发现我差不多可以翻译得有点味道的时候，就已经翻译完了。
不过自己变成了一个翻译，再也不会去骂别人的翻译了。毕竟我们都为大家降低书费支出作出了一点点贡献，想想原版书那么贵。更有甚者帮助你提供了你的英语能力——逼迫你去去看原版书。
紧接着我开始去翻译另外一本书，发现英语水平真的有些提高——毕竟我是考了两次英语四级没过的人。在接受了翻译的时候，在去年写的《一步步搭建物联网系统》也可以变成一本书了。踏入了出版业，我才意识到能力结构金字塔的重要性。下面的图来自网络：
cap.png
一般来说大部分出版社愿意出版的初级是面向初级、中级人才的，特别是对于国内这样的IT环境来说——高级IT人才特别少，据说都是转管理了。那么由国内的作者写出诸如《面向模式的软件架构》这样的书籍变得比较难，不仅仅是因为读者少，而且还在于稿费不及这些作者写作时花出的时间支出。试着往这方面考虑，就会发现一些特别有意思的东西。看待世界的想法又会发生一些变化 ，诸如我这样的人，我觉得出版是一件麻烦的事，我倒是更愿意在GIthub上分享出一些书籍、知识。如
- 复杂的Web Developer 成长路线图
- 整理的GitHub 漫游指南
- 前几天的Developer进阶书单
- 现在计划中的RePractise
但是有时候有意图的去写一些东西，倒是能逼迫自己去深入一些技术和框架。总的来说是各有利弊，看自己去衡量了。然后有幸成为了InfoQ的《物联网周报编辑》，又是一次加深领域知识的机会。就这样成为一名程序员中的编辑，然后我就向终极理想写小说又迈进一步了。
不过，现在我又变成了这个领域的新手。
模式、架构与浮现式设计
今年在Github上建了几十个Repo，大部分都以实战为主，并开始向一些特有的模式发展。说到底还是实现一个软件的架构比深入一个领域来得有意思，虽然最后还是应该深入某一个领域。但是现在，还是让我们自由地生长吧。
学得最好的算是『六边形架构』和『pipe and filter』模式了，代理这种就算过去式了。六边形架构模式就是懒人的最好架构，除此还有最简单的分层模式，如下的Lan IoT算是一个结合：
iot.jpg
模式就是最好的架构。接着，我开始去探索模式如何去具体的应用。开始去创建一些能具体应用的一些场景，并编码去实现其的模式。不过，多数时候都会是一场空。当我可以实现这个模式的应用的时候，我就能做出来。而多数的时候并不是这样的，模式被强加到了一个具体的设计中。
这是一开始我没有意料到的点——模式是总结出来的。而就编码来说，设计模式也应该是重构出来的。一开始以某种设计模式作为理想化的设计，那就类似于瀑布流式的设计。定义好一个接口，并去实现之。并不是说预先设计不好，只是不会如预期的好。而一个模式可以让程序员之间有一个更好的交流接口，他们可以更快地了解到设计本身所含的一些思想。
然后，我就了解到了浮现式设计的概念。可以演进的系统就是最好的系统，假定一开始我们就将系统限制于某种模式来构建，那么我们就会以这种模式来构建我们的系统。而业务本身就是不断变化的事务，因为人本身在不断地变化。同蝴蝶效应一样，可能只是你多余的一个手势，影响到了另外一个人，从而改变了系统的设计。如果你也知晓蝴蝶效应，那么这个模式就是我们的语言，你也就更能理解这句话。
如果在我们系统的后期，我们维护起来比重写起来方便，那么就意味着这个系统本身有着很好的设计。而这也是我要去学习的地方。
尽管我们已经学了很多，但是这又是一个有意思的开始。
网友评论