小米便签精读

目的

• 关键用例的顺序图和详细类图：通过绘制顺序图和详细类图理解关键用例的实现过程。
• 精读部分的代码标注：通过对代码进行标注加深与评估对代码的理解程度。
• 代码编写规范和编程技巧分析，包括是否存在不符合或者不规范的代码部分，是否符合模块化设计思想，是否对可能出现的异常进行了处理，请具体指出。（提示：利用SonarQube，FindBugs等工具+人工检查，进行代码质量分析，从程序的语法、结构、接口等方面进行代码审查，并对代码风格进行分析。）

用例的顺序图和详细类图

• 顺序图：（自己画的可能存在错误）
  
  
  
  
  
  
• 类图：（利用插件生成）
  
  
  
  

精读部分的代码标注

• 仓库链接：https://gitee.com/GoodNanmu/xiaomi-notes-extensive-reading

代码编写规范和编程技巧分析

• 使用spotbugs
  
  了解一下spotbugs主要包括的10大类bug：
  1.Bad practice（90余种）不良的实践，违反常识性的或者必要的代码惯例，比如重写了equals却没有重写hashcode。
  2.Correctness （150余种） 此处的代码有可能在运行时导致错误，与预期不符，比如空指针错误。
  3.Experimental（9种）spotbugs在此处不适用，大概是匹配模式不太适用于此处。
  4.Internationalization（2种）原文是：code flaws having to do with internationalization and locale，没有遇到过类似的错误。
  5.Malicious code vulnerability（17种）代码具有被恶意代码攻击的风险。比如返回一个可变类型引用并保存在对象字段中。
  6.Multithreaded correctness（46种）线程安全，比如可能造成死锁的代码。
  7.Bogus random noise（4种）并不是软件中的实际错误。
  8.Performance（37种）性能不好的代码，比如在迭代中使用“+”连接字符串。
  9.Security（11种）使用了不安全的外部输入，可能导致远程控制的漏洞。
  10.Dodgy（87种）导致自身混乱的代码
  1） 语法审查：

• 检查代码是否符合编程语言的语法规范，是否有拼写错误、语法错误等。
  这块存在的错误不少
  
  2）结构审查：

• 检查代码的结构是否清晰，是否符合设计原则和最佳实践。

• 检查代码的模块化程度，是否遵循单一职责原则，是否存在过于复杂的函数或类。

  通读代码，发现各个模块化程度高，代码结构清晰（可读性很高）

3）接口审查：

• 检查代码之间的接口是否清晰定义，是否符合规范。
• 检查接口的参数和返回类型是否合理，是否易于理解和使用。
  这块的错误就相对较少
  
  小米便签开源代码风格良好。可以从一下几点看出来：
  从缩进和格式：代码应该有统一的缩进风格，代码块的大括号应该有明确的缩进，以便于阅读。
  命名规范：变量、函数、类等命名应该具有描述性，能够清晰表达其用途和含义。
  函数和类的设计：函数和类具有清晰的功能和职责，并遵循单一职责原则。函数短小精悍。
  异常处理：代码具有良好的异常处理机制，能够捕获和处理可能出现的异常情况，以确保代码的稳定性和可靠性。
  也有可惜的地方：注释不够完善

心得

• 检测代码阶段：
  刚刚开始精读任务就出师不利，在代码下载代码质量工具这一块我们就遇到了不小的挑战。不得不感叹一句，万事开头难。首先是对SonarQube的安装，很不幸，只要我们一点击StartSonar.bat就会立马闪退。此时就轮到我们的logs文件登场（因为前面的窗口一直闪退，发现不了原因），经过对es.log的查看，发现了是端口占用的问题，进而得到了解决。时至今日，再次对日志的重要性有了体悟——没有这个日志文件，我们可能会一直云里雾里，找不到解决的办法。希望我们在以后的开发中，在这些个方面也能够积极得向这些成熟的软件看齐。经过千辛万苦的配置，终于是在最后取得了成功。其实中间也坚持不住了，尝试寻找了其他的检测代码软件，比如FindBugs，但是很可惜这个版本的插件又不能和我的Android Studio的版本兼容，最后发现了SpotBugs这个小插件能够和我的AS版本很好的兼容。软件之间的兼容问题真的有着大学问！
• 代码精度阶段：
  本以为万事开头难，没想到接下来也不太轻松。3000行的代码量可不小，为了节省时间，分工先行才是明智之举，我们选择分别对不同的功能代码进行通读并注释，最后坐在一起对着3000行的代码理解进行汇总（分别做对方的领航人）。这一块的效率提升十分明显，可以比喻成这样一种状况：自己通读代码，就像走在布满荆棘的路上，显然是寸步难行的；然而队友带着你通读等于她已经披荆斩棘为你杀出了一条康庄大道。
  同时在分开通读的过程中，我们都意识到了代码规范的重要性。好的代码通过函数名我们就已经大体知道了该函数的功能。这也是我们每个代码人需要好好学习的。
• 画图阶段：
  在画顺序图的时候，因为刚刚开始入门，我们一直很难下笔，但是成功画完第一个图的时候，我们好像才真正的对顺序图的作用和以及如何去画有了深刻的理解并逐渐有了种行云流水的感觉——果然实践出真知，比起看一万次不如动手做一次。正当我们沾沾自喜的时候，看到详细类图的要求我们却犯了难，在一些个类中，先不提类中的属性的多少，单单是方法就多达二十几个，用人力去画感觉还是十分困难的——耗时耗心力。那么我们当然要巧用工具，运用好市面上的自动生成类图的工具，我们选择了Skatch it!+PlantUML的模式（比起code iris与simpleUML感觉更加详细些更加美观些）。
• 总结：
  如果在工程量不大的情况下，一个人行动或许会更加自由些；但是随着工程量的增大，合作势在必得。结对编程在我们想得到的地方（工作效率）和想不到的地方（两个人在情绪上的帮扶）都发挥了1+1>2的力量。