“不要重复发明轮子”，很多开发者在新入行不久，就经常会被这样叮嘱：这个世界上程序员已经太多，遇到的问题已经够多，而解决方案层出不穷。你走过的路，跳下的坑，已经有无数的先驱在你之前路过，跳过。

所以在做技术选择的很多时候，你不需要自己从头去实现一个东西，就可以在现实世界中找到现成的趁手的利器，小到一个类库，工具，大到一个框架，平台，来满足自己的“需求”。你以为你看到了绝美的风景，后面是一马平川。

而这，只是不愿意拒绝懒惰和诱惑的借口，背后很可能面临更多的困难，陷入其中不得自拔。

开发者在技术选型的过程中，很容易对已有的神往已久的某个技术或者工具情有独钟。

“什么都是现成的，直接拿来用（一套）就好了！”

而往往忽略了它们在后期定制化需求，或者弹性及扩展方面对自己可能存在的限制。下面看两个例子。

关于构建工具的例子

比如Maven在Java的世界里很长时间都是主要的自动化构建工具，它的插件化结构，提供的很多现成的archetype和插件，以及命令行和插件化扩展的可能让很多程序员眼前一亮。

而随着手头的项目变得愈加复杂的时候，你会发现Maven的XML声明式结构和插件化，恰恰是阻碍自身伴随项目复杂度进化的绊脚石，因为它缺乏灵活性，以及对于自动化测试实践的支持，尤其在持续交付方面。

而Ant有同样的问题，我们不断发现团队在不可维护的Ant和Nant构建脚本上耗费了巨大的精力。由于工具自身与生俱来缺少的表现力以及清晰的模块性，这些脚本难以理解和扩展。

XML配置文件中太多让人觉得多余的尖括号，以及粗糙的插件架构。虽然语法问题可以通过升级换代来解决，但插件化架构严重限制了构建工具随着项目变得愈加复杂自我优雅进化的能力。我们发觉插件的抽象层次是错误的，相反我们更青睐基于语言的工具，比如Gradle和Rake，因为提供了细粒度的抽象，以及更多的灵活性。

Gradle是一个把理智带入企业级构建世界的尝试，它把划时代的技术和最佳工具组合相结合。Gradle可以让你访问你已有的Maven仓库，但通过清晰的领域特定语言为你的构建添加脚本功能。

相对于像Ant和Maven这样基于XML和插件的构建工具，像Gradle和Rake这种基于语言的构建工具，在持续提供细粒度的抽象和更多的灵活性。这样它们就能伴随项目变得越来越复杂而随机优雅地应对。

关于前端可视化框架的例子

另外一个例子是关于前端（可视化）框架的选择上，一些提供了丰富UI渲染样式的框架库很是夺人眼球，漂亮的表格和图表样式，简单的Demo示例代码，让开发人员都以为这是实现当下棘手UI需求的不二法宝，可以极大地提高开发的效率。

比如ExtJS，开发人员在经历了初期的甜蜜之后，会发现他们很难控制Ext渲染出的HTML和DOM，而编写功能测试代码看起来也不太可能，尤其是当对UI的外观和样式有个性化的定制变化需求时，会显得一筹莫展。

Ext会把你限制在它的UI实现思想框框里面，这样也许可以在那些不需要投资UX的团队里面工作得很好。

Highcharts是个另外一个例子，丰富的图表类型，以及基于提供的图表类型的定制化功能，优异的JavaScript引擎，对HTML内嵌SVG文档的支持，一度是我们在项目中选择前端图表展现库的不二选择：

但随着对图表渲染的个性化UX定制需求的加入，我们会发现Highcharts通过公开API提供的很多灵活性，比如对于X轴、Y轴和渲染细节的定制，已经很难满足我们对更多图表本身的修改，和添加新的样式。

而这时候，如果不是让UX设计迁就Hightcharts既有的实现，也许更好的选择是D3，虽然它会在开始显得底层，需要团队更多的精力来创建通用的不那么复杂的可视化元素，但这也意味着更多的灵活性，加上它的插件模型，以及像Rickshaw和Crossfilter这样的库支持，会让D3比以前更具亲和性。

最后

所以对于技术的官方网站提供的所见即所得的特性展示，简单的示例代码，和想当然的心满意足，开发者需要在接受诱惑的同时，多考虑一些在技术投资后可能存在的风险，以及是否有足够的支持。

需要考量的因素和角度可能但不限于：

