数组问题小复盘

ArrayCaseReview

Posted by Molly on September 30, 2018

换了班以后,学习节奏一下子紧张了起来,这几天英文学习的时间少了,错过了好几次提交作业的时间,弄得我只能在地铁上练口语,哈哈,假装是要个非常用功的好学生。 今天的作业非常有趣,非常好玩,有四道关于数组的问题。说实话,我做得挺慢的,人家四道题都做完了,我还在找bug。嗯,明明觉得思路都是对的,但就不知道错在哪里。但找到以后就发现确实似乎是没有完全想明白。———— 这“狭义理性”也不容易呀。

所以,小复盘一番:

用户名&密码正误判断

1、这道题我的做题思路是分为了几个小版块。首先实现了用户名正误判断,再在里面嵌套密码正误判断。最后,再进行重复输入的功能实现。

2、 我做这个的过程之中,刚开始是没有想到

if esle if 语句里面的判断条件可以不对等,学习的时候下意识认为两个判断条件应该在对等的地位,结果发现不仅不用对等(只要逻辑不相悖),还可以添加其他的限制判断条件。这是一个尝试得到的新认知。

但是它们只能选择执行一个代码块。比如下面这个例子:

它的执行结果是:

虽然第一个if判断语句和第二个判断语句都是正确的,但是也只选择执行了最前面为true的执行代码块。

3、其次(错了很多次的 ),诸如判断等是==而不是=;字母少写了等低级错误也是很值得反思了————这个只有多练习增加熟悉度才行。

4、下午从同学们的qq聊天里面学习到的break用法,这次我主动使用到了合适的位置。为何要说明“合适”二字?因为我前文说过了,我的思路是分成版块实现的,所以如果混在一起我是不会那么容易想到要加一个break,反倒是在因为一个小版块的处理之中,就注意到了这个问题。

用户登录次数限制问题

2018-9-30:第一种解法

有了前面一题的打底,我这道题仍然找了很久的bug。问题出在哪里呢?密码输入限制三次的功能区域,我刚开始的时候没有实现,后来它自己竟然就成功了。也不知道刚开始问题出现在哪里。

但直接影响了我用户名次数限制的思路————对!我照搬,但fail了。因为二者的逻辑是不同的。密码验证的前提条件是知道要和谁比较,所以直接给了一个参数,用来充当计数器。

但诡辩之处就在于用户名验证的点是它要重新进入循环————这样才能遍历数组进行对照。问题来了,如何才能再次进入for循环?嗯,在遇到这个问题之前我没有想到有这种操作,但知道以后便脑洞打开了。

如图:

我对i重新赋值为-1,那样整个循环完成以后i++,则i=1,那么就可以重新开始一个完整的循环流程。听起来非常脑洞大开又简单是不?那么,我在这里又出了什么问题呢?

那就是对于n参数的判断。因为我进入执行语句以后,应该是满足判断条件的,即n<=2,那么我就下意识认为循环结束以后n = 2,但其实n=3。因为循环结束以后有一个n++,则n=3,这个时候它不才能不进入循环。而n的值到底是多少,放在括号外面还是里面的区别并不是核心问题(我刚开始就是单纯以它作为判断条件的),核心问题是它是在执行n++的前面还是后面。本质就在于它执行了就是3,没有执行就是2。

[update2018-10-10]

java学习的时候再错了一次

在做计算米盒位置的时候,大括号里面的执行语句结束以后,进行了一个i++,这个时候再判断就不能再执行大括号里面的执行语句了。

因为for循环的执行流程是这样的: 也就是在判断2之前,是先执行了语法3的。

2018-9-30:第二种解法:

第二种解法是其他同学和老师想到的更为清晰的解法,和我的思路殊途同归。我的思路是先进行判断,如果要是用户名输入错误,那么就给i赋值i= -1,这样去强制重新进入for循环,从而让这个新输入的用户名能够和数组再一一对照。而老师的做法则是在整个for循环外面套一个壳子,让它不管用户名正误都能够执行for循环三次。而里面如果用户名正确,则也是强制让壳子的循环停止执行。他们的方法代码量更好,思路更清晰。可以这样去优化。

