透明、灰度、兼容&半强制

最近重构了一个公司业务的一个模块,涉及的东西有点多,从需求评审到技术评审,再到各端沟通,花了很大功夫才确定架构和技术方案,最后开发提测灰度上线,清洗数据等等,整个重构经历了很长时间。现在一切尘埃落定,我也静下心来把工作中的思考和探索记录下来。业务不能说的太详细,用一些泛泛的概念,比如新业务逻辑,新业务数据,旧业务逻辑,旧业务数据,业务主体等等。

透明

我很喜欢透明这个词,在软件领域的意思就是关注应该关注的东西,不应该关注的东西应该是透明的、看不到的。
原业务是后端提供一个 HTML,前端各渠道各自编写相同逻辑处理 HTML 里面的信息,进而展示给用户。这样的设计真的是非常痛苦,首先各端工作量增加,其次耦合性太高,最重要的是需要使用 iframe 或引入 jquery 来执行逻辑。重构之后由后端处理完 HTML 的信息,传给各端一个纯展示用的 HTML,对于各端来说这个 HTML 里的内容是透明的,他们不必关注,只需要展示就可以了。
另一个是 HTML 里面有很多需要填写的关键信息夹杂在内容之中,在不同的 HTML 中有可能有相同的关键信息,原业务对相同的关键信息用相同 ID 的 input 标签作为区分,后端再根据 ID 来存取所填的值。这样导致每创建一个新的 HTML 都要开发人员编写并保存一个完整页面,并且确保其中关键信息的填空的 ID 和约定一致。重构之后 HTML 的文本内容和关键信息分离,文本内容相当于纯文案,关键信息则是 key-value 列表,由后端装填到一个 HTML 模板中即可,这样一来,这些业务无关的内容对于后端和前端来说都是透明的,文本内容和关键信息的修改不需要投入开发人员。

灰度

重构一个正在运行的服务,新旧逻辑和数据不互通,不能保证同一时间迁移数据的,而且变更内容过多,影响范围较大,一定要有一个灰度方案,保证出现问题能够把影响面降到最小,新的服务能够逐步稳定地替代旧服务。
首先是灰度范围的选择,从业务的哪一层面来划分灰度范围,选取的颗粒度不能太大也不能太小,根据业务来寻找一个层面进行划分。
然后要考虑如何方便地调整灰度范围直至全量,以及如何保证后续新的业务主体自动进入灰度范围,我在数据库的字典表用一条数据记录灰度范围,也就是一些类型 ID 用逗号拼接成的字符串,代码逻辑会根据业务主体判断其类别是否在灰度范围,当灰度范围调整时,更新这条数据,当这条数据为空字符串时,代码判断为全量切换,即所有业务主体走新的业务逻辑,保证后续新增的类型自动进入灰度范围。
最后是灰度策略的制定,灰度范围外的业务如何处理,在灰度范围内但没有新业务基础数据的怎么处理,其他上下游业务如何保证不受灰度策略的影响。我在这次重构中,灰度范围外的业务主体仍然按照旧的业务逻辑处理,加到了灰度范围中但没有新业务基础数据的,仍然按照旧业务逻辑处理。新的业务保证上下游数据的正常交互,就像一条河流在中间分成了两条河道,对应新旧协议,然后又汇聚回原河流。

兼容

在涉及很多端,不能保证各端同一时间上线,尤其是 APP 端不能强制更新的情况下,旧的接口和逻辑要能够保持正常运行,旧的接口可以调用新的服务,而新的接口也要能够调用旧的服务。也就是说在使用灰度方案时,要保证新旧接口都可以正常工作,并根据灰度范围来正确调用新旧服务。
举个例子,这次重构中,旧业务逻辑是前端根据占位符填充的某些内容,新接口无论新旧业务数据,统一直接在后端填充好了,为了让旧接口兼容并正常展示新业务数据,我在旧接口返回新业务数据时 hack 了相应的占位符,仍然走前端填充的方式。

