导读：
不知道是不是大家跟我一样遇到过这样的问题：你头直接给你个需求，然后把你扔到一个角落，你都不知道是什么，怎么做，甚至为这件事情还抱怨过？
抓狂过？因为这个需求太不明确了，这个需求连个页面也不知道是什么样的？你甚至跟我一样反工过好多次，也许是改页面，也许是改数据源等等，现在自
己总结出来的小技巧，希望可以分享给大家，对一些像我这样的小小程序员有所帮助。欢迎大家留言分享自己工作中的点点滴滴。
“未雨绸缪，你要知道，需求错了是你制造出的最大的BUG”
当你的上司直接给你一个东西需要你去做的时候，你会怎么做呢？怎样做可以减少BUG的重复出现呢，记着哦，他给你的只是一个需求，只是想告诉你你
要干什么，这时候你会直接怎么办呢？直接写代码?甚至不问他给你多长时间就去写代码吗？经常遇到这样的问题，开发出来的甚至不是客户想要的，你的头
甚至也不知道你怎么干的，白做活，不讨好。以下是自己的一点点小技巧，希望可以给大家一个很好的帮助。
（1）“用你的眼睛还有耳朵去听，有必要的时候用笔去记”
在你头说的时候，你要用耳朵用眼睛去听，别插话，我以前就有个臭毛病，有问题就去问，直接打断，这是个坏习惯，如果有问题直接记在脑袋里面，
或者写在本子上，一定要带本本哦,这个时候你的头肯定会说一些注意的点，一定要抓住哦
（2）"问"
把你的问题整理出来（是你刚听不懂的问题），问，一定要问，为什么这么走？为什么不是那样？如果需要在数据库添加表，需要添加那些字段，等等，
问完了一定要做记录。
（3）”画页面“
当你认为你已经完全懂你头要干什么了，你就需要画页面了，你的页面是为了解决什么样的问题而存在的呢？需要几个页面，每个页面是干什么的？甚至
这个页面对应几个方法，每个按钮下面实现的方法是什么，对那个数据表操作是什么都要有自己的描述。点击一个按钮会到那个页面也要记描述的。
（4）“与你的头沟通”
自己看一遍，给自己讲一遍自己要干什么样的，感觉不对劲的记录下来，问问自己是不是有更好的方案，为什么自己这么干，不那么干，如果感觉有更好的
方案，马上记录下来，修改自己的方案，整理自己在整个过程里面遇到的不解，直接找你的上头，给他讲你的设计，直接那你画的页面，给他讲，看他是是
否满意，把你的不解一定要讲出来，然后讨论。如果发生争执，需要改页面，方法，直接回去改，改完之后，在跟你的头沟通直到你的设计是满足你的头的，
否则一行代码也不要写。
小结：第三与第四是核心，这两个步骤直接影响你最后的需求是什么样子的。
“if（需求OK）{你可以写代码了}”
现在我们就有一张张图，然后我们根据图去实现自己功能了。
（1）“写代码”
“拿着你画的页面，你写的方法你还怕什么呢”？一般是先写底层的需要用的方法名称（不实现）---写完之后要找头看一眼，他这是看你命名规范的以及返回的
类型，接着是画页面，最后是确定需要提供给外部的接口方法，以及客户端方法等等
（2）注意
当中间遇到问题，自己解决不了一定要跟头打交道，或者有自己想法一定要提前跟你的头进行沟通,找到最好的解决方案，而不是自己闷着脑袋去做
小结：这一步也很重要，别自己去改需求，如果自己认为需要改的直接找你头去沟通。
（3）“写完之后，自己一定要看一遍，确定没问题了在跑”
我以前性子很急，什么事情都急于求成，代码写完之后，比如一个添加用户功能，基本存储OK，调用好了，就直接去跑代码了，结果很多问题，莫名其
妙，甚至调用存储的名称都错了
（4）写个测试功能点的文档扔给测试人员
（5）“看不见的方法自己一定要测”
一些以接口形式提供出去的方法自己一定要测
小结：这些东西是你最后提供出去的东西，也许测试的不会写代码,OK自己测了
（6）“自己发现的问题，一定要及时去解决，而不是等测试人返回来在去解决”
以前一个同事有个坏习惯，就是自己发现问题不解决，等测试部把BUG提回来在解决，被头K了好几次
总结：
以上只是自己在工作中曾经操作的一个小小过程，目的是为了解决程序员在编码前搞明白自己在做什么一个功能，准确无误的表达你与你的头之间是
否沟通无误。对于一些经常因为需求变动而苦恼的程序员可以拿几张图去跟你头去沟通，也许比你会更好点。也许当你这样做过几次以后发现这是对付变
化无常的需求一个很好的方法。