引子

有些时候，软件开发过程中没有将系统功能，且分开从而将系统拆分为多个子系统，或者在自身系统开发过程中有必须要依赖的外部服务，那么对外提供服务的时候就得让所有的子服务都得随时候命， 排列起来就像古代战场的对战状态一样了。

go 的 import 其实是去 GOROOT 下去加载你写的模块，当然 Go 的 import 还支持如下两种方式来加载自己写的模块：

• 相对路径

  import   "./model"  //当前文件同一目录的 model 目录，但是不建议这种方式 import
  

• 绝对路径

产品的特性

• 要像牙刷，高频切实用
• 对用户一定要有价值，如谷歌搜索，反面教材如百度

协作

协作的基础是对知识点的认同

个人品牌

个人魅力，个人品牌

解决问题

阐述问题，探寻本质，给出解决方案

前言

学习 Rust 肯定离不开查看其官方或者第三方开发者的文档，而在 Rust 的 crate 中，对于开发者或者使用者，文档是非常友好的。在这就不举例了。本文主要是记录一下写 rust doc 的一些小步骤。方便日后查阅。

插曲

去年与前 ThoughtWorks 咨询师 李小波的一次线下交流中，学习到了总结知识的一点技巧，非常受用，并且在交流后得到了小波老西自己整理的知识图谱，在自己不断积累下，有文字，也又图片。最近在整理知识，同时也在乱搞知识分享平台。自己虽然有这个博客，但是感觉有些东西不是博客所能呈现的，比如思维导图，我收集的各种模型图等。

在鲁迅的文章《孔乙己》中说，茴香豆的茴字有好几种写法，记得没错的话应该是四种，具体哪四种请参考下文引用。

在 Rust 中，闭包也有好几种写法，今天就来总结一哈。

最近在做 DevOps 的工作，主要是做一个蓝绿部署的方案，在这部分中涉及到了写 shell， Shell 作为一种程序语言，那么对于开发人员肯定是要在部署到正式或者生产环境前进行调试的，在 coding 过程中，发现 shell 的调试其实和平时写的 JS, Java, Rust 等的调试不同，Shell 只能看你每一步执行的语句，至于具体执行是否正确，得由 coding 的人来写正确；好吧，有点难理解，那么我来举个🌰；

一句话的分量是否重，是要看能不能击中听者的痛点。

设计评审过程中，需要各种文档或者其他资料来辅助，在此总结一番，以供后续查阅。

• 产品 PRD：当有疑问时可以拿出来给评审者查看
• 设计分析文档：用来沟通关于行业内对于同类型功能的设计优缺点的分析
• 数据分析文档：用来展示当前版本数据上的表现和问题，以及可以帮助进行下一步改善
• 功能逻辑图：复杂功能可以使用图形化表现功能逻辑，便于评审者理解
• 用户路径图：通过用户路径讲解全局性问题，结合交互设计稿进行具体说明
• 交互动效演示文档：用来解释一些比较复杂的交互过程
• 配色情绪版：用来解释如何选择当前配色的思路

制作的思维导图存放于石墨文档，地址如下

本思维导图中大部分内容由 @haihaio^[1] 完成。

此思维导图中总结了 TDD 的概念，原则，套路，案例及策略等，不失为一份很好的学习资料。

项目地址：https://github.com/AndorLab/MindKnowledgeGraph

软件常用常新，软件大多的目的都是效率，办公，沟通，和娱乐等。虽说 Mac 也有自己的时间机器，可以随时将新机器回复到旧机器上，但是作为分享和传播，那么写一篇文章那是最有效率的了，也可为自己后期使用做备份。 最近由同事的一个脚本启发，特制做了我自己 Mac 电脑上必备的一些软件的快速安装脚本；程序员的本质就是将一切事物简单化，代码化。.. 化； 地址如下，欢迎提 PR： awesome-setup: https://github.com/guzhongren/awesome-setup^[1]