Algorithm、Review、Tip、Share 简称ARTS
1.每周至少做一个 leetcode 的算法题 2.阅读并点评至少一篇英文技术文章 3.学习至少一个技术技巧 4.分享一篇有观点和思考的技术文章
https://leetcode.com/problems/two-sum/
- 这里是使用先构造全部查找表，然后再判断查找表中是否存在(target-cur)
func twoSum(nums []int, target int) []int {
numsMap := make(map[int]int)
for i, n := range nums {
numsMap[n] = i
}
for i, n := range nums {
j, ok := numsMap[target-n]
if ok && j != i {
return []int{i, j}
}
}
return []int{}
}
- 考虑是一个排序的数组
https://leetcode.com/problems/two-sum-ii-input-array-is-sorted/
思路：排序数组总是往二分查找上靠。
思路1. 仍然是两次遍历，外层遍历数组nums,当前被处理元素用cur表示，通过二分法查找target-cur. 时间复杂度:n*logn.
思路2. 基于排序的特点. 在[l,r]中寻找和为sum的2个数.
首尾2个元素l+r与target相比,
- l+r = target, find it.
- l+r < target,那么应该再找一个更大的元素，只能是从l往后找，所以 和为targe的2个元素应该在[l+1,r].
- l+r > target,那么应该再找一个更小的元素，只能是从r往前找，所以 和为targe的2个元素应该在[l,r-1].
从实现上来说，因为不知道循环多少次，用while循环，也就是for;;
func twoSum(numbers []int, target int) []int {
n := len(numbers)
i,j:=0,n-1
for;;{
r := numbers[i] + numbers[j]
if r == target {
return []int{i+1,j+1}
}else if r > target{
j--
}else{
i++
}
}
}
目前在用流利说学习英语口语，英文文章阅读暂缓。
golang传递数组的指针 items *[]*DetailItemVO
https://stackoverflow.com/questions/36242018/golang-pointer-to-slice-and-array
包学习 https://golang.org/pkg/container/heap/
- 测试数据的准备 通过sql还是http接口呢？
Q：float64精度问题。 A： 给出来的是最终解决方案。钱这种东西，从来都不是浮点类型。 A： https://blog.csdn.net/wslyk606/article/details/81333001 go语言中float64 保留2位小数
微服务化，家庭成员获取接口，visible统一处理。
Q: mysql关于 inner join 数据重复问题 https://blog.csdn.net/qq_29498555/article/details/79695815
领域驱动架构（DDD）建模中的模型到底是什么？ - 何明璐的回答 - 知乎 https://www.zhihu.com/question/25089273/answer/69859648
这篇文章开头就和我2年左右的开发经验达成了共识，所以我继续看下去了.
拿到这个功能需求后当然是首先要详细阅读具体的业务功能需求，在阅读完后第一需要思考的不是业务流程，不是数据库表，而是首先应该思考该功能对应的核心领 域对象究竟是什么？
就我2年左右的开发经验而言，我们在需求评审环节，主要的目的都是去明确业务流程或者数据库表结构,明确之后就进行开发了。 然后再编码环节或者测试环节就会不断的去沟通，修改和新增需求，对应的也有代码改动。 这种情况下，软件开发质量，很大程度上依赖测试人员的数量和测试人员的自我要求。
但是以上开发流程还带来了一种不易直接察觉的问题，往往只有后台研发人员才能直接感受到：
当有新的需求进来时，总是觉得原来的数据库设计或者业务函数设计不合理，这些技术债务逐渐累加导致研发进度延期，同时也导致研发人员感觉很别扭。
我一直在思路这个问题的解决方法，之前有听说过DDD，是在寻找"微服务的服务拆分问题"的解决方案是了解到的概念，但是当时并没有找到可操作行强的方法和良好的精力进行实践(轻易使用微服务架构，整个研发团队已经陷入低效率困境中).
过了一段时间，我在知乎上提问："请问这个招聘要求中提到“识别业务关键需求和设计领域模型”是什么意思?" https://www.zhihu.com/question/323218441 我得到了一个很有启发的答案，我觉得我今年有可能为这个困扰多年的问题，找到一个比较满意的解决方案，所以投入一定的时间进行DDD实践。
我继续浏览了"领域驱动架构（DDD）建模中的模型到底是什么？"的回答，我觉得我目前公司的优化，可以从2方面着手
- 用mvc替代原来的只有controller
- 把数据库表设计得更合理，好像用不上DDD，就是E-R图的设计理论就可以了，把实体和联系明确就完全可以。
似乎不关DDD什么事，公司开发流程的很大问题都在需求上，一个是需求没有想清楚，第二是需求没有传递清楚，第三是需求没有被合适的代码所呈现。
很小型的系统推荐采用传统的mvc即可，将所有的业务逻辑放在service层
领域模型驱动设计适用于大型复杂的系统，需要很多领域服务协作完成的场景；很小型的系统推荐采用传统的mvc即可，将所有的业务逻辑放在service层。
举个例子，要设计一个提供"xxx叫车"服务的系统，经过分析，涉及到成员管理（司机/乘客信息）、位置服务（定位/距离计算/路径是否可达）、计费策略（怎么收费，搞营销时怎么退费）、任务单分配（根据司机乘客距离等分发任务）等等等。
编程时，一般会分为 业务逻辑层、领域服务层、数据层，一个典型的好处是如下：领域服务层专注于该领域的服务实现，能够灵活应对各种业务变化而不需大幅度修改xxx系统的主流程代码。
例如，要修改收费标准只需调整"计费领域"，要修改任务单策略，"任务单分配领域"调整即可；业务逻辑层则关注于主流程，使用并协调各领域开放的服务；
作者：沐剑君
链接：https://www.zhihu.com/question/25089273/answer/83018346
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。