软件开发的软件效率与软件开发效率及软件容错能力的重要性

 通过在几家公司工作，感觉各个公司的工作理念有很大的差别。

       第一份工作的公司，注重的是软件的执行效率。容错率极高，其中容错率包括：操作员的操作容错、数据库维护人员的数据库维护操作等等。

        很多软件的操作人员在对一款软件用的时间长了之后，经常找到方便自己的简洁的操作，有些简洁的操作是设计软件的时候本身就设计出来的，但是有的一些简洁操作则是因为软件本身的复杂逻辑关系，导致的软件漏洞（俗称BUG）。软件的一些BUG在软件短期测试和短期实施应用中很难测试出来。那么这个时候就要软件的设计人员在编写程序的时候，把数据所有的可能出现的意外情况都列举出来，并且都限制住。很多软件高手写的代码在别人看来好多都是冗余的代码，特别是在软件交接的时候，负责交接的人为了代码的维护方便，代码的简洁，严格按照既定流程等等原因，可能会屏蔽掉以前旧的认为是冗余的代码，其实这个习惯并不好。比如：当一个软件正在运行，操作人员正在往里录入数据的时候，突然性服务器重启，或者断电了。那么之前操作员操作的数据就有可能会出现问题，而且很有可能是软件开发时候既定流程外的问题，比如，单据没有号、产品BOM部分带入等等。那么这个时候一些看起来冗余的代码就会起到极大的作用。比如下个流程的时候检测单据号，检测BOM的完整性等等。这个检查在正常流程都是不起作用的，而且在软件任何操作的时候都不会产生这种问题。平时看来就还是冗余代码，但是关键的时候就起到了极大的作用。

       对数据库维护人员操作的容错：正如上面所讲的，当意外原因，如服务器或操作机器意外性重启或死机、数据远程传输导致意外性丢包、远程数据传输时网络意外性断开等等，都可能导致数据库数据的异常，而且这种异常有的时候在软件表现出来可能会是软件崩溃。那么就会设计到数据库管理人员直接操作数据库了，那么如果这个时候数据库管理人员在更改数据库的时候把已有的问题解决了，把数据补充完整了，但是由于疏忽，导致其关联的数据部分属性没有补充完整，那么这个时候软件里看起来像是冗余的代码就有可能起到减免手动操作数据库导致的意外损失的作用。（不要和我谈责任，我们开发人员要有职业道德，由于你屏蔽了一个看起来是冗余的代码，这种意外的数据突然蹦出来，造成几百万，上千万的损失的时候，谁都不好过）

       但是这种软件开发的时候，软件的开发周期肯定要长，而且日后交接的时候，也会出现交接不完全，好多地方不能让交接人员完全性了解其部分的重要性。

       第二个公司的时候，注重代码的简洁、规范。他们公司的原则是：开发周期要短，测试时间极少，要求软件既定流程的时候不会出现问题。优点：程序的可读性强，功能代码的理解简单，代码维护简单，程序交接容易。缺点：开发周期短，直接导致对操作的容错性下降。对意外数据的处理能力低。一旦出现意外数据，或者意外功能性BUG（意外操作，导致数据未按照既定流程走）那么容易导致数据不准确。如果是在集团性软件的时候，就很难找到BUG的根源。比如：我在他们公司试用期间熟悉ERP软件流程的时候就发现了这么一个BUG，半成品退库（他们的部分半成品是销售的）的时候，如果接收人员没有及时的提交（他们的软件设计为，单据的建立->单据的提交），半成品出库操作人员就可以再半成品出库提交功能里面发现这个退库的。而且可以提交，这个时候就会发现同样的物品，数量出现负的了（还好，他们是采用的是负数代表的退库，如果只是个标记那么就会出现更大的问题了）。而且他们程序在半成品出库录入数据的时候判断了数量及金额的正负，而在提交功能上未对数量及金额进行判定。这个时候就出现了这种意外BUG导致数据出现问题。其实再大多看来，既然数据录入的时候做了判定和限制，那么提交的时候一定就是正常的数据，这种想法在一个负责人的软件开发人员看来是不可取的。

       我们既然是做软件开发，第一点：保证客户的既定操作功能的实现。第二点：保证客户的利益不会在出现意外的时候受到损失。第三点，给客户的数据操作人员，数据库维护人员最大的容错空间。

       软件好写，好软件难写。负责任的好软件更难写。能够极大容错的负责任的软件不是一般软件工程师能够写的。不是他们不懂怎样写，而是他们不理解冗余有的时候也是艺术，有的时候也会解决客户的大问题。

 

  原始出处：知识的海洋我只取其一粟 

                      http://hi.baidu.com/bookmen/blog/item/e1dd08f5a433c731bd3109b2.html?timeStamp=1298830996140