半强制

在设计了灰度和兼容两个关键点之后,带来另一个业务上必须考虑的问题,就是用户太懒。因为我们有灰度和兼容方案,所以使用者感觉旧的业务还可以使用,便不愿意迁移到新的业务,而且对于他们来说,新旧业务并没有什么不同。
所以我们的半强制策略就是,进入灰度范围的业务主体将不能修改和展示旧业务数据,只有编辑新业务数据的入口,旧业务数据可以走旧业务逻辑完成整个流程,一旦编辑好新业务的基础数据,该业务主体将走新业务逻辑。

问问题前,最好自己要先有一个答案

“问问题前,最好自己要先有一个答案。”这句话是很久之前一个同学跟我说的,
当时我们在讨论项目问题,一个由我主导的实验性质的校内网站项目。我对技术一无所知,但是满脑子都是天马行空的想法,讨论问题时也是心潮澎湃。他的这句话像一盆冷水泼在我火热的心上,我突然冷静下来,我意识到我并没有任何有价值的想法,只是在胡乱地提问。

当时我只觉得这句话很对,但并没有深刻领悟,就像明白很多道理,依旧过不好这一生,因为只是明白而已,没有亲身经历,就无法体会。

最近发生一些事却让我突然对这句话有了体会,即使我忘了是谁在什么时候对我说的。

前几天我在看一些 Java 代码,很基础的源代码。但是依旧让我这个新手看的十分混乱。然后我翻看一本 Java 数据结构的书,里面作者从无到有,一步一步简单实现了一个 ArrayList。看完书中的内容再回头看 jdk 中的 ArrayList,瞬间清晰了许多。

我仔细回顾这两次看源代码的经历,仿佛让我回到的学生时代,就像在上课前有没有预习的差别。没有预习的时候,上课只能跟着老师的思路走,漫无目的被牵着鼻子走,所获得的知识和思想也仅仅停留在表面,很容易随时间淡忘。有预习的时候,更多的是思想上的碰撞,看看哪些想法一样,哪些不一样,对那些不一样的地方,我们可以更加针对的深入思考。

工作当中也是一样,当我们遇到解决不了的问题时,在请教领导或同事之前,自己要有一些思路和想法,不能把问题直接推给别人。一是别人也很忙,从头缕一遍问题并找到解决方案要花费大量时间和精力;二是让别人知道你是一个负责任的人,即使无法解决问题也会积极思考。

对于决策层来说,他们需要的只是针对提议的决策,比如从两个方案中选一个方案。所以发现问题、梳理问题、设计问题解决方案这些工作就要下面的人来做。就像在饭馆点菜一样,如果直接把菜单递给对方,对方往往不知道点什么好,反而向对方提供两道招牌菜,让其从中选择,则会方便许多。

上面说的这些道理,我也仅仅是明白,生活和工作中还有很多地方做的不对不好,仍需努力。

人类的主动进化

生物通过一代一代的繁殖,基因的突变使性状改变,再受到自然选择的优胜劣汰,有些性状保留并成为主流。这就是我们生物学上所说的进化。

我们时常会感冒,虽然一次感冒康复之后我们会对这种感冒病毒有抗体,但我们还会有下一次的感冒。为什么呢,因为感冒病毒在变异在进化,它们的繁殖速度很快,在短时间内就能够繁殖很多代,从而进化很多。而人类大概20年才能繁殖一代,相比之下,进化速度实在太慢了。我时常在想,为什么人类没有被自然界淘汰掉呢。

其实人类有自己的主动进化,这种进化并不是基因上的,而是智慧上的。这使得人类能够在很短时间内提升很多。举个例子,大家去驾校学两个月车,就能拿到驾照,从此有了驾驶汽车这项能力。想象一下,如果让人类进化出这种能力,可能需要几百万年几千万年。

