ARTS Review9 代码整洁之道程序员的职业素养上

终于把《代码整洁之道之程序员的职业素养》这本书读完了，写一下自己的读后感觉，顺便总结一下书中的内容，就当做ARTS活动的Review了。

先说一下我读完这本书的感觉：

这是一本非技术的书籍，旨在教导你如何作为一个专业的程序员，当然不是给你说学习某技术的路线之类，而是从你作为程序员开始，你应该怎么做好程序员的本职工作，以及在工作后你会遇到什么样子的问题，应该采取什么样的措施来解决这些问题，当然这些问题也不是纯技术问题，而是一种关系的处理，工作与生活的处理，上下级的处理，个人的处理之间的指点，通读这本书，让我在读书的时候想到了自己开发过程中遇到的事情，只想说，如果我早点读了这本书，那么是不是会少走一些弯路，将前人的经验和总结应用在实际中，帮助自己快速成长呢？

下面是我关于这本书中的一些总结：

一、专业性

1. 学会担当责任，如果是自己的问题，那么就要及时采取措施来解决补救
2. 不要破坏原有软件的功能
   即你在做需求迭代或者修改BUG的时候，确保你的改动不会引起系统出现其他bug，确保你的修改经过测试让QA找不到问题，这样才算完美
3. 不要破坏结构
   也就说在发布新功能的时候不要破坏原有系统的功能，结构良好的代码更灵活，更加易于维护
4. 了解你所做的领域
   从我的角度看来一切的技术都是为了解决业务需求而出现的，所以你需要了解你的业务领域和技术领域，最好可以知道这款产品设计的目的是什么，要解决什么问题以及如何解决才比较好，如果你拥有了这样的思路和意识，对于你开发产品所提的需求，那么你就会更快的上手，更容易理解需求。
5. 了解技术领域
   对于技术而言，网上有什么资料，你可以去学习，英文好点的可以直接从官网进行阅读，对于专业技术的你，你必须掌握设计模式，设计原则、方法和实践以及工具等
6. 坚持学习
   不管你做什么技术，你都应该坚持学习，技术更新快，所以只有你坚持学习，这样你的知识库才可以得到很快的更新，否则你将处于队伍的末尾，如果你订阅了耗子叔的极客时间专栏，我想你的收获应该会很大。
7. 练习
   不能只是单单的学习纯理论知识，你也需要将理论应用于实际，用理论来解决问题，这样才可以对理论掌握的更扎实，否则就是纸上谈兵。
8. 合作
   一个人学习可能会很无聊，坚持不久可能就会放弃，所以最好的方式是结对编程或者找别人一起学习，相互打卡，分享自己的学习的新知识及问题所在。
   在这里我有一点，觉得腾讯做的很好，其他公司我不是很了解，我一个朋友去年入职腾讯外包，他们每周都会抽一段时间让其中一个人做分享，这样的话既锻炼了程序员的口才和表达交流能力，也督促大家都要学习，分享者不单单是分享了知识，在分享的过程中自己也对知识得到了更好的掌握，其他人也可以对别人的分享进行吸收，这是一个很好的做法。可惜，我们一直没有，一直在写业务代码，业务是写不完的。
9. 辅导
   当你是新人的时候，可能会有人辅导你，你要珍惜这种机会，看你的师父和同事们是如何开发，如何写代码的，如何去分析这个需求来实现它，遇到问题的时候他们是如何来定位问题，解决问题的，当然我也从我师父的身上学到了这些。所以如果有人辅导你，那么请用心，别让辅导你的人觉得你烦，而让他觉得你进步快，懂得他所教你的方法，可以自己实际应用。
10. 谦逊
    无论何时，人和人之间都要保持谦逊，尤其是开发与产品，开发和测试之间，如果相互不能得到很好的沟通，那么大家都会互相甩锅，最后就是很惨的结果。
    二、学会说“不”
    如果一个人在开发过程中，从来不说“不”字，那么我觉得他一定会很累很累，生无可恋。只有敢说“不”的人，才会真正做成一些事情。
11. 当你和项目经理共同追求一个目标的时候，这个时候就有赖于协商，并不是项目经理怎么安排你就怎么来。
    有时候项目经理高估你的能力或者让你在短时间内完成，此时你就要学会和项目经理协商，学会说“不”，这也不是说完全拒绝，如果觉得自己需要长一点的时间完成，可以和其协商，如果实在是要求短期完成保质保量，那么可以要求项目经理换老手，因为这样才可以不耽误项目的进度，不影响给客户演示。
12. 最要说“不”的是那些高风险的关键时刻，越是关键的时刻，“不”字就越具有价值。
13. 试试看。
    试试看，表示你可以尝试，承认你之前没有用尽全力，还有余力可施，换句话说，你可以在加把经或者加加班就可以达成目标。
