X
xiaorang
Unregistered / Unconfirmed
GUEST, unregistred user!
==============================================================================所有的受苦都由我执创造且源于抗拒。——《当下的力量》【入段】作为软件开发者，如果尚还不能根据固定不变的需求写出程序，那还是处于“未入段”的时期。你还有很大的学习空间来提高自己，以后我也将会写专文来讨论。不过即使当你对于“实现”任何需求都感到自信满满的时候，也没有什么可高兴的——因为软件开发的真正挑战才刚刚开始——【挑战】需求的变动一直是软件开发领域中真正巨大的挑战，对许多软件和软件开发者来说，是一片挥之不去的阴云。对于有一定复杂度的软件，初期的开发注定是不完善的，用户永远会提出看似合情合理的“微小”的改动。而当你试图修改时会诧异地发现，用户试图改动的竟然是系统基础框架的一部分，看似微不足道的变化将导致颠覆性的变动和巨大的工作量——当然，一个高段位的软件开发者并不缺乏解决办法。遇到类似的问题，大抵有两大类处理方法：【方案一】一个是设计临时的补丁方案。非常好，用户的愿望被实现了，以很小的代价实现了用户的改动需求。但事情并没有结束，用户会不断提出类似的貌似微小改动，整个系统被打上一个又一个补丁。用户可能会一直非常欣慰地认为系统在她的努力下不断完善着，直到当她的最新的一个需求变动被拒绝，并被告知整个系统在已经在她的肆意破坏下已经变得很不稳定，只有大规模的、成本高昂的重构才能解决问题。给用户留下印象深刻的挫折感之后，又回到了另一个解决方案——【方案二】有些设计师很“敏锐”地注意到了这样一些看似微小的需求修改对系统构架可能产生的巨大影响，对这类问题都坚定地走系统重构的路子，在更好的逻辑架构下包容用户的需求。毫无疑问，看起来这是个完美的方案，但用户可能无法接受如此小的问题会导致如此高昂的改动费用和时间。于是，开发者抱怨用户不懂技术，考虑不周全，乱提需求；用户抱怨开发者不懂业务，连这么自然的需求都不能事先考虑到——问题仅仅是被转换了一个形式，并没有得到真正解决。【折中】现在的用户大都接受在一定时期内在需求变动时进行小规模的系统维护，并且定期进行较大规模的系统重构，从而整合所有的临时补丁，并加入一些大规模的改动需求。许多复杂的大型设备，比如高炉、发电机，都是这样在运行，系统的日常检修维护配合定期大修，可以很好地维持设备在相当长时间内的正常运行。但软件系统却具有一些不同的特色——【软件的特色】众所周知，软件行业的从业人员，具有很高流动性。软件系统在打补丁的过程中，往往已在很大程度上偏离了最初的设计，所有这些修改，几乎都在无文档的情况下进行。一旦开发者离开，后继者不得不费很大的力气阅读源代码，才能勉强了解软件的现状，从而接手进行维护。而这种努力的本身是不能创造任何价值的。所以，几乎没有人愿意去接手别人维护的系统。这样的高流动性导致这样一种状况：一但核心开发人员离开，后续的维护者和开发者就会逐渐开始呼吁重新构造系统，而这种重构并非是为了用户的使用，更多的是为了自己的方便。更糟糕的是，由于新人对业务和系统的理解参差不齐，这样一种重构并不能保证超越前一代系统，于是巨大的投入和开发工作带来的效果只是原地踏步。还能有更好的方案么？文档？【文档】文档是一个软件开发领域神奇事物。很少有人真正知道对于一个软件系统应该建立哪些文档？这些文档都是干什么用的？谁在用？在很多公司里，文档成为一种额外的工作，软件开发者并不能从文档写作中得到任何好处，得不到报酬，学不到有价值的东西，也就不愿意投入精力认真对待。如果你在软件中发现了和文档不同地方，真是一件太平常的事情了，尤其是在长期的维护过程中。没有人会完全相信写在文档里的东西，真正可靠的软件设计思想，只存在于开发者和维护者的记忆之中。一旦他们离开了，就只剩下阅读源代码一途。【成本】即使让公司支付给软件开发者和维护者写源代码的费用，仍然无法真正保证文档的完整性与可靠性。而且将直接导致公司成本的大幅度提高。而现在的软件公司，尤其是给企业做项目的软件公司，本来并非是高利润的公司，很难承受这样的成本增加。更何况，这些公司正面临着另一路解决方案的越来越强烈的竞争，更使他们无暇顾此——【开发平台】在这样一个变革加速的时代，公司若想生存并发展，其业务必须紧随市场变换，而公司所购买的软件系统恰恰是为了表达其业务模式而设计。一个业务软件若想发挥真正的作用，其更新的速度将是非常快的。传统的软件公司的表现已经证实，他们无法在合理的费用下完成这一使命。于是出现了开发平台。开发平台一般集合了大量信息管理系统的常用组件，让开发人员可以通过组合这些组件大幅度提高开发速度，以适应需求的快速变动。并且由于组件是经过充分测试的，所以组成的系统可以具有很好的稳定性保证。【普适性悖论】开发平台的终极目标是让业务人员自己开发自己使用的系统。但这已经被证实，是个无法实现目标。开发平台自身有个内在的无法解决的悖论：普适性悖论。开发越简单的平台其普适性就越差；而灵活性越高的平台，其使用复杂性也就越高。而真正能解决所有问题的平台，就只能回归到软件程序语言本身。开发平台真正能解决的问题是那些重复性很强的问题，而对于一个软件系统来说，成本密集的区域恰恰是那些独特的部分。如果有人会认为试图通过巧妙设计周全定义的开发平台可能解决所有应用软件系统（甚至只在一个行业中）中出现的问题，那仅仅是因为他们不懂得可计算性理论的基本原理。【DSL】领域专用语言（Domain Specific Language / DSL），这个同样不够普及的新事物，也许可以成为一个暂时的解决方案。一种面向一个具体领域设计的语言，只能解决一个具体领域的问题，具有更高的可读性，更高的开发效率。其出发点就是接受了开发平台的普适性悖论，彻底放弃普适性，在程序语言的级别上支持一个领域的应用。如果DSL能够大行其道，软件开发将变成一个高度分工化的行业。由于高度细分，软件开发者随意跨越不同行业开发软件的情况会基本消失。这样的领域必须能够提供足够广阔的空间，独立支持足够数量的参与者。如果某个领域的DSL能够大行其道，这个领域的软件开发问题将会得到极的的缓解，这并不代表问题已经解决，可计算性理论可以保证，DSL的架构会被不断挑战，直到它无法自圆其说地描述这个领域。【根源与解决】如果需求不再改变，任何入段的软件开发者都能够开发出完美的软件。但需求是处于永恒的变化中，而且会加速，这就是软件行业现有问题的一大根源。软件行业中许多重大的发展都在围绕这个问题进行。许多解决方案在试验并失败着。现在常见的提法改为了“最佳实践”，这样表达了一个更加谦虚也更有可能成功的态度。问题终将解决，但肯定不是用许多人所设想的方式。=============================================================================