而人类通过这种方式进化的关键是什么呢,是交流和学习。交流和学习的意义在于经历你未曾经历过的一切,从而学会技能或明白道理。而我们的时间是有限的,我们的一生会有很多事情无法经历,但是人类有数量上的优势,想象着同一时间,各种各样的人都经历着各种各样的事情,而其中某一些也通过文字或影像或声音到达你这里,你身临其境,你感同身受,你仿佛也经历了那些事情,你也学到了些东西或者明白了些道理,你成长了,你进化了。

有些科幻作品中喜欢塑造一种高等外星生物,它们没有个体智慧,只有一个共同的大脑,就像网络云端的服务器一样,每个外星生物经历的一切上传到这一个云端,再从云端获取所有记忆。这个云端大脑能够迅速提高智慧,迅速成长,每个个体都实实在在经历了所有的一切。

而我们没有这种云端大脑,我们可以通过信息的交流来获得某种经历,随着科技水平的提高,人类间信息传递的效率也越来越高,一触即发的视频图像替代了漂泊流转的书籍文字。人类在共享着经历,在学习和领悟,在进行着高速的进化,从而成为在地球上无比强大的物种。

这就是为什么我喜欢与人交流。

有关工程各个分层中方法参数定义的一些思考

一般 Java 后端开发中,习惯上会将工程分为 3 层,controller,service 和 dao。controller 负责接收解析校验请求和返回,service 处理业务逻辑,dao 执行数据库语句。

最近在重构一个工程,里面很多业务模块都是不同的人写的,每个人的代码风格和习惯都不同,看了各式各样的方法命名和参数定义,我也略有感触和思考。见过最狠的就是从 controller 层解析请求到 dao 层的数据库语句,其中涉及的方法全用 Map 作为参数一层一层向下传,真是让我大开眼界。

总体来说,定义方法参数有 2 种风格习惯:

  • 第一种是把所需要的变量作为一个个单独参数来传递,
  • 第二种则是将零散的变量组装成单个复合参数来传递,比如上面说的 Map,或者自定义的 DTO。

controller 层

先说说 controller 层,我建议用第一种方式,原因很简单,第一种方式能直观地看出接口需要的各个参数及类型,并直接在 controller 中对参数进行处理和校验,IDE 也会对未使用到的参数进行提醒。使用 DTO 则有可能会由于业务变更出现冗余字段,维护时容易忽视,久而久之 DTO 变臃肿,开发者也不能搞清楚接口到底需要参数。下面两种方式对比一下:

public Response addUser(@RequestParam("id") Integer id,
                        @RequestParam("age") Integer age,
                        @RequestParam("sex") Integer sex,
                        @RequestParam("name") String name) 
public Response addUser(RequestUserDTO requestUserDTO)

service 层

然后说说 service 层。
* 我认为在参数个数不是很多的情况下,建议用第一种方式,保持代码的简洁。
* 如果参数很多,或者业务变动频繁导致参数变化频繁的情况下,可以考虑使用第二种方式,第二种方式的优势就在于参数的变动不会影响到方法声明,我们只需要关心 DTO 中的变量,然后代码逻辑中处理这些变量。尤其在 service 层十分方便,service 一般都是一个接口对应一个实现类,因为不确定其他工程对原方法的依赖和调用,所以如果方法变更参数,接口和类中都必须保留原方法,增加新的方法来重载原方法,而用第二种方式传递参数,则可以避免这些修改。
* 在业务参数和逻辑参数混杂的情况下,可以使用两种方式结合,比如下面这样:

public PageInfo<User> userPageList(User user, Integer pageNum, Integer pageSize)
boolean updateUser(User user, String operator);

第一个方法使用了分页插件,所以分页参数并不会传递进 dao 层;第二个方法需要额外记录操作人

dao 层

最后看看 dao 层,我觉得 dao 层没什么多说的,两种方式都可以,看情况选择。

注意的地方

