Algorithm、Review、Tip、Share 简称ARTS
1.每周至少做一个 leetcode 的算法题 2.阅读并点评至少一篇英文技术文章 3.学习至少一个技术技巧 4.分享一篇有观点和思考的技术文章
TODO 改善包含数据库操作的测试流程，引入必要的测试。 因为测试对业务最熟悉，可以考虑需求阶段或编码阶段，向测试多请教，给出最基本的测试情况。
完成：crud， 需求-数据库设计阶段的流程化的开发总结。 如何快速理解需求。 实体模型，一般的模型总结。 如何快速根据需求，完成数据库设计。
checklist: 心算一遍，该数据库设计能否实现主要需求点。 根据需求文档的需求点，过一遍思路。 如何事情较多，可以简单写一下文字步骤。
太复杂，需要讨论的就化流程图。
https://leetcode.com/problems/two-sum/
-
怎么想到的 这是一个查找问题，固定一个元素，查找单个元素是否存在。 查询范围可以考虑查找表，正好可以使用。 想到能否用哈希表，每遍历到一个元素num，看target-num是否在hash表中，如果在就得出答案，如果不在就将当前num放入哈希表中。
-
查找表思路的实现：
构造完整查找表后再逐个处理or边检查将构造查找表。
一开始想构建全部元素的查找表，后来发现可以每次处理一个元素，然后根据是否查找到当前元素的匹配元素，再判断是找到了，还是将当前元素插入查找表
func twoSum(nums []int, target int) []int {
// k:item of nums, v:index of nums
t := make(map[int]int)
for i,v := range nums{
if index,exist := t[target-v]; exist{
return []int{index,i}
}else{ // no found,put into search table
t[v] = i
}
}
return []int{}
}
目前在用流利说学习英语口语，英文文章阅读暂缓。
Q： 数据库设计，为了查询而冗余2份数据，导致数据不一致的问题。 A：以后将不同实体的数据分开存储，通过外键联系，多查询一次即可。
-
总结：内容多少： 取决于页面需要的内容+单一原则。
-
过小，思考接口是否可以合并在一起。
实例：风险测评接口合并。
风险测评准备页(家庭成员信息memberInfo+风险测评data)+评论列表页(风险测评result) => memberInfo + data + result.
合并的依据：用户进入，如果已经测评，会进入评测列表页，那么需要用到memberinfo+result，如果要重新测评需要用到data，所以都返回就好了，这样重新测评就不用再请求接口了。
- 过大,接口可以按照页面拆分。一个页面一个接口。
实例：家庭保障方案接口拆分.
本来只有一个接口，detail数据如果用户不点击按钮，就不要给前端，所有把详情页接口拆分出来。
拆分依据： 如果客户端有一定可能用不到，那就不传递。
- 接口按照实体拆分 家庭成员和家庭保障方案，风险测评数据都应该拆分开来，通过多个接口进行获取，最大限度复用已有接口。
A: 关注实体的生命周期 https://www.zhihu.com/question/323218441
需要去阅读书籍有：<实战领域驱动设计>
- 知识掌握的七个境界
- 第一重境界：撸串境界
- 第二重境界：关键词境界
- 第三重境界：原理境界
- 第四重境界：实践境界
Q: 对于算法知识的掌握，有没有必要进入实践境界？
我的答案是：太有必要了。因为，这是计算机专业跟非计算机专业的本质区别。也是你能吃这碗饭，别人不能吃这碗饭的关键。 所以，大家在具体学习的时候，一定要明白：我是计算机专业的，能实现出来，才是我的立身之本。
- 第五重境界：灵活应用境界 比如对二分查找，各种场景都可以反应过来可以使用二分查找进行处理.