首先很感谢团队督促的日志习惯，正是由于这几个月来每天的点滴的日志，让我现在可以回想到很多事情，让自己有机会可以总结并改进自己。
路修远以多艰兮，快速建立客户信任
项目第一天，战战兢兢，思来想去，觉得怎样得到客户信任应该是第一件大事，后来我通过以下两种方式来解决了信任问题的。
寻找客户痛点，用自己的长处去弥补
客户最大的痛点技能水平偏低，如何短期快速提升技能是他们想要的，根据我司OOBootCamp带来的灵感，设计了RefactorBootCamp通过workshop的形式以不同场景不同的题目(坏味道)组合练习使用重构手法。后来事实证明在项目当中客户也学到了很多在workshop中学到的重构手法。
快要下项目的时候，我把课程的例子录制了视频让客户日后参考，后来我写成了文章，也让自己的知识更加系统化，以下我写的一些，还在继续..
- 这件事在客户那里树立很高的威信，客户看到了想要的,我也从准备例子的过程中通过刻意练习，对重构的理解也升华了
- 金子要自己找到发光的方向，如果想要短时间内得到认可就要最大限度发挥自己的价值，不要憋着，找到别人关心的点，付出一定是要有的
如果谁有兴趣在项目上也想尝试这种方式，来提升技术能力，欢迎一起来搞事情，一起完善。
了解客户沟通模式
客户大部分都是技术人员，所以怎样找到双方最佳的沟通模式,塑造自己的影响力是很重要的,我通过像其它提前在项目上的咨询师请教，自己再去摸索比如非暴力沟通所说的全身心去聆听，区分观察和评论的说话语气，通过的实践去探索和客户最佳的沟通方式。
举个栗子:
1.在刚和客户Pair的过程中，有个功能叫XXGroup，在我说的时候我按照我认为的方式告诉他怎样写测试，调整代码结构，客户很困惑我为什么要这么做，而我太以结果导向，忽略了过程这个事，后来我改进自己的方式，在说之前，先和他画图讨论，然后给他讲清楚原理，最后在做的过程中等他先按照按自己方式做完，我再告诉他哪里可以改进的点，示范给他看。
- 要以客户思考的方式多沟通，授人以渔胜过授人以鱼,在coach别人的时候自己也会有新的灵感和感悟冒出来，如果一意孤行，自己也没有收获。
路漫漫其修远兮，探索客户现场最佳实践
在建立了信任之后，推行一些技术实践也变的轻松很多，先后和客户不同成员Pair，通过以下几种方式来探索客户现场最佳实践。
解决客户棘手问题，实施测试
通过解决棘手问题，以此为基础推行测试驱动开发，消除技术债务，以及自动化测试的重要性。
举个栗子:客户这边一个很小的邮箱相关项目，项目成立也没有太久，但是已然有了遗留系统的样子，项目没有自动化测试，技术债也没时间还，统计之后我发现，开发新功能是在原有代码上堆加新的逻辑，通过手动来测试（要命的是手动测试要准备的环境需要很大的effort），甚至会连接生产环境做手动测试，最后上线，紧接着就是噩梦的到来，接下来会用一周甚至更长的时间追踪生产Defect，恶性循环。
发现问题后想到的第一个点是先把手动测试的effort省出来，通过引入GreenEmail先把真实邮箱隔离掉，通过测试复现生产棘手问题，再根据具体的业务场景把自动化测试补上，重构代码，改进架构设计，过程中不仅把问题解决了，还使得项目在一点点变好，开发人员也深深体会到了好处，开始主动写测试了，并且有了更多的时间来关注项目，而不是生产Defect。
- 技术债务真的很重要，开发人员忽视技术债务并不是不懂技术，而是不敬畏时间的代价
- 技术基础设施很重要，因为用机器代替了频繁重复的体力劳动，开发人员应该让自己focus在那些富有创造力的事情上。
根据模块具体症状实施不同测试策略
理想情况下单元测试一定是优先考虑的，但是对于业务逻辑分散在各个层级的代码，就要权衡了，建总说过一句话感受颇深，软件实际上是一门经济学，你要考虑你付出的成本和得到的收益是否成正比。所以针对客户的代码，并没有一味的推行范围很小的单元测试，而是根据模块具体情况应用不同的测试策略
举个栗子:
1.对于代码业务逻辑不多，Sql语句很复杂的模块，直接用集成测试覆盖，因为如果引用内存数据库有两点需要考虑
- 语法可能不一致（因为用了大量的数据特性函数）。
- 更换内存数据库对于现有架构effort比较大，收益并不高。
2.对于代码逻辑很多，相对集中的模块，通过简单的手术。
(提取接口,mock技术)，用组件级别的单元测试覆盖，因为effort相对很小，但是收益很高，因为后续重构调整代码结构反馈时间很短。
- 测试策略很重要，对于庞大系统，想做到面面俱到是不现实的，我们需要权衡成本和收益，通过组合拳来最大限度保证系统质量。
主动查找客户痛点，实施新技术解决方案
客户对概念性东西已经很清楚了，比如写测试有什么好处，重构代码可以让系统变得更加健壮，扩展性好，所以我们要写测试，重构代码呀，这些都懂说出来意义并不是很大，所以一定要找到概念可落地的地方，通过引入一个新的技术方案可以解决客户什么问题，以及带来什么好处，才可以让客户接受，否则就会只停留在纸上谈兵，最后可能适得其反，被认为没有落地能力。
举个栗子:
1.客户的CodeReview工具是Gerrit，这个工具的Review效果非常不好，需要鼠标频繁的操作页面(非常浪费时间)来Diff代码,而且多次commit无法合并Diff,造成的后果就是CodeReview沦为了流程上的关卡，不再Review只是大概看一下点一下审查通过，更不用提团队一起Review这个流程。
针对这个问题，先通过IDE一起CodeReview，因为IDE可以把多次重复修改合并Diff,也减少了鼠标点击频繁点击,通过纸和笔记录提出的问题,团队慢慢建立起CodeReview习惯后，又通过Docker搭建了GitLab把纸笔记录的方式去掉，最后又引入了Fork工作流方式，使CodeReview流程更加规范，通过记录发现，团队随着CodeReview越来越多，磨合的越来越好，提出和发现的问题也越来越有质量。
2.发现客户代码中，有时候会添加一些后门程序，来控制某个功能的开关，而且这个后门程序涉及的范围很广(生产业务代码，数据库表设计,后门的UI页面)，所付出的effort也不小，最主要的是将来没有问题可能就要把这些设计删掉。
针对这个问题，分享了特性开关(Feature Toggle)，做了DEMO，也为日后推行主干开发打下了基础。
3.发现客户代码都是基于实现写的代码，导致的问题就是测试无法添加，因为强行把所有的系统都耦合起来了，如果想对某一个模块添加单元测试，基本不可能
针对这个问题，趁热打铁分享了控制反转，并介绍了控制反转的两种实现方式依赖注入，服务定位器，然后通过这种方式对生产代码做了个小手术，添加了单元测试。
4.发现测试人员有一个自己维护的测试Excele表格,而且开发人员也没有和测试人员很好的沟通，导致有些场景并没有测到，并引发了生产Defect。
针对这个问题引入了Spock Testing框架，目的是想让团队有一个动态文档,从而方便团队针对一个文档进行沟通，由于文档是动态的，也省去了人工维护的成本，因为文档即是测试，测试即是文档。
5.有时候会听到因为一个问题喋喋不休的的争吵，由于架构问题，查询结果无法直接自动映射，会返回一组Object结果集，有人抱怨，但是却没有人去改善。
针对这种问题，我和客户Pair其实只用了2天时间就把自动映射这种问题解决了，结果减少了系统20%的代码，所以我对XP里所说的失败的实践也好过无休止的讨论有了更进一步的理解。
- 引入新技术新实践一定是要解决某个具体问题，而且一定要确定那个问题是真的，而不是直觉感觉出来的。
- 记录是验证某个实践是否真实有效的一个很好的手段，随着时间的流逝，会发现令你震惊的效果。
- 很多抽象的东西都是相关联的，比如服务定位器，我觉得和DDD里所说的DomainRegistry很像。
- Feature Toggle的学问很多，并不仅限于主干分支开发，还有发布开关，运维开关(限流)……还有很多策略，是一个很好的东西。
- 引入合适的测试框架可以极大的提高沟通效率。
- 实践，胜过无休止的讨论。
组内MiniCodingDojo 强化练习
客户人员虽然也参加了一些培训例如:OOBootCamp，Refactor&CleanCode,Refactor Patten,Simple Design……但并没有到学以致用的地步，针对这个现象通过组内强化练习的方式来提高团队成员TDD,Refactor水平。
举个栗子:
1.写了CodingKata相关小题目，有我司的一些小题目，还有codingkata相关的网站上去找栗子，比如鲍勃大叔的博客就有很多，然后在每周某个日子在团队内部练习，当然自己要提前刻意练习，否则会尬场。
2.团队内部找生产代码栗子，大家一起重构，然后我在旁边以观察者形式，在他们做的过程中遇到问题再指点一下，让他们也回忆起OOBootCamp，RefactorBootCamp中所讲的一些知识点，比如Simple Design，S.O.L.I.D原则,BadSmells等
- coding dojo是一个很好提升自己的能力的形式
- 提前准备,以及临场随机应变能力很重要，有一次自己玩脱了，当了一个反例，当时直接就尬场了，现在回头想想如果当时可以临场应变一下就好了，所以之后的东西无论如何我都会自己练习几遍，确保不出现纰漏，也会想Plan B方案
多向有经验的咨询师咨询
参与其它Consultant分享的Session，饭后沟通当前遇到的问题，后续的计划，可以有效克服自身思维局限，解决咨询过程中遇到的问题。
举个栗子:
在我的认知里（包括在TW的各个Team），我会按照自己的所学和理解去和客户一起站会，调整看板，但在这个过程中还是遇到了一些问题，比如客户会Challenge我，那个Consultant不是这么说的，场面会很尴尬，我就说是么，那我去确定下他说的是什么意思，到时候咱再碰一下。在这种事情发生之后，通过和其它Consultant Align，并且从其它人那里学到了更多的知识比如StoryTime，对解析极限编程强调的沟通有了更深的理解。
- 多和其它咨询师聊天可以发现了自己的盲点。
日月忽其不淹兮
时间犹如白驹过隙，也看到了这段时间的带给团队的改变，自己也收获颇多。
在做OOBootCamp的时候得到了很多包括建总，计节的帮助，也通过刻意练习对Task的拆分有了更深的理解，在沟通方面，自己从最开始的不太自信到收集反馈，一点点改进，有了很大的提升，自己最明显的是在讲东西的时候不像以前那么紧张和乱了雪松也给我了很多建议，让我知道在表达一件事的时候，如果站在别人可以很快理解的角度去说，效果会很棒，比如服务定位器 其实就是 提取接口的一种实现，但是如果讲服务定位器，可能会让别人很困惑，所以统一语言还是蛮重要的,感谢宁淑娟在测试策略方面给我的一些帮助，也感谢王威给的一些反馈,告诉我在客户现场应该注意些什么，以及看哪些书，关注在哪些点。
在和内部教练catchup的过程中，谢谢道长分享的Coach Session要探索性的和他人沟通，以引导的方式和他交谈，也发现往往事情并不会一番风顺，会遇到项目紧张，工期紧，事情没有办好，所以我学到了合理安排事情的优先级很重要，不要成为每天都觉得自己很忙，但是却没有做什么事，所以我也养成了健身打卡，学习英语打卡，让这些时间短，优先级也很高的事，来慢慢改变自己，克服拖延症。
这段时间看了很多书，其中对我感触很深的有一些,比如Google测试之道，让我了解了其中一个很有意思的实践Testing on the Toilet,Google的测试团队为了提升团队测试水平，我得到了一些灵感，比如平时听分享的Session实际上对于听众来说，往往印象不是很深刻，那么好我和客户的Team Lead 聊是不是可以把我们这段时间比较好的实践也按照这种方式贴出来，比如当你遇到Framework的静态方法问题无法测试写，那你可以尝试用抽取接口，或者引入Powermock，可以咨询XXX，我想这样可以极大的提高了团队内部知识共享传递的问题。
代码整洁之道 程序员的职业素养这本书让我更加坚定了我所追求的软件价值观
非暴力沟通让我知道了另一种沟通方式，感觉和我司所倡导的提Feedback方式有很多相似的地方，一点点用在和客户的沟通上。
很开心这次的咨询之旅。
