Question

架构能力和写作一样，不是能一蹴而就的东西。这里只是在理念上和大家分享下。

在我看来，软件本质上是一种能力，是封装好的、可高速、廉价、重复执行的能力。

我读过很多关于架构的书，也写过数百个大大小小的项目，一路实践下来，个人觉得最重要有两个原则，DRY和正交性。

DRY

DRY是Don't Repeat Yourself的缩写，翻译过来就是「不做重复事」。

这正是一个逼近软件本质的原则，它指导我们把经常使用的功能抽象成库，把重复出现的代码重构为可重用的框架模块。如果你用DRY来要求自己，很快你就会发现自己抽象和架构能力的飙升。

半自动化

但是我们活在现实世界，所以我们不可能把所有的事情都给自动化了，有人类尤其是女人参与的活动，往往会毫无规律可循。

但我们不能放弃，不要二元思维，除了手动和自动，我们还可以半自动化——让机器做完所有繁杂的常规操作，人类来处理需要智慧的那一点点工作就好，这也能极大的提升工作效率。

正交性

正交性的意思是，功能和功能之间应该尽可能不互相干扰。只有这样，我们才能有效地控制每个部分的行为。所以功能之间的依赖尽可能少，如果有，规则一定要明确，不要试图去做一些自作聪明的事情。

比如JobDeer之前的推送通知是在候选人发布时自动发的。一直用着不错，但有一天有一个候选人需要重新发布，但我们不想推送通知，这时候我们就傻眼了。这是因为发布功能和推送功能不是正交的。

后来我们把发布和推送功能分开，在发布成功后，询问是否需要跳转到推送页面。这样发布人才不会影响推送；推送信息也不会依赖发布了。Keep it simple stupid就是这个意思。

API其实也是强化正交性的利器，它通过接口规范确定了互不影响的功能，又通过接口协议隐藏了后端实现，去除了对实现技术的依赖性。SAE在这点上就受益匪浅。

操作篇

本篇开始讲求职过程中的实际操作。