一、背景
项目背景是某成本测算系统要在原来的住宅逻辑上要求融入商业的逻辑，针对需求第一时间就会考虑这些问题，并且考虑解决的方式、面临的风险等。
1、商业和住宅相互比较差距有多大？
2、住宅的逻辑可以包括商业的多少？
3、系统目前框架扩展性如何？
4、对于需求是编辑、新增还是重构？
在基本了解需求之后就动手对系统进行整改，在这个过程中没有考虑的问题开始浮现，设想的解决方案不能解决问题，业务测试中需求理解出现偏差等，所以针对这些问题提出一些的思考和总结，这些内容可能是很多软件开发中普遍存在，也是总结过很多遍的内容。
二、思考
1、明确的需求，一个明确的需求对于软件开发来说是至关重要的，在软件工程相关的书籍和前人的总结中都是很重要的一条忠告。但是很多时候情况并不会按照设想一样有着明确的需求，要么业务人员对业务的不确定性，描述的不够清晰明了，要么就是对接需求人员没有真正理解到需求，这个时候就是不明确的需求。在项目中比如“反算”、“业态”等这样表意不清晰的词汇，如果这个时候不带着严谨的态度弄明白，而是按照自己一知半解的来开发，结果很可能是返工或者重来的风险。这就要求我们对待需求保持着精益求精的态度，明确的需求是一个好的开端。
2、共同的语言，在业务系统中，业务人员和技术人员相互沟通的过程中很多时候就是业务对一个需求诉说着各种专业的名词，业务的角度解释为什么是这样子？依据了行业的什么标准？参考了什么规则？设计的初衷是什么？这时候的技术人员完全就是不理解，似懂非懂的样子，然后按照自己已经理解的开始对业务人员诉说技术上怎么解决，设计怎么样的数据库和字段、使用什么软件技术，然后业务人员因为行业原因一样不懂，觉得是按照他诉说的样子开发的，在测试的时候大家都会恍然大悟原来不是这样子。究其原因还是大家没有一个共同的语言，没有统一语言，交流不在一个频道上，这也就是为什么要在一个行业深耕多年，才可以把这个行业的业务做好，因为这是一个通过多年付出学习成本，学习相关行业知识的过程，和业务对接的时候无缝对接，在开发时候选择最优的技术，甚至想到业务没想到。但是很多时候这是一个比较理想的状态，所以合理就是与业务人员建立共同的语言，互相在共同语言的框架下沟通，这样出现偏差的可能性相对小了。
3、换位的思考，换位就是系统开发人员站在业务的角度审视系统，比如业务人员使用系统功能的时候，是否会出现歧义，是否操作的顺畅，是否接受这种方式，不同的业务操作习惯，要求不一样，比如会计相关的业务对数值精度相当的敏感，金融行业对安全性要求高等。
4、完整的文档，不管是在系统开发前的文档，还是开发中，开发后的文档都是记录一个功能开发过程，方便开发人员依据文档开发，是业务、需求、开发一起确认的，当要功能朔源的时候有查找的内容。而且对于要进行二次开发，新增需求时候重要考虑的文档信息。
三、总结
在这个系统融入商业需求中，与业务人员的沟通，对代码调整与重构对这些思考深有体会。很多项目这些问题是不可以避免，更多的是尽量进行规避，减少不必要的需求误差，寻求最合理的方式，对业务要足够重视。这就是业务与技术的矛盾，业务建立业务的圈子，技术建立技术的圈子，没有交集，出现矛盾的状态。