• 文档和社区支持的成熟度
• 复杂的代码示例
• 可能的功能性需求变化
• UI呈现上可能的需求变化
• 性能，安全等非功能性需求
• 团队知识和学习能力
• 后期的维护成本

需要针对这些因素，做一一的评估和侦测，才能最大限度地保护成本的投入。

有的时候，你真的需要重复发明轮子。

这篇是关于技术写作系列的第三篇，在尝试解决为什么要写，以及怎么写的问题后，让我们来看一下关于能写什么的问题。但在进入具体的问题，给出一些可能的选项之前，我们首先需要回答的问题是，我为谁而写，写的目的是什么，这两个问题。

写作的目的，受众是什么

按照我自己的写作经验，当开始说我像写点东西，小到一篇文章，大到一本书，这两个问题恰恰是最容易被忽略的。而忽略这两个问题，产生的结果就很有可能是，文章的定位不清楚，读者也很难get到你想在内容中表述的点，成了自说自话，王顾左右而言他的局面。

如果期望自己的内容能在网络发布，或者在一些知名的媒体发表，能影响到更多人，和自己的思想产生共鸣，就要认真考虑这两个问题：

1. 我写这样的内容是为了什么？是为了展示我对卓越新技术的追求，对技术的深入思考和经验所得，还是展现自己对商业领域知识的掌握。也许会有更具体的目的，比如为了呼应和反驳之前网络上出现的一篇文章。
2. 我这样的内容的目的受众到底是谁？是有着怎样背景的人，有着多少年经验的人，是大概担任怎样职位的人？为什么他们会对我的内容感兴趣，愿意读下去一直到底，甚至愿意为我传播分享这篇文章给更多的人？我希望她们能得到什么，从我的内容中。

举个例子，例如这篇文章《敏捷软件测试常见的七个误区》，可以分析这篇文章写作的目的是为了分享作者近十年来，结合实际的项目经验，在敏捷测试领域对于自己经验的总结和回顾。而针对的目的读者，就是那些同样从事测试领域工作，但对敏捷测试还不甚了解，或者是刚开始尝试敏捷测试的人，他们对敏捷测试的理解还不到位，对于敏捷测试的那些坑还没趟过，而这样的内容对于他们是很有帮助的。

写作线索的来源

我跟我的同事说，其实什么都可以写，可以写的东西很多啊，但我看到的仍然是面露难色。那现在我给大家介绍一下具体的可以尝试想和写的线索：

就像你能从这幅图里面所看到的，我们可以从日常工作和生活中太多角度，得到写作的灵感了，下面是一些其中的例子：

• 刚刚解决了一个很难克服的问题。在自己耗费了半天时间，请教了同事，翻查了不少资料后，一个棘手的问题终于被解决了。而这个问题可能只是未来出现的诸多问题之一，要保存对解决方案的记忆，以及分享给更多可能面临这个难题的人，写一篇文章记录下来就是唯一的出口。我的经验是，当过一段时间再次面对这样的问题是，脑子里的答案早已淡去，而当初自己留存的文章记录帮了大忙。
• 团队在头脑风暴时候的一些想法。“三人行必有我师”，当有更多的人和自己一起动脑经的时候，冲突和想法也会指数级的上涨，而不做记录甚至成文，也是很大的浪费的。
• 从失败中得到的教训。失败了，也许不会有再次经历同样状况的机会，但对自己的将来，和可能经历同样情形的他人而言，记录的经验会让人获益良多。
• 从自己阅读的几篇极好的文章中的所得。站在巨人的肩膀上，总是可以有更好的视角和新的发现。所谓的创新也是从前人的研究和总结中来。阅读了几篇同样主题的内容，沃恩总可以有新的角度，或者更高的角度，来看待这个主题。而记录下所思所想，就是一篇新的内容。

情绪写作

这是我自己个人的经验，而我认为这可以提醒到那些实在对周遭正在发生的线索不敏感，而且对上面这幅图中提到的诸多可能一筹莫展的人，那你可以尝试留意你自己的情绪变化。

当你对团队中发生的一些事情表示不满意，敲桌子，大声咆哮的时候； 当你对面对的代码无法容忍，憋着气要对它大动干戈的时候； 当你对一项新技术突然冒出来，你觉得它能极大改善你的工作方式，你对它充满无限激情和饱满兴趣的时候； 当你以一种平和甚至感恩的心态，看着周围发生的一些积极的变化的时候，内心里欣慰自己的努力没有白费的时候；

