Bu・log

  在没有使用AWS China(Beijing Region)之前，我还天真的认为它只是亚马逊云服务的一个中国区延伸，会延续AWS所有的服务。但是在这两天的使用之后，发现AWS China和AWS其他Region的服务差距还是挺大的，所以简单罗列一下，这两天使用它时发现的几个坑（后续也可能还会增加）。

  有幸参与了3月18号在北京举办的DevOpsDays活动，这也是DevOpsDays这个全球性的DevOps聚会第一次落地中国。官方给出的数据是，大会吸引了将近1200名参会者。在此期间，也有机会见到了被业界称为“DevOps之父”的Patrick，以及《持续交付》的中文译者乔梁。从火热程度、嘉宾阵容以及票价上来说，这样的技术活动可算是较为盛大了，但是从一个开发者的角度来说说，会议中的“干货”才是我最期望看到的内容。本文将会从个人角度来回顾这个会议中的一些内容，并针对其中DevOps相关内容给出一些自己的认识，如有不正之处，还望各位读者指正。

本文翻译自老马(Martin Fowler)的博客文章，该译文现已被博客原文收录在其下方中文翻译处。

  在我的职业生涯期间，我曾听过很多关于一个方法(或者说函数，本文针对两者将不做区分)应当有多长的争论。这其实引申到另一个更加重要的问题上：我们应该在什么时候把代码封装在它自己的方法内？有些准则会基于方法的长度，比如方法的长度不应该超出屏幕可以容纳的范围❶。有些会基于复用，即任何被使用超过两次的代码都应该抽出自己单独的方法，而只在一个地方使用过的代码就应当保留在行内。然而，于我而言，最合乎情理的还是这种论点：那就是意图和实现的分离。如果你不得不费点精力查看一段代码，才能弄清楚它具体做了什么，那你就需要把它抽出成一个方法，并且用“它具体做了什么”来为其命名。这样当你再次读到它的时候，这个方法的意图对你来说便一目了然，并且大多数时候你将不再需要关心这个方法是如何实现它的意图的（也就是这个方法的内容）。

  2016过去已有半月，总想像大家一样，给自己的这一年做一些总结回顾。斟酌一二，便不再想花时间过分煽情，还不如列出一些数据，画一些图表，来反映我的生活及工作和这个博客在过去一年的发展，顺便也憧憬下崭新的2017年。

  12月20号在华中科技大学做的一次演讲，题目为《自动化测试，从入门到放弃》，分享一下slide:

  近两个月由于个人处于新环境、新项目的适应阶段，没怎么提笔写些文章。中间有好几个想法想记录下来分享，但受限于没有很好的时间段供自己总结思考（也可以总结为间歇性懒癌和剧癌发作），便啥也没有更新。借这个周末闲适的下午和明媚的阳光，决定把近来项目上的CI/CD（持续集成/持续交付）策略以及git分支模型和以前的项目做一下分析比较，希望对各位有所帮助，也能有所思考，尤其是那些期望搭建项目部署流水线或者想了解git分支模型的开发、运维人员。