软件架构-划定边界


边界，是某种范围的明确区分，有了边界，就有了范围，有了范围就有了工作的目标和任务。边界的明确，是明确责任和控制成本的基本基础。试想，某个工作没有边界，没有范围，那么你如何可能完成这项工作？软件的边界就是对我们软件的某些限制，确定我们可以在此边界的基础上完成我们的软件。
从形式上说，边界来源自两个方面，第一种，明确了契约的边界，这种边界是以合同或者协定的（包括口头）方式确立。比如和客户签订的合同或者约定。第二，是隐形边界，这种边界没有明确的契约，边界的划定在于你本人。
明确了契约的边界，有明确的说明，通常以文字的形式固定，双方签字，这种边界是有据可查，有责任可追究的，只要在契约范围内，就有据可循；谁违反就是谁的责任，所以这种合同对于关键问题都做了明确的约定，当然最好具体问题也能写入就更好了。可惜的是，合同或者协定不可能面面俱到，也不可能对每件事都先见的加以约定，所以这种明确边界下则是模糊边界，而模糊边界则是实施工作的一个障碍所在。模糊边界就会造成责任不清，责任不清就会相互扯皮，相互扯皮就会浪费时间，人力，增加投入成本，另一方面，也会使得双方对对方的印象大大折扣，沟通困难，效率降低，进而拖累推进进度，增加成本投入。对于软件，时间就是金钱，除了合同的约定日期外，还有自身投入的压力。要知道，一个每个月的实际花费是看的见工资的2倍以上，而这种模糊边界拖累的不止一个人，而是一个团队。就是退一步说，不计算成本损耗，节约下扯皮的时间，让团队的人员来学习增强技术水平，于团队于个人来说，都是好的。所以，有可能的话，任何可能引起扯皮的事都做个明确的契约边界吧！本人的一个朋友，做基础平台产品的，他将产品卖给第三方客户，第三方客户在平台产品基础上做二次开发，卖给最终客户，除了买卖合同、支持时间和保证最终上线等约定，没有其他契约规定，于是问题来了，任何和产品沾边不沾边的事，包括上层开发，对方都要求他来做，他如果不做，对方就说他的产品有问题，拖累项目上线。如果项目不能成功上线，则属于违约，除了赚不到钱外，还要倒赔一大笔违约费，于是没有办法，他将所有人员拉到现场，做第三方的包工，给第三方做了次实实在在的“奴隶”.........
隐形边界，是说没有明确契约的约定，是在软件实现的时候，你所把握的度。所谓“过犹不及”，不及，自然不行，你没有达到既定的目标，这个是不能被明确了契约的边界所以接受的。但是“过”也是有害的。过自然是过度了，过度就是做了契约以外不需要、不关紧要甚至无用的工作，这些工作除了浪费成本外，还可能因之影响工作的顺利推进。我们姑且称之为“过度开发”；本人认识一个人，他领导做了个项目，项目合同期限6个月，由于是第一个接手的项目，非常想表现一下，以为后来的项目到来做好铺垫。客户说，现在我们需要满足300并发，将来可能需要提升，那是以后的事。于是为了表现，一鸣惊人，他决定将并发调整为1000。为了拿下后边的项目，处处留有接口（面向接口编程？），处处是通用代码开发（就是为了更好扩展，而抽出通用的代码，应用设计模式），结果，时间过半，还没有看到成型的东西，这种过度开发直接影响了合同的履行，导致赔款破产。还有一个实例，本人的一个朋友所在公司，每次联系发现他都在外地支持，我问他为啥一直在外地，他说，项目问题多多。原来，在JSF刚出现的时候，他的领导认为这个东西很好，为了将来竞争者取得主动，决定在项目上率先应用。可惜的是，那是JSF还不稳定，于是各种问题莫名其妙的出现，不得不常驻客户现场解决问题，除了造成客户的抱怨，还使得支持费用大幅提升，影响合同的旅行。当然也有用非常古老的技术来实现项目的，结果造成开发周期变长 ，性能跟不上，系统展现老旧等问题。
所以，一定要控制好边界，尤其是隐形边界。