前言:
在工作中经常被问道:YM,如果你的那个方法输入空会返回什么?我记得自己曾经使劲回忆也没想到自己那个方法是怎么个回事。
也经常跟同事在对功能的时候在说代码,那个冒泡排序,两个循环就搞定了。。。。。
渐渐就发现,很多时候,写代码是有规则去遵循的。
然后自己结合自己工作中的一些小经验,就出了下文,也许很糟糕,也许很好,但是现在真的很适合我,如果你在写代码
之前也很迷茫过,那么也许可以帮上你的大忙。
1.当你开始写一个方法的时候,你一定要知道他要干什么
你要明白,这个方法的场景。
总结:一般我拿到是一个功能,我会问自己为这个功能的意义是什么?他给那些用户用,那些角色用?我的时间够吗? 我做到什么程度就OK了?我先做什么?
那些功能是先出来的,那些可以后出来?
2.找到已知条件与未知条件,你需要做的是梳理他们的关系
我记得有一个方法,我用了一上午的时间在梳理表之间的关系,但是我只用了半个小时就
把这个方法完整的做出来了。现在有的条件是什么,没的条件是什么?整个过程中那些是自己知道的,那些是自己不知道的?我必须知道什么
才可以去写代码,我的风险点在哪里?大概的参数的流转是怎么流动的?我最后会把这些疑问全部消除掉,然后又一个很清晰的流程。
总结:这个过程我感觉是最主要的一个过程,我花时间最多的也是这里,基本上是问问问,
有的时候只要查表结构就OK了,但是更多的时候由于文档的不完整性,基本是这样的,一个方法要问N个人,
这时候就要发扬程序员的“不要脸”精神了。我基本上是拿张纸边写边梳理的,梳理完之后,
基本上还会去找之前做过的人自己在讲述一遍,问问是不是这个逻辑(当然这只是比较不熟悉的模块了),
简单的还有一种直接方式,自问自答,来验证自己写的方法是否正确,反正我一直有自问自答的习惯,
因为没人给我确认了,只有自己给自己确认了,这个过程中能把自己思路梳理出来,我管这个叫说代码,而不是写代码
3.真的开始可以写了
如果你真的想好了,有自己的逻辑了,那么真的可以写代码了,就按照2说的写就好了,这是多么有意思的一个过程呀,
把你说的用代码进行表述。
但是我基本上开始写的时候写的是一把伪代码,把自己想到的写下来,
接着会去填代码块,逻辑如果超级简单的就真不这么干了,太费时间了。
总结:边写边思考:我也见很多高手写代码,逻辑很清楚,基本是写方法名称刚开始定义的很扯的,比如就x()
,他说他自己也不知道他要干什么,所以就这么写了,等我知道他要干什么我就在重命名了,这样不会耽误自己的思路
函数名称的定义基本是google上查查查,如果写的过程中遇到自己不会的,直接会写一行汉字标注下,等写完之后,在看一遍,然后去找解决方法,而不是边写边查,、这样会很糟糕,代码的产出太少。除非是一门新语言我必须边写边查。
4.自己测试
什么单元测试什么的,自己基本是在项目里面,边写边测试了,有的时候会推到第二天,但是一定要测试的,自测很重要
总结:自己写的方法,一定要测试才给别人去用,这是做开发的最基本的事情,尤其是接口。其实在2第二部去设计了解需求的时候,就已经设计好要输入什么参数,只要搬过来用就好了,自己测试,也就无非验证自己写的是否正确。
5.自己代码审查
注释的加进去,你自己的大名,创建的时间,实现什么功能,以前自己写代码,以前写代码基本是到4就OK了,但是我自
从看到同事写的代码之后,发现人家的代码简直就是艺术呀,所以我也就在代码块加#region #endregion 感觉很清爽
6.代码重构
读书的时候,听人家说,一个方法如果超出70行基本上就该拆几个方法了,所以最好在去重构下代码了。
能拆的话在时间允许的情况下,最好去拆下,去优化下。
总结:代码重构很永恒的话题吧,关于代码重构的看自己的线下功夫了。
总结:
如果出现业务的bug,应该反复走2,3,4这个步骤了,只要按这个步骤走,基本上业务不会出问题了。关于代码测试,我不
喜欢写一个方法就测试一个,我喜欢全部写出来,把大的框架搭出来,然后再去做些细节,原因是现在时间真的很紧急。
但是一个功能做完之后,自己必须全部测一下,在接着去做别的。
总之,在写方法之前,你首先的把业务了解清楚,把自己要写的东西能用自己语言描述清楚,然后再去写代码,我感觉这个方法很适合我。然后在写代码的时候多问问自己一些问题比如:
你的那个方法,如果我输入空,会出现什么情况?
你的那个方法能写在服务器端吗?(为什么问这个问题呢?因为我发现很多方法写在服务器端的方法,会节省你很多时间)
你这个方法能提炼出来,放到公共模块里面吗?
你写的这个方法自己感觉是不是太长了?
有的时候遇到业务性的问题,感觉无从下手,怎么写这个方法呀?他想要的参数都没给我?
等等,我现在感觉这种方法很适合我,并且可以让我的工作效率提高很多。