程序猿的防脱发秘籍

近来年终这段时间， 紧急的需求一个接一个， 直接导致口腔溃疡、脾气爆炸， 以至于掉发剧增， 赶个地铁碰到较真的安检员拦着都可能导致一天的坏心情。 为了防止英年早谢的惨剧， 可得好好梳理梳理我这暴脾气。

仔细想来， 每次脾气爆发的节点都是在一番努力工作之后， 结果却低于预期， 直接导致心态爆炸。 你说我辛辛苦苦加班加点努力出来的成果， 却被测试找出诸多bug， 设计觉得这不好看那不好看， 产品要改这要改那， 老大怪你这没做好那不够完善， 我还得笑嘻嘻的应对： 改改改。 MLGB， 这不爆炸才怪呢。导致上述境地的原因暂且不谈， 怎么平和的去接受才是关键， 怎么也得为了咱那乌黑亮丽的秀发着想， 你说是不（请摸着峰顶不算茂盛的植被回答）。

归根结底， 预期逾大， 落空之后越容易爆炸。 所以， 醒醒吧， 预期≠白日梦， 谁说的你辛辛苦苦加班加点做出来的东西， 就应该毫无bug， 受到各方人员的赞赏。 哪个程序猿不是在生产bug的道路上一步步走过来的呢， 作为程序猿， 应该存有bug会有的、设计会改的、需求会变的这样基本的认知， 不能抱有太大的预期。 如此， 才能平和去改改改。

bug才是常态。 看到这， 估计很多大神手里的刀片已经蠢蠢欲动了。 别急， 且听我细细道来。 程序猿不是神， 难免有疏漏， 所以偶尔的一些bug是在所难免的。 换个角度思考， 测试是干嘛的， 找bug的啊！ 毫无bug的程序猿如何体现测试小姐姐们的价值， 如何与测试小姐姐和谐相处擦出闪耀的火花！ 所以说， 我们生产bug， 为得是那些嗷嗷待哺的测试小姐姐啊， 写到这， 不知不觉挂上了父母般慈爱的笑容。 走啊， 写bug去。

bug.jpeg

需求变更需理解。 可能我们无数次吐槽， 产品咋这么傻逼， 文案老是改来改去， 弹框、toast、点击效果也要抠住不放。 但是， 我们有没有问过为何要这么改， 有没有想过自己使用文案不通、 交互很差的产品的感觉？ 作为一个合格的程序猿， 我们还应该对用户负责， 所以， 在产品变更需求之前， 我们就应该仔细审视产品的设计是否有疏漏， 讨论是否能有更优的实现， 从而减少需求变更的次数， 皆大欢喜。 emmm... 当然也有可能讨论的结果给自己挖坑， 自己挖的坑， 含着泪也得往下跳是不。

业内加班是常态。 并没有赞扬的意思， 只是在这种风气无法改变的， 只能这样自我安慰， 想想隔壁的游戏汪， 是不是心情舒畅了些许（可怜游戏汪一秒）。 并且， 作为单身汪的我， 加班使我快乐。 当然， 即便是这样的我， 有时也会遇到在有计划的周末被公司召唤的时候， 心情不爽在所难免， 只能理性地自我调节咯。 总不能计划打破， 带着一肚子气去公司加班， 结果工作效率低下， 两头受气， 想想多亏啊。不过， 那些打着理想的旗号天天强制加班的公司都是耍流氓， 我可以这样自我安慰， 但是你不能。

work.jpg

相信，带着以上的这些认知， 基本可以应对工作大部分令人爆炸的场景了， 也不用过分担心茂密的封顶日渐稀疏了。