从作坊到工厂_工厂和作坊的本质区别
作坊离工厂究竟有多远 (二）
smilemac
1. 软件大规模定制
在这个市场越来越起主导作用，定制的产品广受欢迎的时代，软件是否也可以做到大规模定制呢？首先看什么是软件的大规模定制。规模与产品的开发速度有关，如果一个定制的软件能够在一个月内交付，如果定制软件的交付数量可以与程序员数目成正比，我们可以将这种开发模式叫做大规模定制，如果这种结果能够出现，那一切将是多么美好！但这种开发模式可行吗？大家还记得那句著名的话吗：给再多的女人，生一个孩子也需要9个月。那么，这个答案应该是否定的。但是我们如果将软件生命周期用显微镜观看，也许会发现，我们不能够提高第一个版本的交付速度，但我们也许有可能提高第二个，第三个版本的交付速度。我们先看看软件的生命周期曲线：
图中②表明的是这样一个事实，任何体系结构均有一个扩展的上限，一旦达到这个上限，软件将变得难以重构，这时必须重新开发新的体系结构，有时这种开发可能会完全coding from scratch.
而基于每个体系结构的重构周期取决于该体系结构的设计是否有比较强的灵活性以及包容性。这也说明了体系结构设计的重要性。然而，需要注意的是，体系结构并非只有一层，一个软件的功能事实上可以划分出若干闭包，也就是说，不同功能之间的关系并非杂乱无章或随意组合的，如果去研究它，你会发现有一些功能是相关的，另外一些功能也是相关的，而不同组功能之间相关程度则弱一些，通过对其分解，可以得到若干个闭合的子空间，而对每个子空间作正交分解，可以得到若干稳定灵活的子框架。这说明了什么呢？说明即使每一次小规模重构定制版本，在定制开发新功能的时候，也可以丰富整个体系结构，为后面的重构活动修桥铺路，这是即使小的重构活动也可以产生的边际效益。
这样的生命周期，也体现了软件的这一商品的盈利方式，即高沉没成本，低边际成本。第一个版本，或重新开发体系结构的成本很高，但每一次小的重构则成本很低，但条件是什么呢，就是重构必须快。如果软件开发不以这样一种盈利方式来进行，则即便能存活一年半载，也可能难以为继，所以，如果你不能实现大规模定制，那就最好只作产品，而不要定制。
如果我们能真正实现上面一种软件生命周期，那么软件大规模定制则并非空想。但是这里依旧有一个组织架构问题需要解决，这正是下面要阐述的内容。
2. 非对称双螺旋组织架构
在现实世界中，定制软件的开发组织往往是针对每一次定制需求成立一个项目组的方式来应对，这是一种单层的结构，其缺点是显而易见的，项目组既是负责产品未来发展的唯一组织，也是直接应对当前客户，需要对当前客户负责的组织，这二者之间是有矛盾的。尤其当不同用户的要求有极大差异甚至截然相反的时候，项目组在疲于奔命，产品也在摇摆不定，这样每次的重构周期和产品质量都将是无法预测也无法管理的。那么如何解决这样的一个矛盾呢？
效率来源于分工，定制开发与长线规划是价值取向完全不同的活动，理应交给不同的人去做。我们再增加一层组织，叫做产品组，她专门作长期的产品规划和开发，但她又不是闭门造车，而是与项目组构成一种类似双螺旋结构的互动关系，但这种双螺旋是非对称的。
项目组在产品组开发的基础上为用户定制开发，而产品组的工作包括：1）将项目组作的有较好应用前景或对基础架构有较好加强作用的代码集成到基础架构中；2）基于来自项目组的反馈，预测未来可能有用的功能，基于此预测作日常的常规开发；3）或对来自项目组的预研要求提供支持。
这样，产品的方向及保证是来源于市场，也可保证以相对稳定的方式发展。只是这个产品并非最终产品，而是最终交付给用户的定制产品的开发基础。而最大的好处在于她最大限度的保证了一个稳定的可预测的产品质量。
软件到底什么最重要？当前版本最重要，那么是否就不考虑未来了呢，也不能，那么就都去做吧。其实这也是很多公司管理层与程序员之间的分歧，每个程序员都希望自己的代码漂亮，而漂亮的标准是什么呢？是耦合度低，可重用，可扩展性强，但很少程序员认为，漂亮的标准是可靠稳定。学校在培养程序员的时候也并没有告诉，当前版本的质量才是第一位！
<节二 完>
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/194914.html原文链接：https://javaforall.cn