最近因为项目需要看一个开源项目的源码，这个开源项目据说内部开发孵化了6年，几年前才开源.看设计文档和源码，发现其高层设计的一致性还是比较好的，但是说到源码实现，就显得有点乱了。既然是一个时间跨度这么长的项目，那么参与这个项目的程序员肯定不止一组。不同阶段的程序员都可能参与，所以我们可以理解实现的混乱。看看这些一段时间沉淀下来的代码，有的代码可能是我刚工作的那一年诞生的，有的是最近加的。不免让我想起了作为程序员，随着这些代码在时间里的成长和沉淀。工作的第二年，接手了一个比较大的项目的一个主要模块。熟悉了整个模块之后，开始往里面加功能的时候，实在看不下去原来的DAO层，是基于原生JDBC封装的。每次添加一个新的DAO，都需要复制粘贴一串长得差不多的代码，时间长了难免会腻味。当时Hibernate刚刚兴起，觉得它的设计理念优雅，代码写的简洁，所以决定用Hibernate的实现替换原来的实现。重新实现所有原来的DAO层类，DAO类有上百个，导致多了一周的类。这是一个纯手工搬砖的工作。做完了，又有新的问题了。Hibernate在某些场景下存在性能问题。断断续续地处理这些新问题，着实让我疲惫了一阵子，后来反思这个决定，觉得真的不合适。替换的好处只是每次增加一个新的DAO时节省几行代码，但它带来了很多当时未知的风险。年轻的程序员对新技术充满好奇，有一颗冲动的心。对于新技术，我知道，我了解，我熟悉，我精通，但我还是要克制自己，等待合适的时机。写到这里，我想起了《勇敢的心》梅尔吉布森看着对方冲过来大喊Hold～Hold～的场景。之前在广东省的中国银行写过一个小程序，就是给广东省的中国银行的所有信用卡客户发送邮件账单。按照目前各大银行几亿信用卡客户的规模，即使是每月发送账单邮件的程序也不能算小。只是那时候广东中行信用卡刚刚起步，第一个月客户不到10万，算是小程序。当年我是全栈工程师，连计费页面模板的样式都是自己设计的。我第一次犯了一个小错误是金额显示没有右对齐。并且，该程序部署在信用卡部门业务人员独立配置的办公电脑上。对于按月计费，核心交易系统下发账单格式文件，业务人员手动导入格式文件生成模板邮件，然后开始发送。因此，这个小程序是一个独立的程序。为了方便业务人员操作，我写了一个GUI界面。第一次用Javaswing写GUI。为了显示发送进度，后台线程会在每次邮件发送成功后通知页面线程更新进度条。那时，我正在学习Java。JDK没有标准的并发包，都是原生的。感觉java线程编程很高端。所以我选择了线程间通信的方案，让后台发送线程和前台页面刷新线程进行通信，这是一种强烈的炫技心理。后来导致界面动不动就卡等一系列问题，因为各种线程提前通知，漏通知等等，代码越改越难看懂。其实一个共享状态可以通过定时轮询来满足，代码实现会简单很多。回头看，在成长的道路上，难免看到手上拿着锤子，到处都是钉子的烈欣喜。话说回来，还是很怀念当初设计的账单模板，可惜现在找不到了。比现在建行发给我的傻大黑厚表好看。传统银行在用户体验方面还能走多远？我现在看的开源代码也看出了一些作秀的痕迹，特别是关于状态机的使用。状态机程序不符合直线逻辑思维。类似于GOTO语句，程序会突然跳转，因此状态机程序比普通程序更难理解。状态机程序由自定义内存消息驱动，这增加了一层复杂性。在我的理解中，状态机程序最适合的场景是真实的映射域状态转换。什么是真实域状态？例如，您的红绿灯表示现实世界的三种状态。另一个主要目的是做协议分析，反映当前解析器的运行状态。在程序设计和实现中使用状态机来表达伪状态通常会增加不必要的复杂性。有时我经常看到一些开源项目有些过度设计和实现的复杂性，而且这些项目都是一些业内最大的公司开源的。在程序员的成长道路上，越是高级晋升，业界喜欢采用专家评审制，评审委员会往往关注项目的技术难点和技术含量。系统的倾向性也可能导致人为制造技术含量，不一定是与项目相匹配的最佳方案。因此，节目的技术含量和深度可能无法从表面上体现出来。我“看山看水是水，看山是山看水是水，看山是山看水是水”。转身归来，机锋锋芒尽收，巧思如拙，深则深，浅则浅。这也是我理解的KISS原则。在很多科幻小说和电影中，都有很多关于未来的假设，以及多个分支存在的可能。在科幻电影《Coherence》中，假设一个人可能有多个版本，恰好在某一天重叠。我真的很喜欢这个设置。它来自于“薛定谔的猫”的理论实验，也就是说未来有很多可能的版本，而我们经历过的部分形成了唯一稳定的版本。我已经走了很远，在时间线的很早的时候停下来回顾自己，得到了这些点点滴滴的启示。而现在的停下来和回顾，就是想用这个启示来帮助我们迈出下一步，无论大小。
