前言
回顾大约7年的程序员生涯，从一开始的小白，到如今成长为一个能够去帮助他人的程序员，虽然离大牛还差得远，但仍是有些东西想写一写，就当思绪的偶尔停留。若是能对他人有所启发，就是意外的收获了。 这里不写具体的编程语言、技术内幕，而是写一些广泛适用的，甚至不止适用于编程领域的内容。这些所谓“进阶思惟”，有些是我在成为程序员以前就具有的，有些是我后来慢慢学会的。按照惯例，先整体罗列出来：程序员
- 并行思惟
- 并发思惟
- DRY (Don't Repeat Yourself)
- 可维护性 >= 性能
- 防护式编程
下面我将逐一阐述。编程
正文
并行思惟
提到并行，就不得不提“串行”。并发
咱们常常去银行办理业务，有些银行中午也上班，但会关闭一些窗口，若是只留一个开放窗口，客户只能依次办理业务，这种情形就是串行。编程语言
中午事后，工做人员陆续回来了，其它窗口陆续开放，客户能够同时办理业务了，这种情形就是并行。布局
很明显，开放的窗口越多，银行接待客户的效率越高，客户等待的时间越短。用一个专业词语来讲，开放窗口越多，并行度越高。性能
有些大型超市，在购物高峰期会增长收银通道，这也是提升并行度的例子。测试
以上是生活中的场景，跟写程序无关，如今假定你须要处理1000万条数据，通过初步测试，从头开始逐条处理，预计须要10个小时能处理完。实际状况须要你想办法在1个小时内处理完，此时你应该能从银行或超市获得启发。进程
逐条处理，至关于只开了一个窗口（程序），若是开10个窗口（程序），速度就能够乘以10倍。资源
这里是按数据ID的维度并行处理，是否还有其它的维度呢？文档
并发思惟
故事仍是发生在银行，时间到了中午，客户依然在排队，开放窗口只剩下一个了。这时有一些不守规矩的客户，又排了一个队出来，一个窗口，两个队伍，工做人员很为难。
大堂经理看到状况不妙，过来劝说，让这一波不守规矩的人排在原有队伍的后面，成功解围。
一个窗口，两个队伍，对于窗口来讲，这种情形就是并发。
从程序的角度看，典型的场景是多个进程同时去修改同一个资源，例如多个进程同时去修改一个计数器。假定业务实例编号的自动生成规则，新编号为已有的最大编号加1，这是否存在并发问题？
简单的想一下，当前最大编号为100，两个用户同时建立实例，若是不考虑并发，两个用户获得的编号都是101，这显然是一个bug。
如何判断代码是否存在并发问题，只须要判断：两个进程同时执行这段代码，是否会出问题。
如何处理并发问题？大堂经理的作法能够带来一些启发。
DRY (Don't Repeat Yourself)
此次的故事发生在银行大堂经理身上。最近银行作了一次装修，柜台布局有些变化，常常有客户问xx业务在哪办理。经理在回答了10多遍以后，在银行入口处贴了一张告示：xx业务办理，左转倒数第二个柜台。
大堂经理这么作，是由于他不想重复回答同一个问题。
联想到写代码，DRY的通俗表达就是“封装”。有些“懒”的程序员，一样的代码写3遍就去封装了，有些人则比较“勤快”，不厌其烦地写着一样的代码。
看来，懒并非一个贬义词，程序员应该懒一点。
DRY带来的另外一个好处：减小代码冗余。重复10遍的代码，修改起来也须要10次；若是封装起来，修改只须要一次，维护成本急剧降低。
再联想到平常的工做沟通，若是发现本身老是在重复回答一些问题，不妨写一篇QA文档，若是再有人问，直接让他/她去看文档便可。
可维护性 >= 性能
有一句不知出处的话：代码首先是写给人的，其次才是写给机器的。
软件代码老是被不断维护、重构，这些都是人的工做，因此代码首先是写给人的。
若是一段代码没人维护，只有两种可能：没用的，或没法维护的。
一段代码没人能读懂，或者读懂代码太花时间，还不如重写，即便它的性能很好，也是无用的垃圾。
显然，代码量越少，相应的维护成本就越低，这也是DRY原则提倡的。举个例子，一个方法原本有100行，重构后增长200行，性能提高10%，这时就须要在可维护性与性能之间做出取舍了。
100行的代码清晰易读，性能略差；300行的代码晦涩难懂，性能较好。你选哪个？
防护式编程
你们都有乘车的经历，前段时间去千岛湖，我乘坐的大巴，老是紧跟着前车行驶，驾驶员假定前面的车不会急刹。
防护式驾驶，是假定他人的驾驶是不可靠的，行人是不可靠的，自身主动去规避风险。为了不前车急刹致使追尾，须要保持车距。
引伸到编程，防护式编程就是自身主动去规避他人的代码错误，例如参数传递错误，返回值错误等。
对于PHP这种弱类型语言，一个方法接受array类型的参数，若是在一开始就检查参数类型，就属于防护式编程。调用他人的API，拿到返回结果的第一时间就去校验是否符合预期，这也是防护式编程。
归纳成一句话：防护式编程是自身主动去规避风险，避免他人的错误致使自身程序崩溃。
后记
这篇文章断断续续写了一周，还有一些想法之后继续写。
欢迎批评指正。