KuaiLeShiFu的博客

不用c和c++,那么要不要去阅读这两种语言优秀的的源码呢？ 由于这两种非常底层，对于了解一些底层的原理非常有帮助； 而且，高级语言比如，Java都是增加了更多的抽象层，而底层差不多都是一样的， 因此，当我们使用Java的时候，可能不知道底层是怎么运行的，如果能经常阅读一些优秀的底层语言比如c的优秀代码，对于我们使用Java也是非常有帮助的； 就像我们读一些名著并不是为了成为一个牛逼的作家一...

任何的猜测都是不够的，还需要要验证. 不要习惯用猜测代替事实。 不要习惯用猜测作为事实。

凑合 在日常开发中，使用或者测试中出现问题，一般都喜欢打补丁，补丁这个概念被用错了。补丁不是凑合。补丁不是简单粗暴，毫无业务逻辑性的凑合。 如果为了修复一个问题，而让你的代码变得不能体现或者表达它的业务含义或者污染了现有的代码逻辑，那么这个修复就埋下了一个日后潜在的更大的问题。 为了清晰性，为了功能的单一性，为了以后的可维护性，代码不能凑合。 陋习举例：比如业务调整，需要调用端新传入一个参...

对什么陌生，就要对什么重复(重复看，重复读，重复写，重复练)。重复可以消除陌生，重复可以让你熟练。重复可以让复杂简单！！！重复—-让不可能变成可能，让胆怯变成勇敢！！！

我们学习一个东西时，如果能够找到和它对标的一个东西来对比着理解和学习， 那么，很有助于你的记忆和理解。对比是常用的一种深化记忆和理解的工具。比如，如果你之前通过并了解MySQL， 那么当你学习hbase的，你可以试着这样学习： hbase和mysql有什么不同，既然有mysql,为什么还会出现hbase hbase比mysql的优势体现是什么？...

背景在开发中，有很多博弈的事情。具体比如如果觉得一段代码执行效率低，我们需要压榨硬件的资源，那么就可以采用并发，多进程，多线程，但是如果不加限速，甚至不关注硬件资源的实时情况，那么会造成效率不升反而会降低，因为多线程也是有调度消耗的。因此，这里面有博弈道理在。

做大做全： 闭环–生态

背景封装可以让我们不用关注细节，但是，有时我们想知道内部执行的情况，那么怎么办？具体两种方法，可以让封装对外开放，一个就是可以注册，一个就是开放一个引用

背景在开发中，批处理常常用到并发编程，但是，你是怎么保证以及验证你的并发是正确的呢？并发并发下产生的问题是复杂的，而且难易追溯和复现，因此当你打算使用并发来解决效率问题的时候，你要做好如下事情： 验证你的并发是提升效率的； 验证你的并发处理的结果是符合预期的，是准确的结果。如果你做不到验证上面两点，那么你就不要去做什么所谓的并发方式去处理你的逻辑。

业务代码可以无上限激发你的想象力， 而框架代码需要你自己激发自己的想象力。因此，如果你觉得业务代码简单或者枯燥，那是因为你自己没有掌握精髓或者你没有好好走心设计你的代码。

不同的测试环境，侧重点是不同的。 本地进行功能测试 压测环境进行压力测试 预发环境进行功能线上模拟测试从本地测试到性能测试到预发测试到线上测试，这样的流程是必须的。 但是，在实际中，往往“为了节省时间”并“觉得改动小（而且也不进行仔细review）”就仓促直接发到线上，这样是非常不合规的，容易造成重大问题。

一个JOB在一台机器上执行很多的操作，使用的本机的资源，那么如何把具体的动作转移到其他机器呢？JOB执行——>JOB触发执行（http方式等）； 如此一来，JOB就是一个调度了，而真正执行的触发通过消息或者http就转移到了其他机器上；

在排查过程(线上排查心里素质会下降)中可能使用了错误的方法或者使用了错误的判断或者看错了等等 当我们陷入绝境，我们要休息下，然后中断一会。休息完毕后，我们再仔细复盘下刚才的做法是否是对的，或者重新使用新的方法来试验。

作为一个技术宅， 都往往会不经意推崇一个技术（工具），而对工具所能解决的问题，对其所能使用的场景不清楚。 这就是为了学而学。学一个东西前，调研它，首先搞清楚它能做什么，它是否能为你所用。 不要被“别人说牛逼”蒙蔽双眼和思考。做任何事，都要不要忘了目标，忘了你的初衷。要在做事时，时刻反省，发现自己目的模糊就要立刻认识并强化。...

