近来年终这段时间， 紧急的需求一个接一个， 直接导致口腔溃疡、脾气爆炸， 以至于掉发剧增， 赶个地铁碰到较真的安检员拦着都可能导致一天的坏心情。 为了防止英年早谢的惨剧， 可得好好梳理梳理我这暴脾气。
仔细想来， 每次脾气爆发的节点都是在一番努力工作之后， 结果却低于预期， 直接导致心态爆炸。 你说我辛辛苦苦加班加点努力出来的成果， 却被测试找出诸多bug， 设计觉得这不好看那不好看， 产品要改这要改那， 老大怪你这没做好那不够完善， 我还得笑嘻嘻的应对： 改改改。 MLGB， 这不爆炸才怪呢。导致上述境地的原因暂且不谈， 怎么平和的去接受才是关键， 怎么也得为了咱那乌黑亮丽的秀发着想， 你说是不（请摸着峰顶不算茂盛的植被回答）。
归根结底， 预期逾大， 落空之后越容易爆炸。 所以， 醒醒吧， 预期≠白日梦， 谁说的你辛辛苦苦加班加点做出来的东西， 就应该毫无bug， 受到各方人员的赞赏。 哪个程序猿不是在生产bug的道路上一步步走过来的呢， 作为程序猿， 应该存有bug会有的、设计会改的、需求会变的这样基本的认知， 不能抱有太大的预期。 如此， 才能平和去改改改。
bug才是常态。 看到这， 估计很多大神手里的刀片已经蠢蠢欲动了。 别急， 且听我细细道来。 程序猿不是神， 难免有疏漏， 所以偶尔的一些bug是在所难免的。 换个角度思考， 测试是干嘛的， 找bug的啊！ 毫无bug的程序猿如何体现测试小姐姐们的价值， 如何与测试小姐姐和谐相处擦出闪耀的火花！ 所以说， 我们生产bug， 为得是那些嗷嗷待哺的测试小姐姐啊， 写到这， 不知不觉挂上了父母般慈爱的笑容。 走啊， 写bug去。
需求变更需理解。 可能我们无数次吐槽， 产品咋这么傻逼， 文案老是改来改去， 弹框、toast、点击效果也要抠住不放。 但是， 我们有没有问过为何要这么改， 有没有想过自己使用文案不通、 交互很差的产品的感觉？ 作为一个合格的程序猿， 我们还应该对用户负责， 所以， 在产品变更需求之前， 我们就应该仔细审视产品的设计是否有疏漏， 讨论是否能有更优的实现， 从而减少需求变更的次数， 皆大欢喜。 emmm... 当然也有可能讨论的结果给自己挖坑， 自己挖的坑， 含着泪也得往下跳是不。
业内加班是常态。 并没有赞扬的意思， 只是在这种风气无法改变的， 只能这样自我安慰， 想想隔壁的游戏汪， 是不是心情舒畅了些许（可怜游戏汪一秒）。 并且， 作为单身汪的我， 加班使我快乐。 当然， 即便是这样的我， 有时也会遇到在有计划的周末被公司召唤的时候， 心情不爽在所难免， 只能理性地自我调节咯。 总不能计划打破， 带着一肚子气去公司加班， 结果工作效率低下， 两头受气， 想想多亏啊。不过， 那些打着理想的旗号天天强制加班的公司都是耍流氓， 我可以这样自我安慰， 但是你不能。
相信，带着以上的这些认知， 基本可以应对工作大部分令人爆炸的场景了， 也不用过分担心茂密的封顶日渐稀疏了。
