我做软件设计有一个重要原则，即经济性。这个原则最终决定了软件的功能和定位。两年前开始开发定下来的基本架构到现在都没有大动。这至少说明这个框架还是比较成功的。但随着时间的推移，问题也暴露出来的，比如不支持回退，不支持结果的回馈（即修改了构件向导产生的钢筋，下次重新提交的话不能记住修改）。有的问题可以通过改良来修正，而有些却需要用打破旧世界的革命来完成。这很令人恐惧。
再回到“经济的做软件”的原则，我们人手有限，而我们面对的却是一个艰巨的任务。这时候，就更需要我们发挥自己的智慧，以获得更高的工作效率。
工业革命有以下几个重要的里程碑：1826年的可交换部件、1901年的装配线和20世纪80年代的自动化装配线。我认为，所有这些的重要意义在于能够经济性的产生大批量的工业产品。那么，我们在我们的项目中引入框架就是必然。他就类似于一个装配线，将众多程序员的劳动串接起来，经济的完成软件产品。这里存在着一个问题，如果框架在某些方面不适合用户的需求，那么无论程序员多么努力也是不行的。那么框架能否设计成柔性的，就好像汽车工业的柔性生产线了。当然可以。如果说，设计一个框架的劳动是传统项目的数倍的话，那么设计一个柔性的框架就需要投入数十倍的劳动。这又牵扯到经济性的问题。
显然，在做软件设计过程中，这种权衡是困难但是必须的。所以，软件如何发展，做什么不做什么都依赖于自身的设计目标，并不是简简单单就改变的。比如，目前呼吁的列计算公式的问题。首先，我可以说，软件内部没有计算公式可列。如果软件简单到能把每种情况都列出公式，那编程岂不是太简单的事了。只要将这些公式全部输入软件中，然后调用我写的公式解释器，就可以万事大吉了。不过下场倒很悲惨，因为往里面输输公式的工作也轮不到我做了。另外nath提到的反推公式的方法则更不可行，简直是把我往火坑里推。因为其他人的前车之鉴还历历在目，我岂能再犯。
目前，唯一可行的是做好文档，比如做一个范例，里面有详细的手算和软件计算的过程对照。不过由于多种原因，这方面的工作一直没有做起来。
向大家汇报一下工作，要不然肯定有网友要质问我为什么不写这个范例。首先我不懂专业，写不好。另外我一直认为我最重要的工作是架构设计，下个月全新架构的图形法将要推出，这是我这几个月的工作成果。希望大家喜欢。
总结一下，好做的需求，我们一直都改的很快，成绩都在软件的升级说明里。不好做的，十有八 九涉及到架构。有些是水平问题，有些是出于经济性的问题，有些就是根本就没有考虑到。
再回到“经济的做软件”的原则，我们人手有限，而我们面对的却是一个艰巨的任务。这时候，就更需要我们发挥自己的智慧，以获得更高的工作效率。
工业革命有以下几个重要的里程碑：1826年的可交换部件、1901年的装配线和20世纪80年代的自动化装配线。我认为，所有这些的重要意义在于能够经济性的产生大批量的工业产品。那么，我们在我们的项目中引入框架就是必然。他就类似于一个装配线，将众多程序员的劳动串接起来，经济的完成软件产品。这里存在着一个问题，如果框架在某些方面不适合用户的需求，那么无论程序员多么努力也是不行的。那么框架能否设计成柔性的，就好像汽车工业的柔性生产线了。当然可以。如果说，设计一个框架的劳动是传统项目的数倍的话，那么设计一个柔性的框架就需要投入数十倍的劳动。这又牵扯到经济性的问题。
显然，在做软件设计过程中，这种权衡是困难但是必须的。所以，软件如何发展，做什么不做什么都依赖于自身的设计目标，并不是简简单单就改变的。比如，目前呼吁的列计算公式的问题。首先，我可以说，软件内部没有计算公式可列。如果软件简单到能把每种情况都列出公式，那编程岂不是太简单的事了。只要将这些公式全部输入软件中，然后调用我写的公式解释器，就可以万事大吉了。不过下场倒很悲惨，因为往里面输输公式的工作也轮不到我做了。另外nath提到的反推公式的方法则更不可行，简直是把我往火坑里推。因为其他人的前车之鉴还历历在目，我岂能再犯。
目前，唯一可行的是做好文档，比如做一个范例，里面有详细的手算和软件计算的过程对照。不过由于多种原因，这方面的工作一直没有做起来。
向大家汇报一下工作，要不然肯定有网友要质问我为什么不写这个范例。首先我不懂专业，写不好。另外我一直认为我最重要的工作是架构设计，下个月全新架构的图形法将要推出，这是我这几个月的工作成果。希望大家喜欢。
总结一下，好做的需求，我们一直都改的很快，成绩都在软件的升级说明里。不好做的，十有八 九涉及到架构。有些是水平问题，有些是出于经济性的问题，有些就是根本就没有考虑到。