算法设计与架构设计

最难的是开始，最惨烈的战争是事后。
朋友晓月曾经告诉我，开发三条路：算法、设计、系统。

系统，这条路，需要对文档和环境有足够兴趣，这块不适合我。算法和设计，我倒是很有兴趣。我希望能把算法和设计该怎么做好好想清楚。

算法
对算法有兴趣的朋友可以看这本书： http://item.jd.com/11098789.html

算法，由难到易，有四件事可以做：

1 ､扩展现有算法的应用领域。

算法发展到今天，已经积累了相当多的存量。除了新创算法以外，目前最迫切的需求大概是需要一大批去研究现有算法，把这些算法的优点扩展到更多领域，优化那些一直被错误操作的地方。这座算法金矿，有两种生意可以做，一个创出有生产力的算法，一个帮更多人进来挖矿。

2 ､优化算法的空间。

对存储的读写，一直是计算过程最大的限制。如果可以优化算法的空间占用，更少的读写次数，在更小的读写空间上遍历，将有助于提升算法的速度。空间上的优化，造就时间上的同时优化。

3 ､优化算法的时间。

CPU/GPU 等计算资源的提升，使得时间上的优化越来越没那么重要。但如果是从指数级优化成线性级，不管计算资源怎么改变，都会有明显的差别。随着大数据云的扩张，时间上的优化也会得到更多的重视。

4 ､理清算法的验证方法。

一个算法能不能用在当前环境，在未来一段应用时间，是否可以满足需求，这是对算法认识的最低要求。

架构
对架构有兴趣的朋友可以看这本书： http://item.jd.com/10057319.html

设计，由难到易，有四件事可以做：

1 ､测试架构的稳定性、可维护性、可扩展性。

一个架构设计到最后，应该有一份详细的比较数据。清楚地显示在什么地方有提升，提升程度如何。这是架构选择的根据，而不是去靠跟别人讨论、八卦、打嘴仗。

2 ､叠加现有模块满足需求。

通过已有的基础模块和业务模块的叠加快速搭建需求变化所要求的服务。

3 ､理清模块间的依赖。

通过模块间依赖最小化的设计，将有助于提高模块的独立性，提高模块的复用程度。

4 ､清楚问题的充要条件。

什么是业务必需的，有哪些地方可以裁减，尽可能降低业务使用的难度，这是架构设计的基本要求。

算法设计上，我一片空白，只读了《算法》第 4 版 200 页的书。架构设计上，我非常新手，只初步熟悉 VIPER 、 MVVM 、 MVCS 、 MVC ，只看了《设计模式》的 150 页。这是我的算法设计和架构设计框架的第一版，希望在这方面有经验有想法的朋友可以不吝赐教，帮我完善好应该怎么去做这两块工作的框架，不胜感激。

后记(下面以聊家常为主，没时间没兴趣的朋友请直接忽略)：
我还在尝试验证“递减原则”。只做了 150 个仰卧起坐，比昨天还少 3 个，比前天少 150 个。健身是非常好的可以反思“递减原则”。以目前的结果看，“递减原则”效果远远差于“递增原则”。

也不是毫无收获，今天第一组做了 100 个，比昨天第一组的 75 个有明显提升，比前天的 50 个更是差天差地。今天，同事都被我能做 100 个惊到了。

递增原则在总量上也许有优势。但它没有附加效果，更多是纯拼力量。而递减原则往往会有很多附加效果，在总量不足的情况，可以附外获得很多成果。而且，在递减原则下怎么增加总量，我也有一点点灵感。

就是，不要因为下手点的困难辛苦放弃再次尝试，哪怕下次尝试的效果微乎其微。我第一组做了 100 个，第二组做了 10 个。这个时候，我觉得今天完蛋了，大概只能 110 收场了。过了一会，我再做，第三组却神奇地能做 30 个。

在递减原则，也许，开始的那组会比较困难，但是第一组的困难尝试，却往往可以给后面的尝试打开新的道路。

又比如我对 VIPER 的尝试，对 Casa 大大的离散型网格模块的尝试，对 Casa 大大的数据调整器的尝试，虽然最后未必能直接用到项目中，但见过好东西之后，我就本能地知道比之前好一点的代码应该怎么写。

我用“递减原则”重新优化了一遍我的方法论：疯子一般深入系统。

长久以来，我一直对这套系统非常不满意。因为它虽然从低到高给我在人生选择上提供一个顺畅的指导。但总是让我感到无聊。而且它对高手、老手、新手的指导无法达到同样的效果。

引入”递减原则“，可以让这套方法论有更普遍的适用范围，也就是我现在的算法设计框架的第一点：扩大适用范围。

递减原则，可以让我第一眼就关注到最能让我兴奋的选择。如果我能力不足，才是第二选择，这样可以让我的热情利用最大化，把我的潜力用到尽。