长假随想

今天是休假的第三天，9月本想更新一篇日志上来，奈何太忙了，只好拖到了今天。

9月发生了两件事，对我产生了一定的影响。一是组内关系较好同事的离职，和之前那位关系很好的同事一样——为了前途，为了钱途。而组内刚好也进行了人员变动（另一位能力很强的同事也被调度到了另一条产品线），一些活直接到了我手里，但项目的展开还在继续，资源一下子就变得很紧张。

那么是这个软件很难吗？其实并不是。我写过业务更复杂的软件，但还是将它交付给另一个组的同学去开发维护了，至今还在迭代。故此我还是有一点发言权的，问题的原因在我看来有两点：

1. 快速迭代中忽视了人才培养，即某个模块一开始由A负责，后来为了迭代速度则一直由A负责，而其他人并不熟悉A负责的模块，那么如果A离职了则会引起单点故障。
2. 为短期利益舍弃了长期发展：部分模块的可读性并不强，大量违反SOLID原则，但并没有机会重构以及补充适量的自动化测试，只能基于熟悉的经验去增加业务代码及缓慢的手公测试去验证，就像明明是工业时代却还在用石器时代的低效率做法。相比第一个问题，这需要至上而下的达成共识。我们常说先有再好，那么前期就是讲究一个快字。这听起来没有任何问题，因为产品得先卖出去，才有钱，才能养活团队。那么我们一般如何判定“快”呢？
   • 某个功能某位同学来做只需要3天，其他人来做可能要5天，很快！
   • 组里的人都在加班了，原计划10天的功能5天就可以出来了，很有精神！

那么快带来了什么问题呢：

1. 某个功能某位同学来做只需要3天，其他人来做可能要5天。这位同学对业务很熟悉，且反应灵敏，于是主管觉得很多东西都可以迭代的很快，整个项目继续基于这种方式迭代，直到几个星期后发版时回归出了一些问题，或者为了快来不及回归，直接发布到客户现场然后炸雷，客户印象极差。但后来他离职了。在此之后，3天做一个功能就很难了，因为过程是不可复制的，这基于某人的能力，而不是那些可复制的文档、设计、自动化测试用例。
2. 组里的人都在加班了，原计划10天的功能5天就可以出来了。但是如果一开始我们就采用了符合规范的做法，我们可以更快的做好这些事，而不是加班加点，再一次降低软件质量。

问题到这里就结束了吗？显然不是的。这需要至上而下的去解决，并不是单纯的技术能解决的。

第二件事则是我的挚友结婚了。见到了几个好几年没见的同学，以及在他向新娘致辞的时候我流下来了感动的泪水——我之前常为别人结婚流下泪水感到奇怪，而我这次算是明白了。我为他的幸福感到高兴，同样也感叹自己的青春似乎快到末尾了。

那阵子还回去看了一眼高中老师，说到离开学校的时间以及同学们的变化，让我恍如隔世。老师说大家都很幸福，对于幸福定义模糊的我来说，不禁好奇，于是展开聊了聊。老师还特意提醒了我身体保重——这是自然的，因为这是我活在世上的基础啊。

总而言之，这次回家最大的感觉就是——我正在变老，或者，留给我自己发挥的时间不多了。