室友跟我说我拿了黄衫的时候,我第一时间觉得本身摸鱼被发现了,被黄牌警告了……后来仔细看了看那段关于peek experience的介绍才知道这玩意儿属于奖励性质。git
而后我思来想去,我看了看本身中上而已的分数,不以为作到了“最好”。那为啥给我了件黄衫呢……我想了老半天,以为多是由于我测试部分写得比较特别吧。算法
我当时拿到题目要求,看了看那老长老长的一大串,就感受这玩意儿想对很难,又瞥见有个性能测试,并且数字还挺大,脑子里稍微想了想算法,感受这个时间复杂度确定低不了。我察觉到这个项目要作的话可能会永无止今,毕竟有个性能优化的问题,这个问题没有尽头,但个人时间有限,因此须要有个“让本身绝望的标准”。也就是本身写测试样例卡死本身,并且还得是那种我不知道能不能跑对、跑通的测试样例。编程
基于以上的想法,一点点往下推想,就天然而然地把测试样例划分红了多个种类,也天然而然地会想要有个自动生成测试样例的方法。也就是所谓的需求、资源驱动的结果啦,否则我也不会在测试上搞那么仔细。性能优化
我以为这也是种团队精神吧,就算是不想干了、以为没可能搞下去,也得要有个能报告的玩意儿,像是“不管如何也没法在5min内经过1000词的测试”,而后把那个1000词的测试摊开来给伙伴看,劝他也放弃,而不是本身自顾自地不折腾了啥的。性能
并且还有很重要的一点,我比较懒,要我手写1000词的测试,或者光凭想象力去想那么多测试样例,而后还要追求代码覆盖率,那还不如杀了我。作事有点条理性也是方便本身把活儿干好。固然,要是没想把活干好那另当别论。测试
总结来讲,就是这几点让我去作了比较复杂的测试:优化
这课其实也还挺闲的,主要是压力不是很大。和OO、计组、OS这些课不一样,软工的工做重点我以为是调研+计划+交流。至于实际的编码问题,就个人状况而言,遇到的问题都不是很棘手,或者说若是太过棘手的话,那在计划、交流的时候可能就把这个需求给pass掉了,毕竟是本身作决策,本身总不能给本身找难受是吧。不过虽然本身不会给本身找难受,但得说服别人不给本身找难受——我以为这就是软工的工做重点了。编码
举个例子,结对那会儿,我花了至关一些时间和搭档解释说明个人git习惯,可能和第一次一块儿看题花的时间同样。由于咱们大多数人其实用git的经验不多不多,特别是团队使用的状况。就算是团队使用,不少人也都是线下商量好,再线上装模做样地提交。这在两三我的的小团队里还好说,要是大团队里面感受会是个灾难。从这点来看,我以为目前软工的团队人数设置得挺合理的,6~8人,不大不小。太大的话,有的组的代码管理可能就要崩溃了,过小的话,有的组大概就没有代码管理了。资源
不过固然,git习惯只是一个手段,真正重要的仍是交流的方式吧。我也不是很懂,就慢慢学。怎么和别人一块儿搞事情,这就是工程吧。开发
团队做业这部分的引入,我以为教学方面真的带得不够。正如我上一段所说的,咱们大多数人没有任何大项目的开发经验、管理经验。像是团队成立后的第一次课上去作个PPT去讲,而后对于要讲啥的要求都是很概要的几个字/几句话。我知道这是由于各组项目性质/人员类型都不尽相同,不能给出一个定式的模板。可是也正由于如此,我以为助教的深度介入应该就在此时进行,而不是拖到alpha阶段都快结束了才介入。让一个已经成立的团队改变作法比在一个团队创建时给出意见矫正路线要困可贵多。我感受到课程的意思是让咱们先去作,而后再正经地教,这好像是目前更提倡的作法,毕竟本身动手作了才有感觉,才能更有针对性地听。可是实际的操做结果是,作的时候一头雾水,瞎搞,而后由于课上讲的都是已经作完上交了的东西,因此都没啥人在乎,过后更加没人根据课上讲的东西返工以前作的东西。(在没有出大事故以前,不会有人愿意返工的。)
我看见黄衫上写着“Learning when doing”,我以为这句话是没毛病的。因此个人建议是,teaching及时介入doing的过程,引领好doing的方式,让学生能更好地自主地去learning。而不是听任学生本身doing,而后再teaching,期望着学生能自发地返工/自省从而达到learning的效果。
固然,如今已经alpha阶段快结束了,立刻要进入beta阶段了,该定下的团队运做模式基本都定下来了就是了。
这里还想提一下做业的提交方式。我很喜欢结对编程的那个做业提交方式,两我的有共通的内容,但也有各自独立的部分。不知道为啥团队做业不这么搞了。我以为哪怕咱们以团队形式进行工做了,至少在alpha阶段,也应该在我的级别地督促教学。固然,这不是说要给我的增长单独的博客做业啥的,只是须要有个渠道能真正看见团队里每一个人吧。不过由于各组项目的性质、分工都天差地别,这部分可能真的有点棘手吧(笑。
(我会不会说得太直了,我不会被扣分吧(惧怕.jpg