ARTS 是 左耳朵耗子 提出来的一个打卡任务。每周一个 Algorithm，Review 一篇英文文章，总结一个工作中的技术 Tip，以及 Share 一个传递价值观的东西！我希望这个事可以给大家得到相应的算法、代码、技术和影响力的训练。

这是我的第八周打卡。这周在使用Elixir函数式编程的时候，发现由于函数式编程本身的特点，之前很多使用迭代来解决问题的思路都需要通过递归来解决。通过对递归的专项训练，掌握了一些递归算法的基本套路。

🤖 Algorithm

二叉树的坡度

📖 Review

Presentation Domain Data Layering

这篇文章是Martin Fowler关于三层架构的一个讲解。一个最基本的web架构，通常会垂直划分为表示层、业务层和数据层。关于三层架构，很多人会把它跟MVC搞混，之前专门写了一篇文章介绍过它们的区别。

在我们实际应用中，由于业务的复杂性，我们会划分出更多的层，比如domain和data access之间使用Data Mapper可以让领域层不依赖于数据源。这样我们在切换数据源时就比较容易了。很多web框架基本上都会有ORM，它们的实现分为Data Mapper和Active Record这两种。有时间可以研究一下它们两种不同实现的差异。

后面又提到BFF，作为专门为前端业务实现的后端，我们可以把它视作表示层。很多公司会选择使用nodejs来作为BFF服务，它其实做的事情也蛮多的，比如我们可以借助graphql来做数据聚合等等。但它本身应该是一个很薄的层，而且不应该涉及到具体的业务规则。

我觉得这篇文章最重要的还是后面提到的关于架构的一个水平拆分。直接在顶层模块上使用垂直拆分对于一个复杂的应用来说并不是很好。一方面它会把团队给割裂开来，形成前端团队、后端团队这样的局面。国内很多公司目前的现状就是如此，这样的话整个领域的语言其实是不完整的，团队的信息也不对称，前端没有话语权等等问题都暴露出来了。另一方面，基于这样的设计，业务本身的拆解粒度也会过大。

在顶层模块上使用水平拆分可以把一个复杂的系统拆解成若干个不同的模块，对于每个模块的实现我们可以组织若干个跨职能的团队。一个团队应该是full-stack的，而不是前端凑一块，后端凑一块。这是组织层面的拆分。在架构层面，我们的设计应该是遵循Module-based而不是file-based的思想。

💡 Tip

使用 Typora + picgo 来打造极致的写作体验

作为一个经常写作的博主来说，怎么舒适地写作一直是我的一个痛点，因为市面上的工具总是不能达到自己想要的结果。其实我的需求也就以下几点：

1. 能比较好的支持 Markdown 语法
2. 能自定义 Markdown 显示风格
3. 文章中的图片能上传到自己的图床
4. 能够同步到印象云笔记

之前一直都是使用Cmd Markdown来作为写作工具，它不好的一点就是不支持上传图片到自己的图床。对于图片的存储我一直都是有顾虑的，总觉得小众软件不太靠谱。后来发现Typora和PicGo这个组合刚好解决了我困扰已久的问题。

Typora可以自定义主题和设置上传图片的服务。PicGo我们配置一下自己的图床就可以了，还可以下载super-prefix的插件，配置上传图片的文件名。

"picgoPlugins": {
    "picgo-plugin-super-prefix": true
  },
  "picgo-plugin-super-prefix": {
    "fileFormat": "YYYYMMDDHHmmsss",
    "prefixFormat": "YYYY/MM/DD/"
},

参考：

1. PicGo：免费搭建个人图床

💎 Share

分享文章：掌握这些套路，轻松解决递归算法问题