在学习《问题分析与解决》时学到了一种找到问题根源的方法——问五次为什么。具体内容是：当遇到一个问题，不要只看当前答案，要继续往下问，为什么，连问五次，就能够找到更深层次的问题。 最近在复盘bug的时候，也使用了这种方法，屡试不爽。
案例前端发布后，页面按钮点击失效，用户反馈问题，前端回滚代码后恢复。 问题一、为什么按钮点击会失效？ 因为前端代码写出了一个bug，没有对空对象进行判空，导致页面js抛出异常，按钮失效。 一般到这里就结束了，把代码加上对象判空，继续发布就完成了。 但是大家集思广益，问五次为什么，看看是否有新的发现。 之后又问了几个为什么，果真有收获。 问题二、为什么是用户反馈...
最近参加了多次的代码review会，在review的过程中，发现有些问题几乎每次都出现。挑了几个比较典型的问题讲解下。这几个问题都是初级问题，解决方法都很容易。只要掌握了方法，有意识避免，能让短时间内迅速提高代码质量。真所谓投入小，见效快。
变量命名不清晰，一词多义为变量命名时最重要的考虑事项是，该名字要完全、准确地描述出该变量所代表的事务。容易阅读，不会与其他事务混淆。
例如：
1234if(staff_id == 0){ printf("系统归档，不是员工归档");}
上面这段代码，staff_id是员工号的意思，用staff_id为0表示是系...
管理者工作中，很大一部分就是决策。如何作出有效的决策？先要了解有效决策的几个要素：
一、了解问题的性质做决策前先对当前问题进行思考，是经常性问题，还是偶然性问题。如果是偶然性问题，把它恢复原状就完成了。如果是经常性问题，要制定一套规则来解决。
经常会混的是本质是经常性问题，但是被误以为偶然性问题，要仔细分析。例如运营环境总出现发错消息的事故，每一次看着原因都不同，都很偶然，不是配置错了，就是代码bug。如果当作偶然性问题，头痛医头脚痛医脚，每次都打补丁，看似解决，实则危机四伏。本质是对发消息机制的检查不够，包括权限流程检查，代码审查，运营异常监控。这三方面哪方面做了，都能拦住最后的事故，...
人的精力、时间是有限的，在有限的资源下，如何能作出巨大的贡献，甚至是无限的贡献呢？就是要做重要的事，优先做重要的事。 如何做到要事优先，尽可能产出更大的成果呢？
一、摆脱过去1. 不要躺在过去的功劳簿上 成功要依靠天时地利人和，还需要一点点运气。但是成功的人，大部分都认为是自己的努力，不愿意承认和运气有关。很多成功过的人，都会把过去的实践当成真理。因为我用这招成功过啊。但是有没有想过，时机不一样了，当初的很多条件变化了。 在2014年做移动游戏，是很赚钱的，能够绕过大公司的壁垒，很多小公司都赚得盆满钵满。放到今天，时代变了，大公司已经把移动互联网都布局完了，用户的口味和审美也越来越高了，...
案例一个管理后台的bug，把操作记录中的操作员姓名，写成了该操作员的id。原因是修改了一个返回操作人姓名的函数，返回了操作人的id。但是还有其他地方也用这个函数，导致其他地方把姓名字段填写成了操作员的id。该bug污染了一条修改记录，操作员手动删除就好了。回滚代码后恢复。本质是修改了函数的返回值，却没有查看所有调用的地方。这个函数的名字叫getinfo，但是在代码的其他模块中也有同名函数，返回的都是id，让修改的人以为都是一个函数，引起了混淆。所以函数名也要修改，做到通过名字能够清晰看出函数功能。
本来很简单的一个线上bug，按照上面的描述几句话就说清楚了，但是一个组员说了一个小时，才勉...
如何做系统迁移下线类的需求系统迁移类需求，要考虑：
要考虑可以回滚
要有前后效果的对比
对老系统要有监控，是否真的流量没了，而不是依赖于具体业务迁移方说迁完了，要相信自己的眼睛。
有一个冷却时间，过了冷却时间再下掉机器。
例子：要去掉一个老的图片系统，让业务方反馈都谁有调用过，然后让大家去改，改好了上报。
实际上要让大家反馈，还要根据流量或日志，验证是否反馈的正确，是否有遗漏。按照规模分别拉群组织，给出迁移的基本通用方案，让大家能够做到快速迁移，快速检测迁移效果。当有人反馈迁移成功后，能够验证是否迁移正确、完全。定期推动迁移节奏，防止业务忘记迁移，导致迁移时间过长。尽量控制时...
组件升级，大多数程序员都觉得很简单，直接给个新的包，或新组件的地址，让大家都去下载不就可以了。但是实际这里面还是有很多学问，和需要考虑的地方的。
要考虑业务推广的难度，以业务方来看，不要没事改这改那，对业务没有什么帮助，相反到有所风险，而且还增加了工作量。
如何做组件升级需求，都是围绕着如何减轻业务顾虑来做的。
听说Facebook的最简单粗暴，谁升级组件，谁就负责把别人的代码改好。
要保证api尽量向前兼容如果api有同样的功能，但是新版本变了，会让业务很难接受，因为本来已经写好的东西，又要重新修改。或者是为了使用一个新功能，但是让业务要重新改动和此不相干的大部分代码，这些都是不可取的...
人类总是在不断的扩大边界，没有终点，边界不断变大
多少钱够花，多少时间够用，多快的计算机够速度。永远不够。
人类总是能制造新的边界，原以为达不到的，到了就够用，当新边界到了时候，又会去更远的地方，就像地平线，看得到，但永远达不到。
对于人来说，要适应变化，不断进化自己，才能适应时代发展规律，永远在线。
程序员如何讲清楚技术方案最近在评审技术方案，和代码review的时候，遇到刚入行的同学们，很多都讲不清楚技术方案。
具体表现是：
上来不说需求，直接说算法实现。台下一头雾水，根本不知道设计方案是否合理。
描述完需求后，又直接看代码，看表结构，没有交代流程。
比较简单的算法，描述的特别绕，让人听不懂。被别人指出后，觉得这东西这么简单，你们为什么听不懂，还很委屈。
直接说术语，不给解释。还有自己造术语不给解释的，更混乱的是「复用」已有的术语，让大家理解都不同。
那么程序员如何把技术方案讲清楚呢？下面从实用的角度教大家一些小技巧，在短时间内具备讲清楚的能力。在文末给出通用的方法论学习书籍，...
出笔试题的目的：为了筛选人，筛掉不满足需求的人。所以题目要有区分度，能够区分出哪些是可以的，哪些是肯定不行的。然后把满足需求的人也能够按照层级区分开来。
题目尽量不要出死记硬背的题目，不要出偏题怪题。我们的目的不是为了考倒应试者，而是为了找到合适的人。对于知道不知道的知识，尽量少考。多考思考类的知识，因为我们能够培养不知道的人知道，但是很难让思考不明白的人明白。
要有必须要会的题目，这种题目必须要面试者打出来，如果答不出来，直接就不过。
还有分层次体，一个题目要有及格答案，优秀答案的分别，能够区分出面试者的能力。
题目有部分网上找的经典题，即使有人准备，也证明准备了。还有自己出的经典的题...
