南昌航空大学-软件学院-24201911-杨亿淼第二次blog作业

一、前言
——总结三次题目集的知识点、题量、难度等情况
·关于知识点
本次航班的题目主要考察的是总体设计思路和统筹框架，考察了类的设计，继承和多态的使用。这次的航班从客户、收件人、发件人、货物、订单、航班几个方面考察，然后进行第一次的简单设计，老师在第一次发布题目时就说，只要第一次设计的合理，后面迭代特别容易，而后的迭代，就是在第一次合理的设计的基础上进行修改。
·关于难度
这一次的题目的侧重点在结构设计上，难度相较于上次的电梯的迭代，简单了不止一点，没有算法的考察，写起来比较轻松，时间花费的也比较少。但是还是在有些地方卡住了，以后还是要多花时间训练。
二：设计与分析
第一次航班类图：

这一次的类设计比较明了，父类为person，用来当做收获和发货人和客户的父类，第一直观的感受到继承的最大作用，极大地方便了后面代码的书写，其中，我又把航班订单类，和货物的计算分开来，这样的话更加便利的处理各种情况。
在开始时，我将打印放在了bill类里面，然后就感受到了恐怖的一件事————bill类的代码量太大了，于是我把它单独拎出来，封装了一个类。
同样的，货物的计算开始也是放在了commmodity类里面，计算就会出现各种各样的问题。然后我在写的时候，就只盯着commodity这个类里面的货物进行考虑，没有再纠结计费的问题，然后把计算单独拎出来进行编写。
从效果上来看，这两个举动无疑是为下次迭代打下了非常好的基础，不出我所料，下一次果然从计费方式和客户下手了，同时也想到老师说的一句话“第一次的类设计的更合理，第二次迭代时就会越轻松”，果然不诚欺我。
复杂度分析：

·根据六维雷达图来看的话，这一次的航班程序并不算复杂，分支语句只占了3.7%，比上次电梯的语句少了不知道多少，最大复杂度也特别小，也是得益于这次的题目比较简单吧，所有的深度和方法数，都控制在了一个小的范围。但是在我感觉，main函数输入那一段还是太过于臃肿了，但是因为题目要求，又不得不这样做。
根据柱状图来看，main函数里面的输入语句太多了，导致了深度特别高。许多的输入全塞进了main函数里。
其中严谨性还是一个大问题，输入的格式还是没有特别严谨，只是输入进去了，但是没有去检查是否正确，然后出现的现象就是哪里错了改哪里，好迁就的，没有真正的以高标准要求自己。
其中一个很致命的东西是，注释语句太少了，平常没有写注释的习惯，注释量只有%6。导致在第二修改的时候压根看不懂一些方法，在第一次写的时候还记得清清楚楚，过了一周再看就如同陌生人。
从总体效果上来说，这次的复杂度还在我的心里承受范围内，原来想着又会不会像上次一样复杂出天际，因为我只是从结构上进行优化，但是类里面的许多方法都没有仔细考量，用着最最最简单的方式进行编写，代码量就挺大的。

这两个方法就是计算重量的核心计算，用来比较两个重量的较大的那个然后返回计算费用，来一次性处理这个订单。实际上我在写的时候，因为连个重量分不清哪个是那个，搞混了好多好多次，最后加上了变量名的前缀，还是搞不明白，导致好多次的输出都是空白，要不就是对不上重量。研究了好大一会才把这个搓出来。
第二次航班类图：

在开始迭代时，我没有看到题目要求，没有对客户和货物做继承，只是又添加了一个属性，来标记类的类型，在改之后发现，这样的话，每一次都要做一次判断，这样的话感到好麻烦好麻烦，于是乎，我放弃了原来改了一大半的代码，又找回原来的第一次的程序，重新进行编写。
在重新编写时，我开始对计算方法，客户，和商品都做了继承，大大节省了时间和精力。在危险品货物，加急货物，普通货物做了严格的区分，使得对费率的计算更加方便。
其中有一个非常致命的点，知道改完了进行测试用例的测试了，才发现输出对不上。又重新看了一遍pdf文档题目要求，才发现个人和团队是有打折要求的，当时我人感觉都要裂开了，又重新进行找位置，进行添加，然后去重新规划布局，才完成了个人和团队的布局，人都要麻了。
复杂度分析：

