继续"提高代码质量"
接着上文提高代码质量, 需要从这几个特点入手
1、代码重用性。2、可读性。3、可扩展性。4、可靠性。5、高内聚，低耦合。
仅仅就"可读性"去分析一下吧, 毕竟例子实在是太多了
递归的"可读性"不如while循环
递归的可读性很差, 虽然短小的递归也能读懂, 但是能用while循环去写程序, 更容易理解
观察者模式导致"可读性"更差
如果两个对象能直接调用就直接调用, 如果非要使用观察者模式监听另外一个对象, 就是给自己找麻烦. 有时候观察者模式能实现解耦的功能和监听的功能, 除此以外, 不同模块之间使用观察者模式通信, 让可读性更差. 典型的模块间使用观察者的例子有, 广播通信, Eventbus, LiveData. 如果模块之间能直接调用, 还要借助平台工具, 一定要有必要的理由.
日志打印可读性
我日志一般这种方式打印
Log.d(“ClassName”, “methodName paramName: $paramName”)
结合过往经验, 这样打印根据日志调查问题会更轻松. 一目了然.
高频的日志要用verbose级别去打印, 也就是Log.v(), 这样方便开发者过滤掉高频日志, 只看d级别以上的, 开发者尽量不用Log.e()去打印, 因为这会让日志爆红, 不方便查看系统的重要日志, 开放给开发者的最好是用debug info级别的, warn和assert不用也没关系
当然真养成这样的习惯, 看别人的代码和日志会感觉别扭, 尽量"严以律己, 宽以待人", 毕竟大家都是混口饭吃, 谁都不是老板
typo问题的可读性
集成开发环境通常会提示拼写错误, 如果确定是"专属名词"也可以让IDE避免提示, 经常为了提高效率而选择粗略的根据命名搜索过滤, 这样有可能忽略掉有些代码. typo问题已经是很低级的问题了, 因为编译器会提醒
重构本身就需要有能区别好坏代码的能力
罗翔曾经说"希望自己的孩子有分清什么是Good的能力", 他没有说"好", 而是用"Good"也就是说, 他眼中的Good不是传统意义的好.
软件程序常常讲"最佳实践", 这就是Good. 通常不会为一个可能半年就会改掉的类精心设计, 因为精心设计一个临时的类反而不是最佳实践.
区分Good和不Good是要有"评价能力", 评价本身会得罪人, 评价又属于较真的一类行为. 所以在不较真的中国文化, 这个话题不能和人聊. 记得很久以前和一个后端同事聊, 定义一个类型是用int还是用string, 后来我们得出答案, 以前的机器存储比较贵, 能用int就不用string, 现在的存储不贵, 用string表示类型增加"可读性". 但是这个结论不能分享给不在同一个层次思考的人. 大多数人思考的层次还是"完成需求"而不是"最佳实践"
跟不同思考层次的人聊天, 不仅聊不出结果, 还能聊出误解, 在只为实现功能的人眼中, 如果给他说他写的代码不是最佳实践, 他就会说他"这是很正常的操作". 举个例子, 不要给不同功能的函数起一样的名字, 哪怕他们在不同的类, 只要两个类有关联, 仅仅为了阅读的时候能够"一次性根据名字懂得它的实际功能", 因为方法的注释不一定及时的被维护. 为了软件在逐渐庞大的过程中能够保证不腐烂, 这些细微之处的"最佳实践"在复用率比较高的代码里是必要的.
对于我自己而言, 阅读别人的代码有时候代入自己的"思维惯性"可能会导致忽略别人糟糕的设计埋下的隐患. 以为所有人都像自己那样把容易出问题的地方写的更加详细更加清晰, 就会察觉到别人是真的不在乎细节处理. 这大概就是事务的两面性,
每天把自己收拾的干干净净的人可能会觉得别人的打扮会别扭. 反倒是不在乎外表的人看谁都顺眼.
可能垃圾代码更适合职场
和网友讨论过屎山, 摘录大家的看法
- 迭代快, 赚钱快. 慢了的话 屎都吃不上一口热的
- 国内架构和技术经理都被优化了
- 屎山有助于保持就业率
- 很多领导怕被替代, 故意搞成别人很难掌握的屎山. 不是能力不行
- 现在付出的成本就是以后的收益(这是反对屎山的)
- 软件分为两种, 一种是业务型, 一种是工具型(暗指有的工具类还是认真一点写)
- 越是屎山别人越无法接手
- 规避不了熵增的问题, 最终都会变成一坨屎山
- 你想想你连屎山都搞不定, 说明自己的能力还不如屎山程序员
- 说屎山只有一种可能, 自己看不懂, 能看懂的代码都不是屎
- 很多时候是需求变更导致的, 所谓重构无非就是把别人的屎山变成他自己的屎山, 而且公司还有比他代码水平更差的, 但是人家是公司的老员工, 他不敢说什么
…
