后端技术 by Tim Yang

一场黑客马拉松项目，大家会首先选择那些业界做得不够完善、或者有较大潜在价值的领域。比如最近举行的Go & Docker Hackathon，参赛人员会首选Docker领域的服务发现、服务调度等领域。

Docker是一种软件打包及运行的技术，其主要思想是将软件打包成一个image并可以到任意的机器运行，运行时候已经被打包的可执行文件被隔离在一个叫容器的沙箱里运行，并独立于系统其他服务，安全性及资源占用方面都得到了有效控制。Docker软件以及大部分Docker生态圈的软件是由Google的Go语言(也称为为Golang)编写。

但上面提到这些Docker领域的功能需求和实现都较复杂，完成一项功能费事费力，在短时间尤其是一天的Hackathon期间内，很难较好的完成。反而是找一些技术实现简单的领域，解决一个较小的需求，不但可以快速实现，并可以有机会将体验做得更好。让项目在一个很小但又经常使用的点上打动用户，得到用户的关注及认可。比如这次就有一支队伍完成了一个Dockerfile（生成Docker镜像的配置文件）的编辑器，并且进一步可以将用户在测试环境的的操作录制下来，自动构造Dockerfile。虽然技术实现很简单，但是对很多Docker用户会带来便利。

很多公司在选择创业项目的时候也会碰到如此的情况，如果选择了一个技术实现复杂的领域，考虑到功能的完整性，早期的开发周期就会变得不可控。创业公司通常希望每个月都有新的产品迭代，但复杂领域的开发，预期1-3个月的项目通常会拖到半年以上，这无疑是增加了公司运营的风险。

Docker目前在实际环境中主要还是用在管理云平台上的服务，但Docker的这种隔离运行的思想也可以应用在更多领域，比如参赛中应用在硬件控制、可插拔的开放平台等领域的设想。

黑客精神的一个重要点是程序员通过自己的编程打破已有的软件功能使用方式，给程序员自身及其他使用软件的用户带来自由及便利。参赛作品中比较能触动这一点的是挑战Siri的封闭性的一个项目，他设想通过一个个外接的容器能将智能做得更扩展，延伸到生活各方各面。有点类似微信的连接一切的概念，不过连接之后HUB不是微信，而是一个类似Siri这样的入口。

从这个角度，大部分我观察到的程序员思想还都比较禁锢，一方面是从小缺少创新（或者改变）的氛围及引导，在被设计的道路上循规蹈矩的长大，学习成绩好就是一个好孩子。工作后比较正常的做法也是每天接受分配的任务，完成得好就是一个靠谱的成员；打破常规的改变的成本过高，也被视为不那么正常的孩子。程序员即使换工作，也经常落在在薪酬、Title等因素的考量上，较少有动力去首先考虑那些通过技术来改变一个领域的事情上去。

目前好的app会将数据存储在云上，给我们生活带来很多便利，我们可以方便的多屏之间获取到数据，也不用担心app及数据在本地删除后丢失的问题。但很多基于云平台的优秀软件到了国内就会出现一些使用上的问题。

比如Day One是一款跨平台笔记工具，得过苹果设计奖，也得到不少人推荐，功能确实很简洁实用。白天在路上用Day One写了一些文字，回来后发现uploading一直卡住，不知道是否跟文章中某些词语相关。打开iPhone VPN后，终于上传成功，但在电脑上还是半天下载不回来。忙了一些其他事情之后，发现终于同步完成了。

Day One底层可以选择用iCloud，Dropbox等云平台存储。这些云服务在国内访问速度及稳定性方面会存在一些问题。Day One可能出于功能简洁的考虑，将同步设计成后台进行。当同步出现问题时，界面上通常看不到相关提示，系统自动在后台重试同步。界面上也找不到任何同步按钮及菜单，也没有状态信息显示何时会进行同步，因此在同步失败时候，用户只能一筹莫展了。

在国外，由于云平台在基础网络链路及带宽方面都具有优势，因此同步阶段不会出现这么多曲折的情况。上面的问题更多是国内特殊的网络环境造成，软件开发商也无辜的被躺着中枪了，这是app存在的一类问题。

但并不是说国内的app就可以处身事外了，国内也有自身奇特的网络问题，比如一些厂商的DNS不定期的被劫持指向一些奇怪的IP。但开发商即使了解到这个反馈，未必有有效的手段短时间解决，这也是app存在的一类问题。

做互联网分布式系统的通常也有这样一种情况，在主从同步等场景下，数据只能保证最终一致性；互联网业务通常不会使用transaction来保证数据提交一致性，因此可能会存在半状态的数据，用户如果碰到这种情况并且会存在困惑，但开发商通常会采用事后修复的办法，从CAP理论的角度不会首先考虑引入事务来彻底解决，这又是一类问题。

上述问题是否能有效的解决？是否值得花大的精力解决？从“用户第一”的角度，所有用户的问题确实需要第一时间第一优先级解决，特别在影响用户范围足够的情况下。但上述这些问题都是小众群体及场景出现，而且都是在使用标准化方式的情况下出现了异常。

从架构师的角度，我是极力赞成使用通用化技术而反对自建轮子，比如不赞成用自己维护的UDP代替TCP，不赞成使用非主流或自己开发的数据库、框架、工具包；不赞成通讯上使用自定义的协议来代替XMPP，或者为了防止DNS劫持而去搭建自己的DNS方案。可以预见，这些自建方案的决策在一定程度上打开了一个潘多拉盒子，社区通用技术体系经过5-10年或更长时间的演进，经过较多问题的修改与避免。比如上面的TCP/HTTP RESET/URL关键词错误属于一个问题的话，TCP/HTTP协议已经很好的解决了前100个你看不到的问题。自建的体系从0开始搭建系统，可能需要将大量时间放在重复业界已经完成的功能上。

从工程师体验来说不太倾向于对各种特殊小众的环境都做一个适配方案。如果有机会能做这样一个比较，在“工程师体验第一（类似facebook的Hacker文化)”与“用户第一”做一个优先选择的话，究竟谁的成效很更好一些？老板们通常会倾向后者，类似有阿里的“客户第一，员工第二”文化；一些声称工程师文化主导的公司可能会声称选择前者，而且某些持这种理念的人也认为工程师主导产品改进的环境会激励工程师的主动参与及改进精神，而导致成效更好。另外一方面文化层面的东西很难直接比较优劣。

感谢新买到的低因伯爵红茶，让我写完这些文字后接着睡觉不会失眠。