14. 不要进行消极对抗
    就算你在开发中遇到了问题，解决不了，研究了1-2个小时还是毫无思路，那么你就应该上上面反馈，请教同事或者你的上级，求助，及时解决问题，不要一直拖着。。。。最后不可以达标，锅只能你来背。
    三、说“是”
15. 承诺用语，做出承诺，包含三个步骤：
    （1）口头上说自己将会去做
    （2）心里认真对待做出的承诺
    （3）真正付诸行动
16. 识别“缺乏承诺”的征兆：
    （1）需要/应该
    （2）希望/但愿
    （3）让我们。。。。
17. 之所以没成功，是因为我寄希望于某某去做某件事
18. 之所以没成功，是因为我不太确信是否真能完成得了
19. 之所以没成功，是因为有些时候我真的无能为力。
    在这里，如果你不尽早的告诉他人可能的问题，就错失了让他们帮助你达成目标，兑现承诺的机会。
20. 专业人士不需要对所有请求都回答“是”，不过，他们应该努力寻找创新的方法，尽可能做到有求必应。
21. 当专业人士给出肯定回答时，他们会使用正式的承诺，以确保各方面能明白无误的理解承诺的内容。
    四、编码
22. 你所编写的代码一定要能通过测试case，能保证线上正常运行。
23. 代码必须能帮你解决客户提出的问题
24. 代码必须要能和现有的系统结合的天衣无缝
25. 其他程序员必须能读懂你的代码
26. 如果感到疲劳或者心烦意乱，千万不要编码
27. 焦虑情况下，写的代码质量也不会很高，所以应该抽出来一块时间去集中处理让你焦虑的事情
28. 结对编程最大的一个好处就是结对中的任何一方都不可能进入流态区。
29. 音乐可能有助于你提高代码编写能力，也可能会导致你编码水平下降
30. 结对是用以应对中断的一种好办法，也可以采用测试驱动开发TDD的方法
31. 调试时间和编码时间一样昂贵。
32. 衡量你是否是一名专业人士的一个重要方面，便是看你是否能将调试时间尽量降到最低。绝对的零调试时间是一个理想化目标，无法达到，但是要将之作为努力的方向。
33. 保持节奏，知道什么时候可以离开一会或者暂时性从问题中跑出来，清晰一下后，再去考虑问题
34. 进度延迟，管理延迟的诀窍是早期检测和保持透明。根据目标定期衡量进度，使用三个考虑到多种因素的期限：乐观预估、标称预估、悲观预估
35. 避免盲目加班，有时候加班是有用有必要的。
36. 定义“完成”，对于程序员来说，完成是指开发编码完成还是指自己编码通过自己测试后才算完成，所以这个也是一个完成的概念的区分点，一般某个模块功能分给你，那么你应该是在梳理需求，然后编码、测试完成后，才可以说完成，而不是编码结束未测试就说完成。
37. 要开发过程中，要懂得互相帮助，帮助他人的同时，也需要懂得如何求助他人，需要找合适的机会去求助，最好不要当一个人正有思路的时候，你去求助打断别人的思路。
    五、测试驱动开发

测试驱动开发，这个概念来源于极限编程中。所以什么是测试驱动开发？
简单的理解，就是因为测试不能通过而去开发，换句话说先有测试代码，再有开发代码，我们的开发代码，主要是用来解决测试不通过的代码所出现的问题。

1. TDD可以缩短编码周期。
2. TDD的三项法则：
   （1）在编译好失败单元测试之前，不要编写任何产品代码
   （2）只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况
   （3）产品代码恰好能够让当前失败的单元测试成功通过即可。不要多写代码。
3. TDD的优势
   （1）具有确定性
   （2）缺陷注入率
   （3）TDD是一套值得信赖的测试，便可完全打消对修改代码的全部恐惧。整洁的代码更易于理解，更易于修改和扩展。
4. 遵循TDD三项原则的话，所编写的每个单元测试都是一个示例，用代码描述系统的用法。
5. 测试代码的一个问题是必须隔离出待测试的代码
6. TDD也具有其局限性，如果编写的测试代码很糟糕。
   六、练习
   关于练习这一块，你需要在掌握理论的前提下，去实践，比如写小的DEMO等，或者通过算法来练习应用基础功，通过功能开发来练习等，只要你在实际中得到了熟练的应用，那么你才算掌握了这个技术，但是如果要掌握的更好，你还需要去了解它的实现原理，为什么它会这么设计，这么设计有什么好处等等。通过原理，来学习大师们的设计思路和实现思路以及技术技巧。