我的思考——软件开发中的“收敛”

从事了几年的软件开发，期间学习了很多名家的知识和经验，自己也经历了一些实践，不经意间自己也会有一些个人对于软件开发的思考，可能不像名家的言论令人信服，也没有严谨的论证，权且给大家说说，希望能在一定程度上帮助到大家，足矣。

今天想到了软件的“收敛”，就来谈谈它吧。学过高数的都知道收敛的含义，我这里“收敛”意义与此类似，指的是无限逼近一种状态。

软件需要无限逼近什么状态呢？

软件无限逼近的状态就是暂态稳定状态，就是在某一个阶段，我们希望软件能够有一段时间不需要变化。这个时间可长可短，对于需求变化剧烈的，时间可能不会长，对于需求相对稳定的，时间则可能会相对久一些。

但是，软件存在着太多的风险，软件开发是一个充满主观性的创造过程，其中有很多未知的问题等待着我们，我们每天都在解决各种问题，迎接各类挑战。当需求不再变动，代码不需要更改时，反而意味着我们的软件生命即将终结，而不是我们的作品完美无瑕。

所以，软件的生命周期伴随着需求的变化，需求的变化必然导致后续的一系列变化：架构设计的调整，代码的调整，新bug的引入等等。我们如何能够让我们的代码“收敛”呢？

高数中，我们如果要让一个函数值收敛于某个值，采取的办法是让变量沿着某个方向变化。当变量值无限逼近某些值时，函数值就会收敛于某个值。

我们借着这个思路（感谢伟大的数学XD），看看我们的软件开发。

软件产品（V）中最根本的变量就是需求（X），设计（Y）以及编码（Z），所以V=f(X,Y,Z)，而当V过测时，软件是合格的，否则，软件不合格。

设计（Y）是需求（X）的函数Y=g(X)，当Y满足需求时，设计是合理的，否则，设计有待改善。

编码（Z）又是设计（Y）的函数Z=g(Y)，当Z按照设计要求实现时，Z是合格的，如果Y是满足需求的，那么Z也是满足需求的。反之，Z有可能是不符合设计的，也有可能被设计误导，导致偏离需求。

需要澄清一点，上面的关系只是说明软件产品与需求，设计和编码的关系，不是说我建议软件开发流程是瀑布流程，每一个变量的收敛需要迭代，软件的收敛也需要迭代，而且迭代的收敛速度不要求一致，必然导致整个软件开发流程是迭代的，每个步骤的进行过程也不需要首尾相接。

所以，我们如果想让V收敛，就应该保证X,Y,Z收敛，那么，我们如何做到呢？从上面的分析中，重中之重在于需求，只有需求的逐步“收敛”，也就是需求迭代的逐步清晰，才能保证设计的迭代逐步完美，进而保证代码的迭代逐步完善，最后生成暂态稳定的软件产品。

虽然上面的想法很清晰，但是实践中却可能遇到很多问题。为什么需求总是变更？为什么设计总是让需求方不满意？为什么代码总是要改？为什么每一个步骤的速度总是赶不上其影响因素变化的速度？

这其中每一个问题的解答，都需要当事人付出极大的努力，还需要相关方的交流沟通，解决这些问题存在着各式各样的方法论。我才疏学浅，也限于篇幅，无法列举，但是，我常常思考一些如果，也和大家说说，或许让每一个如果成真，我们就解决了上面的问题。

如果需求可以挖掘的更深入一些。

如果需求分析可以采用更多的手段。

如果需求讨论能够更直观一些。

如果设计可以更多的考虑需求的要求。

如果设计能够更好的考虑使用的技术以及与技术的匹配程度。

如果设计能够尽可能地考虑系统的可扩展性。

如果编码能够更好的协调设计，需求和技术三者之间的关系。

如果在编码过程中能够更好的做重构。

如果编码过程中能够做一些力所能及的测试。

如果编码能够考虑的代码的维护性。

......

这些如果不是一个人可以胜任的，需要的是一个团队，需要的是公司领导层的支持，需要的是一个良好的企业文化和软件开发流程。这些条件可能无法全部满足，但是上面的如果能够尽可能多的实现，我想软件的风险就会更小一些。

话题有些沉重了XD，本文也到此为止吧。希望软件的未来愈发光明，程序员的工作负担和压力愈发减小。