一个需求是怎样完成的？

这段时间以来还是有很多感触的，特别是在写程序方面

我思考最多的就是设计是否合理？如果设计不合理，那受苦的也只有写程序的那个人了

有的时候可能我们会质疑我们自己，为什么这段程序这么难懂？是我们太笨了么？

殊不知写程序的那个人把一段简单的逻辑写的那么复杂，谁知道他怎么想的呢？

有的人觉得一个接口能办完的事情，为什么要分两个接口？哈哈哈，对于这样的疑问，不想置评，自己好好想想呗，为啥要区分接口

有的觉得我只要把功能写出来了就可以了，是的，这本身没有错，因为每个人都是这样过来的

目前我采用的方案还是这样的，如果功能没有实现，你别和我说这里该用什么设计模式？况且呢，设计模式这东西吧，如果不写通用型工具，用的还是比较少的

我们在日常的工作中大部分都是在写业务逻辑，有的时候，一个简单的需求就会遇到一些困惑

正如，最近我也是刚用一项新技术，面对新技术的使用，我遇到最大的问题，这个表这样的设计，我完全没法实现啊，怎么办？

找人，重新设计表了，就这样，表设计变了，我的那个需求也变得相对容易一些了，可是，对于这样的需求，api我不知，只能靠搜索了，找了一圈，调试了很多，终于满足了需求。

然而，在我打算和别人联调时，他告诉我，需求变了，我去，我都不知道…，没事，需求变更在程序里很常见的，勿见怪

吭哧吭哧改逻辑呗，就这样，由于变动的需求，原来的api已不再使用，继续找呗，这个过程是痛苦的，调试，调试，调试…，搞了半天，满足了功能实现

接下一步是我的程序不够健壮，需要判空的判空没？最大值，最小值的判断需要不？提示信息写的对不，用户能看懂这段提示么？好了，这些东西都满足了

接下来就是我的程序写的优雅不？我的同事能看懂么？他们看不懂，怎么办？估计会被吐槽写的什么？

一步步优化，就这样，自上而下，每一步要做什么？每个方法要做什么？都进行合理的剥离出来，关于方法的抽取我个人是比较赞同单一职责的，不要乱七八糟的参数都放进来，没用，你放进来干嘛呢

就这样，采用了三步走策略，检查参数，编写有条理的业务逻辑，封装返回数据格式，一个需求就这样完成了

其实，说实话，到这里，我们才经过自己单方面的程序编写，接下来，还需要很多事情要做…

前后端分离下，需要提前把接口文档给到他们，毕竟数据的展示，排版呀都需要他们的，这也是比较重要的一点，还要和他们简单对一下字段呀，需求呀，就这样你的任务也仅仅完成了2/3

最后，你可以使用接口工具去编写一些测试用例去调试你的程序了，是否有NPE问题？是否会有在编写程序时未考虑的场景？程序会有异常么？权限检验了么？接口需要做限流么？日志需要记录么？异常有捕获么？存在事务问题么？等等等能说的还有好多

就这样，还是在别人没有来打扰的情况下，你才能一鼓作气写下整个需求，倘若中间被拉去开会，别人找你看问题时，你的需求实现就会被一拖再拖，拖到最后，距离上线还有一点点时间

这里没有提到项目发版的内容，一般我们的程序如果没有重要的问题都会按照固定的日期进行发版，比如说，每周几，每月几等等等，这里就不过多说了，我快要到家了…