除了上面所说的工程中不同层级方法的参数定义方式,我还想说一些其他东西。
1. 不要用 Map。这真的真的很蠢,不能描述出所需变量的个数、名称和类型,如果存的变量类型不同还不能用泛型,只能取的时候强制转型。
2. 不同层不要用同一个 DTO。不同层都有自己的职责和意义,controller 层的 DTO 为了描述网络请求的参数,service 层的 DTO 为了描述业务相关的变量,dao 层的 DTO 为了描述数据库语句需要的参数。有的开发者为了方便,在开发一个功能时,定义一个字段很多的 DTO,从 controller 用到 dao,这也是很蠢的操作。不同层级的 DTO 放在各自的工程模块中,一方面可以解耦,另一方面可以让开发者加深工程化思想。

以上观点仅仅是我个人基于我当前的工作经验总结出来的,欢迎交流沟通。
我总结完才发现说的有点所谓的“理想化的最佳实践”了,工程中还是自由派比较多,大家写代码开心就好。

离职

今天组内有位同事离职了,准确说是跳槽吧,无所谓了,反正是和每个人悄悄打了个招呼就突然离开了。离职的是个小哥哥,在职时间不是很长,也就 1 年多点。

对于我来说,这只是一件小事而已,不过,我看到有同事依依不舍的抹眼泪了。说实话,这对我的触动很大。同事基本都是刚毕业的年轻人,可能没经历过太多的这种场面。而且基本上都是刚从学校出来的第一份工作。那种学生时代的情谊还在他们身上体现着,对同伴的不舍也可以理解。

在我看来,IT行业,人员流动是很正常的现象,我遇到的离职,入职,包括我自己的跳槽,加起来都不知道有多少了。甚至我的第一份工作仅仅持续了 1 年的时间,就遇到了部门解散,同事各奔东西的情况。或许面对了这么多,我也有些麻木了,有些淡然了,有些不近人情了。总感觉自己和同事相处表现的有点内向,有点自闭。一方面担心某天分别时的不舍和尴尬,另一方面也没有精力去联系曾经的同事。那干脆就不要混的太熟了,不然离个职还要像情侣分手般不舍。

但这又往往是领导所担心的吧。对于管理层来说,团队的产出是基于团队成员的协作,关键就在于凝聚力,团队精神和归属感。这也是为什么很多销售的培训和公司的拓展训练都是培养这些东西。对于我们团队来说,平时一起吃午饭,打乒乓球就是增进团队氛围的一种方式,另外小组领导还会出钱找个时间让大家一起去玩玩。其实,在我看来,领导最费心的不是技术问题,而是带好整个团队。

不过,我看到的他的离职,内心却是十分高兴的。真的是发自内心的高兴,而且是替他高兴。因为我相信他是的目标很明确,敢于离开自己的舒适区。
我相信一点:真正做技术的人,应该是自由的 。热爱着自由,追寻着自由。从一行行飘逸的代码,到灵活的架构。从项目的开源协作,到成果和技术的分享。从生活到生命,无时无刻体现一种自由的态度和对自由的追寻。

我刚刚入职不久,他是我入职带我的人,而且是我试用期评分人,我马上试用期就要结束了,HR 肯定要找我谈话,很定避免不了这个问题。我打算就把上面这些话讲给 HR 听了。哈哈哈哈。

一个简单的同事离职,我却想了这么多,想到了同事,想到了自己,想到了管理层,想到了离职的他。回顾这一切,最后还是欣慰和高兴。毕竟我也是离职过的,站在离职同事的角度比较多。
可惜那位同事离开的有点快。真想给那位同事一个大大的笑脸,然后祝那位同事前程似锦,加油!

对于阿里的月饼事件一点感想

前段时间阿里有几个程序猿写脚本抢月饼被开了.
IT界引起了一些争论.总的来说就是大部分程序猿认为阿里做错了.
我并不关注谁对谁错,也不想客观的评论这件事.
我只想说一些主观的话,这件事对我的影响,以及我的想法.

1.程序猿是如此的低微和脆弱

