2020-01-17打卡
明天最后一天上班
就放假了 18 20
2020-01-17不要在函数中使用布尔类型的标识参数来控制内部逻辑，true 的时候走这块逻辑，false 的时候走另一块逻辑。这明显违背了单一职责原则和接口隔离原则。我建议将其拆成两个函数，可读性上也要更好。这个深有感触 2 11
2020-01-17个人以为还有善用和合理运用各个编程语言提供的语法糖和语言特性。比如Java开发，工作中有的老程序员不喜欢不适应lambda表达式，实际上合理恰当的使用lambda表达式可以让代码简洁明了 1 6
2020-01-17老师晚上好、关于代码规范这块，是不是有好的Java开发脚手架推荐呢？我发现公司的代码没有统一的脚手架，各小组重复造轮子，想规范化这块，但又不知道有哪些通用的脚手架。作者回复: 可以看下这篇文章：
https://mp.weixin.qq.com/s/0eOm3dBOlFUy8Si1_k7OAw
代码中的很多低级质量问题不需要人工去审查，java开发有很多现成的工具可以使用，比如：checkstyle，findbugs, pmd, jacaco, sonar等。
Checkstyle,findbugs,pmd是静态代码分析工具，通过分析源代码或者字节码，找出代码的缺陷，比如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。三者都可以集成到gradle等构建工具中。
Jacoco是一种单元测试覆盖率统计工具，也可以集成到gradle等构建工具中，可以生成漂亮的测试覆盖率统计报表，同时Eclipse提供了插件可以EclEmma可以直观的在IDE中查看单元测试的覆盖情况。
Sonar Sonar 是一个用于代码质量管理的平台。可以在一个统一的平台上显示管理静态分析，单元测试覆盖率等质量报告。 3 5
2020-01-17一般大公司都有自己的编程规范，但执行的效果取决于commiter，而最终还是项目交付进度决定的。 1 5
2020-01-17课堂讨论:
简单说一个本人常用的改善项目可读性的方法:
在每一个module/package下编写一个description.md,简要说明是做什么的,有哪些需要注意的地方.
不会花很多时间,但可以提高项目整体的可维护性.展开 3
2020-01-17作为一名phper，这里有很多话想说，但是最后汇成一句话，没有什么参数不是一个数组不能解决的。解决函数嵌套那块，挺实用的。 7 3
2020-01-181.先提问题：
第一块代码里面，存在一点瑕疵:if (calendar.get(Calendar.DAY_OF_MONTH) == 1) { return true; } return false;
直接 return calendar.get(Calendar.DAY_OF_MONTH) == 1 ; 即可。
2.请老师谈谈你的看法
A.boolean isSummer = date.after(SUMMER_START)&&date.before(SUMMER_END);if (isSummer){}；
这个场景是定义“isSummer”这个临时变量，还是if(date.after(SUMMER_START)&&date.before(SUMMER_END)){};好点。
看过<重构>第三版，里面其实偏向于用函数代替临时变量（变量是魔鬼）。但这可能就会有这种if里面包含比较长的函数调用的场景，可读性其实不好，有点做了两件事的味道。但在代码重构上是比较好的，毕竟没有变量滥用带来的不确定性。拿捏不准，我最后是跟着<重构>的思路走。但这里特请栏主谈谈自己的看法。
B.boolean isSummer = date.after(SUMMER_START)&&date.before(SUMMER_END); 是否需要写成final boolean isSummer。我的习惯对不可变临时变量都会加final，事实上我基本没有可变临时变量，对可变临时变量很敏感。final会导致语句行变长，但能规范代码，具有明确语义，方便其他人阅读和扩展（约束了行为）。这个也拿捏不准，栏主怎么看？
C.类中成员属性按字母大小顺序排列。这个感觉不是很合理。拿订单类为例，我会让金额相关字段，地址相关字段，和状态相关字段分隔开各自聚合在一块。这时候就没办法按字母大小排，但语义更强。当然，对金额和地址字段，其实属于值对象，可以单独成类（存对象序列化）。但老项目难有这种设计，往往是一张表平级包含一切。所以这个按大小排序的规范，感觉太“任性”了。
3.其他编程规范，篇幅有限，而且是死的东西，不罗列了。感兴趣的同学有时间看看<Effective java>（一礼拜），没时间就看看<阿里开发手册>（2小时）。平时工作重视Sonar的每个告警，慢慢积累就好了。展开 2
2020-01-17for里面有时候会出现下标0的特殊判断，这个时候就把0下标单独拉出去玩，for从下标1开始。
我发现我的代码风格居然和争哥有点像，我仿佛在膨胀😁 2- 2020-01-30老师公司制定的统一编码规范长什么样子，能不能供大家学习学习 1
2020-01-18感谢争哥分享
文中提交的技巧都是实际工作中code的原则，可以作为CR时代码规范项的参考标准。
以前经常踩 问题3 的，主要理论依据就是对外隐藏更多的细节，但违反了单一职责。
还有更多的代码规约方面的， Google Java代码规约 和 Alibaba Java 代码开发规范 其实都可以作为案头必备手册了，安利一下。 1
2020-01-17设计模式_33
使用参数作为控制逻辑，这一点深有感触，除了故意设计成这样，还有一些是改成这样的(不想改程序结构，或者不能改)，在原来的基础上扩展功能，这样加一个用于控制逻辑的参数，程序就分成了两部分；如果后面再加，代码分成2^n个部分，而是会有大量的重复代码，同一个逻辑要该好几个地方，很容易忘。
对于代码质量，我有些个人的心得就是：写完代码之后，再看看，如果发现“不舒服”的地方，多想一想。 1
2020-01-171.命名长度问题
2.利用上下文简化命名
3.命名要可读，可搜索
4.如何命名接口和抽象类
5.注释应该怎么写
6.注释是不是越多越好
7.类和函数多大才合适
8.一行代码多长才合适
9.善于用空行分隔符
10.缩进是两格还是四格
11.大括号是否需要另起一行
12.类中成员的排列顺序
13.代码应该分割成更小的单元块
14.函数参数不要过多
15.不要用函数参数来控制逻辑
16.函数设计要职责单一
17.移除过深的嵌套
18.学会使用解释性变量
19.
20.统一编码规范
这些都是开发过程中，让代码更好的一些编码规范
我自己在项目开发过程中也会时刻注意是否符合规范。
自己在项目中还遇到很多人提交代码不写注释，
因为重构很多注释掉的代码不删除
重复代码不提取公共类
临时代码随意修改，随意提交线上等等很多代码混乱问题。
从自身做起，让代码更加整洁，提交的代码尽量减少代码的坏味道。展开 2 1
2020-01-17函数中不要使用参数来做代码执行逻辑的控制。我之前写代码从来没关注到这点，学习了 1 1
2020-02-08对于不要把控制逻辑参数暴露出来，而是拆分成多个方案。这个点。我有点疑惑。
1. 比方说有个组织查询组织下人的抽象，暴露了listUserByNode()的接口
2. 组织包括(部门-员工),(班级-学生),由于某种原因，有4张表，部门表，员工，班级，学生。
3. 如果我只想查询学生的时候 调用 listUserByNode()，传入type=student，但是由于底层表是分离的，实际上执行了另一段代码。只不过调用方认为这只是个筛选条件。
还有是最近在看Dubbo，dubbo里面用的 spi机制，我感觉也是把控制留给了参数，实现对外代码通用。只不过它是用多态实现，我们有时候方法逻辑简单。就用if...else解决了。这点不是特别能理解。展开
2020-01-24打卡30:今日学习《设计模式之美》第33节，主要收获是：复习了改善代码可读性的编程技巧
1. 避免多层嵌套、避免复杂的逻辑控制关系，移除过深的嵌套层次，方法包括：去掉多余的 if 或 else 语句，使用 continue、break、return 关键字提前退出嵌套，调整执行顺序来减少嵌套，将部分嵌套逻辑抽象成函数。
2. 函数的职责要单一，避免用boolean变量做参数控制函数内部的逻辑
3. 尽量抽取出不相关的子问题
4. 配合《编写可读代码的艺术》和《代码整洁之道》一起阅读更好展开- 2020-01-22英雄所见略同。除了每行缩进不一样之外，其他全部一致。能跟这样的人一起工作是最幸福的事。
2020-01-21关于Java代码规范这块建议参考《阿里巴巴Java开发手册》，每个点都比较细
2020-01-21关于代码可读性，除非公司导入了提供统一的布局配置文件，否则绝对不要用 IDE 的全选代码再自动格式化。我以前有个 leader 就是这么干的，后来他就转行了。
2020-01-19最后一节课里的很多小细节我都是对号入座了，这也就间接说明我来了，是一件正确的事情。
来这里，把很多对号入座的错误都找出来，并一一改进，那我还有什么遗憾的呢