CodeView活动的启动仪式发言稿
今天，我们部门的活动提前了。这可能是我们在这座使用了十几年的办公楼里最后一次提前举办活动，并不是为了庆祝即将到来的国庆节。主要原因是我之前提到过的，我们将举办一个名为“Codeview”的活动。为什么要举办这个活动呢？这得从很久以前离职员工的反馈说起。
每次有员工离开，我总觉得这是一次损失，但同时也是一次机会。我们失去了一位熟练的队友，但同时也迎来了新的队友，新的机会和想法。因此，我通常会在员工离职时询问他们，对团队有什么建议或遗言。他们通常都会直言不讳地指出同样的问题：团队的代码已经到了难以继续改进的地步，这也是他们选择离职的原因之一。
我平时看到大家交付的工作都挺不错的，代码有方法、有注释，也能按时完成。但怎么会觉得无法继续改进呢？接下来，他们就向我倾诉了他们的困扰：代码可读性差、注释不清晰、功能重复、BUG频出，每个人都按照自己的喜好编写代码，毫无规范可言，甚至出现了将Service代码放到Controller层的问题。
这些问题，我相信在座的各位心中都有所感触，只是没有人愿意捅破这层窗户纸。但大家知道这些问题会带来什么后果吗？它们会导致代码难以理解、复用性降低、测试难度增加、可扩展性下降、性能受影响，甚至可能导致业务逻辑泄露。
这让我想起了海峰上次分享《代码整洁之道》时的一句话：“Rubbish in, rubbish out”。因此，我们有必要让大家一起来认可、识别、处理这些问题，并达成一致的理解和规范。这样可以减少代码输入的不规范性，降低编写代码的风险，缩短处理问题的时间，让编程体验更加顺畅，工作更加轻松。
可能有人会说：“我觉得现在的写法很舒服，我想怎么写就怎么写，你管得着吗？”我们听过很多脱口秀节目，其中程序员经常吐槽老板，比如邱瑞说的，他们的老板会开发，整天帮员工改代码，一行代码能改进去5个BUG。如果我们产品的质量实在不过关，那把我逼成那样也不是不可能。
当然，这些都是玩笑话。作为程序员，如果你想在某方面成为专家，最有可能的是哪里呢？肯定是代码的经验和设计的思路。根据成为专家的“万小时理论”，我们每天都在刻意练习，但如果缺乏反馈和规范，那又是什么呢？
爱因斯坦曾说：“什么是疯狂？不断重复同一件事并期待不同结果。”你想成为专家，但每天都用同样的方式、同样的习惯来编写代码，不看看别人、高手的反馈，你能成为高手或者大师吗？
因此，我们希望大家把每天都在重复的工作视为自我精进的过程，这就需要我们重新认知和改变。
