10炫技与克制代码的两种味道与态度.pdfVIP

2018/8/24 极客时间 | 程序员进阶攻略 讲堂 程序员进阶攻略 文章详情 10 | 炫技与克制：代码的两种味道与态度 2018-08-24 胡峰 10 | 炫技与克制：代码的两种味道与态度 朗读人：刘飞 07′52′′ | 3.61M 虽然你代码可能已经写得不少了，但要真正提高代码水平，其实还需要多读代码。就像写作，写 得再多，不多读书，思维和认知水平其实是很难提高的。 代码读得多了，慢慢就会感受到好代码中有一种味道和品质：克制。但也会发现另一种代码，它 也会散发出一种味道：炫技。 炫技 什么是炫技的代码？ 我先从一个读代码的故事说起。几年前我因为工作需要，去研究一个开源项目的源代码。这是一 个国外知名互联网公司开源的工具项目，据说已在内部孵化了 6 年之久，这才开源出来。从其 设计文档与代码结构来看，它高层设计的一致性还是比较好的，但到了源代码实现就显得凌乱了 些，而且发现了一些炫技的痕迹。 /column/article/13921 1/4 2018/8/24 极客时间 | 程序员进阶攻略 代码中炫技的地方，具体来说就是关于状态机的使用。状态机程序本是不符合线性逻辑思维的， 有点类似goto语句，程序执行会突然发生跳转，所以理解状态机程序的代码要比一般程序困难 些。除此之外，它的状态机程序实现又是通过自定义的内存消息机制来驱动，这又额外添加了一 层抽象复杂度。 而在我看来，状态机程序最适合的场景是一种真实领域状态变迁的映射。那什么叫真实领域状态 呢？比如，红绿灯就表达了真实交通领域中的三种状态。而另一种场景，是网络编程领域，广泛 应用在网络协议解析上，表达解析器当前的运行状态。 而但凡使用状态机来表达程序设计实现中引入的 “伪” 状态，往往都添加了不必要的复杂性， 这就有点炫技的感觉了。但是我还是能常常在一些开源项目中看到一些过度设计和实现的复杂 性，而这些项目往往还都是一些行业内头部大公司开源的。 在程序员的成长路径上，攀登公司的晋升阶梯时，通常会采用同行评审制度，而作为技术人就容 易倾向性地关注项目或工程中的技术含量与难点。 这样的制度倾向性，有可能导致人为制造技术含量，也就是炫技了。就像体操运动中，你完成一 个高难度动作，能加的分数有限，而一旦搞砸了，付出的代价则要惨重很多。所以，在比赛中高 难度动作都是在关键的合适时刻才会选择。同样，项目中的炫技，未必能加分，还有可能导致减 分，比如其维护与理解成本变高了。 而除了增加不必要的复杂性外，炫技的代码，也可能更容易出 Bug。 刚工作的头一年，我在广东省中国银行写过一个小程序，就是给所有广东省中国银行的 客 户发邮件账单。由于当时广东中行 刚起步，第一个月只有不到 10 万客户，所以算是小程 序。 这个小程序就是个单机程序，为了方便业务人员操作，我写了个 GUI 界面。这是我第一次用 Java Swing 库来写 GUI，为了展示发送进度， 线程每发送成功一封邮件，就通知页面线程 更新进度条。 为什么这么设计呢？因为那时我正在学习 Java 线程编程，感觉这个技术很高端，而当时的 Java JDK 都还没标配线程 concurrent 包。所以，我选择线程间通信的方案来让 发送线程和前端 界面刷新线程通信，这就有了一股浓浓的炫技味道。 之后，就出现了界面动不动就卡住等一系列问题，因为各种线程提前通知、遗漏通知等情况没考 虑到，代码也越改越难懂。其实后来想想，用个共享状态，定时轮询即可满足需要，而且代码实 现会简单很多（前面《架构与实现》一文中，关于实现的核心我总结了一个字：简。这都是血泪 教训啊），出 Bug 的概率也小了很多。 回头想想，成长的路上不免见猎心喜，手上拿个锤子看到哪里都是钉子。 /column/article/13921 2/4 2018/8/24