本文主要是介绍对于订餐系统的一些扩展的感受，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
这几天，由于五楼食堂里面，由于订餐然后不去吃饭的人越来越多，食堂的亏损在增加，于是，行政部门呢找到我，要求订餐系统加一个扣款的功能，旨在把订餐但是没有去吃的人的饭钱都扣掉，然后就引发了下面的故事。
一、自己的理解
由于项目是已经上线将近一年的项目，所以不可以进行大改，所以，扣款的方法最好是一个麻烦，但是改动比较少的方法，于是我选择了和行政部门协商为做一个扣款的按钮，只要一点击按钮，扣款就成功了，并且记录到扣款记录中。这样是最简单的修改方法了，如果修改为订餐的时候就扣，则订餐模块需要改，刷卡模块需要修改，改动就不是一点半点了，至少需要三个人半个月的修改（老代码规范不是很好），加上三天的测试才敢上线。
二、老师的理解
由于这个是一个比较大的改动，所以直接就去询问老师的意见了，老师的答复却是，我早就考虑到了这个问题了，当时和楼下负责管理系统的人去讨论的时候，他们说不用这样做，并且我们的员工是不会这样的，到了现在却成了这个样子，怎么样，是不是我很有远见？
在说了，你们去年开发的时候我就和你们提过这个需求，需要做成可以配置的，可以考虑到他们会出现这个问题，去做，但是不在页面上给他展示出来，如果你们那个时候做了，现在只需要在后台打勾，然后收费模式就变了，这样软件维护起来是不是就好多了，我们在做软件，考虑问题的时候，不只是要考虑到客户现在的需求，还要考虑到客户考虑不到的需求，这样我们在软件维护的时候，第一，他如果要这个需求我们就可以在很短的时间把这个需求呈现出来，和他们说我们需要用三天，其实我们需要1分钟修改一下配置就可以了，这样的软件开发是不是不需要很多的维护了呢？
但是现在这种情况我们可以从另外一个方面来考虑，就是从需求上加上一个交易的系统，可以让来不及退订的员工打折出售自己定的饭菜，像这样的话，可以通过这个交易系统来增加这个系统的趣味性，但是这个功能也是可以配置的，我们可以自己在后台决定要不要给他这个功能的使用权。
第二天，老师在吃饭的时候又说了，我们还可以这样，可以加上一个自动寻找订单的功能，超过时间没有订餐的人可以选择自动匹配一份菜，然后订了但是不来吃的人可以发布一个随机的，让人来获取。在我看来，这个有点像玩游戏中的匹配对手，这样可以很快的满足没有什么特殊需要的未订餐员工。
三、总结
总结一下老师说话中的思想，第一是要想到客户提的需求中他没有想到的，并且以可配置的方式做出来。第二就是我们做的系统中的功能都是需要是可以配置的，这样也可以灵活的掌握客户的需求和可变的需要（变是永远不变的）。第三就是我们在做系统的时候肯定有一些功能是不一定会在一次做出来的，这个时候我们需要留下可以扩展的接口，让我们下次在进行开发的时候可以直接从这个接口进行一个开发，甚至不需要动原来的程序，直接开发一个可以使用这个接口的新程序就可以了。通过和老师的交流，真的是感觉软件设计也是一个需要练习和思考的功夫。
这篇关于对于订餐系统的一些扩展的感受的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
