我想到了设计模式，之前有个直播写代码的程序员，粉丝还挺多的，他大言不惭的说搞设计模式的都是装逼。 我一时不知道怎么反驳他。 后来我想明白了一个问题，除了扩展性以外，所谓的设计模式，就是程序员之间约定好的代码语法，我看到这段代码用了什么设计模式，大概就能猜到是什么功能了。
不同母語的可讀性/偏好不一樣. 漢語 SVO, 日語 SOV 主賓動語序. 比如，Java 物件導向看 Lisp 系會覺得一堆括號和閉包沒有可讀性. Lisp 系會覺得 lambda 是日常. JS 日常短路求值, 隨處可見. `var locale = navigator.language || navigator.browserLanguage;` 每天工作都看得到, 已經刻入母語底層 不用思考. Basic 系會覺得什麼短路求值, 沒有可讀性.
代码的可读性和实际水平非正相关 我所接触的开发以 1-10 年为范围吧。 1-2 年老老实实写，虽然性能可能烂但是可读性好，学习态度良好说说愿意改。 3-4 年开源项目看的多，奇技淫巧学的多，魔法操作一对对 说还不愿意听 可读性最差的工作年限。 5-10 年代码健壮度逐渐提升，能够考虑兜底方案，从代码开发阶段及时提出改进方案。 个人理解的可接受奇技淫巧最主要的前提是性能有真实的提升或者其他代码的便利性有明显提升与此同时性能仅有少量降低，这些是可接受的。 如果你的奇技淫巧没有性能提升可读性还变差就是垃圾，通常 ide 的代码提示也没有了，关联代码跳不过去，大概率应该与反射有关吧，除非你的需求真的于此有关。 代码的可读性有很多方面就是通过代码的执行流程让人能够理解你的解决方案，有些为了性能的奇技淫巧应该加代码注释和文档辅助。 至于你说的远离业务代码我不认同可能你以为的业务代码只有 curd 吧。。。 就 curd 来说没有并发的 curd 和 qps 过万的 curd 是完全不同的领域。
谈可读性的前提是大家拥有相似的认知水平，认知水平相差太大就会导致一个人觉得很好读而另一个觉得不好读的情况发生。 比如你对一个熟悉函数式语言的人讲使用 pattern matching 有助于提升可读性，他大概率会同意你的观点；而你对一个跟没有怎么接触过函数式语言的人讲这件事情，他大概率觉得你在胡扯，而反倒觉得尽可能使用基础的控制流语句才是提升可读性的方法。
看项目代码前，先看项目需求文档，项目设计文档， 等等说明性的文档，对项目和业务有了解在去看代码。 没有没脑的拿一段代码出来， 是谁都不知道干什么用的，更不要说什么可读性了， 你根本就不知道为什么要写这个代码。