这一次迭代的复杂度上升了一点，因为要处理更多的情况，其中，最致命的注释还是没有解决，只占了总代码的6.7%，其中平均复杂度和最大复杂度太大了，原因主要是在show方法里添加了对情况的判断，没有单独拎出来封装。
其中好几次都把rate的几个类型给搞错了，导致输出错误。
三：踩坑心得
1、最主要也是最重要的一点，不要当眼瞎淼，不要当眼瞎淼，不要当眼瞎淼！最重要的事情要说三遍，无论是第一次还是第二次，因为眼瞎，没有看清楚文件题目要求，出现了好多不得理解的错误，就比如，支付方式的命名，APLiPay看成了ApliPay，改半天不知道哪里错了，微信支付也一样，Wechat看成了WeChat，这种奇奇怪怪的错误。
2、不要着急编码，先看思路的合理性，在第二次的迭代过程中，看到要求对客户支付方式和货物进行继承处理，我开始把支付方式放在了客户的类里，心里觉得很合理，但是压根处理不了问题，折腾了40分钟又推到重来，浪费了好多时间和精力。
3、注意小细节，我在第一次时，错误的情况测试点迟迟过不去，眼看着和测试用例一摸一样，但是就是过不去，问了旁边的人才发现，是我一个空格少打了，另外中文的冒号的英文的冒号不一样，导致了错误。
4、理论联系实际，在软件这一领域，我们编写代码总是要立足于某些东西，实现某些功能，并不是说是空穴来风，没有立足点。我们编写代码的时候，这个编写的是什么，你编写的依据是什么，他这一个领域有哪些知识需要你学习，因为你编写代码可能会用到那些领域的知识。有时我们在拿到一个题目或者课题时，我们并不清楚要用到什么技术，也不能瞎写，这个时候我们就要学习相关的知识，然后再把它应用到课题当中去。当然，考虑欠缺也是一部分原因，自己也是要更加考虑周全。
四：改进建议
这一次的题目给了我好多启示，学到了好多东西，其中主要的就是多行信息的输入怎样控制消去换行符号，怎么去合理地设计继承类，处理类与类之间的关系。在第二次的迭代的题目集中，我坐了3个小时进行编写，写到最后航班的一个测试点死活过不去，我就出去转转歇一会，回来以后就立马发现了错误所在，几分钟就搞定了所有错误。有时真的就是太急了，没有心思去注意一些细节。以后也要保持心态的平和，无论学习还是生活。
对自己以后得学习建议：
多去追溯根本方法，理解每个结构后的底层逻辑，不能将就着敷衍了事。
学习List的知识，熟练掌握运用List，利用list泛型解决更多的复杂问题。
写代码时注意注释的书写，对代码加强理解，将平时所学的东西运用到实际中去。
五：总结
对于java课程的建议的话，我觉得现在的模式就足够可以了，每个星期都有要做的事情，对于没有笔试我是非常赞同的，笔试考验不出来水平，上机考试才能考验出水平。
但是关于线上慕课，我还是有些建议的，那个随堂答题可以不止设置一次性答题，可以设置两次或者三次，因为有时候我的答案是对的，但是顺序填错了，还是判定错误。另外我的答案有时候加了个前缀，但是还是判错，这样的话会丢掉好多分。
关于翻转课堂，这个我是非常赞同的，可以让我们深刻了解fx的一个区块，同时又能倾听别的同学对内容的理解，又可以解放老师来进行对我们的点评，可谓是一石好多鸟。
这次题目集主要提高了我的眼界，对把控题目的眼界，可以从一个更高的视角去审视题目，去做到全面布局。大大提高了做题速度，谋定而后动。
我以后还是要注重细节的把控，比如输出时，printf和println的格式问题，对程序核心算法的把控要更加精细，完善自己的知识体系，多做多练，手不能懒，积极拓宽自己的知识面，独立自主完成作业。
多与同学和老师交流，及时获得专业动态变化，在交流中增加自己的知识。