其实程序猿和工地上搬砖的工人没有太大区别.只是我们自己把自己看的太厉害了.确实,我们用无懈可击的逻辑写着严谨的逻辑代码,沉迷于代码世界里,创造着自己所认为的艺术品.仿佛在IT领域的风口浪尖,仿佛推动着全人类的发展.
但这种自豪感和搬砖工对摩天大楼的自豪感又有什么差别呢.
没有人会记得盖起一栋大楼的千万工人.外行人也不会知道究竟是谁设计谁建造的这栋楼.他们只知道,淘宝是马云的,腾讯是马化腾的.
而搬砖工的饭碗又如此的脆弱.我也曾经认为自己的工作不可替代,如果让人顶替我,也至少需要一段时间交接工作.但现在发现真的不是这样.总有人能顶替你,甚至不需要交接工作.所以,只需要上头一句话,你的饭碗立刻没有.

2.程序猿脱离了社会

写代码写多了,思维方式总会受到影响,
正所谓有人的地方就是江湖,江湖自然有江湖的规矩,不懂的和人打交道注定要吃亏.
多提高点情商比什么都强.虽然我们并没有完全脱离社会,没有很偏执.
我的自我评价是高智商逻辑型生物,情商为0.虽是自嘲,但也差不多是这样.

一个算法问题

在一个直角坐标系的第一象限有面积为100*100的区域,即(0,0)(100,0)(100,100)(0,100)四个点围成的正方形区域.
输入一个多边形的顶点坐标集合(顺时针过逆时针方向).已知多边形是规则的,即其边沿着网格虚线,不会横穿单元格.比如:一个矩形(2,1)(2,3)(6,3)(6,1)

image001

之后会在此坐标系中,不断输入一个规则的多边形,比如继续输入一个十二边形(7,1)(7,6)(2,6)(2,10)(7,10)(7,15)(11,15)(11,10)(16,10)(16,6)(11,6)(11,1)

image004

对每次输入的图形,判断:

1.是否有顶点与已存在的图形顶点重叠.

2.是否有边与已存在的边重叠.

3.如果面积与已存在的面积重叠,或图形超越所定义的100*100区域,则退出程序.

输入的数据格式可自行定义,能够表示图形顶点坐标即可,算法语言自行选择,伪代码也可.

提示:

1.问题1较为简单,用集合(set)可解.

2.规则图形坐标点输入有规律,即输入的相邻两点x或y值相同.

3.问题3确保了判断问题1和2过程中不用考虑面积重叠情况.简化了算法复杂度.

眯起眼睛,热泪崩坏

去年的这个时候,我还是一个无忧无虑的少年。
毕了业,没去找工作,回来考驾照,搬砖,旅行。
做了很多自己想做的事情。
没有思考过未来,也没有怀念过曾经。

年前找点事情做,为当地的一家小报社做个小网站。
每天睡到自然醒开车去报社,中午管饭,下午四点就可以走了。
每周上三天,休息四天。每周三晚上他们把排版交给印刷厂。
报社员工很少,每天来上班的不超过三十个人,都是托关系进来的临时工,虽然工资很低,但有转正机会,况且没有哪种工作每周有四天休息。
正式工都是编制里的,从来就不来上班,但工资照常发,毕竟是事业单位。

我来这也是偶然的一个原因。
小城市有小城市的好处,熟人社会,你可以通过几个亲戚朋友认识大半个城市的人。
当时那家小报社的广告部主任在一次饭桌上遇到了我,看到我做的网页,感觉我很厉害。问我能不能帮他做个发布文章的网站。毕竟是我姑父的朋友,我一口答应了。
之后请我在报社边的餐馆吃饭,一瓶白酒喝完了之后,他又喊服务员”来瓶啤酒给我俩漱漱口”。于是我俩就又喝了一瓶啤酒。从那以后我才知道原来中国的酒文化里,啤酒和水就没区别。
第二天我就去报社了,他还单独把我安排在了旁边的一个单独的小办公室,牌子上写的”副编辑”,前面也说了,正式工都不来上班的。他和他的部下在对面的大办公室。不过那个大办公室里就他一个人抽烟,所以他也经常来我这屋,和我一起抽烟聊天。

