条理性

其实技术人员在工作中遇到大部分的写作，都是应用文写作，并不需要拥有丰富的想象力、风趣幽默的文风、小清新的玻璃心或者历经沧桑的过去，只需要把事情讲清楚就好，所以只要内容条理性够好，听众就会认可。我们可以用列表来写一个提纲，比如今天你要汇报最近一周的工作，那么先写一个一级列表，

像这样： ·优化招聘方请求

·提升通知到达率

·订阅系统升级然后，再为每一项写小的列表，

比如：

·优化招聘方请求

·根据关键字对请求加减分

·增加被拒绝请求的优化提示

·提升通知到达率

·添加短信通知

·微信下行通知换成模板通知

·订阅系统升级

·添加被动订阅模式

·修改界面，改为关键字订阅和条件订阅二选一模式不多写了，再写这周周报都写完了。

那当我们汇报的时候，要先点后面，先给概要再给细节。具体起来就是这样：上周我们主要做了三件事情，分别是优化招聘方请求、提升通知到达率以及订阅系统升级。为了优化招聘方请求，我们分别采取了根据关键字对请求加减分和增加被拒绝请求的优化提示的措施，这两项周三已经完成，经过测试并上线，用户反馈数据正在收集中，预计下周一可完成，当天下班前我会发邮件给大家……

逻辑性

虽然缺乏逻辑性是产品经理的而不是程序员的通病，这里也提一下吧。我们写文章或者做汇报时，前后文之间是应该有明确关系的，后一句对于前一句，或者是后续、或者是论据、或者是总结、或者是并列。不要搞跳跃性思维，不能前边一句说你去了洗手间，后一句说你吃得很饱，这会出人命的。只要你牢牢记住前面介绍的技巧，写一篇条理清晰、逻辑顺畅的文章还是很容易的。

走完分享的最后一公里

毋庸置疑，程序员是非常愿意分享的一个群体，正是这样才有了数不尽的开源软件，我现在正在使用的GitBook就是其中之一。但是很多程序员在分享这件事上虎头蛇尾。我们分享的目的就是让别人能够理解、重用我们的劳动成果。如果我们只是将代码直接push到GitHub上，其实这无法达到分享的目的。我们走过程序开发这千里“长征”，一定要坚持走完分享这最后一公里。为自己的项目写概要说明文档，为新手用户写Quick start，将项目提交到各个技术资讯站，为感兴趣的同学提供讨论和交流的场所。充分的交流不但会扩大你的影响力，更会聚集各种有意思的想法，往往让你惊喜不断，获得新的启示。

程序员的沟通和写作

渠道

如果是技术文章，下面列出了一些常见的渠道：

·首先可以发布到自己的技术博客

·如果反响不错，可以再通过微信公众号推送给订阅读者

·提交到Startup news和CSDN极客头条，掘金等社区。

针对文章的受欢迎程度，我们还可以进行二次加工：

·定期精选系列文章，更新到最新后整理成PDF，通过微盘分享

·对于特别受欢迎的教程类文章，可以做screen-cast，通过在线教育网站（比如优才网、慕课网等）进行传播如果是开源项目，当然首选GitHub。

开始你的开源项目

开源项目在技术求职中是大规模杀伤性武器，如果要面试的公司正在使用你写的开源代码，你会有非常高的加分；即使不是那么有名的开源项目也可以让面试官清晰地了解你的编码风格、架构能力，从而节省很多不必要的面试与笔试时间。所以现在就开始你的开源项目吧。

通过开源项目转型

经常有候选人和我说，我很喜欢XXX语言，但是在公司没有机会做，所以我想跳槽到一家使用XXX的知名公司进行学习。这种想法的愿景不错，但往往很难实现。因为从招聘方来讲，它不是做免费教育的，它是一家商业公司，所以它总是招性价比最好的人选。除非你之前的工作经验能很好地移植到新的领域，否则为什么不直接培养一个应届生呢？他们处于职业的成长期，对薪资不敏感，又有更充沛的学习精力。所以如果你想转型，做一个开源项目是非常有帮助的。它让你在新领域的经历不是一片空白，也向招聘方证明了你对这个领域的真实兴趣。反过来，如果你对招聘方说你对一个语言“非常感兴趣”了好几年，却从来没有用它写过一个项目，很可能会被贴上光说不练的标签。

开源项目不是遥不可及的

并不是一定做出WordPress这样的项目才行，其实很多有名的开源项目不过是一些细节上的改进。比如iScroll这个项目，它其实只是处理滚动条的小Tip而已，技术上没特别的难度，代码量也不大，但由于大家都不想在这种细节上花太多时间，反而让iScroll大规模流行，最后苹果和微软甚至雇佣过它的作者做兼职。所以开始一个开源项目其实很简单，找一些自己在做项目时遇到的费事费时的小细节做好，然后开源就可以了。举个例子。比如我们在做图片列表的时候，如果图片高度不同，就需要截图，很容易把照片中的人脸给截没了。但其实JS版的人脸识别库已经在GitHub上开源了，那么可以做一个根据识别的人脸智能截取一定高度图片的jQuery插件，自己先使用，然后开源给其他人。随着用户的增加，我们会添加对不同版本浏览器的支持，以及添加对手机的支持。这样使用的人就会越来越多，他们也会帮我们传播，最后我们就有了一个很不错的开源项目。比起技术能力，更多的是“来自于真实的需求”以及“持续更新的毅力”，这就是做好开源项目的秘诀。

提升架构能力

架构能力和写作一样，不是能一蹴而就的东西。这里只是在理念上和大家分享下。在我看来，软件本质上是一种能力，是封装好的、可高速、廉价、重复执行的能力。我读过很多关于架构的书，也写过大大小小数百个项目，一路实践下来，个人觉得最重要原则有两个：DRY和正交性。

DRY

是Don’t Repeat Yourself的缩写，翻译过来就是“不做重复事”。这正是逼近软件本质的一个原则，它指导我们把经常使用的功能抽象成库，把重复出现的代码重构为可重用的框架模块。如果你用DRY来要求自己，很快你就会发现自己抽象和架构能力的得到飙升。

半自动化

但是我们活在现实世界，所以我们不可能把所有的事情都自动化，有人类尤其是女人参与的活动，往往会毫无规律可循。但我们不能放弃，不要二元思维，除了手动和自动，我们还可以半自动化——让机器做完所有繁杂的常规操作，人类来处理需要智慧的那一点点工作就好，这也能极大提升工作效率。

正交性

正交性的意思是，功能和功能之间应该尽可能互相不干扰。只有这样，我们才能有效地控制每个部分的行为。所以功能之间的依赖尽可能少，如果有，规则一定要明确，不要试图做一些自作聪明的事情。比如JobDeer之前的推送通知是在发布候选人时自动发的。一直用着不错，但有一天有一个候选人需要重新发布，但我们不想推送通知，这时候我们就傻眼了。这是因为发布功能和推送功能不是正交的。后来我们把发布和推送功能分开，在发布成功后，询问是否需要跳转到推送页面。这样发布人才不会影响推送；推送信息也不会依赖发布了。“Keep it simple stupid”就是这个意思。 API其实也是强化正交性的利器，它通过接口规范确定了互不影响的功能，又通过接口协议隐藏了后端实现，去除了对实现技术的依赖性。在这点上SinaAppEngine就受益匪浅。

程序员的沟通和写作