代码素养
写代码也是一样，很多人都只会考虑一种情况，这其实不是智商也不是能力问题，只是考虑问题的时候是否严谨。而当你告诉他这个地方需要判空，那个地方需要加try catch的时候，他往往不以为然，觉得这只是一时没考虑到而已。很不幸，这种素养很难短时间内养成，而这种没有代码素养的人，写大项目或者复杂系统，写出来的代码将是灾难。
就像一堆沙子，你把水倒进去，你根本不知道哪里在漏水，但是到处都在漏水，水一下子就没了，你只能推翻重写。而好的代码应该像一块铁板，水倒上去滴水不漏。
代码水平绝对不是会多少种语言，会多少个框架。而是你在写代码的时候的种种思考，对细节的处理，对各种情况的判断，代码的清晰程度等等。
控制复杂性
复杂问题简单化，在某个局部，程序的逻辑一定要简单，只有足够简单，才能提高可靠性。
如果你发现一个逻辑很复杂，都写不下去了，那么很有可能你的设计就很复杂，一定是你想的不够清楚
不需要什么都自己做
如果你想使用zookeeper实现一个服务发现，最好的办法是什么
- 找一个zookeeper的书，学一下，然后自己实现
- 到github上找个相关的源码，学习并分析一下
你觉得哪个更好些。
如何记笔记
你记了很多笔记，使用了笔记管理软件，但你碰到一个知识的时候，还是习惯性的打开浏览器，google一下，那么这些笔记还有存下来的必要么？或许学习一些搜索的技巧更重要。
恰当的报错
程序在运行过程中总会有一些异常，当异常会使系统失去服务能力时，这样的异常需要让用户知道。有时，则可以返回部分有效数据，无需让用户感知。
笔者曾经碰到一种情况，urla在app运行时会请求多次，返回part1和part2两部分数据。part1只在第一次请求时用到，part2则每次都会用到。后端在生成part1数据发生异常时，因为觉得不太重要，便没有报错，只返回part2数据，导致部分app用户显示错误。
理论上part1和part2应该是分开请求，但这又涉及到另一个理念，那就是冗余。假设第一次请求生成part1时报错，第二次请求没有报错（或者第二次请求时，part1数据进行了更新），则app可以根据第二次请求的结果对客户端显示进行校正。
可以运行，没有故障的系统肯定是好的系统。但是没有故障几乎是不可能的，好系统的另一个指标就是出故障了能够快速找到问题代码，并且能够快速进行故障恢复。而我们在设计系统或者写代码的时候就要考虑这些因素。
重构 + 维护才是代码最大的生命周期
工作后，常见的场景是
- 花一个相对完整的时间开发了一个项目，然而客户端没时间给你对接
- 你着手做别的项目，然后客户端找你对接，改点小需求，你急于赶紧干完，以尽快干自己手头的项目。
- 产品经理加点需求，你简单看了下原来的项目，加点代码。
- 代码一点点脱离了原来的设计思路，越来越难看，越来越不敢改。
这就要求我们写代码的时候注意以下几点
- 代码尽可能的能体现思路，按照“重构”那本书的说法：有时哪怕一行代码，如果有必要，也可以独立成一个函数（函数名表达它干了什么）
- 相关联的部分尽可能写在一个类中，以防止你改了一个地方，却忘了另外一个地方要做相应的调整。
代码不停地修改的过程，是你全面认识这个项目的机会，也是你不停重构代码的机会，单纯的为重构而重构通常意思不大。