在开发业务需求的时候，往往策划有时提出的需求不是那么简单和合理，我在工作中遇到过很多次，有些是可以通过近似的结果来满足需求，但有的不是那么简单，比如下面的一个需求，在大部分游戏项目中可能都会遇到。
角色身上有十个部位，每个部位可以穿戴装备，且对应的装备可以由碎片合成(可能在合成的时候也要花费其他材料)，且能穿戴需要花费一定的资金和经验，某个碎片不足的时候，可能由另外的材料合成，大概需求是这些。
后来在开发完后出现两个bug，其中一个是需求不明确(能在不同部位穿戴相同的装备)，另一个是后期加的需求，由另外同学在原代码基础上加的条件，因代码位置不对导致可能有其他能合成的装备，没有机会合成和穿戴，进而导致整个逻辑出问题。
其实这个需求是不难，但因为能自动合成，这里要考虑的是递归的深度，尽最大能力来满足当前可穿的，不能出现不能穿的却被穿上，或者扣除材料出现负数。
比如A装备合成需要材料1，2，3，数量10，15，20，花费金币300，需要条件X；B装备合成需要材料1，2，3，数量8，10，11，花费金币500，要条件Y；玩家现在没有A和B装备，但有材料1，2，3，数量分别是10，15，20，金币1000，条件Y；条件是后期功能完成后加的。
有问题的写法是在能合成A时，需要的材料先预扣除，但是在处理其他条件时，发现A不能满足X，导致后面的B没机会被合成和穿戴，所以这里需要把对条件的判断移到适合的位置，先过滤，然后再进行合成。
因为这里合成是递归的，需要考虑什么时候停止，因为策划的配表数据，可能会造成A->B->A这样的循环，如果中间再多层不是很容易发现，那么程序很可能进入死胡同。这里要么在导表时通过工具检查配表，在提交时发现问题，要么在程序中，限制递归的次数。
再比如上面的需求，A装备合成需要材料1，2，3，数量10，15，20，花费金币300，需要条件X；B装备合成需要材料1，2，3，数量8，10，11，花费金币500，要条件Y；C装备合成需要材料1，2，3，数量5，5，11，花费金币500，要条件Z；玩家现在没有A/B/C装备，但有材料1，2，3，数量分别是13，15，22，金币1000，条件都满足；这里看能合成A，或者B/C两个，因为A/B/C装备的属性不一样，穿戴A能提供10000战斗力，穿戴B能提供6000，穿戴C能提供5000，为了寻求最优化，这里是不能合成A的，需要把B和C进行合成。
所以，问题就归纳为贪心或者背包类的算法问题，因为我对这块没有过多的深入，这里暂时不再分析算法本身的思想。