而我之所以是这种思路,是因为做第一题的时候,我就把多次用户名和密码输入的功能给做出来了。因此做第二题的时候就是直接在这个上面去修改的代码。如果我第一题没有做出多次输入的功能,那么应该也能够得到外面套三次机会壳子的思路。

用户注册

虽然老师说这题难,但我觉得这不是难点啊。因为前面两题把思路都大致做出来了,这题就没有所谓很难的说法了。和前面一样,脑洞是可以放飞的,但是细节才是魔鬼!我的问题又出在哪里呢?

让我找了半天,浪费非常多时间的小魔鬼就是这个:

因为我做前面题目的时候并没有要求进行注册,所以我刚开始的红框里面填写的是具体的数据,而不是代码。但是随着用户注册了,数据的输入以后,这个地方自然就不能作为判断条件继续存在。所以使用代码来指代才是更稳定的做法。

这让我想起我做计时器的时候在做之前就预设了一些思路。比如,一次点击就触发一次function,如果我自己设置一个后台变量,那么就不能够实时跟进。( 设置后台变量这个脑洞完全是我之前做苹果计算器的时候留下的思路)但这次我聪明地先做了一些思路草稿,才不至于“所谓想到了一个小点子,就立马动手,万一还有后续没有考虑到呢”。就像这道题一样,在前面两道题成立的代码,这道题便不再成立。是因为没有预设到这种情况的产生,所以直接用代码指代,而不用直接的数据是更为稳妥的做法。

2018-9-30:

第二天发现还有一个类似的地方也需要修改, 和上面一个逻辑是一样的。

随机点名

2018-9-29:

这道题卡了我很久bug的地方在红框这里。因为常规思维的影响,我直接就写作:i < array.length。但是我没有考虑到我的数组长度是一次循环减少一个。所以,它的限制条件就应该反过来,只要这个数组还存在就循环,直到它被删除干净为止。

2018-9-30:

后来想到了一种更为简单的办法,可以直接生成满足条件的随机下标数。即: math.random这个函数可以随机生成0~1的随机小数,那么1是不满足的,因此最大的必须要大于最大下标数,即数组的长度。

2018-9-30:

刚开始的思路是随机生成一个下标数,然后输出该位置的数据。后来执行全局。这样就能生成随机的一个数组排名。但后来发现,这就是经典的洗牌算法。因此,完全不用被“简易点名器”的思路限制了,如果从洗牌算法这里去看,也许能够找到更为简单的解法。

To Be Continue…

总结

这样总结下来,我的很多思路都是相互影响着的。前面的苹果计算器思路影响后面的计时器,之前的常规用法也会影响到后面的方法采用。是一件好事情,也不是一件好事情。

心态总结和其他安排

编程的乐趣远超出我的想象。但进了这个新的班级以后,发现这个班里的同学不仅学得更好,更加努力,基础也更牢固。我是很担心自己能不能学好。于此同时,还有小伙伴给我讲解到了一些我听到没有听过的内容。我突然发现他们是真的准备学习java和编程,而我之前只是在各种尝试而已,所以我了解得太少、太少了。连基本的东西都给靠别人的传递和提醒,压力是真的很大。

于此同时,其他的安排还有:英语的学习(因为我的计划里面这段时间是有英文安排的),有博客的持续更新(也就是经典阅读输出了),国庆以后开班的信息分析课程————这是我最最最最期待的课程,也是我最最最想要学好、掌握好的内容。(它不被大多数人知道,也是我说过的“广义理性”层面的东西了。因为我曾经被莽撞的决策害得自己填错了专业,浪费了很多很多的时间,所以想要尽量在重要的事情、决策方面建立起全局认知,得到一个相对不差的决策结果。)

我曾经一年多的时间每天睡眠不足六小时,但是结果不仅没有得到什么,反而失去了更多。所以,我是挺害怕再次all in的。已经不再敢抱有太多的期望,只是觉得有责任把该做的事情做好。老师说的代码量和工资的问题,听听笑笑就好。仍然是那个“考上好大学,就能有好工作的”老套路。决策分析层面的问题更加重要,如果能够拿出这种态度去处理决策方面的问题,把握住舵,大体的逻辑是能想通的。,然后就是细节纠正&落地执行的事情。没有执行力,就再去找外界压力嘛!反正我明白自己对已同侪压力一直是非常敏感的。嘿嘿!