函数式编程以及lambda 运算符的看法

最近接手一些代码.

其中用到了许多lambda运算符的函数内联方式的编程。

有一些的确用的还可以，但另一些，则并不恰当。

许多程序员，一些技法都学会了，然后就要用。

就象写作文一样，一个好的词汇，华丽的辞藻，未必能堆出来好的文章。

用一个技术，首先考虑一下这个词汇的优缺点，然后根据语境，选择用不用，如何来用。

设计是选择，是优化，这里的优化，绝不是华丽的堆砌。

作为一个老程序员，今天冒死，劝谏一些新程序员们，如何使用这类技术。

程序的第一目标，是可维护性

我们去买一样东西，事实上，你也实际上，把这一条放在第一位，只是不容易察觉。

今天，这不是要点，但是我们文章的起点，所以，我不想多说。

可维护性的前提，是程序的可预知性强

许多现在的程序员，代码里放了无数的 throw ，错误，一扔就完了。（请耐心往下读，这与本文主题紧密相关）。

这习惯糟透了，我可以断定，他们家里，也是乱糟糟。

为什么？

第一，语言学，从上世纪50年末突破以来，就没再有实质性突破，你不要以为新发明一种所谓的新语言，就能解决C语言和C++语言所面对的问题。

第二，C++的大师，如何解释throw的？一句话：你不得不用时。

什么时候是不得不用时？一般是说，你调一个接口时，而接口的内部，你并不清楚机制，也没有代码。

throw违反了许多原则，一个是事故立即处理的原则，没有得到保证。

你可以说，调用栈的信息，在throw里啊。

那我问你，throw所在的函数，存在的目的是什么？是完成一个功能吧？你一个throw，无非是把责任扔到别处去了吗？

这是负责任吗?不是。throw也丢掉了许多现场的信息。

程序里这样的事情多了以后，每个人、每段函数，都在面对无法预知的各种情况。

throw有个传染性，导致，整个团队的每个人，都不负责任。反正我throw了。

另外，throw使程序可以存在性能问题，因为有的进候，出错了，程序也会跑下去，有些更奇葩的员工，会显得自己牛，而把执行代码放到catch里去。

你可能说，程序本来就是这样啊！

我说，你错了，如果一个程序员，心中这样想，这么说吧，我开公司不会要他。

为什么，这说明这个人没有维护过程序！

什么意思呢？他干的都是一手扶墙，一手接钱的买卖。拿了钱，墙就倒了。

所以他从来没有接触过一个需要维护的程序。

当一个程度，进入维护状态后，你会逐渐发现，所有的错误，都出在那些没有反回值，或是有返回值没有处理的函数上。

而且，只要有这样的函数，必然会出现错误。

见过许多所谓牛人写的代码，整个程序没有日志，难道你没有想过Release以后，你的程度在裸奔吗？

没有想法出了错以后，使用者无法告知你死掉前，有什么现象吗？

这些事情太多太多了。

傻人才能办大事。

就我本人来说，IQ我的确有自信，但因为我从小就忘事，所以，我养成了步步为营的习惯。

所以，多年以来，我带队完成的项目，都被继承了下来。

结果是，不论如何，目前公司里的上位机项目，都是我带队或是我本人写的。

throw还有一个坏处，是编码的效率的下降。

每个程序员，不得不时时刻刻在想：我是throw，还是利用反回值？

结果是，整个代码编码的时候，脑里子尽想些没用的。

每个函数要确保完成一个完整的事情

接着上面的话题，每个函数，都要有始有终，你调你一个函数，你要相信他，如果那家伙随随便便throw，

你也要捕获，处理。

让用户，知道发生了什么，日志里有记录。

坚持事前检查，事中监视，事后把结果返回给调用方。

出错，一定写日志。

日志，绝不能在分析时，有混淆的意思。有的混账程序员，竟然把所有的出错的日志，写成一样的。

碰到这样的，真想骂娘啊。

有个故事，几个侦查兵，到了敌人炮兵阵地前方，汇报坐标的人，是个高中生，自称懂得，实际是走后门来的。

当敌人炮口开始升高，准备功击时，他们终于把电话接通了：报告首长，敌人的大炮，我们找到了！

首长：太好了，在哪里？

高中生：在前面，就在那！

。。。。。。

结局是可悲的。

不写日志，可能是懒，也可能是不懂。

但把日志写成这样的，应当立即纠正。你不体会到去过前方，哪里懂得问题定位的痛苦。

lambda 运算符用在哪里

用在哪里？

为什么前面讲了那么多？

函数式编程，问题是什么？

把函数写在调用处，缺点是显尔易见的：函数的Wrap没有了。

错误处理的基石不存在了。

同时，程度的可读性、目的性、可控性变差了。

所以，慎用。

可以用在哪里？

一些不太可能会出错的地方。

比如，构造的过程中，lambda，可以代替构造函数。这些地方，用用，还是不错的。

再比如，事后的分析时，也可以。

但中，关键的事中处理，求您还是不要这么写了。

特别有，更有甚者，有人的把lambda这种函数式调用，一个挨一个写成了一大串。

my lady gaga,这是要命啊。

前面我说了，不论如何改，for each还是for each，每个for的每个item，都可能会出错。

所以，一般而言，每个for each，应当在一个独立的函数中，并且，有详尽的出错的监控，所以报错的代码。

这样，把n个for each写成一长串，这是要让维护人员哭的节奏。

这样的程序员，你样真应当反醒。