一张调薪通知
2005 年，我在北电工作满一年，经历了人生第一次所谓的“普调”。
我的经理约我做一对一沟通，递给我一张调薪通知。他叫 Fred。
那张通知上的涨幅我已经记不太清了，印象中大概只有 3%。
我看了一眼，其实并没有什么特别的感觉。毕竟刚毕业没多久，这是人生第一次加薪。我甚至不知道原来还有这回事，也不知道 3% 到底意味着什么，所以反应很平淡。
反倒是 Fred 显得有些激动。他皱着眉头说：
“这肯定搞错了。” “我帮你再争取一下。”
我当时还有点莫名其妙。
钱都已经涨了，为什么还要争取？
后来我才知道，有些事情，年轻的时候是看不懂的。
一本很红的书
2000 年前后，软件行业有两个特别热门的话题：一个是泛型编程，一个是 Design Pattern（设计模式）。
今天的年轻程序员听到“设计模式”，大概和我们今天听到“汇编优化技巧”差不多：知道有这么回事，但已经很少把它当成一种必须掌握的核心能力。
可在那个年代完全不同。
《Design Patterns》几乎是所有程序员书架上的必备读物。因为作者有四个人，所以大家更习惯叫它 GoF（Gang of Four）。
那几年，Design Pattern 和泛型编程如日中天。大家都在讨论这些“高级技术”应该如何应用到实际项目里。
而我，也是其中疯狂随大流的狂热分子之一。
一个让我得意的设计
那段时间，我参与了一个项目。项目里有一个关于 Flash 日志写入策略的设计。
对于电信级系统来说，这并不是一个简单的问题。Flash 的擦写次数有限，写得太频繁，会影响设备寿命；写得太保守，又可能在断电等极端情况下影响系统可靠性。
因此项目设计了两种不同的日志写入机制，而我负责具体实现。
当时 Design Pattern 正热，而这个场景又刚好完美符合 Strategy Pattern（策略模式）的典型应用方式。所以我最终采用了这种实现方案，把两种写入机制封装成不同的策略，在运行时根据场景动态切换。
从代码结构上看，非常优雅。
后来项目的北美 Architect 专门发了一封很长的邮件，对这个设计给予了公开表扬。对于一个工作刚满一年的新人来说，这种来自顶层架构师的认可还是很受鼓舞的。
Fred 后来也专门在小组的会议上聊过这件事，给了很多正面的反馈。
第二张调薪通知
大概一个月后，Fred 再次约我做一对一沟通，然后递给我第二张调薪通知。
两次调整加起来，差不多接近 20%。
这次我是真的有点意外了，连忙向他道谢。他只是微微笑笑。
后来有了更多的职场经历后，我才慢慢意识到这件事并不简单。
对于一个工作仅一年的新人来说，管理者往往不会有太高的调薪预算与规划。而 Fred 显然觉得，我的付出和成果应该得到一个更合理的回报。
我相信，这个过程绝不会只是填一张表那么简单。总会有解释、沟通、争取，甚至打破一些原本默认的规则限制。
后来我见过很多管理者，也做过管理工作，才慢慢理解一件事：
有些管理者会告诉你：
“规则就是这样。”
而有些管理者会觉得：
“规则应该服务于合理的结果。”
显然，我极其幸运地遇到了后者。
那些后来被我忘掉的模式
这些年偶尔想起这个项目，如果让我重新写当年的代码，我大概率不会再使用 Strategy Pattern。
甚至会觉得那个设计多少带点炫技的成分，属于典型的过度设计。两种策略而已，也许几个简单的函数就能完美解决问题，根本不需要构建那么复杂的抽象层。
但我也明白当年的我会这么做。
因为很多理解，并不是通过直接学习获得的，而是通过实践的碰撞获得的。
你必须亲手做过一次复杂设计，才会真正理解什么叫简单；你必须认真搭建过很多抽象层，才会理解什么叫克制；你必须走过一些弯路，才会明白直路为什么珍贵。
所以后来有人问我：设计模式还有必要学吗？
我的答案一直是：学。然后尽量在真实项目里用一次。再慢慢忘掉它。
因为学习软件设计的过程，并不是去死记硬背多少个 Pattern，而是在不断实践与反思之后，最终理解什么时候该用，什么时候不该用。
那些被我一直记住的事情
这些年，那本 GoF 里的很多具体技术内容我已经记不太清了。
但有两件事一直深深留在了心里。
一件事，是那个被北美 Architect 公开表扬的设计。
另一件事，是那个坚持帮我争取第二次调薪的经理——Fred。
前者让我知道：认真做事，总会有人看见。
后者让我知道：一个管理者当然要遵守规则，但有时候，也要愿意为自己相信的人去对抗和争取一点什么。你只有经历过死板的规则，才会明白那些愿意为你打破规则、争取合理结果的管理者有多么不可多得。
至于那个 Strategy Pattern，这些年我大概已经忘得差不多了。
但成长往往就是这样。
有些技术后来会被遗忘，有些代码后来会被删掉。
但那些在途中照亮过你、帮助过你的人，和那些让你真正心智蜕变的经历，会伴随你一生。