关于算法和复用性，可维修性的看法

关于算法和复用性，可维修性的看法。

在上一篇文章  关于技术，框架，概念，设计 中说到关于复用性以后会说的坑，那么我现在来填坑了。

首先，来说一下算法。

算法大致分为，分析与实现两部分。这里我只谈算法分析的用途。

大致的场景我说两个，不讨论如何实现，只讨论为什么会要用到算法和大概应该怎么用。

1）批处理任务

定义如下：对保单表进行执行一年内的数据统计处理，要求统计出最大保额的保单号。

这个问题的解法对于开发人员来说十分简单，在sql语句中使用最大函数统计某一个字段就可以。

我们统计一下可以解决问题方法：

     1）SQL语句。

     2）分块读取，并行本地计算。

     3）2基础上进行排序。

     4）3基础上进行最优化排序。

     5）4基础上进行并行排序。

     6）5基础上进行最优化并行排序。

（排序并非最优化算法， 寻找第K大的数的方法总结，这篇博文讲述的比较全面）

以上大概6种层次的解决方法，1的方法最简单，代码也最容易维护。但如果面对数据量大，表关联十分复杂的时候，你的效率都限制在I/O上了，我这么说，16核的CPU，64G内存 假设他的RAID不太好，没有做磁盘和索引优化，或者恰巧管理员休假了且休假前忘了做按摩硬盘了（我们就碰到过这种情况），那很不幸，你的任务跑不出来，明天领导恰巧要结果，完蛋鸟！！。

所以，要解决这个问题，至少要看过算法，分析和并行方面的原理书才能知道一个较优质的解决方法。

当然您是只要遇到了问题，总能解决和思考出较优质的解，且没看过任何关于此成型的算法案例和书，这种算是天才了。

我觉得我们大部分（99%）都是前者。

在解决效率问题的基础重要工作的测试基准有两个 一个是测试，另一个是算法分析。

一般的工程人员认为只要测试就可以了，但这有个问题，就是你测试条件不具备，或者很难实现测试环境怎么办？（海量和复杂的数据，昂贵的测试机）

所以算法分析在这里很重要，先要有理论，然后再尝试测试。

2）应用功能

定义如下：前端录入有一个录入功能，假设有100000个地区，是正确的，要求录入的时候做提示，并不影响录入效果，实现等待时间不小于1秒。

比如录入"海"，会提示海淀，海新，海南等。假设词库里有海字的都要提示。

这个算法在各种搜索引擎上，能搜索不少，关键词：“下拉框 提示 算法”

---------------------------------------------------------------------------------------------------------

也就是可以认为算法和算法分析这种基本功：

结论：能够决定你对一个问题分析的时候，能够采用和选择的手段有多少和一个最优化求解的一个基本技能。

可维护性，复用性：

大部分人认为算法的可维护性很差。

我不认为！！

算法，是一个完整的可复用功能模块，所以内部的维护不需要再进行，这个完全符合软件的复用性原则，且无需维护，可维护性为0%。

也就是可以这样说： 要么用，要么换。如果你没做到这点，那只能说明你的软件结构糟糕，代码写的很糟糕。

这里我偷个懒，不具体举例了。

当然我用如下一个比较实用的例子说明，您能看懂，就看懂，看不懂，以后会懂。

我是这样描述：

[case 0] : SQL.execute();      [case 1: ( PARAM: case[0])  ] : len ( SQL.result)  ?                         [                               ( >100) : QUICK_SORT( ?P0 )  , ( <100) :INSERTTION_SORT( ?P0 )                         ]      [case 2: ( PARAM: case[0]) ] : SQL.split(?P0,100000) >[   async  QUICK_SORT(?P0)]

 

假设我们可以通过如上逻辑代码定义模版的情况下，那么他会自动生成你要的代码。那么请问，维护性如何？复用性如何？

而且现行的库大部分都是按照， 要么用，要么换的模式发展的。

我觉得没有必要去 维护继承，有必要去 复用继承。

上述描述代码就是个复用继承的例子。

差不多说到这。