在这小小的报社,我认识了各式各样的人,也听他说了各种人和事。
报社有个比我大三岁的小姐姐,学的会计,文凭含金量不高,找个好工作不容易,便托关系来到了这,每天最开心的事情就是和异地恋的男友网上聊天。她男友又高又帅,当兵,参加过大阅兵的仪仗队。每次她男朋友请假回来,朋友圈就会秀恩爱,帅哥美女,羡煞旁人。
报社还有一个比我小一岁的小妹妹,在这实习,每天来的时候都是裹得严严实实的,只露出两个眼睛,平时不喜欢说话,只是偶尔发一些搞怪的自拍。她和我来的时间差不多长,所以也没有完全融入整个办公室的氛围。
另外让我印象深刻的是一位大姐,快四十岁了,依然单身。业务能力很强,但情商太低了。每个月都能为广告部拉到广告或赞助,但又常在工作群里耿直的谈论工作中涉及到钱的各种事情,让领导头疼不已。至于为什么单身,听说她是硕士毕业,只看得上博士毕业的,这又让身边的同事唏嘘不已。

他们给我的印象就是平平庸庸,忙忙碌碌,每天都为小事操心着,为小事开心或忧愁。
可能中午做的菜合胃口,一下午都心情好。
可能某篇文章的排版有问题需要重做,就抱怨一下午。
可能外面天气突然不好,就担心一下午。
日子就像打印机里的纸一样,单调又重复,静静的被生活渲染,没有一丝波澜。
他们就在等待着转正的这一个念头里,平淡的度过每一天。
这种生活状态和节奏,又似乎和这座小城市如此的协调和默契。每天脚步悠闲的路人,日常聊天谈论最多的是菜价和天气,每到晚上十点就空旷的街道。
没有激情,没有梦想,没有光怪陆离的夜生活,也没有朝气蓬勃的明天。

就在这样的环境中,我也渐渐放慢了脚步,融入了这种生活。像一个漂浮在浅水区的游客,享受着温暖阳光的沐浴,眼睛不想睁开,耳朵也睡着了。
也就是在这个时间,这种状态下。私人FM里传来一首歌。没有复杂的前奏,一个磁性的声音瞬间像温柔的手掌抚顺你的每根毛发。又像一个有故事的人,讲述着三十岁的故事。
我听得深陷其中,手里的烟不知燃了多久,缭绕的烟雾又加深了我的思绪。

之后每次开车往返于家和报社之间,我都会单曲循环了这首歌。
我想到了未来,也回忆起了过去。
过去做了很多错误的选择,人生之路历经坎坷,错过了很多人。虽然我不止一次告诉自己,过去有遗憾但不后悔。但这些遗憾还是会让我在夜深人静时心中流泪。
未来的我又会是什么样子呢,等我到三十岁,我会在哪里,做什么事情,是否每天庸庸碌碌,碌碌无为,是否会失去激情和梦想,是否会有人爱我,是否仍然还是一个人。
三十岁的我,是否又会回想起如今的我,是否回忆起这个曾经天真活力又热爱生活的我,是否回忆起曾经的我会唏嘘不已,是否会在回忆时热泪盈眶。

就歌唱吧 眼睛眯起来
而热泪的崩坏

每次听到这句歌词,我总会湿润眼眶。我似乎看到了三十岁的我,也似乎是三十岁的我看到了现在的我。
如今青春早已不在,激情和梦想也被打磨的没有棱角,总感觉好多事情没有做,总感觉不到生活的意义。总感觉这不是我想要的一切。
我只有一个想法,我只希望,等到我三十岁的时候,唱起这首歌,不要热泪盈眶。

