34 | 实战一（上）：通过一段ID生成器代码，学习如何发现代码质量问题

王争大佬以后课多带点实战代码

争哥，老实说，这个小王是不是曾经的你

设计模式_34 Logger的方法一般不会有未决行为，不影响可测试性，不用依赖注入。 以前看代码质量是看感觉，现在开始有章法了。

我要把这个checklist打印出来贴桌子上

这个logger没有未决行为，不影响可测试性。我之前的一篇文章里提到过，将logger对象设置成static的原因是确保日志对象每个类一份、设置成final的原因是避免日志对象在运行时被修改。https://mp.weixin.qq.com/s/1OpvN8_dzIDWYBDiICU6yw

1.split效率较低 2.随机字符的生成可用固定数组随机取数: int count = 0; String random = ""; char[] doc = { 'A', 'B', 'C', 'D', 'a', 'b', 'c','d','1','2','3' }; while (count < 8) { int index = (int) (Math.random() * doc.length); random = random + (doc[index]); count++; } System.out.println(random);

【设计模式笔记34】20200529 今天代码质量自查手册很实用，我看了评论有同学说要打印出来之类的，我觉得好东西就应该第一时间消化并想想怎么内化为自己的实践。结合前面学的设计原则和质量手册，我想了如下问题： 1、分了哪些模块，每个模块负责的事情是什么，满足单一职责么 2、具体某个模块分了哪些包，每个包放什么样的类，分类是否合理重复 3、具体到某个类，命名是否清晰简单，注释是否包含做什么、为什么做、如何做，API是否有如何用 4、类的属性有哪些，是否有魔数，属性结构是否统一，是否有非关联的属性，是否有大函数，每个函数的职责是否单一，某些函数是否可复用和抽象，是否可读 5、是否使用了设计模式，使用了什么设计模式，是否可以不用，如果非要用带来的好处是什么以及不用带来的坏处 6、如果要新增或者修改功能是否好扩展，是否满足开闭 7、某些函数是否可以复用，是否有现成的工具，强烈建议每个团队内部都有一个工具包 8、代码是否有异常会影响原有逻辑么，如果有怎么解决，想想兜底或者降级方案 9、是否有并发问题，如果出现了会有什么影响，怎么解决 10、代码是否有测试用例，是否覆盖了正常合异常的情况

争哥这一节跟马丁那本<重构>的第一章有异曲同工之妙。 如果大家觉得意犹未尽，可以尝试动手去学学重构的第一章，然后动手实践一下🤪

为什么说静态方法会影响代码的可测试性？

学完这篇文章后，体会到之前学习的东西逐渐影响到自己后面的学习。这也验证了“你努力走过的路，每一步都算数”。在读文章的过程中，自己也思考了文中提供的代码有哪些问题，但是在读完文章后，发现自己并没有像文章中罗列的那套路来思考，自己都是按照之前学习的知识想到一点是一点，没有条理，没有章法。这也提醒了我该回炉重新去回顾以前学过的知识，要不断的进行思考总结将它们在自己的大脑里留下更深的记忆，并产生相关的连接。文中罗列的两个checkList，个人感觉很好用，通过这两个checkList，从“通用的代码关注点”和“业务功能、非功能需求”这两个维度思考将之前学习到的知识点都串联起来了，使我们能够学以致用。回顾自己以前在看自己的代码和别人的代码的时候，只是简单的看一些命名是否规范，是否可读等。感觉有内功又深了一层的感觉。 对于课堂讨论，Logger对象，个人觉得并不影响测试性，它只是一个辅助手段用于打印日志。也没必要通过依赖注入的方式构造对象，这一点耦合还是可以接受的。使用依赖注入为了是解耦，将依赖类在外部创建好，通过构造函数，函数参数方式传递来给类使用。