程序员的日常码农的世界

呀,上班都30天了

2017-07-25  本文已影响439人  半生不熟_

今天一过,正式上班就整整30天了,也是来这个项目的30天了,特意翻了好几遍日历,是的,真的是,是真的。

讲真,感觉一切都好快,好像很多东西突然都变得不够用了。

时间过的好快,还那么不够用,什么都不会,还学的那么慢。

若有所思脸......

但就像那句话说的,急好像并没有什么用,还是得慢慢来。

说着说着,一个月也就说过去了,很庆幸,又发现了自己的一些不足,也看到了别人很多优点,瞻仰了组里的各种老司机。

突然又想起了林老师曾说的一个词—闻过则喜,记得当时我说觉得我这辈子是也做不到了,但最近发现有那么些时候,好像会有一丢丢地些感触,这个词又反复地在脑海里浮现着。

大概总结了一些自己的问题,当然还有很多,就是觉得很多东西还是需要再思考下的,但愿后面能时刻提醒着自己,慢慢改掉不好的地方。

黑线尴尬脸~~~
说实话,不论是连我自己都不知道在说什么的时候还是我觉得我已经尽全力搜罗了我触及的知识后然后从嘴里说了出来的时候,都会有或多或少的问题存在,打心里觉得这一点特别重要,也是我一直在注意却没有改好多少的地方。这一点和buddy比,她很明显特别棒,也注意了下周围人说话的时候一些东西,真的很明显。

很多时候看到一个现象或者问题,张口就开始问身边人了,其实这个问题也挺严重的,有时候问完发现问题的答案真的简单到出乎意料,那时候真恨自己没有再多想几秒钟,但总是没有意识,后知后觉,这也是这一点改的很慢的原因。

认真想想,虽然说好像生活中一些东西思考的还是很多的,也许是因为感兴趣或者觉得别人也不知道吧,总喜欢多想那么一丢丢,但在学习方面,真的相差很多,总有一些自己都觉得蠢的时候,很多时候都不过脑子。

每当想问问题的时候,再多想那么几分钟,把自己思路整理好了再张口,既节省了别人的时间,也让问题的答案能早点解决自己的问题。

学gulp的时候,有个gulpSequence方法,不知道眼睛怎么了,看了好几遍,就是忽略掉了run 'a', 'b' in parallel 的parallel这个单词,导致run出了与最初理解不同的结果,奇怪了半天。告诉buddy的时候,buddy虽说不知道有gulpSequence这个方法,但很好奇地问了一个问题,让我一下子意识到了又是自己错了,她说:“之前按顺序直接写的方法已经可以实现顺序执行了,为什么要专门再出一个方法来实现它呢?”

还有关于Spring中使用@RequestParam传参的问题,虽然最终解决了问题,跑通了测试,但是没有跟之前的知识联系起来,其实再想那么一下下,从命名就可以看出来一个是放到http请求的query里的,一个是放到请求的body里的,但就是没有再多想那么一点,就简单觉得就是一个参数和多个参数的问题,还是跟舍友两个人一块看的,真的是。

透过表面,多思考内在,特别是在学习新东西的时候

虽然没有严格按照TDD形式,但是,测试是必须而且必要的,完成了 一个新功能后,要思考要加哪些测试的case才能保证自己的新功能不出差错,尽量覆盖全面,而且不能影响到其他正常的功能。

看了小青姐画的导图和举的一个小模块测试的例子,还有pair让我看的用等价类划分法如何写测试用例,觉得都让我有了新的思考,原来里面其实是有技巧的,没有过深地研究黑盒白盒等等什么测试,但绝对其实生活中我们都用过,只是不知道系统的将其整合起来其实有个专业的名字而已。

就拿自己特别喜欢的一个游戏来说—捉迷藏,同一间屋子内,一个人守着后门,一个人守着前门,你会在屋子里找到可能会藏下一个人的地方,然后依次去找,然后确定对方有没有藏在这间屋子里,不会说我检查了一遍床底下没有,然后看了衣柜里没有,然后再去找床底下,所有等价类测试的定义就是把所有可能的输入数据划分成若干部分,然后从每一部分中选取少数有代表性的数据作为测试用例,用少量代表性的测试数据取得较好的测试结果。

