2020-01-27还学到什么：
1.一下子想搞个例子讲这些真的太难了，拍着脑子想demo。栏主这个demo背景简单，也将要讲的内容串起来了，实属不易，幸苦栏主了。
个人见解：
1.按我的习惯，我会尽量把入参和中间不可靠变量的异常校验都放在public方法，所有私有方法都以契约的方式不再做参数校验。也就是说 public方法干 1.参数校验 2. 系统一级流程编排 3.统一异常处理 这三件事。所以对private方法的提炼会和栏主有点出入。
2.如果这个id生成器还要带有业务key，比如分表路由key之类的东西。那么这个实现就还得大动干戈。但凡这种涉及持久数据的玩意，很可能需要考虑新老版本兼容的问题，也就是如何平滑过度老数据。所以需要在id生成算法上引入版本或者类型的标记，把标记打在持久化的数据上，以备平滑过度老数据。展开作者回复: 我觉得你懂我~
19
2020-01-28争哥这种设计思路考虑了一下，但是在业务中往往获取唯一ID的地方，不关心ID内部生成错误，需要的只是能够返回出来ID即可。目前我们的处理是异常在generate内部自己解决，同时返回ID 1 4
2020-02-01个人见解：如果 id 生成器需要应用到生产环境，类似 hostname 获取失败的问题，需要由生成器本身给出降级方案。一来为了 id 格式统一，二来假若抛给业务，业务对于这种系统底层的失败，也没有什么好的解决方法。 2
2020-01-27打卡，也祝大家新年快乐，身体健康，另外我始终觉得generateRandomAlphameric这个函数里，随机获取这个写法很不利于性能测试，假如这个函数会被百万，甚至千万次的调用，不可控性也太强了，我觉得可以改成随机生成0-26的数字，对应去加到字母的位置，不知道老师和大家有什么想法吗 2
2020-02-07设计模式_37:
刚刚看了一下，这4篇文章，我做了14条笔记，这些东西都是我认为非常好的细节。
随便举一个例子:
```
使用注解 @VisibleForTesting 来表示某private方法改为protected只是为了便于单元测试。
```
很喜欢这样的细节，当时的感受是，这种规范的做法是非常好的习惯，读起来非常友好。
剩下的也都差不多，我自己的开发中是注意不到的，缺乏这样的智慧。
另外，我也非常同意 @Jxin 同学的说法，找到一个Demo，能够涵盖绝大多数的要点，同时例子不能很生僻，并且让别人容易看懂。我也经常写文章，我知道这里的困哪和工作量。
佩服争哥！展开 1
2020-01-28还学到了：
1.函数出错时是返回NULL还是异常对象？
要看获取不到数据是正常行为，还是异常行为，如果业务上来说是异常行为就抛出异常，反之返回NULL。
2.是直接返回出错的异常还是重新封装成新的异常？
要看函数跟异常是否有业务相关性。相关的话就直接抛出。不相关就包装成与函数相关的异常类型，而且这样也能隐藏实现细节。
3.NULL值或空字符串在什么时候需要判断？
a.如果函数是 private 类私有的，只在类内部被调用，完全在你自己的掌控之下，自己保证在调用这个 private 函数的时候，不要传递 NULL 值或空字符串就可以了。
b.如果函数是 public 的，你无法掌控会被谁调用以及如何调用（有可能某个同事一时疏忽，传递进了 NULL 值，这种情况也是存在的），为了尽可能提高代码的健壮性，我们最好是在 public 函数中做 NULL 值或空字符串的判断。
c.但是单元测试会测试一些corner case，所以，最好也加上判断。
4.个人的一点思考
如果代码中报的错是受检异常就可以针对具体情况来处理是throws出去、吞掉还是包装新的异常。如果报的错是非受检异常我还是习惯内部自己处理，因为非受检异常throws出去的话，调用方不处理，编译器也不会报错，所以，为了防止调用方未处理的情况，还是自己内部处理吧。展开 1 1
2020-01-27今天学习了异常代码处理思路。在处理到异常时，通常会将上层关心的异常直接包装成RuntimeException往上抛，没有根据业务域定义相关的自定义异常。通过今天的学习，了解到处理异常的基本思路：是往上抛还是吞掉，主要看调用者是够关心该异常。是否要包装成新的异常主要看调用者是否理解该异常，该异常是否业务相关。如果能理解、业务相关可以直接抛，否则重新包装。
在这4节课的持续迭代过程中，除了文章中提到的开发思想，自己总结了如下一些个人想法：
1. 科比说过“我现在所做的一切，都是为了追求更加完美” - 缅怀逝去的伟大的科比。我们对生活，工作都要尽量追求完美。
2. 人生是个不断重构自己的过程，自己写的代码也要不断持续重构，优化。这样自己才能不断进步。
3. 参考优秀的开发思想，方法论，不断地将之实践，总结，改进，逐渐形成合适自己的方法论。展开 1
2020-01-27希望老师每节课举的代码有下载的地方，自己下载下来结合老师讲解的，自己理解体会其中的解决问题作者回复: 好的，等我俩月，我整理好，一块放到github上：
https://github.com/wangzheng0822 1
2020-01-27设计之所以难是因为没有标准答案，很多权衡是依赖于具体业务的。这就是DDD的思想所在，要先想清楚问题域是什么在思考解决方案。很多开发讨论问题的时候没有层次，上来就陷入技术细节，这就叫缺乏抽象。下游系统要想清楚哪些是上游系统给你提供的服务？哪些是人家的内部技术实现？比如ID生成，作为上游系统，ID生成服务提供的是有小概率重复的随机ID服务，至于随机算法，下游系统不必关心，这是上游系统的内部实现，这样上游系统才有空间更换算法而不影响下游系统。 1- 2020-01-27果然还是看技术文章能让恐慌的心静下来 1
2020-02-07从这个迭代重构的过程中，你还学到哪些更有价值的东西？
学会了分析过程和思想道理,咸鱼与高手的本质区别,
学到了学习的目的是为了代码写得更好;
还学习到了争哥的思维分析过程,先分析出存在的各类情况,哪些不会出问题,哪些会出问题,会出问题的再根据实际需求怎样处理会更好,以及这样处理好在哪里,又有什么弊端,辩证深入领悟问题,并寻找更优解;
还学会了怎样将编程思想理论落实的实践,更深入理解编程思想精髓;
还懂得了人生的哲理,有些道理早领悟,有些技能早掌握就可以享受更长时间的复利价值.
编程一代宗师,唯我王争哥!!!展开- 2020-02-07问题
重构之后的 RandomIdGenerator 代码的generate()代码中,对于generateRandomAlphameric(8)该把IllegalArgumentException封装成抽象的业务异常IdGenerationFailureException,不要将底层实现暴露给上层代码,不然这里就违背了面向抽象而非实现编程的原则. 
2020-02-05争哥你好，有两个问题想请教：
1、类中的私有成员变量在重构后，貌似没被用到了，那是否意味着可以干掉？
2、generate方法抛出的是编译时异常，那为了不影响正常的业务逻辑执行，调用它的方法都应该捕获它吧？这样就会有比较多处理异常上的冗余代码，有什么方法可以减少这类代码呢？
2020-02-03从来没有否认过争哥这个专栏的认真程度，但是对于generate方法是否抛出异常有点异议 我的想法跟下面的人是一样的 本质上这是个id生成器 是为了追踪请求错误时候用的 在这个条件下id能不能生成并不应该阻止请求的流程 假如抛出异常给调用者那调用者继续走下去 那这个抛出来的异常的价值在哪？就只是为了知道一下hostname获取不到？如果抛出异常后终止了请求 那会不会有点”小题大作“了？当然demo怎么样举都可能有不完美的地方 评论里说出来也是给其他读者一个思路而不是一味的“照搬” 而且我觉得这个专栏争哥举了那么多的demo的牛逼之处在于不仅把要讲的知识点抛砖引玉出来而且还是贴近我们的日常开发 确实是实实在在很有可能在企业里用到的案例 就比如今天这个demo 后面我就考虑在我新开发的接口添加id生成器 来追踪请求出现的问题 说实话 我并没有看过争哥的算法课程 但是看到争哥这个专栏的前言后毫不犹豫地订了 追求代码极致这一态度是争哥给我的共鸣展开
2020-02-03太棒了，打卡！
2020-02-02争哥说：我有个朋友叫小王，哈哈 2
2020-02-02小伙伴们，针对函数入参的值，里面可能含有前后空格，你们会检验么，好纠结😳- 2020-02-01以前不管啥情况就抛出个Exception搞得很懵逼！
函数和异常的业务相关性分析得很透彻，赞！ 
2020-01-30很喜欢作者对于"正常情况"和"异常情况"判定的讲解, 还有依赖抽象而不是具体的思想在以上直接上抛还是包装后上抛的分别.
2020-01-28打卡