Manifesto敏捷开发宣言
Offical 官方:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Translation 翻译：
敏捷开发宣言
我们正在探索更好的发展方式通过做它和帮助别人做它。 通过这项工作，我们认识到：
个人和交互胜过过程和工具
工作软件优于综合文档
客户合作胜过合同谈判
响应变化而不是遵循计划
虽然右边有价值，但是左项具有更大的价值。
Wrong Name Comprehend 错误的命名理解
agile 翻译出自牛津英汉汉英词典
① (lithe) 敏捷的 ‹person, animal, movement›; (fit) 灵活的
② attributive(mentally acute) 机敏的 ‹mind,* intellect›
敏捷，拼音是mǐn jié，解释出自百度百科
意思指反应（多指动作或言行）迅速快捷。如：敏捷地跳上敞篷车，敏捷地翻身上马，敏捷地躲过攻击。出自《汉书·酷吏传·严延年》：“延年为人短小精悍，敏捷於事。”
通过上述两个翻译的对比我们不难看出关于敏捷一词，中英的理解其实是完全不同的，在汉语中敏捷一词表达的更重要的意为迅速
然而在英语的语境中，当aglie形容人时，意也指，然而当aglie用来形容思维时，更注重的是机敏灵活。
所以这里更加取决于无论boss也好，leader也好，亦或是程序员也好，大家的共识里面认为软件开发究竟是一个体力活，还是一个头脑风暴，思维实现的过程。在进入公司的第一天，leader便告诉了我一个团队信条，“听懂做到讲明白”，"Jump to white board from keyboard"，只有从根本上认可自己做的工作是思维工作而非重复劳动，才能深刻的理解到"敏捷"一词的意思。
可是如果我们将《敏捷开发》翻译为《机敏开发》/《灵活开发》，可能敏捷开发对于当今的业界影响力，应该会大打折扣。毕竟敏捷开发这4个字就会得到boss或者leader的认可，因为快速高效正是中小型公司或是大型公司需要贯穿整个企业的工作方式。
回归到敏捷开发真正的含义：一种一人为本，团队合作，快速响应变化和可工作的软件作为宗旨的开发方法。
敏捷开发的高效并不在于一味的快速，敏捷开发推崇的是一个正向的循环，通过产品的不断迭代，每一次的code review （代码评审），product review（生产发布评审），Requirements review（需求评审），Standing meeting Daily（每日站会）来实现快速高效，协作同步。团队经历了不断的磨合，自然而然的最后可以回归到boss和leader的需求：快速高效。
所以敏捷开发对于一个研发团队而言，可以拉平大家的信息理解，让大家可以随时确认大家的设计思想是一致的，而不是在中间的理解中出现了理解偏差，使得最后的整个产品根本不满足于市场。相信各位经历过程序返工的同僚，都可以想象真正的低效缓慢正是做的事不被boss/leader认可，不被市场认可，疲于返工，从而团队共识分崩离析，进入一个无限的恶性循环。
Waterfall Development VS Agile Development
在网络上提到瀑布式开发，总会给人一种二极管的感觉，更有一种踩一捧一的感觉，通过踩瀑布式开发来捧敏捷开发。这对于瀑布式开发个人认为是完全不公平的，难道瀑布式开发就真的被敏捷开发给完爆了吗？其实不然
Waterfall Development 瀑布式开发
(图片出自百度图片)
- Requirements/analysis（需求分析/调研）
- Design（设计）
- Coding（编码）
- Testing（测试）
- Maintenance（项目运维）
Agile Development 敏捷开发
图片出自敏捷开发入门教程-阮一峰
- 项目启动（Initial planing）
- 需求分析（requirements analysis）
- 设计（design）
- 编码（coding）
- 测试（testing）
- 部署和评估（deployment / evaluation）
contrast对比
| 瀑布开发 | 敏捷开发 | |
|---|---|---|
| 工作模式 | 以文为本： 1. 文档将贯穿整个项目生命周期，从（需求分析，软件设计，编码设计，测试用例，运维部署）每个阶段都将输出相应的文档 2. 每一个阶段的文档输出后都将作为下一个阶段的输入 3. 以文档为基准，交流的作用不一定有文档可靠 4. 产品上线后即可满足用户90%的需求，之后只需要投入少量的运维成本 | 以人文本 1. 强调了团队的合作，需要团队的共同协作与配合，实时拉平大家的理解，当然并不是说文档不重要，而是团队协作以人为本更加重要 2. 迭代是产品的核心思维，产品的第一次上线可能结果并不乐观，但是需要根据市场的反馈来进行迭代，与各个团队的员工拉平市场的需求，进行产品的迭代 3. 不断的迭代迭代，最终将产品进入一个正向循环的模式 |
| 项目周期 | 第一次发布通常会花上半年及以上的时间，产品上线后投入少量人手运维即可 | 通常第一次发布会在两个月内，之后不断的迭代，实现符合市场的产品 |
| 优点 | 1. 目标明确，各个阶段大家只需要完成自己的工作，最后输出相应的文档即可 2. 产品上线后，即可撤出大量人手投入新的项目开发中，只需要少量人员运维即可 3. 在团队中调配相应资源时非常的明确，因为各个阶段的目标是明确的 | 1. 在经过了不断的迭代之后，输出的产品一定是符合市场需求的 2. 灵活性高，如果出现了巨大的市场变革，亦或是紧急的需求，只需要加入新一轮迭代即可 3. 以人为本，调动整个项目各方（包括市场）的参与，理想形态下，开发模式将不再是分配制，而是各个成员主动承担工作 |
| 缺点 | 1.风险高，各个阶段如果有一个地方出错，那么将作为输入传入下一阶段，最终做出的产品或许完全无法满足市场的需求，需要回炉重做 2.如果出现市场变革基本等于项目死亡，紧急的需求的插入也将影响整个软件的开发，甚至可能需要从头设计 3.会出现人员空滞的情况，因为各个阶段都需要等待上一阶段的输出结果后才会展开工作 | 以人为本，就是敏捷开发最大的风险。你是否可以相信团队中的每一个人，大家是否拥有着敏捷开发的五个价值观（出自敏捷开发Scrum）： - 承诺 – 愿意对目标做出承诺 - 专注– 把你的心思和能力都用到你承诺的工作上去 - 开放– 项目中的一切开放给每个成员看，大家共同分享 - 尊重– 尊重团队中的每个人，就事论事而不是有色眼镜看人 - 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重 是否可以对每一个团队成员说出 “你永远可以相信我” |
| 适用项目 | 需求明确，在开发周期中（一年内）定不会出现巨大市场变革 | 互联网项目，敏捷开发可以响应互联网快速的发展变更 需要急速上线，抢占市场的项目 |
通过上述的对比我们可以看出，并不是任何产品都适合敏捷开发，敏捷开发并不是一个万灵药，如果在不适当的项目跟中强行使用敏捷开发，反而会让它变成愚笨开发，因为我们会将明确的需求反复沟通，反而降低了研发效率。更重要的是，你团队中的成员是否适合敏捷开发，以人文本即为敏捷开发的核心思想。
培养敏捷精神
敏捷开发的核心是以人为本，关于敏捷开发的流程，具体实现，在网络上已经有很多了，大家随时都可以看到网络上给出的示例，以及请专业的敏捷团队来公司进行培训。本篇文章的主要主题是如何培养敏捷的精神 ，接下来将会根据我从书籍文档中，工作经验中学到的敏捷精神，希望阅读了的你，不会感觉文章是一篇口水话鸡汤，而是能让你感同身受的文章。
1. Blame can't help 指责没有帮助任何事
指责并不会修复bug更不会帮助任何事。遇到问题我们的反应如果都是去思考解决问题的方案，而不是解决导致问题的人，才是一个正向的循环。
勇敢的承认自己不知道的答案，与团队的各个成员讨论。如果出现了一个重大的错误，应该被当做是一个学习的机会而不是落井下石的机会，团队中应该互相帮助，而不是落井下石。特别是如果有一个东西，大部分人都知道是坑，此时去诱导一个并不清楚的人跳下去，就算自己逃过了一劫，那么在这样的团队中，怎能知道下一个坑自己是否能够躲过呢？如果次次都躲过，你并不会成为受人尊敬的人，而是行业老油条，是受人背地里唾弃的人，别人又将如何尊重你？
你可能会说，如果真的有团队成员一而再，再而三的对团队造成了负面的影响，那么此时他应该离开团队，但我们并不该周而复始的指责他。
2. Don't blindly seek of speed 不要盲目追求速度
在各个公司，亦或是各个团队中，都会有一套编码规范，如果盲目的追求速度，我们就会在我们的代码中增加许多的魔法值，漏掉注释。最后这段代码将会晦涩难懂，甚至作者本身都不一定能看懂如何实现。
追寻代码规范，不盲目追求速度，对自己新增的变量/对象命名负责，对自己的代码块注释负责，才是一个研发最基本的素养，而不是将代码工作想象为一场赛马比赛。如果遇到自己不确定的问题，特别是性能/设计上的问题，一定要向同事请教。
我上周便向我的leader请教了
假如同一个业务涉及到三张关联表。 做某个接口服务时，是三表联查，直接得出结果，还是三个表分别查做隔离，组合成最后结果。
leader和研发同事们都给出了自己的理解与解决方案，令我受益匪浅，或许在这类性能问题发生之前，我都不会再去因为这个问题而痛苦，当问题发生时，我相信我的团队会和我一起著力于解问题，得到更加适合的解决方案
以下是我综合同事和leader给出的解决方案得到的答案：
- 根据阿里巴巴规范：首先超过三张表关联强制禁止join
- 如果单表查询能够使用缓存或者复用，建议使用单表
- 虽然多表关联能够省去很多业务代码，但是绝大多数情况并不能带来性能上的很大提升，数据库关联查询也会增加SQL的复杂度
- 单表查询还便于以后扩展分库分表，SQL层优化空间大，业务层对于大数据量可使用一定算法解决性能问题
- 在C端项目中，我们要完全避免联合查询，在B端项目中，我们可以尽可能避免联合查询，在G端项目中，我们完全无法避免联合查询
3. Focus on issue，not person对事不对人
人人都懂的道理，人人都喝过的鸡汤，却很难做到的事。做不到对事不对人，只会给整个团队带来一种消极，人人自危，人人想落井下石的氛围。
Negativity kills Innovation （消极扼杀创新）：
我们每个人都可以想到一些极好的创新想法，同样也有可能萌生一些特别憨憨的想法。如果提出自己的观点前，担心自己被嘲笑，甚至被批评，你将会扼杀掉自己的创意。任何一个出色的产品都需要大量的创新力和市场洞察力，分享各自的观点，融合彼此的优良创新设计，才可以做出一款好的产品。
“你不需要很出色才能起步，但你必须起步才能变得出色”——莱斯布朗
“能欣赏自己并不接受的想法，表明你的头脑足够有学识”——亚里士多德
以下的话说给作者自己听：
如果你连起步的勇气都没有，请问出色和你这辈子能有什么关系呢？
在抒发每个人的idea的过程中，我们一定会遇到无休止的讨论，甚至最后从头脑风暴变成了扯淡大会也不是没有可能，如何避免这类情况的发生呢？
- 设定最终期限：在最终期限时，如果没能确定到最好的方案，我们需要的是寻找最适合的方案，而不是无休止的讨论，需要落地思维碰撞
- 逆向思维：寻找方案/idea的缺点，如果最终有一个方案的缺点都是大家可以接受的，那么这个方案是不是就是最好的方案呢？
- 仲裁人：仲裁人需要做到绝对公正，如果有人从头脑风暴变成了扯淡大会，那么需要仲裁人出来制止，维持会议正常进行
- 支持决定：落地的方案需要执行下去，除非能够证明方案是错的，否则请尊重大家制定的方案
4. Brave 勇气
人类的赞歌就是勇气的赞歌 出自《JOJO的奇妙冒险》
勇气，勇敢这是一个大家都从小听到大的概念，但是想要拥有勇气，拥有勇敢，真的是相当困难的事，做一个有勇气的人，这句话真的是能让人耳朵都听出茧来，又更何况在一家企业中这么做呢？
勇气会让人感觉有点不自在，鼓足勇气需要魄力。有些时候，它是扫除障碍的唯一途径，否则问题将进一步恶化下去，最终会变成，明明知道了错误，却不断的将错就错。鼓起你的勇气，这能让你从恐惧中解脱出来。当然这是在你已经知道了正确答案的情况下，如果你此时的工作正是一个前无古人后无来者的工作，你作为这艘船上的船员，自己都不知道下一个领域会是哪里的时候，此时你的勇气究竟是破釜沉舟的航行下去，还是下船，这是一个哲学问题？如果你正在做一件没人知道答案的事，很羡慕你，我也想如同你一样。
5.Tracking changes 跟踪变化
互联网的进步实在是太快了，个人感触最深的例子就是jQuery与三大前端框架，这里甚至给了我一种断层式进步的感觉。再说到java，如果关注java的新特性，我们会发现从java8的Lambda到jdk14中间出现的各类语法糖，都会发现java正在不断的向函数式编程靠拢，js中也引入了很多面向对象的概念，每一门语言都在不断的去完善自身的特性，如果我们闭门造车，无法追随行业的变化，和在监狱中的囚犯又有什么区别呢？在电影《肖申克的救赎》中，当囚犯回归到城市时因为完全无法适应现代的变化，而在旅店选择了自杀，而主角因为不断的写信，阅读，始终与时代接轨，最终完成了自己的救赎。
监狱的可怕并不在于关押了人很多年，更可怕的事情是，也许你自己成为了自己心灵的囚徒，是自己内心的监狱禁锢了你自己。
想起来前段时间在网络中看到的一段很有意思的话
任何在我出生时已经有的科技都是稀松平常的世界本来秩序的一部分。
任何在我15-35岁之间诞生的科技都是将会改变世界的革命性产物。
任何在我35岁之后诞生的科技都是违反自然规律要遭天谴的。
——英国科幻作家道格拉斯·亚当斯
任何比我早出生10年及以上的人都是裹步不前的老顽固。
任何出生时间和我相差10年以内的人都是这个社会的精英，中流砥柱。
任何比我晚出生10年及以上的人都是无可救药垮掉的一代。
——纳什·沃夏尔·硕德
囚徒究竟是被监狱囚禁了？还是自己囚禁了自己？
如何做到跟踪变化呢？
- 迭代和增量式学习：
知识投资也是一样。你需要定期投资最低限度的时间量。养成一种习惯，如果需要的话。躲到你的家庭办公室里去或者走进有无线网络的咖啡厅。并非每期学习都同样富有成效，但是只要定期安排学习，长期来看一定会成功。如果你一直在等待空闲时间或者等待灵感的突现，那么它永远都不会发生。
安排自己定期的学习时间，听到不熟悉的术语/新鲜事物时，记录下它，计划时间深入研究它
-
逛逛论坛，知乎，掘金社区，简书，github：社区永远是最潮流的地方，书籍的潮流程度将会低于社区，但是书籍的严谨程度高于社区
-
如饥似渴的阅读：reading，reading，reading！
我扑在书本上，就像饥饿的人扑在面包上！——高尔基
- 跟踪技术变化：不需要精通每一门技术，但是我们需要了解行业动态，规划自己的职业生涯
个人脑洞：如果有一天出现了一门完全取代了java的语言，我会怎么做？我能否提前发现技术更迭的征兆，成为技术革命的受益者呢？
6. Investment your team 对你的团队投资
总是要成为你所在的那个乐队中最差的乐手。如果你是乐队中最好的乐手，就需要重新选择乐队了 ——爵士吉他手Pat Methany
追赶团队，和团队中的各个成员形成正向的互补，有勇气抱有开放的心态与团队中的成员分享，尊重团队中的成员给出的意见，承担团队的任务。构建属于团队的学习平台。如果你认为分享知识你就亏大了，除非你是一个国家级的科研工作者，需要签订严格的保密协议，否则我们需要思考自己是不是井底之蛙呢？当你视若瑰宝的东西有一天被人发现所有人都知道了，甚至有更好的方案时，你那是的脸会不会像被人用皮鞋踢过一样，开始无能狂怒呢？最后愤然感慨“任何在我35岁之后诞生的科技都是违反自然规律要遭天谴的。”任何比我晚出生10年及以上的人都是无可救药垮掉的一代。
7.Reduce 减法
沉舟侧畔千帆过，病树前头万木春
当我们在工作的过程中以及意识到某些事物制约了你的设计，并且你能够发现社区已经存在可以解决此类问题的技术，我们应该果断作出减法，在充分调研后，拥抱新技术，你宝贵的工作经验不应该受制于代码，或者说受制于自己的怠惰，跟上浪潮才能成为“千帆”与“万木”
8.Get to the Root of Things 刨根问底
亚马逊内部面对 S1 和 S2 的故障复盘，需要那个团队的经理写一个叫 COE（Correction of Errors）的文档。
这个 COE 文档，基本上包括以下几方面的内容。
- 故障处理的整个过程：就像一个 log 一样，需要详细地记录几点几分干了什么事，把故障从发生到解决的所有细节过程都记录下来。-
- 故障原因分析：需要说明故障的原因和分析报告。
- Ask 5 Whys：需要反思并反问至少 5 个为什么，并为这些“为什么”找到答案
- 故障后续整改计划：需要针对上述的“Ask 5 Whys”说明后续如何举一反三地从根本上解决所有的问题。
除了在面对事故时我们需要有刨根问底的态度，在我们的工作讨论中，我们也应该大胆的去问为什么。就像医生一样，医生总会问清楚我们，去了什么地方，吃了什么东西，有什么症状，然后经过化验后才会对我们的病症下判断。如果我们带着疑惑去工作，那么只会将这个问题如同地雷一般埋在项目里，直到其爆发的一天。
当我们在问为什么的时候，请注意，不要跑题，你需要保证的事情是你问的为什么是有意义的，因为在你问别人why的时候，别人也会来问你，为什么你要问这个问题，所以请问自己的发言和疑问负责。
9.Keep Control Develop Rthyme 掌握节奏（If U Can)
- 如果今天进行了编码工作，别忘了下班前，测试你的代码，并提交至Version Control Tool中
- 能不加班尽量不要加班，没有必要把自己搞的精疲力竭。从长远的角度来看，无论是身心健康还是职业规划这都是不利的，很多人认为加班可以提高工作进度，其实不然，加班的时候请尽量保证你的工作只是简单的体力劳动，复制代码。而不是一些真正需要深思熟虑才能做决定的工作。
- 如果项目成功，别忘了参加/组织一次团队聚会，与大家一起品味胜利的果实
10. Let customers make decisions 让客户做决定
不要将客户孤立，要把客户拉近到项目中，让客户做决定，保证做出来的产品是客户想要的。研发与产品经理不应该做业务方面的决定，一定要产品负责人在于客户充分沟通后再做决定。如果产品负责人对你的问题回答是“不知道”，这其实是一个很好的答案。因为他们的设想可能并没有你站在技术角度上看的长远，尽可能的提出有用的建议，在产品作出后，或许他们会给出一个好的答案
11.Design guidance development 设计指导开发
设计的作用应该是指导开发，而不是操作开发。这里的设计需要分为两种设计
- 产品设计：
如果一个产品设计师把设计文档设计的极致的详细，就一定会干涉到技术的实现，例如分库分表，数据库字段，微服务拆分等等，那么这时候研发人员如果明知道这样的设计并不合理，还完全按照设计文档进行开发，结果会是怎样的呢？想必大家已经可以猜测到了
- 研发设计:
画好关键业务时序图，UML图。不要上来就开始编码，需要把当前业务的核心流程图画出来，才能考虑清楚是否业务流程有问题。
如果你自己都不清楚所谈论的东西，就根本不可能精确地描述它。
——约翰 冯 诺依曼
计划是没有价值的，但计划的过程是必不可少的。
——埃森伟豪尔
好的设计是一张地图，他最开始可能只绘画了一个雏形，一个指南针。这张地图只需要保证我们做的事是正确的即可，而不需要精确。
12.Not bound by technology 不要被技术束缚
在采用新的技术前，一定要做好充分的调研，并且去查找社区里是否有和它功能形态类似的框架，比较优缺点，最后在做决定使用哪个框架，而不是看到了一篇公众号，论坛帖子，就一股脑的无理由使用这个技术。技术是服务于最终的产品的，如果研发人员都被技术束缚，那么最后这个产品真的是满足市场需求产品吗？
每一门技术都会有优点和缺点，无论它是开源还是商业产品，框架，工具或语言，一定要了解它的利弊
13. Show to Customers&Get feedback 向用户演示&得到反馈
在开发时，保持应用可见，每次迭代过后都需要向客户演示新的功能，得到用户的反馈。保证自己做的东西是客户想要的。
- 不用向所有的最终用户，可以灰度发布
- 尊重客户，客户如果决定一个月进行一次演示，那么就一个月，但一定要保证有一个合理的周期进行演示和收集反馈
- 保证功能是完整的，如果功能是个半成品，请不要演示，那只会让客户生气。可以大概描述功能，与用户沟通。
14.Unit Testing 单元测试
很多开发者都会有一种盲目的自信，我的代码没有问题，包括我自己也是一样，但是其实归根结底，还是自己太懒了，我们应该依赖单元测试，尊重单元测试。单元测试是优质股，值得投资。单元测试需要达到规定好的代码覆盖率才有用，请保证单元测试的代码覆盖率。需要有效的测试，而不是尽可能多的测试。
15.Different Environment Different Problem 不同的环境不同的问题
这个在我的机器上是好的呀
这句话想必是每一个开发人员最常说或者听到的话语吧，我们需要注意的是不同的环境会有不同的问题。
如果在以前我们需要针对每一个环境进行处理，以确保系统可以在各个环境中正常运行，现在我们可以使用容器技术，来解决这个问题。
16.Measuring real workload 度量真实的工作量
用百分比来度量工作量其实是没有意义的，当然有时候老板或者上司就是希望得到一个百分比的数字，然而这种数字他本身并不具备任何意义，因为剩下的20%工作量如果有一个难点或者疑惑点，那么这20%的工作量并不会在他们期望的时间内完成。
在公司的项目管理软件上面，写清楚ToDoList，写清楚每个人正在实现的每一个功能点，而不是每个人实现了百分之多少，通过功能点的实现，其实更会让人安心，也让评估的工作量与实际的工作量更加接近。
17.For Customer 倾听用户
每一个抱怨的背后都隐藏了一个事实，找出真想，修复bug
倾听用户的声音，用户的抱怨并不一定是无意义的，也许这个抱怨背后隐藏了一个bug，一个不合理的业务流程。你做出来的产品的目标是为用户使用的，而不是一个不可亵渎的艺术品。保证用户在你的产品上有着轻松便捷且能完成业务目标的体验是最重要的。比如抖音，抖音这款APP的用户体验是极好的，起码是满足绝大部分人的，它最大的缺点，在我使用下来，就是没有缺点，强大的推荐算法总是能在你乏味的时候，给你一个有趣的新视屏，让你的时间在不知不觉中消耗。当然有的用户的抱怨或许不用理睬，毕竟我们也接到过，账号名密码输入错误，然而用户坚持认为这是bug的投诉。
18.Respect and implement code specifications 尊重并执行代码规范
请尊重并且执行你们公司的代码规范，对自己的变量负责，对每一个方法名负责，不要用难懂的注释来包裹代码，然后自信的告诉别人，我注释写了呀。遇到难懂的代码要找你的同事code review，问下他们能不能看懂，如果他们都明确告诉你不能看懂，也许不是你写的代码有多么牛B，而是你将很多功能耦合在一起了，你的变量命名不好，让他们需要去猜测这个变量是什么意思等等。
使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。
解释代码做了什么的注释用处不大。注释要说明的是为什么会这样写代码，你的意图和约束。
请尊重并开心的执行代码规范，从长远来看，那对任何人都是有益的。
19.Trade off 取舍
学会取舍，充分考虑性能，便利性，生产力，成本和上市时间。如果性能表现足够了，就将注意力放在其他因素上，不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化
过早的优化是万恶之源
过去用过的解决方案对当前的问题可能使用，也可能不使用。不要事先预设结论，先看看现在是什么情况。
20.Simple is not simplistic 简单不是简陋
最典型的例子就在于苹果的设计思路上了，简单并不是简陋，在我们代码中也是一样，不要刻意的追求设计模式，或者高难度的技术，优雅的代码是任何人第一眼看上去，就能知道它的作用是怎样的，并且很简洁。
简单、可读性高的代码才是我们需要追求的目标
一个人认为简单的东西，可能对另一个人就意味着复杂，这里需要平衡
21.Cohesive code 内聚的代码
内举行用来评估一个组件（包、模块和配件）中成员的功能相关性。内聚程度高，表明各个成员共同完成了一个功能特性或者一组功能特性。内聚程度低，表明各个成员（方法，属性）提供的功能是互不相干的。
让类的功能尽量集中，让组件尽量小。
具有良好内聚性的代码，可能会根据需求的变化，而成比例地进行变更。而不是牵一发而动全身的修改。
22.Record the required logs 记录需要的日志
记录需要的日志，记录需要的日志，记录需要的日志。
记录日志是为了你能及时排查问题，而不是因为要记录日志而记录日志
23.Execute Exception 处理异常
处理每一个异常，不要将异常吃掉，而是要去处理异常。处理或是向上传播所有的异常。不要将它置之不理，就算是临时也不行，因为异常现在发生了，那么它之后也会有发生的可能。处理异常是为了生产环境做保障
24.Provide useful error information 提供有用的错误信息
我们害怕用户看到异常信息，所以我们将每一个异常都包装成了“请稍等，服务器错误，请稍后重试”。这样的处理并没有意义，我们遇到了问题需要及时的排查，我们需要对特定的错误进行code码的编译，为每一个第三方的调用进行分类，在将自身服务器作为一个分类，在报错时，我们需要报出的 设备接入[001] 设备未找到 我们不应该把报错信息原封不动的打印出来展示给用户，而是自己封装后的有意义的报错信息展示出来，这样的好处在于，用户向你反馈有错误的时候，你只需要拿到分类和错误码，就可以快速的排查问题了。
25.Enjoy Code享受编码
希望你是因为热爱编码而加入程序员的行业，就算你成为了架构师，也希望你能亲自编码。架构师也无法在PPT中进行编程。特别是当要使用新技术，新框架的时候，也需要你来亲自加入。只有自己的体会才是真实的，也希望你能享受编码的过程。在Github上有很多的项目开源，很多人每天提出了很多的pull request 。这些开源项目开发者们将不再有时间自己编码，而是要去处理无数的pull request。也是因此有很多开源项目的编码者们逐渐退出了开源项目，因为不能再去享受编码的过程了。
26.Share&Teach 分享&指导
好的想法不会因为被许多人了解而削弱。当我听到你的主意是，我得到了知识，你的主意也还是很棒。同样的道理，如果你用你的蜡烛点燃了我的，我在得到光明的同时，也没有让你的周围变暗。好主意就像火，可以引领这个世界，同时不削弱自己。
成为指导者意味着要分享——而不是固守——自己的知识、经验和体会。意味着要对别人的所学和工作感兴趣，同时愿意为团队增加价值。
给别人解决问题的机会。指给他们正确的方向，而不是直接提供解决方案。每个人都能各抒己见，头脑风暴。如果真有人陷入了胶着的状态，我想你应该给予他们答案了，至少他们认真思考过了。
参考文档
《高效程序员的45个习惯——敏捷开发修炼之道》