后来,我去了大城市,一个人找工作,租房,每天做自己喜欢的事情,每天都很开心。生活节奏很快,竞争很激烈,机会也很多,很多东西都是公平的,你可以通过自己的努力得到。我就享受着这种生活,也努力着。只是,对自己的三十岁还是不确定。

我也曾回到过家乡的小城市,那位叔叔已经是小报社的社长了。报社里的那个小姐姐找了其他工作,她男朋友也转业了,准备结婚了,很幸福。报社的那个小妹妹则去考研了,现在应该刚刚考完,祝福她吧。最后那位大姐则是一直留在了报社,也是唯一一个坚持没走,终于转正的员工,应该现在也很幸福。

生活就这样继续着,每个人都匆匆的走在自己的路上。偶尔会遇到同行的人,又很快会分开。
每个人都会思考着未来,思考着过去,思考着现在。
每个人都会经历三十岁。
而我们到了三十岁,又将是怎样的一幅模样呢?
我现在偶尔会迷茫,偶尔会徘徊,偶尔会孤单。
我好奇着,也期待着三十岁。
我只有一个小小的心愿,等到我三十岁的时候,唱起这首歌,不要热泪盈眶。

[理想三旬-陈鸿宇]

雨后有车驶来
驶过暮色苍白
旧铁皮往南开 恋人已不在
收听浓烟下的 诗歌电台
不动情的咳嗽 至少看起来
归途也还可爱
琴弦少了姿态
再不见那夜里 听歌的小孩
时光匆匆独白
将颠沛磨成卡带
已枯卷的情怀 踏碎成年代
就老去吧 孤独别醒来
你渴望的离开
只是无处停摆
就歌唱吧 眼睛眯起来
而热泪的崩坏
只是没抵达的存在
青春又醉倒在
籍籍无名的怀
靠嬉笑来虚度 聚散得慷慨
辗转却去不到 对的站台
如果漂泊是成长 必经的路牌
你迷醒岁月中
那贫瘠的未来
像遗憾季节里 未结果的爱
弄脏了每一页诗
吻最疼痛的告白
而风声吹到这 已不需要释怀
就老去吧 孤独别醒来
你渴望的离开
只是无处停摆
就歌唱吧 眼睛眯起来
而热泪的崩坏
只是没抵达的存在
就甜蜜地忍耐
繁星润湿窗台
光影跳动着像在 困倦里说爱
再无谓的感慨
以为明白
梦倒塌的地方 今已爬满青苔

逻辑(续)

还记得之前我写了一篇关于逻辑的

逻辑

之前我一直认为人类的道德和伦理会让有缺陷个体的基因同样得到延续,违反大自然优胜劣汰的进化法则。
而与人形影不离的感冒病毒则不断快速繁殖,进化,对抗新的疫苗,淘汰,然后变异,又一次进化,然后永远不可能绝迹,人类也不可能永远摆脱它。
似乎人类处于了大自然进化中最弱的位置,弱不禁风。

但事实上我们的地位却高高在上。这其中的原因我终于想通了。

主动进化!

刚看了《果壳中的宇宙》提到了DNA携带信息,DNA复制的时候可能产生误差,信息也就发生了改变,从而得到传递。这就是所谓的进化吧。

人类,信息从一代向下一代传递,不必等待基因突变和自然选择,一本浪漫小说就够储存关于猿和人类DNA差别那么多的信息。30卷的百科全书可以描述人类DNA的整个序列。

你读了这篇文章,大脑中明白了一些东西,这就是一种进化。现在知识越来越多,我们需要掌握的也越来越多,现在的小孩子懂的东西远比以前一个耕地的成人多,这就是一种进化。

最后总结一句:人类是智慧生物,他们能够主动进化。

逻辑

今天我要讲一些有些哲学意味的东西,思想精炼到每句话中。
阅读——停顿——思考
【警告】以下内容可能深深影响你的人生观、世界观、价值观(俗称:毁三观)。未成年人请在家长陪同下阅读。声明:一切后果与寡人无关。
Let’s go!!!

