变，才是王道

迭代回顾会议上，很多人都提到了xxx需求的变化导致了大量的代码返工，抱怨需求变化，抱怨系统架构
没有预先识别这个风险，抱怨其他模块没有屏蔽这个变化...


我当时的想法是，为什么没有人提出自己写的代码有什么可以提升之处，只是抱怨其他人能提高个人的
代码能力吗，能解决最终的问题吗？写代码时能不能尽量的少做假设和依赖？需求，变是很正常的，不
变反而奇怪了。不过，当时我并没有坦然的说出这个想法，依然在会上少发言，鄙视一下自己。


稍微做过几年开发的人都知道，需求总是常常变化的。这次的变化找到了几个很合理的理由（确实是这
样的），抱怨一番，表示是其他人造成了我的工作量，心里上也许会好受一点。但如果每次都这样，下
一次的变化依然可以找到其他的理由。


个人认为，写代码的关键是如果抽象出变化与不变部分，对可能变化的地方用什么样的方法解决。各种
各样的模式书籍，其实就是想归纳某一类问题用某种方法可以适应变化（改动甚少，或者不改动）。如
果都是一成不变的，还需要啥模式，架构啊。


不过在我司，吵吵闹闹，讨论几天，再加班几个晚上，把事情闹大，领导知道了，通报表彰，影响力也
有了，PBC也好写了，推动XXX事情解决了。这已经是常态了。


一直很怀疑，领导也应该知道这些现状，看起来是浪费的事情，为什么会认为是有功的呢？俺不是领导
，无从推测领导的心思。


变，才是王道，不仅仅是软件开发。