调用http接口执行任务，但是http接口内部的逻辑执行到完全结束需要很长时间，此时，链接会超时并结束。也许你的目的仅仅是触发http，让http底层的服务端代码执行起来。 那么你可以运用异步的思路，让http的响应“快速返回”，并且让http的服务端代码通过一个新的线程来继续完成真是逻辑的执行。然后再搭配任务的监控（比如心跳，返回执行进度报文）等，或者让调用者注册一个回调。

后端采用的技术： SpringMVC PageHelper 核心点： ThreadLocal、拦截器前端采用的技术： http://www.jeasyui.com/documentation/datagrid.php

贫血领域对象：方法不单一，方法的名字不能传达方法的含义，并且方法体的实现也不具有单一性，也不能体现方法的功能。说白了，方法不能体现业务。好的代码就是能表达业务的代码。 贫血领域对象会随着时间推移，会让人搞不清楚它最初的含义和功能是什么，即让人搞不清楚它要实现什么样的业务场景或者用例流。领域驱动设计的领域对象应该有它应该具有的行为，千万不能因为降低代码量或者为了凑合而把复用特性用烂、用错。该是...

如何高效review代码：对改动的地方多问一个为什么？多问业务是什么？多问为什么这么做？多问，多思考还有其他的实现方法吗？总之，让你的注意力集中并在思考。...

如果你做一个行业，核心的知识你必须需要搞明白。 核心的搞明白了，你就称职，不然，你做再久，还是原地踏步，无实质上的进步。比如，你如果搞金融的，那么钱就需要搞明白。每种贷款怎么算的，每个贷款方式是什么样子的公式。比如，你要是搞电商的，那么就需要搞懂供应链，搞懂渠道。往往，会存在不去面对难的东西，而是避难就易。...

有时，对于所开发的东西不清楚，或者杂乱无章， 我们可以去做，然后测试，定位问题，诊断问题，解决问题。 这个过程中，我们会慢慢成长。对所做的事情会越来越清晰。 这就是从问题出发。 并不是所有的事情都是完全规划好了，搞清楚了才能进行。换种思路，也许就海阔天空。...

一万张从1到一万的卡片，打散后，从中找出数字是10的卡片，你会怎么找？同样一万张从1到一万的卡片，找出指定的1000张，你会怎么找？第一种情况，一般情况下，都会随机找（存在侥幸心理） 第二种情况下，人们会强烈的意识到要排好序，然后找比较划算（心中强烈需要规律和规则）。第二种情况就引出了排序，还有就是数据量更多情况下如何更好实现排序？人都喜欢有规则的东西，有了规律就容易处理。计算机...

入行难，难在入行就代表你熟悉这个领域，对这个领域的一切别人看不出什么的地方，你能够看出规律和特性。比如，你如果熟悉分期购车的业务，那么你知道分期购的分期方案一般都是多少首付和比例吗？ 比如，你如果房地产业务，那么你知道什么样的房子可以买？...

在一个方法中，增加一行代码，觉得没问题吗？原则：修改一处代码，都要通篇进行review； 重点看下修改的代码对原有代码的影响是什么？新增的代码是干啥的？对流程有什么影响； 对逻辑有什么影响？例子：在一个执行过滤功能的方法中，新增一个过滤代码。 可能造成的影响以及review的重点是：该行代码放的位置对吗？是放在哪个过滤前，还是哪个过滤后，还是放到哪些过滤之间？...

在平时的工作或者生活中，你会在意或者注意你的表达方式吗？你觉得你的话别人能很好的理解吗？你能准确表达自己的意思吗？ 特别当你遇到问题时，向别人寻求帮助时，你连自己的困难都讲不清楚，别人怎么帮你，特别是做为一个开发者，必须要会表达，善于表达。很多人都沉浸在自嗨中，因此很多人的表达对于受众来讲，都是会碰到疑惑，更加疑惑，甚至抵触的情况。要知道，人都是力争想要明白的，你给他表达你的意思，反而让其糊...

桶 趟 哨兵 回文

如何从一大波信息中，摘出来哪些是要点，哪些是核心？ 那么基础的，被其他信息依赖的并且是其他信息产生或者存在不可获取的就是核心的。比如，做一个分期购车的网站，你认为车的那个信息是核心的，那就是车价。其实，在一个领域，都有很多领域模型的，模型中有些属性是核心属性，这些核心的就需要认真对待，给予更高的重视度。

有问题了，就需要沟通 有歧义了，就需要沟通 有想法了，就需要沟通但是，怎么对待沟通呢，是不是认为自己是对的，别人就一定要听取？ 沟通，就是把自己的掌握的认知信息有条理并且有“感情”地让对方听到。 沟通是事情达成共识的一种方式，但是记住，它不是一种让你宣泄清晰，甚至攻击别人的方式。 沟通的前提是尊重对方。沟通有时需要我们也要有耐心。 尊重对方，尊重沟通

