所属文章系列及序号：寻找尘封的银弹：设计模式精读（一）
《设计模式》这本书自从第一版开始，到现在已经畅销了20多年，仍然长盛不衰，很多书籍都是由它衍生而来的。程序员在面试的时候，也会经常被问到关于设计模式的问题。
但是，进入一家新公司之后，才发觉产品代码中很少出现设计模式，即便出现，其编码手法也比较稚嫩。相反的，复制粘贴的代码随处可见，漏洞百出的代码俯拾皆是，当我们发现看不懂的代码时，就去读注释，然而，我们看到的大多是啰嗦到不忍卒读的注释，或者是简约到只有规范没有内容的地步，就是这样的注释，在编码规范的光环护卫下，显得那么难以下咽，却又不得不吃。
于是，面试时被问到设计模式时的兴奋感--今后可以在设计模式上施展拳脚了，逐渐归于平淡。再后来，经过了无数bug的洗礼，平淡逐渐蜕变成了无奈。此时才对那些“稚嫩”的设计模式代码，产生了由衷的敬佩之情：人家的手法虽然稚嫩，却做到了！
很多程序员会在内心中反复问自己：该怎么办？
我想不外乎三条路：
一、找一个注重技术的公司。
二、找一个注重技术的上司。
三、寻求上司的支持。
这三条路，最终都能归结为“搞定上司”一条路，只是不同的实现层次而已！
【找一个注重技术的公司】
说实话，这种公司真的很难找。
我见到过一些公司，嘴上说“注重技术”，但行动上却是“注重进度”，这种现象，在我所经历过的国内公司和外企中都是如此，只是程度的不同而已。
其实，这种“注重进度”的思维，并不像想象的那么不堪或者不高尚，试想：如果连生存问题都解决不了，何来“注重技术”？正像管仲说的：“仓廪实而知礼节，衣食足而知荣辱”，他的话用在软件公司上，依然不过时。
人家公司正处在“Start up”阶段，或者说粮仓见底阶段，作为一个想实现“设计模式”小理想的程序员，最好的方式是和这里说一声“Good luck”。
【找一个注重技术的上司】
即便在一个不太注重技术的公司，如果能遇到一个注重技术的上司，也能实现自己的技术小理想，不过这是一件可遇而不可求的事。这在某种程度上解释了：有些人只用几年时间就成为了一个领域的高手，而有些人用了十几年仍然徘徊在高手和俗手之间。
在注重技术的上司手下工作，上司会为你顶住来自公司高层的进度压力，有时还会为你提供技术指导，你与上司之间，拥有如此契合的价值观，会让你的信心和责任感陡增，怎敢不把代码写好吗？
【寻求上司的支持】
前面两种情况，运气的成分超过50%，而现在要讨论的这种情况，几乎没有运气的成分。同时“寻求上司的支持”这种情况，是大部分程序员要面对的通常情况，需要用自己的方式搞定上司，否则就不要奢谈什么小理想！
如果公司的实际价值观是“注重进度”，上司的实际价值观也是“注重进度”，而你的价值观却是“注重技术”。如果这种矛盾积累得时间长了，可能会产生“不在沉默中爆发，就在沉默中灭亡”的情绪。这当然不是解决之道，而只是让自己的情绪“不受控制地自由发挥”而已。
和上司搞好私人关系，这是我们首先能想到的。然而，怎么搞？
上司交代的任务，除了保质、保量、提前完成之外，还能做到早请示晚汇报、事事有着落、件件有回音，而且态度积极、和颜悦色，上司会觉得你很靠谱儿和顺从。在私人关系上，没有笑点也要挤出笑点来取悦上司，与上司的爱好看齐，你抽烟我给你准备打火机，你爱看电影我就和你聊电影。
我相信这种做法一定能“搞定”绝大部分上司，不过这种方法会让自己很累，每天戴着一副面具，时间久了，能不能坚持得住也是一个问题。也许，自己某一天状态不好，一反常态，一句不经意的话得罪了上司，那么以前的所有努力有可能会瞬间化为泡影。因为上司也知道，你的这一切表现，只是一个幻象，只是因为他是上司，你是员工，一旦触碰到他的利益，他会毫不犹豫地选择自保。例如，你想在一个时间紧迫的项目中，使用一个自己还不太熟练的设计模式，或者做一些较大的重构，上司会为了你的“每日讨好”而甘冒项目延期的风险吗？理智的上司是不会冒这种风险的。
本质上，这种上司想要的是下属的顺从和无风险，下属必须做到这两点，否则好不容易建立起来的与上司的私人关系，会瞬间失去作用。因为双方的价值观不同，发生分歧是迟早的事。
有一种更加智慧的方式也能“搞定上司”，敏捷软件开发大师Kent Beck为我们提供了一个很好的范例：
他在《实现模式》一书中写道：“将一些实现模式形成习惯后，我的开发速度得到了提升，令我分心的想法也更少了。”
他的这本书，主要关注于设计与代码的衔接，即让代码更加有效地体现设计，从而减少bug、便于阅读。他在形成习惯之后，写出优秀代码的速度，反而比写出一般代码的速度更快！不过他有多年的经验积累，再加上前期投入了几个星期，总结出一套优质编码习惯，而这个习惯远远超出了编码规范的范畴。
我们需要下定决心，才能舍得投入一段时间，去总结经验并形成习惯，时机可以选在换工作的间歇期、或者依靠每日的反思，厚积薄发才能一飞冲天！
于是，依靠习惯的力量，我们就形成了逻辑自洽，并不需要让项目延期，因此就不需要上司的特别支持。唯一需要注意的是，需要获得“同僚”们的支持，因为他们在code review时的意见是你需要听取的。
【结束语】
“找一个注重技术的公司”实际上是在选择“大船”，
“找一个注重技术的上司”是在选择“大船”上的头等舱，
“寻求上司的支持”是在大船上的末等舱里睡五星级的床。
如果大船偏偏是那艘“泰坦尼克号”，那么自己所做的一切努力都显得苍白无力。因为没有高手的指点，只靠自己的奋力打拼毕竟速度慢。可见“大势”多么重要！
附：设计模式开心之旅即将起航，敬请期待我的后续干货，是那种绝不枯燥的干货！
作于2018-4-20
