我的方法（函数）设计小心得

在工作中经常被问道：如果你的那个方法输入空会返回什么？我记得自己曾经使劲回忆也没想到自己那个方法是怎么个回事。也经常跟同事在对功能的时候在说代码，那个冒泡排序，两个循环就搞定了。。。。。渐渐就发现，很多时候，写代码是有规则去遵循的。然后自己结合自己工作中的一些小经验，就出了下文，也许很糟糕，也许很好，但是现在真的很适合我，如果你在写代码之前也很迷茫过，那么也许可以帮上你的大忙。

1. 当你开始写一个方法的时候，你一定要知道他要干什么

你要明白，这个方法的场景。

总结：一般我拿到是一个功能，我会问自己为这个功能的意义是什么？他给那些用户用，那些角色用?我的时间够吗？ 我做到什么程度就OK了？我先做什么？那些功能是先出来的，那些可以后出来？

2. 找到已知条件与未知条件，你需要做的是梳理他们的关系?

我记得有一个方法，我用了一上午的时间在梳理表之间的关系，但是我只用了半个小时就把这个方法完整的做出来了。现在有的条件是什么，没的条件是什么？整个过程中那些是自己知道的，那些是自己不知道的？我必须知道什么才可以去写代码，我的风险点在哪里？大概的参数的流转是怎么流动的？我最后会把这些疑问全部消除掉，然后又一个很清晰的流程。

总结：这个过程我感觉是最主要的一个过程，我花时间最多的也是这里，基本上是问问问，有的时候只要查表结构就OK了，但是更多的时候由于文档的不完整性，基本是这样的,一个方法要问N个人，这时候就要发扬程序员的“不要脸”精神了。我基本上是拿张纸边写边梳理的，梳理完之后，基本上还会去找之前做过的人自己在讲述一遍，问问是不是这个逻辑（当然这只是比较不熟悉的模块了），简单的还有一种直接方式，自问自答，来验证自己写的方法是否正确，反正我一直有自问自答的习惯，因为没人给我确认了，只有自己给自己确认了，这个过程中能把自己思路梳理出来，我管这个叫说代码，而不是写代码。

3. 真的开始可以写了

如果你真的想好了，有自己的逻辑了，那么真的可以写代码了，就按照2说的写就好了，这是多么有意思的一个过程呀，把你说的用代码进行表述。但是我基本上开始写的时候写的是一把伪代码，把自己想到的写下来，接着会去填代码块，逻辑如果超级简单的就真不这么干了，太费时间了。

总结：边写边思考：我也见很多高手写代码，逻辑很清楚，基本是写方法名称刚开始定义的很扯的，比如就x(),他说他自己也不知道他要干什么，所以就这么写了，等我知道他要干什么我就在重命名了，这样不会耽误自己的思路函数名称的定义基本是google上查查查，如果写的过程中遇到自己不会的，直接会写一行汉字标注下，等写完之后，在看一遍，然后去找解决方法，而不是边写边查，这样会很糟糕，代码的产出太少。除非是一门新语言我必须边写边查。

4. 自己测试

什么单元测试什么的，自己基本是在项目里面，边写边测试了，有的时候会推到第二天，但是一定要测试的，自测很重要。

总结：自己写的方法，一定要测试才给别人去用，这是做开发的最基本的事情，尤其是接口。其实在第二部去设计了解需求的时候，就已经设计好要输入什么参数，只要搬过来用就好了，自己测试，也就无非验证自己写的是否正确。

5. 自己代码审查

注释的加进去，你自己的大名，创建的时间，实现什么功能，以前自己写代码，以前写代码基本是到4就OK了，但是我自从看到同事写的代码之后，发现人家的代码简直就是艺术呀，所以我也就在代码块加#region? #endregion 感觉很清爽。

6. 代码重构

读书的时候，听人家说，一个方法如果超出70行基本上就该拆几个方法了，所以最好在去重构下代码了。能拆的话在时间允许的情况下，最好去拆下，去优化下。

总结：代码重构很永恒的话题吧，关于代码重构的看自己的线下功夫了。?

小结

如果出现业务的bug，应该反复走2，3，4这个步骤了，只要按这个步骤走，基本上业务不会出问题了。关于代码测试，我不喜欢写一个方法就测试一个，我喜欢全部写出来，把大的框架搭出来，然后再去做些细节，原因是现在时间真的很紧急。但是一个功能做完之后，自己必须全部测一下，在接着去做别的。总之，在写方法之前，你首先的把业务了解清楚，把自己要写的东西能用自己语言描述清楚，然后再去写代码，我感觉这个方法很适合我。然后在写代码的时候多问问自己一些问题比如：

你的那个方法，如果我输入空，会出现什么情况？你的那个方法能写在服务器端吗？（为什么问这个问题呢？因为我发现很多方法写在服务器端的方法，会节省你很多时间）你这个方法能提炼出来，放到公共模块里面吗？等等，我现在感觉这种方法很适合我，并且可以让我的工作效率提高很多。

本文地址：http://www.nowamagic.net/librarys/veda/detail/1951，欢迎访问原出处。