企业定制软件开发不是计算机科学。有什么需要解决的不是编译原理或组合数学。那么，什么是企业定制软件开发的核心问题？
我越来越觉得，在一个领域从事不需要有特别深刻的理解，但至少知道需要什么核心问题，在这一领域需要解决。例如，在Ｃ的发展／ Ｓ结构软件，状态同步（Ｃ ／ Ｓ的状态同步和窗口之间的状态同步）是核心问题之一，而Ｂ的发展／ Ｓ结构软件，状态同步是没有这样的核心问题。如果事先知道需要考虑这些核心问题，您可以与具体事务遵循打交道时，提高解决问题的水平，以更宏观的层面。
目前，我个人觉得有企业定制软件开发两个核心问题：
１．如何确保所有参与者的通信强度（研发团队，包括客户和最终用户），使他们能够满足完成发展目标的需要
２．如何管理自己的企业定制所带来的软件固有的高复杂度，从而使复杂不会超过球队的维修能力
在介绍了该组织以前的博客，我谈了第一个核心问题，通信强度的问题。至于球队而言，以消除个人能力，最重要的是人与人之间的沟通。如果没有良好的沟通，即使球队的个人能力是超强的，它们不能形成合力。但是，只要有良好的沟通，至少人们可以让他们物尽其用。假设一个标准的人的生产力是１次／天。一些特别强的人可以达到３ ／天。但是，如果你需要实现１０ ／天的生产能力，完成由市场允许的时间内的项目，那么你不能用一个人来完成任务临时，所以会有需要一个团队。但是有两个标准的人，也不会达到１ ＋ １ ＝ ２ ／天的生产能力。它可能只是１．５。有三个标准的人，他们不会达到１ ＋ １ ＋ １ ＝ ３ ／天的生产能力，这是很容易有１．８。那么是什么限制了团队的整体生产力，那就是沟通。当两个相关的任务Ａ和Ｂ是由一个人来完成，关于任务Ａ的知识存在于左脑，以及有关任务Ｂ知识右脑存在。然后组合的两个任务知识来组装它的通信效率是大脑内的电信号的速度。但是，如何任务Ａ通过开发一个完成，任务Ｂ被开发完成若Ｂ完成，整合这两个任务的效率是由人类口腔的振动频率，通过表达能力上的限制约束，并通过理解能力上的限制。有人研究过，即使两个人互相面对，数据传输的比特率比最早的拨号Ｍｏｄｅｍ低。更何况，有时开发团队是分布式的。我看不到面部表情，身体语言，不能共享白板，只能听到越洋电话的声音，其中一人是不工作小时。在这种情况下，１ ＋ １几乎是不可能达到的１ ／天的生产力。什么是高效的团队是一个团队，可以使１ ＋ １的值尽可能大。如何成为高效，让沟通更有效。如何使通信效率和强烈？这是核心问题，我们必须处理。
第一个问题可以适用于所有的人的团队行为。只要人们聚集在团体，会有沟通问题。所谓，那里有个人，也有河流和湖泊。第二个问题是针对企业定制软件开发。对于互联应用的发展，也许是复杂的管理是第二，最重要的事情是下了大量用户的可扩展性。但对于企业软件定制开发，在定制软件的复杂性是由于业务本身的复杂性。尤其是企业的合并，导致组合的复杂性。假设在理想的情况下，系统可以被分解成模块Ａ，Ｂ，和Ｃ中，所有具有的复杂性２．在良好复杂性管理的情况下，这些模块被分得很清楚。要了解一个，你只需要注意Ａ，Ｂ和Ｃ之间的相互作用少量也许理解复杂仅为２ ＋ ０．５。但是，当复杂性没有被管理，所有的“逻辑”（即，复杂度）被随机放置。那么有没有办法保证的阅读逻辑只需要注意一个，甚至是这方面的一个不存在。你看到的知识是包括Ａ，Ｂ和Ｃ，这是一个完整的片的功能的系统。要真正理解这个系统在这个时间的行为，可能需要很大的代价的２ ＊ ２ ＊ ２ ＝ ８，随着模块的增加（变量，方法，类，包，模块，包），我们需要的东西同时了解也在增加。这是不可能的管理复杂性。这是非常可能的，我们需要了解的功能，我们需要阅读所有的代码。换句话说，一个方法是改变，使整个项目需要再进行测试，因为没有值得信任的地方。如何管理复杂性？这是核心问题，我们必须处理。有趣的是，这两个核心问题重叠。想想人角色的类和接口抽象为点。懂沟通人与人之间的连接问题。其复杂性也被理解为类之间的依赖性问题。那么通信问题和复杂的管理问题是如何把这些点连接线上，形成一个高效的图形。这张照片是“依赖”的图片。人与人之间的关系，类和包之间的依赖之间的依赖关系。对于依赖的另一个名字是耦合。而我们追求的是凝聚力。这两个词耦合（Ｃｏｕｐｌｉｎｇ）的美容／接应（凝聚力）是人们谁了解，根据自己的经验，一眼点头。谁不明白，因为他们不具备相应的经验，不管他们如何解释它的人，他们很困惑。正是因为其“妙”的性质，我可以说，这两个词回答所有问题（你无法反驳的话）。但至少我们可以知道，企业定制软件开发的核心问题实际上是一个：它是管理人员和包之间的依赖之间的依赖关系，使信息可以迅速高度依赖人与人之间（重点转移信息的效率通过耦合带来递送），和理解可以被限制在高内聚模块（强调通过凝聚带来的维护的便利性），但在同一时间，有人不能由被过度劳累依赖和过度劳累。你越依赖，更好的体能。这同样适用于包装凝聚力如此。高内聚性是最小的编译单元（类？），这将导致过小的封装粒度，使包装庞大的数量，失去维修的便利性。我们需要做的是根据依赖或不依赖现场做出选择。
因此，在抽象的术语，无论是为了解决通信问题或复杂问题，可以归纳为：
１．设置目标指标
２．测量现有的指标和观察现有的依赖关系图
３．依赖于图的调整计划并执行
４．观察在指标的变化
５．重复步骤３和４，直到达到目标
但问题是：
１．如何衡量指标？沟通的效率？代码的质量？他们都是可测量的。
２．如何遵守现有的依赖关系图？软件包的依赖关系仍然可以观察到，但团队协作更难以观察。
３．如何调整依赖图？重构？变更代理？人是不容易改变的代码。
４．如果指标不是简单的数字，如何比较？你怎么知道该指标朝着目标变更？
这四个问题都几乎没有确凿的科学问题。管理复杂系统的复杂性，可能是硬科学。然而，定制软件，为企业的发展与人的因素不能是硬科学。那么，数学公式是不回答这些问题。所以，在哪个方向，我们应该努力？
返回列表