主题:神一样的逻辑

前几天看了一则短篇小说。

妻子一直埋怨丈夫不如邻居收入多、不如邻居职位高,丈夫一直抬不起头来。(哎,男人不容易啊)
终于有一天邻居被双规了。丈夫当然喜闻乐见,屁颠屁颠地跑到妻子面前眉飞色舞汇报。
妻子听到之后,说“人家至少被双规了,你连双规的资格都没有。”

然后,世界就安静了。

这个妻子无敌了,真的无敌了,因为她的逻辑是无敌的。

再说一个打游戏的事。

前几天打游戏(LOL大神当然玩LOL了)。
把对面虐出翔了(对于我这种大神来说很正常了)。
这是一个推塔的游戏,所以我们放慢推塔的节奏,尽情体验杀戮的快感。对面很惨,又气又恼,打也打不过,想结束也结束不了,只能品尝着被蹂躏的快感。
最后结束游戏的时候,对面有个人打字“你们阵容如此好,竟然被我们拖这么久,你们真菜。”

然后,我就安静了。

这个玩家赢了,真的赢了,因为他的逻辑赢了。

当然,按照你的逻辑,加上我的语言作用,让你认为以上两个例子似乎是反面教材。

但是,我们换个角度,
就追求上进的精神而言,是不是就可以说这位妻子的逻辑值得肯定,因为她不甘平庸。
就游戏精神和娱乐精神而言,是不是这个玩家的逻辑就值得赞扬,因为他不被游戏娱乐。

是吧,你点了点头。
好的,我轻易的改变了你的逻辑。(是不是有种被愚弄的感觉,哈哈哈。)

那我再讲个故事。

水塘中一只蚜虫和一只瓢虫相遇。
瓢虫说“我要吃掉你,因为我是益虫,你是害虫。”
蚜虫说“为什么你是益虫,而我是害虫。”
瓢虫说想了想,说“人类这样称呼你和我。”
蚜虫说“为什么要按照人类的逻辑定义你和我。”
瓢虫说“。。。”
蚜虫说“你和我都是自然中平等的生命体,只不过进化的食物链上你我处在不同位置而已,我吃植物,你吃虫子,都是天经地义、无可厚非的,为什么非要区分善恶呢。”
瓢虫听后很受启发,然后把蚜虫吃掉了。

【前方高能,脑残绕行】

好的,让我们跳出人类的逻辑。

在大自然面前,在宇宙面前,人类算个屁!人类和自然万物一样是平等的生命存在!
大自然的逻辑:进化选择,优胜劣汰,放弃一切有缺陷的个体,十分残酷。
人类的逻辑:我们时刻照顾老弱病残,不抛弃、不放弃,我们让有缺陷的个体同样存在,并能够继续生存和繁衍。我们称之为‘道德’和‘伦理’。
这,似乎和大自然的逻辑相违背,,,,当然,相违背的逻辑不仅仅使这些,还有很多很多。
看过《动物世界》就会发现,面对失去父母的幼崽、面对被追捕的幼崽、面对走丢的幼崽,摄像师不能有半点怜悯和同情之举,不能以人类的逻辑去干涉大自然的逻辑。

好了,好了,在这里千万别多想,千万别多想!逻辑没有对错之分!
我只是担心不小心引导你坚持极端逻辑,走向反人类的不归路。
如果你深陷我的思想不能自拔,请看一周的新闻联播以安抚情绪。

【再次高能预警】

由于种种复杂的原因,我能接受、吸收、采纳一切逻辑,包括一些不被大众所认同的逻辑。(我的包容力是你无法想象的,我能包容整个宇宙,更不用说包容你的一切了)

更重要的是我能跳出固有的逻辑,不被某些逻辑所左右,不被某些逻辑所束缚。

不过最重要的,也是我追求的,就是丰富你的逻辑,让你从黑白世界中感受到彩虹。

That’s all.Thank you!