排列组合,全面覆盖。

自己不知道的太多,每次都绝对问出来会大家会浪费时间,打断别人思考,所以大多数的选择就是沉默,然后下去自己看吧,再后来就是拖着拖着就忘记了。

buddy说要多问问题,不要怕影响项目进度,特别是站会和diff的时候,首先是要学着更多的了解项目上下文,其次是不知道别人在说什么的时候就要表达出来,不要想会耽误时间什么的,开始的时候不问,问题积攒多了问那才是浪费时间。

然后就是当别人提出代码有需要 refactor的时候,不仅要听完别人说怎么怎么改的好处,也要想一想别人为什么能想到要那样改,在处理各方面好坏优缺的时候怎么衡量然后如何取舍的。自己以后遇到同样的场景时,会不会想起曾经的diff,然后不犯同样的错误。

有问题的时候, 自己先在心里思考一分钟,有没有必要问这个问题,这个问题能不能自己是真的不知道答案吗,这个问题问出来以后对方能不能听明白自己在说什么?对方有这个问题的上下文吗?对方理解的上下文和自己认为他所理解的一致吗?然后,再决定要不要问这个问题。这样既理清了自己的思路,也节省了大家的时间。

记得第二周的时候学了一个新知识,然后问了buddy一个问题,描述完之后她满脸疑惑,重点是我发现我自己都不知道自己在说什么,还指望对方理解我的意思了,然后还要去回答我的问题了,当时真的感觉脑子都不知道在想什么,说的话没有丝毫思考就蹦出来了。

没理解的不懂得知识,不要着急着去问,因为这时候自己都不知道自己在说什么

开始的两周我的确是这样的,早上的站会,我基本都是在圆圈的开始那边,所以早早一说完,就觉得轻松了许多,后面团队的人说的还好,会认真地听,但是当客户在说的时候就几乎跑神了,不是因为不想听,而是当有一句两句,甚至三句都听不懂的时候, 不由自主地就跑神了,虽说可能表现的很认真的样子,但是真的什么都听不进去了,导致最后大家说到什么好玩的时候笑的时候,我是满脸懵逼加大写尴尬。

词汇方面和口语的表达都需要好好练,但愿下个月能好点,会尝试着认真去听,即使一两句听不懂了,后面还是要专心去听,说不定哪天就全听懂了呢。

有一次是写一个CSS样式,做一个Header,但之前有做过类似的东西,样式基本已经实现了,所以就想着把别人之前的代码拷过来就好了,但是有一些样式都没见过,之前写的也不多,这是一个点,重要的是自己也没有去搜那个样式是用来干什么的,就开始把代码复制过去了,但其实那个样式根本就是多余的,而且用在那里是不对的的,buddy问它是干什么的时候的同时也意识到这是一个特别严重的错误,虽然说当下产生的影响不大,但回想,自己之前很多时候都是这样,慢慢地,就养成了习惯,这是一定要改的。

buddy说的一句话特别有道理,你写的每一行代码都是要负责的,如果你自己都不知道什么意思,别人又怎么会知道,别人问你的时候,出现问题的时候你再去搜吗?

写出来就要知道它是做什么的

第三周和pair写代码的时候,用的一个框架,是新的,他以前也没怎么用过,但是碰到问题的时候人家就知道怎么一层一层地去搜,快速就能定位到自己想找的那个function,而自己就在一遍纠结着这样为什么不对,有什么新的方法呢,然后去搜的时候,就会找一篇一篇的中文文档,然后学东西又不快,真心效率低很多,总是慢一拍。

  • 看Log 看Log 看Log

明天就开始新的一个月了,但愿自己能比这个月好一点点。

真的超级感谢buddy对我的悉心关怀和每一个帮助我成长的人。

上一篇下一篇

猜你喜欢

热点阅读