这些都是你的情绪在发生一些甚至激烈的变化，而这就产生了一些可能，让自己把自己的情绪写下来的可能。

我把这样的过程称作“情绪写作”。

相比较正常状态下的写作过程，情绪写作难能可贵的是，自己的情绪可以支撑自己连续写作很长一段时间甚至一蹴而就。在基本完成后可以离开一段时间，再回头重新打磨，甚至考虑祛除掉那些因为情绪所带来的，对于主题没有帮助的部分，让内容本身主题更加明确，目的性更强，或者显得更加理性。

最最不该做的就是任由情绪稀释，白白流失掉一次很好的写作机会。

最后

到这里，关于写作的三个问题就基本回答完成了。怎么写，为什么写，写什么，似乎是当我们面对写作的时候，最首当其冲要解决的问题，而解决它们也不会一蹴而就，甚至可能会在纠纠结结，反反复复中徘徊。

但一旦解决了愿意去写，知道写什么的时候，剩下的问题就好办了。

接地气的技术雷达

ThoughtWorks在每年都会出品两期技术雷达，这是一份关于技术趋势的报告，它比起一些我们能在市面上见到的其他各种技术行情和预测报告，更加具体，更具可操作性，因为它不仅涉及到新技术大趋势，比如云平台和大数据，更有细致到类库和工具的推介和评论，从而更容易落地。

这是2016年4月份的技术雷达全貌：

其中，自上次雷达发表以来新出现或发生显著变化的技术以三角形表示，而没有变化的技术则以圆形表示。每个象限的详细图表显示各技术发生的移动。

技术雷达对于不同层级和水平的技术从业者，有可以从不同角度和分类进行解读的可能。不管你是个人开发者，对于新工具和技术有执着的追求，寄希望于从新工具和技术那里获取改进每日工作的灵感，或者你是技术领导者需要针对自己的系统做技术选型，以及对未来技术趋势的把握，技术雷达都会是一份很好的参考。

而如何解读技术雷达就是变成一件很有意思的事情，解读方式可以帮助我们更有效地利用它。下面会介绍几种观察技术雷达的不同角度。

在这里可以下载到最新版本的中文技术雷达。

… →

在聊了怎么用精益创业的思维开始写作怎的问题之后，我们来尝试回答一下为什么要写作这个问题。而这个是本源问题。

其实这是个老生常谈的问题，很多具有丰富写作经验的朋友或者同事，已经给出过无以复加的观点。

下面是我很认可的几个：

• 王健：写作驱动学习

回到写作这件事情，抛开那些“总有一天”才能实现的好处外，眼前的好处无外乎就是帮助我们记录理解消化沉淀学到的知识了。不过我们的内心里总有一个声音反复出现：反正书看了，Session听了，感觉知识已经学会了，那还值得花时间写么？我用这个时间多学点东西不更好？

• 刘未鹏：书写是为了更好的思考

你越是不开始书写，总是拿有限的思维缓存去默想一个问题，就越是没有内容可以写，如果你逼着自己将一些不成熟的想法写下来，看着自己写的内容，试着进一步拓展它们，就有可能在理性的道路上走得很远，很远。

… →

我的周围有很资深的同事，进入软件这个行业没有十年也有五六年，我和她们在一个项目中工作时，往往惊讶于她们处处显现的真知灼见。她们会很轻易地点出设计上的短板，流程上的浪费，还有潜在的缺陷，然后轻轻挥一挥手离开，留下我们傻傻地坐在屏幕前，一身冷汗。

而我试图抓住潇洒的她们，说可以把这些宝贵的实践经验写下来，分享给更多人的时候，得到的回复更多是：

啊，我没写过文章啊，不知道怎么写？

这些都是常识啊，很多人都写过了吧，还有什么可写的？写出来谁会看啊？

我实在太忙了，项目家里一堆事儿，顾不上写了。

这是三个问题，我们一个一个来解。今天，我们先解第一个。

很有意思，在我们组建团队，开始构建软件的时候，我们已经习惯了拥抱变化，我们说不变的是需求的变化，我们接纳这样的变化和挑战，我们对它习以为常，我们认为这样才是解决软件需求之道。

我们会和客户以很小的迭代周期进行频繁反馈，然后上线，或者改进，去交付最终的价值。但让人好奇的是，我们对待写作的态度却一直没有怎么变化，没有对待软件变化那样宽容，而是一如从前。

… →