代码简洁之道-吴乐声

1、这次真被了。讲师上来就问“写程序让你想到了什么？”“加班、新需求、老代码、码农、挨踢”于是他笑着拿出了一幅图，当下环境中各人的看法：原图没有，类似的讲师，这面的看法都是片面的，存在问题的。不关注细节，只看产品功能是否实现，那么他就应该理解“冰山原理”，水面上只是冰山的一角。架构师设计的架构往往是跟不上实际市场变化的，架构师更应该懂编码，同时从工程师编码反馈的信息中优化架构，理解编码即设计的想法。而工程师应该审视自己，代码是否合乎规范，是否可扩展，而不是把抱怨留给客户、留给给的时间。讲师接着又问“了解代码么？知道好代码么？”好歹坐着都是专业的工程师，大家异口同声说代码肯定是了解，然后各种好代码，

2、诸如多写注释呀，符合多层结构呀，性能突出呀但大家都说不出一个总结概括性的东西，到底什么才是好代码。“Good code is not bad code.”一片唏嘘。这不是废话么！讲师笑，转头看了看墙上的宣传画说，看，公司宣传画里面的“党员52 个”。“只要做到了这 52 个那就是好代码。”，你就是好党员。只要做到不出现这类坏代码，“Good code is not bad code.”于是，他引出了“代码坏味道”。包括：重复代码、过长方法、条件逻辑过度复杂、分支语句等等 22 项判断原则。（我这里有各种坏代码标准，及处理的方式，需要的）就像感冒的症状是发烧流鼻涕，坏代码的症状就囊括在这 22

3、个基本坏味道里面。那知道了坏代码的表象，方法去识别坏代码呢？通过经验和已知的现象，“搜索”。这在产品开发之初很有必要，通过对自己开发的代码不断的重构，使代码显得简洁、优雅。通过自动化工具：FindBugs、CheckStyle、PMD。人的处理能力是有限的，当检查大量代码时显得力不从心，这些工具就提供了帮助。要树立一种价值观：沟通珍视与他人沟通的重要性；简单把多余的复杂性去掉；灵活保持开放，应对变化。编程是一种态度、编程是一种技艺、编程是一种。等等，前面说了那么“道貌岸然”的说辞，我为什么需要写符合这些规范代码？有需求，我直接改，工作效率快，不用重构，甚至偶尔不测试，但是上去就能用了呀。写好代

4、码也是有的：1.对公司：无论是产品还是项目，后续的和后期的开发，都是要建立期代码的基础上。一个的代码，产生的直接就是费用和开发费用指数级上升，得不偿失。Costtotal = Costdevelop + CostmaainCostmaain=Costunderstand + Costchange + Costtest + CostdeployCostmaain Costdevelop2.对个人：代码就是前人的恶性循环。，写烂代码是要遭的：陷入被后人骂和骂的代码，大家都见过不少吧。3.对客户：客户掏钱想买的产品，到的是延期和无穷尽的烦恼。商业关系。听到这里，我陷入了深深的感。欠着多少债，真是内牛

5、满面啊。于是我问讲师，“您咋不早来讲啊？”。讲师答曰：“只有手染鲜血的人，才能感受到那种放下屠刀的赎罪感。”编码创造出来的，应当是易于理解、可以、高效的产品！这些形容词是按重要性排序的，为了理解和可分高效。，甚至可以牺牲掉部这跟传统的观念很不一致，性能高效才是硬指标。但是讲师用他 10年的经验，各个公司资讯后的结果，以及对不用产品的研究后，用大量的例子告诉品！这个结论，编码创造出来的，应当是易于理解、可以、高效的产价值观，才是行为的主宰。接下来 2 天，讲师着重讲了各种重构代码的策略。我这里简单总结一下：1.为什么要写函数。a)降低复杂度。圈复杂度：从 1 开始，一旦遇到以下关键字，或者同类字

6、，+1（if/while/for/与/或）。不超过 10.代码行数20.为什么这么做？因为正常的人，很难处理好超过59 个以上的智力实体。大家都有翻屏找变量，找方法，看代码的经历吧？修改，痛苦？这都是债啊。，痛苦不职责单一。b)封装变化。c)引入中间的，易懂的抽象。d)避免代码重复。e)简单复杂的判断。f)支持子类化。g)提高可移植性。h)递归。i)协同开发。j)2.函数的三个基本原则。单一抽象层次 SLAPa)这个概念非常重要，举个简单例子：doAThing();/doBThingcode how to do B/End doBThing这个时候，要把 doBThing 的代码封装成子函数。使整个父函数体内抽象层次一致。b)短小，尽量短小。c)单一职责和高内聚。3.数据抽象a)数据封装b)行为封装数据封装好理解，行为封装就不好理解了。提供以下代码，请各位细细品读。几天的培训，主要是从大量的案例告诉，简洁代码的重要性。同时，就像写作文一样，初稿出来后，要不断的修改，打磨，才能写出一篇好作文。好的编码，它所套用的模式，它所适应的规范，都说不是一次写出来的