不要以为你明白，你就懂了， 你把脉络搞懂了，但是细节呢，比如实现细节呢？如果你总是认为你搞懂了业务，但是么有搞懂或者研究过实现的细节，并明白实现细节，你就不能算懂。一般情况下，业务都是很普通的，但是其实现细节或者运营细节都是差异性所在，有时，实现细节的差异性是非常大的。

如果一个系统包括了前台（面向C端用户），一个后台（面向B端用户），而且也有一些平台化的运营使用模块（比如ERP，CRM等），还有一些后台调度系统（JOB等）。那么这么全面的系统怎么能够了解全面呢？ 那就是去做与这些系统相关的需求，或者修改这些项目相关的bug，或者是跟（一步一步调试地跟踪）这些项目相关的代码。 总之，要亲身经历，然后多问，多做，多使用（操作这些系统）。时间到了，你就懂了。

在一个项目中，很多功能是相似的，那么如何把相似的功能抽象出来，并通过一定的技术手段来实现，那么久可以减少代码量并增强代码可维护性。 注意：不能过度抽象，不能滥用抽象。比如切面思想就是一个把相似功能进行抽象而得出的精华思想； 我们要做的就是分清楚哪些可以归到一个切面里面。...

运用面向对象的目的之一是可以让实现和扩展按照我们定义（一次）的规范来开展。 比如接口的定义，比如父类的存在。 比如模型的定义，比如业务的填充； 另外，接口（或者模型）的定义和基于它的实现（或者补充业务逻辑）的往往不是一拨人。举个例子，storm设计了一套模型，你按照这个模型进行开发补充你的业务代码，就可以实现你想通过storm实现的功能。这里面就有storm的模型规范在规范你。...

怎么才能够认清一个开源组件的功能？ 如果你能够说出或者描述出它的一个用途，或者使用场景，那么说明你对它的认识就比较深刻和准确？ 比如，你知道storm是干什么用的吗？你的什么业务能够使用它呢？哪怕牵强点的使用也算。...

背景在一个拥有大量数据的公司，如何通过数据来看业务，来了解业务，甚至来分析自己的代码处理逻辑呢？具体要有意识地全局来看，要了解依赖的数据的来源，分类等。也要弄清楚数据的去向等等。 孤立地看数据，只会造成思路闭塞，有些问题难以发现。开发一个子系统，那么这个系统可能会依赖一些数据，那么这些数据要知道从哪里来的。 另外，子系统会产生一些数据，要弄清楚这些数据的处理逻辑。

如果把整理思路，调研都算到设计里面的话， 那么设计和开发的时间比例一般都是设计远大于开发时间。 所以，至少想清楚了再去开发，比较顺畅，也不容易返工。

做事，遇到问题，遇到突然情况，遇到困难事情，怎么应对？ 首先要跳出来，从事情中跳出来，控制自己的反应，最好的表现去应对。 这样的方法才洒脱，才不为被事情控制而错乱。

背景不同类型的数据库，如果不同的读写诉求，怎么推动和决策？具体在关系型数据库中，如果设计得当（表的粒度合理），那么修改操作只会影响很小一部分，但是，如果是复杂的读，那么就需要多个表之间进行复杂的关联等操作。在nosql中，比如ES，它天生接受你的数据扁平化，那么复杂的读在这里就不是问题，但是写，就变得影响很大。关系型数据库是分割 而Nosql是聚合一般的在线业务需求都

背景并行工作，如何快速切换？具体做事不能太投入 做每件事，都要给它分配一个时间，比如做它用一个小时，就算完成不了，也要学会切换。 要知道事情的轻重缓急。 做事内容是一个关注点，但是事情的轻重缓急更是事情的一个重要属性。每个事情要设置一个优先级，更要设置每个事情的时间片。轮换着做。TIP: 1. 当一个事情完成时，一定要注意这个事情是否是原子的，因为你做了一部分，而认

背景开发一般都依赖测试。但是如何做到低bug率，并提升效率呢？具体开发要主动并且爱上review自己的，而且要多遍，不是review一遍就万事大吉或者说就提测。 review代码可以提前知道自己的问题，并且可以不断深化自己对业务的理解。

1.背景延时任务如何精确处理，比如下单后10分钟没有支付，就必须取消订单。假如一个订单的下单时间是上午10：00，那么10：10必须做到该订单被处理。如果有成千上万的订单都是这种情况，怎么做到都能够这样处理？2.方案思路一般情况下，待执行的任务，都是存储到关系型数据库中，这个现状会自然的影响我们做出下面的解决方法：轮询。 轮询：采用轮询的方案，假如执行轮询的是一个执行者（单个进程或者

有很多时候，事情的发展往往不尽人意，如果这个事情你不想放弃，就不要轻易放弃。 不要轻易放弃，就要用最好的状态和心态来努力争取，努力了就会有意外的收获。