Code Review(一)

来源:互联网 发布:mac下的数据库软件 编辑:程序博客网 时间:2024/05/01 18:14
"

1.       尽可能减少return的次数,同时避免不必要的重复逻辑处理

    public boolean isWIFIOpened() {        if (mWifiManager.isWifiEnabled()){            returntrue;        }else{            returnfalse;        }    }

    改为

   public boolean isWIFIOpened() {        returnmWifiManager.isWifiEnabled();    }


2.       把不同逻辑下相同的代码提取了出来,避免重复,提高阅读性


3.       使用String进行数据拼装过于繁琐,之后再进行反向解析耗费时间,可考虑用整形数组等其他方式替代;尽量避免使用String作为比较逻辑处理,可使用int数值等方式替代;数据优先,延迟实现,数据的处理应该放在首要位置,数据处理完了在进行UI的显示处理;原始数据需要保存下来,参数传递时都使用原值传递;星期数的提取可以使用XML进行中英文适配;当有需要进行数据适配时可以使用XML文件匹配相应的要显示的值,同时如果有需要可以把原始的值保存到相应的XML文件中


4.       变量以及函数的命名要更有意义,要有明显的区分,不能混淆,避免使用My等命名方式,WIFI应该命名为Wifi;方法与参数的命名要统一,相同类别的参数可以加上相同的前缀,格式整体一致;命名应该避免与系统的API或者类名重复


5.       善用系统API,自己写重复代码不仅效率低而且需要承担风险,比如判断字符串是否为空等等

使用系统isEmpty()函数判断字符串是否为空

使用String.format()函数为时间值自动补0


6.       层级与层级之间避免耦合,每层要有自己的判断,不能依赖于其他层的代码


7.       成员变量数量不宜过多,如果不是重复被调用的,仅作一次性使用的不应作为成员变量定义,变量的作用域不应太大,应该只在他使用的范围内定义

多次使用的变量依旧用作成员变量,一次性使用的全部挪到相应的作用域内


8.       使用反射机制时需要考虑版本的风险,有可能有的版本没有所需要反射的类或者方法等

由于项目中使用了Connectivity类的反射,但是暂时没有找到Connectivity类以及其中的方法有与版本相关的信息,还在查找资料中,后续确认了补上。


9.       数据库操作需要考虑并行问题

目前还没实践过,之后补上


10.    自定义类统一放置底部,静态变量统一放置顶部


11.    AlarmManager如果没有设置重复闹钟那么在定时激活后系统将会自动cancel掉,不需要手动进行cancel


12.    可以尝试直接使用AlarmManager直接进行定时处理从而避免使用多余的类以及数据库操作等繁琐的处理


13.    Fragment的数量要进行控制,避免过于碎片化


14.    HappyPath

Happy Path Test是指在测试中仅对用户的正常操作流程进行处理,这个处理的路径就是Happy Path,在代码编写过程中,举个例子,在逻辑处理方面中的必须按照正常逻辑思维去处理,顺序应该是如果满足条件系统去做什么事,不满足条件系统去做什么事,而不应该变成不满足条件系统去做什么事,满足条件系统才去做什么事,这不符合正常逻辑思维


15.    将String类型值统一放入String.xml中进行统一资源管理

目前在类中存放的只有更适合放置在本类中的例如星期的中文写法,并且也只在本类中使用从而较好维护的字符串,其余的都已归入Stirng.xml中统一管理


16.    UI提示应与逻辑处理进行分离,不应写在同一个函数中,避免耦合

将UI提示从逻辑处理函数中抽取出来


17.    需要对ListView进行优化

目前使用复用缓存中的view对象实现,用holder的方式正在学习中,后续补上

"
0 0
原创粉丝点击