概述
工作即将满8年，如果算上2年实习的话，满打满算我已经走过将近10年的程序员编码生涯。关于Spring Boot知识点，关于微服务理论，也已经看过好几本书籍，看过十几篇技术Blog，甚至自己也写过相关技术Blog。
无论是Spring Boot，还是微服务，这些我们都可以称之为编程职业硬技能。这些硬技能一般来说都是固定的，有规律可循的。对大多数人而言都是可以快速习得的，至少是掌握其使用方法的。
但是职业不是说仅仅有这些硬技能就可以应付的，我们还需要很多软技能，包括：融入团队、人际交往、压力应对、成果交付、冲突解决、沟通、带领团队、合作互惠等等。
我们需要阅读这本书！
这本书就能给你一些警醒和帮助。阅读过程中，相信你也会会心一笑，又或者苦涩一笑。
很后悔没有早几年读到这本书。当然，这并不是说这是一本度过一遍就可以放下的书籍；事实上，这是一本常读常新的书。
注：下文以引用的方式摘抄原文，附带一些个人体会、私货与碎碎念。
专业主义
什么样的代码是有缺陷的呢？那些你没把握的代码都是！
要用这些自动化单元测试去测多少代码呢？还要说吗？全部！全部都要测！
我是在建议进行百分百测试覆盖吗？不，我不是在建议，我是在要求！你写的每一行代码都要测试。完毕！
说“不”
说“是”
编码
测试驱动开发
TDD，Test Driven Development，测试代码先于业务代码的编码。
TDD三项法则：
1.在编好失败单元测试之前，不要编写任何产品代码。
2.只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况。
3.产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。测试代码的一个问题是必须隔离出待测试的代码。如果一个函数调用了其他函数，单独测试它通常会比较困难。为了编写测试，你必须找出将这个函数和其他函数解耦的办法。换言之，测试先行的需要，会迫使你去考虑什么是好的设计。
事后写的测试只是一种防守。而先行编写的测试则是进攻，事后编写测试的作者已经受制于已有代码，他已经知道问题是如何解决的。与采用测试先行的方式编写的测试代码比起来，后写的测试在深度和捕获错误的灵敏度方面要逊色很多。
练习
只有通过不断的反复练习，才能提高自己的职业技能。作者提到的练习方式包括：学习其他语言，为开源项目做贡献，参加编程柔道场（编程马拉松），
一万小时理论。
展开来说，除了作者说的练习外，我们还可以解决同事疑问，学习GitHub开源代码，参加技术峰会，看技术书籍，浏览stackoverflow网站，回答技术问题，写技术blog，写技术书籍。
验收测试
在工作中，有一种现象叫观察者效应，或者不确定原则。每次你向业务方展示一项功能，他们就获得了比之前更多的信息，这些新信息反过来又会影响他们对整个系统的看法。
首先，即便拥有全面准确的信息，评估也通常会存在巨大的变数。其次，因为不确定原则的存在，不可能通过反复推敲实现早期的精确性。需求是一定会变化的，所以追求那种精确性是徒劳的。
测试策略
QA在团队中要扮演的便是需求规约定义者（specifier）和特性描述者（characterizer）
自动化测试金字塔。
时间管理
回头看我过往8年的职业生涯，参加过无穷无尽的用户需求评审会议，测试用例评审会议，Code Review会议，生产事故复盘会议，
关于会议，有两条真理：
1）会议是必需的；
2）会议浪费大量的时间。如果会议让人厌烦，就离席。
凡是不能在5分钟内解决的争论，都不能靠辩论解决。—— Kent Beck
有人会表现得非常被动。他们同意结束争论，之后却消极对待结果，拒绝为解决问题出一份力。
要小心这类会议：它们的目的是发泄情绪，或者让大家站队。如果会议上只有一面之词，就要避免参加。
死胡同和泥潭
所有软件开发者都要遇到死胡同。比如你做了决定，选择了走不通的技术道路。你对这个决定越是坚持，浪费的时间就越多。如果你认为这关系到自己的专业信誉，就永远也走不出来。
慎重的态度和积累的经验可以帮你避免某些死胡同，但是没法完全避免所有的。所以你真正需要的是，在走入死胡同时可以迅速意识到，并有足够的勇气走回头路。这就是所谓的坑法则（The Rule of Holes）：如果你掉进了坑里，别挖。比死胡同更糟的是泥潭。泥潭会减慢你的速度，但不会让你彻底停下来。泥潭会阻碍你前进，但如果使尽全力，你仍然可以取得进展。之所以说泥潭比死胡同更麻烦，是因为在泥潭中，你仍然可以看到前进的道路，而且看起来总是比走回头路要短（虽然实际不是这样）。
我曾经看到过产品因为陷入泥潭而报废，公司因为陷入泥潭而破产。我也看到过原本小步快跑的团队，在几个月内被泥潭搞到步履蹒跚。除了泥潭，没有其他东西能够对开发团队的效率产生如此深远且长期的负面影响，绝没有。
真正的问题在于，泥潭和死胡同一样是无可避免的。慎重的态度和积累的经验有助于避开泥潭，但无法彻底避开每一处泥潭。
预估
需求估时，项目排期，
PERT，计划评审技术，Program Evaluation and Review Technique。
压力
谈到压力，就不得不提到当下非常流行的一个词：PUA。
在我之前的工作经历中，被人PUA过。
换一份工作，换一个岗位。在我做技术经理时，我可能也在不知不觉中PUA过其他同事，当然在我自己看来，这哪里能算得上PUA呢？
需要谨记的是，随着我们的工作年限的提升，工作能力的提高，自然而然工资也在增长的过程中，要时刻管理好压力。我们可能会作为一个小领导，手下带着几个人。在我们上面，也有话语权更大的领导们。当上面领导在施加压力的时候，压力往下传递的方式和方法是一门很大的学问。
协作
专业程序员的首要职责是满足雇主的需求。这意味着要和你的经理们、业务分析师们、测试工程师们和其他团队成员很好地协作，深刻理解业务目标。这并不是说你必须要成为业务方面的老学究，而是说你需要理解手上正在编写的代码的业务价值是什么，了解雇你的企业将如何从你的工作中获得回报。
专业程序员最糟糕的表现是两耳不闻窗外事，只顾一头将自己埋在技术堆里，甚至连公司业务火烧眉毛行将崩溃了也不闻不问。你的工作职责就是要让业务免于陷入困顿，让公司可以长久发展下去。
团队与项目
组建一个强有力的团队远远比做成一个艰难的项目更有意义。绝大多数人（98%）仅仅只是平庸人。世间少有的是一个旷世奇才，能够仅仅凭借一个人完成一件伟大的产品。哪怕是乔布斯那样的偏执狂般的天才人物，也需要一直队伍协作起来才能创造出iPad、iPhone等划时代的产品。
有凝聚力的团队通常有大约12名成员。最多的可以有20人，最少可以只有3个人，但是12个人是最好的。这个团队应该配有程序员、测试人员和分析师，同时还要有一名项目经理。
关于团队建设的重要性不言而喻，组建一个战斗力超强的团队更并非易事。君不见，多少创业团队失败就是因为团队成员出现各种各样的隔阂、利益出现冲突、想不到一起去等等。
所以，项目应该跟着团队走，而不是团队因为某项目而临时组建。临时组建的团队要经历多久的磨合期，什么时候才能有多少比较高效的产出，这些都是不确定性。而不确定性就意味着失败。
专业的开发组织会把项目分配给已形成凝聚力的团队，而不会围绕着项目来组建团队。一个有凝聚力的团队能够同时承接多个项目，根据成员各自的意愿、技能和能力来分配工作，会顺利完成项目。
辅导、学徒期与技艺
鄙人本科专业是自动化，所谓的又一个【万金油】专业。【隐隐约约】记得，本科即将毕业时有去找过实习找过工作，但是一来自己啥也不会啥也不懂，没有找到满意（高薪）的工作；二来也不想太早面对现实社会（能多逃避几年是几年），所以选择读研。专业是模式识别与智能系统。
嗯，非计算机科班出身。
本科和研究生（实习时）甚至都没有怎么写过Java代码，只写过C、MATLAB、C#、Python、Shell。误打误撞，第一份工作去了一家外企，使用Java语言。工作前两年疯狂恶补Java基础与Spring等框架。这几年一直也在持续看书学习在弥补所谓的非科班出身的基础薄弱。
我想表达的意思是，程序员，尤其、特别、非常值得一提的是Java程序员并不是没有门槛。
虽然在达内（嗯！有没有会心一笑的朋友们？！！）培训机构学习一两个月就可以找到一份Java开发职业！！！
事实上，编码还是有门槛的，哪怕是Java编码。
事实上，还有相当多的人，确实也承认编码是有门槛的，但是测试能有什么门槛呢？不就是点点点吗？不就是发现Bug吗？不就是根据产品出具的需求文档来验收功能发现其中不想符合的地方吗？
所以，我无数次听到或看到：哎呀，行业不景气，经济在下滑，要不要考虑转行做测试呢？
这口气说得好像，测试没有任何转行的门槛一样。
事实上，在我不算长的职业生涯里，看到过好几例表现极其差的测试（QA）同事。表现是逻辑思维混乱，理不清业务模块间的关系，不具备自我学习的能力等等。
画家不会这么做，管道工不会这么做，电工也不会这么做。天哪，我甚至认为快餐厨师也不会这么做！在我看来，这些雇用计算机科班毕业生的公司在新员工培训上的投资，起码应该比麦当劳在服务生身上的投资要多些才对吧。
我们不要自欺欺人地说这无关紧要。这很要紧。我们的文明运行在软件之上。是软件在传送和操纵我们日常生活中无处不在的信息，是软件在控制我们的汽车引擎、变速箱和刹车，是软件在维护我们的银行账户、发送账单和接收付款，是软件在帮我们洗衣服，是软件在告诉我们时间，是软件在电视上显示图片，是软件在发送短消息和拨通电话，是软件在我们疲劳时为我们带来娱乐。软件无处不在。
我不是在反对转行，只是在提醒自己需要持续学习。公司不能（也没有任何规定必须要如此）给你提供培训的资源时，你需要自己主动积极去学习。
工具
git是必备技能，