发表于

6年前看的书，重新整理一下

前言

摘要

一 (专业主义)

  1. 专业主义的精髓就在于将公司的利益视同个人的利益。(这个呢，看情况吧)
  2. 不能忽略完整的测试环节，否则就交付软件是不负责任的。
  3. 为自己的不完美负责。代码难免出现bug，但这并不意味着你不用对它们负责。
  4. 让QA找不出任何问题。把自己没把握的代码发送给QA是不专业的，违背了“不行损害之事”的原则。
  5. 有些代码很难测试，是因为设计时就没考虑如何测试。唯一的解决办法就是要设计易于测试的代码，最好事先写测试，再写要测的代码。(前半句挺对，后半句实际上比较难操作？)
  6. 职业发展是你自己的事。雇主没有义务确保你在职场能够立于不败之地。
    • 雇主出了钱，你必须付出时间和精力。一周工作60个小时，前40小时给雇主，后20小时是给自己的。你应该看书，练习，学习，做一些提升职业能力的事情。
    • 每天大概是3个小时是给自己提升的，你可以在路上学习，在公交学习等，利用一些时间碎片。
    • 一周有168小时，给你雇主40小时，为自己的职业发展留20小时，剩下的108小时再留56小时给睡眠，那么还剩52小时可做其他的事。
    • 其实这样让你免于枯竭匮乏，假设你热爱软件开发，渴望成为专业开发者，在那20个小时里，就应该做能够激发，强化你的热情的事，那20小时是充满乐趣！
  7. IT行业发展迅猛，要时常了解自己的领域，坚持广泛学习才不至于落伍，但并不意味着忘掉过去。别忘了桑塔亚纳的诅咒：“不能铭记过去的人，注定重蹈先人的覆辙”。
  8. 每个软件开发人员必须精通的事项：
    设计模式。GOF书中的全部24种模式。
设计原则。必须了解SOLID原则，而且深刻了解组件设计原则。
方法。必须理解XP，Scrum，精益，看板，瀑布，结构化分析及结构化设计等。
实践。必须掌握测试驱动开发，面向对象设计，结构化编程，持续集成和结对编程。
工件。必须了解如何使用UML图，DFD图，结构图，Petri网络图，状态迁移图表，流程图和决策表。
    • 练习。业精于勤，真正专业人士往往勤学苦干，以求得自身技能的纯属精炼。
    • 合作。学习的第二个最佳方法就是与他人合作。从彼此身上学到很多东西，而且能在更短的时间内更高质量地完成更多工作。并不是要花全部时间一直和别人共事，独处的时间也更重要。
    • 辅导。教学相长，想迅速牢固地掌握某些事实和观念，最好的方法就是与由你负责的人交流这些内容。传道授业中，导师也会从中受益。
  10. 了解业务领域。了解自己所开发项目的业务领域，了解该领域的基本架构和基本知识，一边同客户和用户访谈。花时间与业内专家交流，了解他们的原则和价值观念。
  11. 雇主的问题就是你的问题。弄明白这些问题，并寻求最佳解决方案。开发系统时，站在雇主的角度思考，确保开发的功能真正满足雇主的需要。

二 (说“不”)

  1. 许诺“尝试”，就意味着你承认自己之前未尽全力，承认自己还有余力可施。
    只要你许诺会去“尝试”，你其实是在承诺你会确保成功。
    从本质上讲，承诺“尝试”就是一种不诚实的表现。你这么做的原因，可能是为了护住面子和避免冲突。
  2. 坚守专业主义精神，不能为了赶工而写出糟糕的代码，如果不能做到，当初就应该说“不”。
    (这个吧，尽量吧，前提老板是个讲道理的人。。。。)

三 (说“是”)

  1. 口头上说。心里认真。付诸行动。
    做出承诺，包含三个步骤。
    1口头上说自己将会去做。
    2心里认真对待做出的承诺。
    3真正付诸行动。

  2. 没有做到自己对他人之前的承诺，会让自己难堪。言必信，行必果。
    你只能承诺自己能完全控制的事。
    如果你不尽早告诉别人可能的问题，就错失了让他们帮助你达成目标，兑现承诺的机会。
    (前提是老板要讲道理啊。。。)

  3. 若为了赶工完成任务，周六日加班，那么要求周三才上班也是应该的。 (现实情况。。。)

四 (编码)

  1. 编码是一项颇具挑战也十分累人的智力活动。相比其他，编码要求更加聚精会神。
    自己的代码要让其他人看得懂。(将心比心啊！)
  2. 如果感到疲劳或者心烦意乱，千万不要编码。
    奉献精神和职业素养，更多意义上指要遵循纪律原则而非成为长时间工作的工作狂。
    要确保自己已经将睡眠，健康和生活方式调整到最佳状况，这样才能做到每天的8个小时工作时间内全力以赴。 (虽然生活欺骗了你，但自己也别自暴自弃。。。。)
  3. 中断无法避免，总有人会打断你，消耗你的时间。发生这种情况时要记住一点，也许下次也会轮到你去打断别人请求帮助。因此，礼貌地表现出乐于助人的态度才是专业的态度。(还是将心比心！)
  4. 当大脑已经无法正常思考却硬逼自己在深夜还加班解决问题，你只会把自己折腾得更累，回家洗澡之类的反而会豁然开朗。
    当碰到困难而受阻时，当你感到疲倦时，就离开一会儿，让富有创造力的潜意识接管问题。
    精力分配得当，你将能在更短的时间内以更少的精力完成更多的事情。让自己保持好节奏，让团队保持好节奏。
    了解你的创造力和智力运行的模式，充分发挥它们的优势而非与之背道而驰。
    埋头忙于解决问题时，有时候可能会由于和问题贴得太近，无法看清楚所有的可选项。由于大脑中富有创造力的部分被紧张的专注力所抑制，你会错过漂亮的解决方案。
    (适当放松一下，欲速则不达！！)
  5. 互相帮助是每个程序员的职责所在。作为专业人士，要以随时帮助别人为荣。
    当然你需要独处时间，你可以直接并礼貌的告诉别人你在某个时间段不希望被人打扰。
    (自重感啊)
  6. 接受他人的帮助。如果有人向你伸出援手，要诚挚接受，心怀感激地接受帮助并诚意合作。
    不要因为自己进度压力很大，就推开伸来的援手。不妨给他半个小时的时间。如果到时那个人不能真正帮到你，再礼貌地致歉用感谢结束谈话也不迟。要记住，如同要以乐于助人为荣一样，也要以乐于接受别人的帮助为荣。
    要学会如何求助。如果帮助唾手可得却让自己一个人堵在那儿，是很不专业的表现。
    (透明透明！不盲目埋头苦干！)
  7. 辅导缺乏经验的程序员是那些经验丰富的程序员的职责。向资深导师寻求辅导也是年轻程序员的专业职责。(大家都那么菜，别不好意思！)

六 (练习)

  1. 保持不落伍的一种方法是为开源项目贡献代码。
  2. 职业程序员是用自己的时间来练习。老板的职责不包括避免你的技术落伍，也不包括为你打造一份好看的履历。
    既然你是用自己的时间练习，就不必限制在老板规定的语言和平台。可以选择你喜欢的语言，练习你喜欢的技术。
    (要多多学习啊！)

九 (时间管理)

  1. 受到邀请的会议没有必要全部参加。参加的会议太多，其实只能证明你不够专业。理智使用时间，谨慎选择，礼貌拒绝。
    邀请你参加会议的人并不负责管理你的时间，为时间负责的只有你。
    领导最重要的责任之一，就是帮你从某些会议脱身。好的领导一定会主动维护你拒绝出席的决定，因为他和你一样关心你的时间。
    (时间宝贵，无效浪费还不如用来睡觉。。。)
  2. 如果会议让人厌烦，就离席。如果你发现参加某个会议是在浪费时间，就应当想个礼貌的方法退出来。
    重要的是，你应当明白，继续呆在会议室里是浪费时间；继续参加对你没有太多意义的会议，是不专业的行为。
  3. 如果受到会议邀请，务必弄清楚指定的议题是什么，每个议题花多长时间没要取得什么成果。如果得不到确切的答案，你可以礼貌拒绝。
  4. 专业开发人员会安排好他们的睡眠，保证清晨有饱满的注意力去上班。
  5. 运动需要肌肉的注意力，而编程需要的是心智的注意力。肌肉注意力有助于改善心智注意力。
  6. 时间拆分与番茄工作法。
  7. 专业开发人员会评估每个任务的优先级，排除个人喜好和需要，按照真实的紧急程度来执行任务
  8. 选择了走不通的技术道路，你对这个决定越是坚持，浪费时间就越多。
    专业开发人员不会执拗于某个不容放弃的主意，他们会保持开放的头脑来听取其他意见，让自己有多种选择，一旦看清楚，就会避开。

十(预估)

  1. 专业开发人员能够清楚区分预估和承诺。只有在确切知道可以完成的前提下，他们才会给出承诺。而且会尽可能清楚说明预估的概率分布，这样主管就可以做出合适的计划。
  2. 大多数情况下，专业人士都不会给出确切的承诺，而是提供概率预估，来描述期望完成时间及可能的变数。

十一(压力)

  1. 即使有压力，专业人士也会冷静果断。尽管压力不断增大，他仍然会坚守所受的训练和纪律，他知道这些是他赖以战胜有最后期限和承诺所带来的压力感的最好方法。
  2. 快速前进确保最后期限的方法，便是保持整洁。专业人士不会为了快点前进而乱来。脏乱只会导致缓慢。
  3. 观察自己在危机时刻的反应，就可以了解自己的信念。如果在危机中依然遵循着你守持的纪律，就说明你确信这些纪律。
    如果在平常时候你会注意保持代码整洁，但在危机时刻你却产出混乱的代码，就说明你并不真正相信混乱会导致速度下降。
    如果你遵守的纪律原则是工作的最佳方式，那么即使是深度危机中，也要坚决秉持这些纪律原则。

十二(协作)

  1. 专业程序员最糟糕的表现就是两耳不闻窗外事，只顾一头将自己埋在技术堆里，甚至连公司业务火烧眉毛行将崩溃了也不闻不问。
    你的工作职责就是要让业务免于陷入困顿，让公司可以长久发展下去。
    专业程序员会花时间去理解业务。他们会和用户讨论他们正在使用的软件，会和销售人员与市场人员讨论所遭遇的问题，会和经理们沟通，明确团队的短期目标和长期目标。

  2. 不正常的团队最糟糕的症状是，每个程序员在自己代码周边筑起一道高墙，拒绝让其他程序员接触到这些代码。
    这样会造成许多重复代码，模块间的接口完全是杂乱混淆而非正交的。
    将代码所有权的各种隔断全部打破，由整个团队共同拥有全部代码的做法，相较于此要好得多。
    专业开发人员不会阻止别人修改代码的。他们通过合作来达到学习的目的。

十四(辅导、学徒期与技艺)

  1. 计算机科班毕业生的质量一直令我颇感失望。究其原因，并不是这些毕业生不够聪明或缺乏天份，而是由于大学并没有教授真正的编程之道。
  2. 我们今天的做法和我所提倡的理想化的学徒制程序，这两者之间的主要差异在于技术方面的传授，培训，督导和检查。
    观念上最大差别在于，专业主义价值观和技术敏锐度需要进行不断的传授，培育，滋养和文火慢炖，直至其深植入文化当中。
    我们当前的做法之所以传承无力， 主要是因为其中缺少了资深人士辅导新人向其传授技艺的环节。

附录

编辑推荐

编程大师Bob大叔40年编程生涯心得体会
讲解成为真正专业程序员所需态度原则
业界权威好评，广受赞誉
助您职业生涯迈上更高台阶

媒体推荐

Bob大叔的这本新作又一次抬高了专业程序员的门槛，指出了他们需要在历练尚浅的软件开发职业生涯中需要不断精进的内容。
——Markus Gartner,it-agile公司资深软件开发者

有一些技术书颇具启发与教益，有一些则读来轻松喜悦且富有趣味，但很少有技术书籍能够同时兼具所有这四个特色。我感觉Martin所有的书都可归入此列。
——George Bullock，微软公司资深程序经理

如果计算机科学学位要求有“毕业后必读书单”，本书当在其列。本书描述了迈向专业程序员的修炼旅程……而且阅读起来确实异常有趣。
——Jeff Overvey，伊利诺伊大学厄本那-香槟分校

如果你期望自己能成为软件专业人士，那么本书不容错过。
——R.L.Bogetti,Baxter Healthcare公司系统主设计师

作者简介

Robert C.Martin
世界级软件开发大师，设计模式和敏捷开发先驱，敏捷联盟首任主席，C++ Report前主编，背后辈程序员尊称为“Bob大叔”。20世纪70年代初成为职业程序员，后创办Object Mentor公司并任总裁。Martin还是一名多产的作家，至今已发表数百篇文章、论文和博客，除本书外，还著有《代码整洁之道》、《敏捷软件开发：原则、模式和实践》、《UML：Java程序员指南》等。他最近创办了cleancoders.com网站，专为软件开发人员提供教育视频。

目录

目　录

第1章　专业主义　1
1.1　清楚你要什么　2
1.2　担当责任　2
1.3　首先，不行损害之事　4
1.3.1　不要破坏软件功能　4
1.3.2　不要破坏结构　7
1.4　职业道德　8
1.4.1　了解你的领域　10
1.4.2　坚持学习　11
1.4.3　练习　11
1.4.4　合作　12
1.4.5　辅导　12
1.4.6　了解业务领域　13
1.4.7　与雇主/客户保持一致　13
1.4.8　谦逊　13
1.5　参考文献　14

第2章　说“不”　15
2.1　对抗角色　17
2.2　高风险时刻　20
2.3　要有团队精神　22
2.3.1　试试看　24
2.3.2　消极对抗　25
2.4　说“是”的成本　27
2.5　如何写出好代码　34

第3章　说“是”　37
3.1　承诺用语　39
3.1.1　识别“缺乏承诺”的征兆　40
3.1.2　真正的承诺听起来是怎样的　41
3.1.3　总结　43
3.2　学习如何说“是”　43
3.2.1　“试试”的另一面　43
3.2.2　坚守原则　44
3.3　结论　47

第4章　编码　48
4.1　做好准备　49
4.1.1　凌晨3点写出的代码　50
4.1.2　焦虑时写下的代码　51
4.2　流态区　53
4.2.1　音乐　54
4.2.2　中断　55
4.3　阻塞　55
4.4　调试　57
4.5　保持节奏　60
4.5.1　知道何时应该离开一会　60
4.5.2　开车回家路上　61
4.5.3　洗澡　61
4.6　进度延迟　61
4.6.1　期望　62
4.6.2　盲目冲刺　62
4.6.3　加班加点　63
4.6.4　交付失误　63
4.6.5　定义“完成”　64
4.7　帮助　64
4.7.1　帮助他人　64
4.7.2　接受他人的帮助　65
4.7.3　辅导　66
4.8　参考文献　66

第5章　测试驱动开发　67
5.1　此事已有定论　69
5.2　TDD的三项法则　69
5.3　TDD的优势　70
5.3.1　确定性　70
5.3.2　缺陷注入率　71
5.3.3　勇气　71
5.3.4　文档　72
5.3.5　设计　72
5.3.6　专业人士的选择　73
5.4　TDD的局限　73
5.5　参考文献　74

第6章　练习　75
6.1　引子　75
6.1.1　10的22次方　76
6.1.2　转变　77
6.2　编程柔道场　79
6.2.1　卡塔　80
6.2.2　瓦萨　81
6.2.3　自由练习　81
6.3　自身经验的拓展　82
6.3.1　开源　82
6.3.2　关于练习的职业道德　82
6.4　结论　83
6.5　参考文献　83

第7章　验收测试　84
7.1　需求的沟通　84
7.1.1　过早精细化　86
7.1.2　迟来的模糊性　87
7.2　验收测试　89
7.2.1　“完成”的定义　89
7.2.2　沟通　91
7.2.3　自动化　92
7.2.4　额外工作　93
7.2.5　验收测试什么时候写，由谁来写　93
7.2.6　开发人员的角色　94
7.2.7　测试的协商与被动推进　95
7.2.8　验收测试和单元测试　96
7.2.9　图形界面及其他复杂因素　97
7.2.10　持续集成　98
7.3　结论　98

第8章　测试策略　99
8.1　QA应该找不到任何错误　100
8.1.1　QA也是团队的一部分　100
8.1.2　需求规约定义者　100
8.1.3　特性描述者　100
8.2　自动化测试金字塔　101
8.2.1　单元测试　101
8.2.2　组件测试　102
8.2.3　集成测试　103
8.2.4　系统测试　104
8.2.5　人工探索式测试　104
8.3　结论　105
8.4　参考文献　105

第9章　时间管理　106
9.1　会议　107
9.1.1　拒绝　107
9.1.2　离席　108
9.1.3　确定议程与目标　109
9.1.4　立会　109
9.1.5　迭代计划会议　109
9.1.6　迭代回顾和DEMO展示　110
9.1.7　争论/反对　110
9.2　注意力点数　111
9.2.1　睡眠　112
9.2.2　咖啡因　112
9.2.3　恢复　112
9.2.4　肌肉注意力　112
9.2.5　输入与输出　113
9.3　时间拆分和番茄工作法　113
9.4　要避免的行为　114
9.5　死胡同　115
9.6　泥潭　115
9.7　结论　116

第10章　预估　117
10.1　什么是预估　119
10.1.1　承诺　119
10.1.2　预估　120
10.1.3　暗示性承诺　121
10.2　PERT　122
10.3　预估任务　125
10.4　大数定律　127
10.5　结论　127
10.6　参考文献　128

第11章　压力　129
11.1　避免压力　131
11.1.1　承诺　131
11.1.2　保持整洁　132
11.1.3　危机中的纪律　132
11.2　应对压力　133
11.2.1　不要惊慌失措　133
11.2.2　沟通　133
11.2.3　依靠你的纪律原则　133
11.2.4　寻求帮助　134
11.3　结论　134

第12章　协作　135
12.1　程序员与人　137
12.1.1　程序员与雇主　137
12.1.2　程序员与程序员　140
12.2　小脑　142
12.3　结论　143

第13章　团队与项目　144
13.1　只是简单混合吗　144
13.1.1　有凝聚力的团队　145
13.1.2　如何管理有凝聚力的团队　146
13.1.3　项目承包人的困境　147
13.2　结论　148
13.3　参考文献　148

第14章　辅导、学徒期与技艺　149
14.1　失败的学位教育　149
14.2　辅导　150
14.2.1　DIGI-COMP I, 我的第一台计算机　150
14.2.2　高中时代的ECP-18　152
14.2.3　非常规辅导　154
14.2.4　艰难的锤炼　155
14.3　学徒期　156
14.3.1　软件学徒期　158
14.3.2　现实情况　159
14.4　技艺　160
14.5　结论　161

附录　工具　162

发表于

十年前看过这本书，现在早就忘掉差不多了，重新整理一下。

  1. 与人相处的大秘窍：献出你真实，诚恳的赞赏。
  2. 如果这样做，你将到处受欢迎：真诚的对别人发生兴趣。
  3. 在辩论中，获得最大利益的唯一方法，就是避免辩论。
  4. 要真诚的以他人的观点去看事情。
  5. 在批评对方之前，不妨先谈谈你自己的错误。
  6. 请对方帮忙。

第一篇　待人的基本技巧

第一章如欲采蜜，勿蹴蜂房

  • 批评是没有用的，因它使人增加一层防御，而且竭力的替自己辩护。批评也是危险的，它会伤害了一个人的自尊，和自重的感觉，并激起他的反抗。
  • 人类自然的天性，是做错事只会责备别人，而绝不会责备自己，我们每个人都是如此的。
  • 不要批评，责怪或抱怨。

第二章　与人相处的大秘窍

  • 自重感，这是一种痛苦的，而且急待解决的人类「饥饿」，如果能诚挚的满足这种内心饥饿的人，就可以将人们掌握在他手掌之中。
  • 寻求自重感的欲望，是人类和动物间，一项重要的差别。它使人努力成为伟人或强盗。
  • 献出你真实，诚恳的赞赏。

第三章　左右逢源的方法

  • 如果有一个成功秘诀的话，那就是如何得到对方『立场」 的能力；由他的观点设想，正同由你自己的观点一样。
  • 一个人能设身于他人境地，能了解他人意念活动，他不必考虑到将来的前途如何。
  • 永远站在别人立场去打算、设想，并由对方的观点，去观察事物的趋向。
  • 先激起对方某种迫切的需要，若能做到这点就可左右逢源，否则到处碰壁。
  • 威立姆．温德，有一次说过：「表现自己，那是人性最主要的需要。」可是，为什么在我们事业上，不用这种同样的心理学呢？
    引起别人的渴望。
●提要
不要批评，责怪或抱怨。
献出你真实，诚恳的赞赏。
引起别人的渴望。

第二篇 使人喜欢你的六种方法

第一章　如果这样做，你将到处受欢迎

  • 真诚的对别人发生兴趣。

第二章　如何给人好印象

  • 微笑！
  • 如果你希望别人用一副高兴、欢愉的神情来接待你，那么你自己先要用这样的神情去对别人。
  • 遇到人就展开一个轻松的微笑。
  • 行动该是追随着一个人自己的感受………可是事实上，行动和感受，是并道而驰的。所以你需要快乐时，可以强迫自己快乐起来。
  • 没有给人微笑的人，更需要别人给他微笑。

第三章　你要避免发生麻烦，就请这样做

  • 你要记住你所接触中，每一个人的姓名。
  • 最简单、最明显、而又是最重要的如何获得好感的方法，就是记住对方的姓名，使别人感到自己很重要

第四章　如何养成优美而得人好感的谈吐

  • 做一个善于静听的人，鼓励别人多谈谈他们自己。
  • 很少人能拒受那专心注意所包含的谄媚。
  • 专心静听着对你讲话的人，那是最重要的，再也没有比这个更重要的了
  • 最爱挑剔的人，最激烈的批评者，往往会在一个怀有忍耐、同情的静听者面前软化下来
  • 他们所喜欢的，不是善于谈话的人，是那些静静听着的人。能养成善于静听能力的人，似乎要比任何好性格的人少见。
  • 要使别人对你感到兴趣，先要对别人感到兴趣。

第五章　如何使人感到兴趣

  • 就别人的兴趣谈论。

第六章　如何使人很快的喜欢你

  • 使别人感觉到他的重要–必需真诚的这样做。
  • 如果我们是那样的卑贱自私，不从别人身上得到什么，就不愿意分给别人一点快乐，假如我们的气量比一个酸苹果还小，那我们所要遭遇到的，也绝对是失败。
  • 自重的欲望，是人们天性中最急切的要求。
  • 最重要的定律：「你希望别人怎样待你，你就该怎样去对待别人。」
  • 真诚，一股出自内心的赞赏的力量。
  • 爱默生所说的：「凡我所遇到的人，都有比我优越的地方，而在那些方面，我能向他学习。」
    ●提要
使人喜欢你的六种方法
第一项规则：真诚的对别人发生兴趣。
第二项规则：微笑。
第三项规则：记住你所接触中，每一个人的姓名。
第四项规则：做一个善于静听的人，鼓励别人多谈谈他们自己。
第五项规则：就别人的兴趣谈论。
第六项规则：使别人感觉到他的重要--必需真诚的这样做。

第三篇　得人同意于你的十二种方法

第一章　你不可能在争辩中获胜

  • 在辩论中，获得最大利益的唯一方法，就是避免辩论。
  • 「永远避免正面的冲突！」
  • 天下只有一种方法，能得到辩论的最大胜利，那就是尽量避免辩论………避免辩论，就像避开毒蛇和地震一样。
  • 「我们绝不可能用辩论使一个无知的人心服口服。」
  • 「跟这种冷厉，傲慢，固执的稽查员讲理，那等于是废话……．跟他争辩愈久，他愈是固执，所以我决定避免跟他争论，换个话题，赞赏他几句。
  • 释迦牟尼曾这样说过：「恨永远无法止恨，只有爱可以止恨。」
    所以误会不能用争论来解决，而需要用外交手腕，和赋予对方同情来解决。

第二章　如何避免制造敌人

  • 你可以用神态、声调，或是手势，告诉一个人他错了，就像我们用话一样的有效……而如果你告诉他错了，你以为他会感激你？不，永远不会！因为你对他的智力、判断、自信、自尊，都直接的给予打击，他不但不会改变他的意志，而且还想向你反击。如果你运用柏拉图、康德的逻辑来跟他理论，他还是不会改变自己的意志，因为你已伤了他的自尊。
  • 我所知道的只有一件事，那就是我什么也不知道。
  • 很少人有逻辑性，我们大多数的人，都怀有成见，我们之间，都受到嫉妒、猜疑、恐惧，和傲慢所毁伤。
  • 任何事情只要运用若干的手腕；并不需要告诉对方，他是如何的错误。
  • 尊重别人的意见，永速别指摘对方是错的。

第三章　如果你错了就承认

  • 迅速、坦白的承认错误
  • 假如我们已知道一定要受到责罚，那我们何不先责备自己，找出自己的缺点，那是不是比从别人嘴说出的批评，要好受得多？
    你如在别人责备你之前，很快的找个机会承认自己的错误，对方想要说的话，你已替他说了，他就没有话可说，那你有百分之九十九会获得他的谅解。
  • 任何一个愚蠢的人，都会尽力辩护自己的过错………而多数愚蠢的人是这样的一个能承认自己错误的人，却可使他出类拔萃，并且给人一种尊贵、高尚的感觉。
  • 若是我们对了，我们巧妙婉转的让别人赞同我们的观点。可是，当我们错误的时候，我们要快速的、坦直的承认我们的错误。运用这种方法，不但能获得惊人的效果，而且在若干情形下，比替自己辩护更为有趣。
  • 「用争夺的方法，你永远无法得到满足。可是当你谦让的时候，你可以得到比你所期望的更多。」

第四章　使你走上理智的大路

  • 以友善的方法开始。
  • 温柔、友善的力量，永远胜过愤怒和暴力。
  • 『让我们坐下一起商量，如果我们之间意见不同，我们不妨想想看原因到底何在，主要的症结是什么？。我们不久就可看出，彼此的意见相距并不很远，不同的地方很少，而相同的地方却很多。也就是说只要忍耐，加上彼此的诚意，我们就可以更接近了。」

第五章　苏格拉底的秘密

  • 跟人们谈话时，别开始就谈你们意见相左的事，不妨谈些彼此间赞同的事情。
  • 有说话技巧的人，开始的时候就能得到很多「是」的反应，唯有如此，他才能将听者的心埋，导向正面方向。
  • 他的处世技巧，现在被称为「苏格拉底辩论法」，就是以「是，是，」作为他唯一的反应观点。他问的问题，都是他的反对者，所愿意接受而同意的。他连续不断的获得对方的同意、承认，到最后，使反对者在不知不觉中，接受了在数分钟前，他还坚决否认的结论。

第六章　处理一个抱怨者的安全手法

  • 这是实在的，即使是我们的朋友，也宁愿多谈他们自己的成就；喜欢听我们吹嘘的人，可说少之又少。
  • 法国哲学家洛希夫克，曾这样说过：「如果你想得到仇人，你就胜过你的朋友，可是，如果想获得更多的朋友，就让你的朋友胜过你。」
  • 因为当朋友胜过我们时，那就可以满足了他的自重感。可是，当我们显出胜过朋友时，那会使他有种自卑的感觉，并会引起猜疑和妒忌。
  • 德国人有句俗语，那是：「当我们所猜疑、妒忌的人，发生一桩不幸的事时，会使我们有一种恶意的快感。」
  • 所以，别让我们表现出太多的成就来，我们要虚怀若谷、处处谦冲，那样会永远使人喜欢你，谁都愿意跟你接近。
  • 生命是短促的，别把我们不值一提的成就，作为谈话的资料，令人听了厌烦。我们要鼓励别人多说话。仔细想一想，你实在没有什么可以夸耀的。

第七章　如何使人跟你合作

  • 没有人喜欢强迫自己去买一样东西，或是被人派遣去做一件事。我们都喜欢随自已的心愿买东西，或是照着自己的意思去做事情。同时，希望有人跟我们谈谈我们的愿望、需要、想法。
  • 要让他觉得这是他自己的意思。

第八章　一个创造奇迹的公式

  • 要真诚的以他人的观点去看事情。
  • 你接触到每一件事时，会处处替别人着想。而且以对方的观点，去观察这件事情。

第九章　每个人所需要的

  • 同情对方的意念和欲望。
  • 你是不是愿意得到一句神妙的语句？一个可以停止争辩，消除怨恨，制造好感，使人们注意的听你谈话的语句。
    是的，就有这样一句话，让我告诉你。你对人开始这样说：「对你所感觉到的情形，我一点也不会责怪你，如果我是你的话，我也有同样的感觉。」
    就这样一句简单的话，世界上最狡猾，最固执的人，也会软化下来。可是你必需极是真诚的说出那些话来，假如你是对方的话，你当然有他同样的感觉。
  • 你明天遇到的人，其中可能有四分之三都饥渴似的需要同情…．！如果你同情他们，他们就会喜欢你。
  • 当你接到这样一封信的时候，第一件事，就是如何用严正的措辞，去对付一个不礼貌而鲁莽的人，接着，或许你就动笔写信了。
    可是，如果你是一个聪明的人，你会把这封信放进抽屉里锁起来，经过两天后，再把这封信拿出来……像这类的信，迟上几天寄出，也不会受到什么影响。但当你两天后再拿出这封信来看时，你就不会投入邮箱，那就是我所采取的途径。
  • 盖慈博士在他那一部著名的「教育心理学」书上，这样写着：一人类普遍的追求同情，孩子们会急切的显示他受伤的地方。有的甚至于故意自己割伤、弄伤，以博得大人们的同情。」
    成人们也有类似的情形，他们会到处向人显示他的损伤，说出他们的意外事故，所患的疾病，特别是开刀手术后的经过。「自怜! 实际上是一般人的习性。」

第十章　人人都喜欢的吸引力

  • 事实确实是如此，凡你所见到的人–甚至你照镜子时所看到的那个人- 都会把自己看得很高尚，他对自己的估计，都希望是良好而不自私的。
    银行家摩根，在他一篇分析的文稿中说：人会做一件事，都有两种理由存在……一种是好听的，一种是真实的。
  • 要改变一个人的意志，需要激发他高尚的动机

第十一章　实行、推进，别停顿下来

  • 现在是表演的时代，只是叙述其中的原理，还不能有具体的效果。这种原理需要生动、活泼，需要使它更有趣、更戏剧化，所以必需用有效的「表演术」。
  • 使你的意念戏剧化。

第十二章　当你无计可施时，不妨试试这个

  • 让司华伯用他自己的话来解释：「如果我们想要完成一件事，必须鼓励竞争，那并不是说争着去赚钱，而是要有一种胜过别人的欲望。」
    争胜的欲望加上挑战的心理，对一个有血气的人来说，是一种最有效的激励。
  • 激将法
    • 党魁伯位德用了激将法，他转身向罗斯福大声的说：「难道圣巨恩山的英雄，竟是这样一个弱者？」
    • 司密斯见他犹疑不决的样子，微笑说：「年轻人，我不会怪你感到害怕……是的，那边确实不是一个太平的地方，那是需要一个有、大人物。才干的人，才能有这份魄力去做的。」
  • 只有竞争，才能发挥他们的工作效能。
  • 争强的欲望，自重感的欲望。
● 提要
得人同意于你的十二种方法
第一项规则：在辩论中，获得最大利益的唯一方法，就是避免辩论。
第二项规则：尊重别人的意见，永远别指摘对方是错的。
第三项规则：如果你错了，迅速、郑重的承认下来。
第四项规则：以友善的方法开始。
第五项规则：使对方很快的回答「是！是！」。
第六项规则：尽量让对方，有多说话的机会。
第七顼规则：使对方以为这是他的意念。
第八项规则：要真诚的以他人的观点去看事情。
第九项规则：同情对方的意念和欲望。
第十项规则：激发更高尚的动机。
第十一项规则：使你的意念戏剧化。
第十二项规则：提出一个挑战。

第四篇　使人同意你的九种方法

第一章如果你必须批评，这是开始的方法

  • 当我们听到别人对我们的称赞后，如果再听到其它不愉快的话，就比较容易接受了。
  • 不使对方难堪、反感，而改变一个人的意志
  • 用称赞和真诚的欣赏作开始。

第二章　如何批评才不致招怨

  • 我们要劝阻一件事，永远躲开正面的批评这是必需要记住的。如果有这个必要的话，我们不妨旁敲侧击的去暗示对方。对人正面的批评，那会毁损了他的自重，剥夺了他的自尊。如果你旁敲侧击，对方知道你用心良善，他不但接受，而且还会感激你。
  • 间接的指出人们的过错。

第三章　先说出你自己的错误

  • 如果批评的人，开始先谦冲的承认自己也不是十全十美的、无可指责的，然后再指出人们的错误，这样就比较容易让人接受了。
  • 在批评对方之前，不妨先谈谈你自己的错误。

第四章　没有人喜欢接受命令

  • 你不妨可以考虑一下。」或者是「你认为那个有效吗？」
  • 运用那种方法，他保持了对方的自尊，而且使那人有了自重感。那种方法，也很容易取得对方的真诚合作，而对方不会有任何的反抗，或是拒绝。
  • 发问时，别用直接的命令。

第五章　让对方保持他的面子

第六章　如何鼓励人们成功

  • 即使只有稍微的进步，我们也要称赞，这样可以鼓励别人继续进步。
  • 我们具有各种潜在的能力，可是却惯于不会利用。这潜在的能力，其中一项，就是称赞别人、激励别人，让他们知道自己这股潜在的能力，所蕴藏的神奇效力。

第七章　给狗取个好名字

  • 一般人，都会愿意接受指导，如果你得到他的敬重，并且对他的某种能力表示敬重的话。」
    我们也可以这样说，如果你想改善一个人某方面的缺点，你要表示出，他已经具有这方面的优点了。
  • 莎士比亚说：「如果你没有某种美德，就假定你有。」是好是「假定」对方有你所要激发的美德，给他一个美好的名誉去表现，他会尽其所能，也不愿意使你感到失望的。
  • 几乎包括了富人、穷人、乞丐、盗贼，每一个人都愿意竭尽其所能，保持别人赠予他的「诚实」的美誉。
  • 给人一个美名让他去保全。

第八章　使错误看起来容易改正

  • 告诉一个孩子、一个丈夫，或是一个员工，他在某一件事上愚蠢至极，没有一点的天伦，他所做的完全不对。那你就破坏了他想要进取、上进的心情。可是，如果运用一种相反的技巧，多给人们一些鼓励，把事情看成很容易。使对方知道，你对他有信心，他有尚未发展出的才干，那他就会付出最大的努力，争取到这个胜利。
  • 用鼓励，使你要改正的错误，看来很容易做到；使你要对方所做的事，好象很容易做到。

第九章　使人们乐意做你所要的事

  • 人与人之间关系中，一项重要的规则，那是：「永远使人们乐意去做你所建议的事。」
  • 可是就有这样一件事，发生在拿破仑身上。当他训练荣誉军时，发出一千五百枚十宇徽章给他的士兵，封他的十八位将军为「法国大将」，称他的军队为「伟大的军队」的时候，人们也说他「孩子气」，讥笑他拿玩具给那些出生入死的老军人。拿破仑回答说：「是的，有时人就是受玩具所统治。」
    这种以名衔、或权威赠予的方法，对拿破仑有效，对你同样有效。
●　提要
改变人而不触犯或引起反感的九种方法
第一项规则：用称赞和真诚的欣赏作开始。
第二项规则：间接的指出人们的错误。
第三项规则：在批评对方之前，不妨先谈谈你自己的过错。
第四项规则：发问时，别用直接的命令。
第五项规则：顾全对方的面子。
第六项规则：称赞最细微的进步，而且称赞每一个进步。
第七项规则：给人们一个美名让他去保全。
第八项规则：用鼓励，使你要改正的错误，看来很易做到；使你要对方所做的事，好象很易做到。
第九项规则：使人们乐意去做你所建议的事。

第五篇　创造奇迹的信件

  • 这封信里的语气、含意，使人很愿意为发信人做一点事情，并且使对方有一种自重、高贵的感觉。因为请对方帮忙，使对方有了自尊、自重的感觉。
  • 巧妙的运用这种「帮我一个忙」的心理学。
  • 我们需要尽量鼓起对方的自尊心，但不是运用谄媚，或是虚伪，如果引误了这个出发点，是绝不会有效果的。
    必需记住：我们每一个人，都是希望如何被人欣赏、如何被人重视……甚至会不顾一切的去达到这个目的。可是，没有人会接受不诚恳的、虚伪的奉承。
    我愿意再说一遍：这书中所告诉你的原则，必需出自由衷才会有效果出现。

发表于
  1. 大的需求应预留时间方案设计和评审
  2. 方案时间( 包括跟相关依赖方确认方案时间)
    • 确定依赖方工作量和时间点
    • 工作项拆分
  3. 需求细节确认预留
  4. 开发时间
  5. 联调时间
  6. 配合测试时间（改bug）
  7. 单元测试
  8. 产品验收（测试环境）
  9. 需求改动预留
  10. 代码审核时间
  11. 处理其他突发事情预留
  12. 上线跟进
  13. 记录延期原因（需求变更，需求优先级调整，方案改动等；并同步相关人）
  14. 数据需求(可能影响方案实现细节)

参考场景

  1. 需求方需要一个相对准确的时间点；
  2. 给自己一个合理靠谱，相对科学的心理预估，避免坑人坑自己；
  3. 紧急情况特事特办。。。

发表于

不只局限于做需求本身

  1. 可以考虑把原本不合理的东西进行优化（当然要考虑分享和成本以及必要性）;
  2. 基于基础通用的角度设计方案；
  3. 只做需求本身和想同时做更多的事，时间成本肯定不一样，如何解决两者之间的矛盾：
    1. 透明！把方案抛出来，由团队共同决策选择；
    2. 提供短期方案和长期优化方案。

及时反馈

  1. 发生故障及时反馈，不独自默默处理，避免由小故障变大故障；
  2. 工作进度和成果及时反馈，避免无用功；
  3. 其实还是要透明。
  4. 凡事有交代，件件有着落，事事有回音。
  5. 在不确定的场景下，尽量可以在多个假设中做多套方案（代价不会特别大），这样在对方案的时候，才不会导致得先重做才能继续讨论。

按流程做事

  1. 大公司的流程虽然繁琐，但很多流程其实有其存在的道理，毕竟来源于很多历史教训；保持敬畏，可以减少错误；
  2. 当然紧急情况除外，但是要保持透明，和坚持底线；

总结

  1. 尽量透明；
  2. 站在对方的角度考虑问题；
  3. 保持底线；

To Be Continued …

扩展

寻帮助 - 《认知觉醒》

  • 原来出现特殊情况时，飞行员的注意力会被巨大的危险所俘获，心智带宽降低，容易陷入单一视角，而此时，指挥员可以给飞行员提供有效的外部视角，帮助他们更好地处置特殊情况。
  • 同理，当我们对情绪问题或工作问题百思不得其解的时候，不要一个人闷头苦想，要学会主动寻求外部帮助，借助他人的多维视角来克服自己单一视角的局限。

发表于
  1. 告警信息要标明：机器、业务和环境等信息
  2. 制定合理的告警规则，梳理告警项，优化项目error日志等；避免大量无用的告警导致麻木
  3. 重要的特定业务可以单独配告警
  4. 是不是经常遇到临时打开某个开关，最后又忘记修改回来的事情？其实这种可以通过告警来解决，通过配置常规状态的固定值，定时检查告警即可。

扩展

发表于

业务场景描述

不说废话，直接描述以下两个业务场景

  1. 使用分布式锁控制并发
    请求----------> 服务A
       [1.尝试获取锁]
       [2.获取锁失败]
       [3.返回失败(提示操作太快)]


2. 强依赖服务超时或”请求处理中”

请求----------> 服务A
          [1.强依赖请求]----------> 服务B
                           [2.执行慢(网络抖动等原因)]
          [3.请求服务B超时]   
          [4.返回失败(提示服务繁忙)]

问题描述

  1. 场景1在获取锁失败时直接返回业务失败，可以考虑二次尝试；
  2. 场景2因为服务B执行慢，直接返回上层失败。
    • 服务A重试请求服务B时，可能请求已经执行完，很快就返回成功；或者服务B仍在执行该请求，返回“执行中”错误码。

解决方案

  1. 场景1可以使用“自旋”减少失败率：在抢锁失败时，当前线程“自旋”100m以内的随机数，再二次获取锁；
  2. 场景2同样可以使用“自旋”减少失败率：服务A在请求超时或收到“执行中”错误码时，同样自旋后再次重试，较大概率得到成功结果。

扩展

发表于

前言

本文只讲自己在使用canal之后的一些总结，关于canal的基础用法和介绍，不在这里赘述。

原理

  • canal的原理是基于mysql binlog技术，所以这里一定需要开启mysql的binlog写入功能，建议配置binlog模式为row

  • 原文：https://blog.csdn.net/liupeifeng3514/article/details/79687130

  • mysql的自带复制技术可分成三步：

    1. master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，可以通过show binlog events进行查看）；
    2. slave将master的binary log events拷贝到它的中继日志(relay log)，这里是I/O thread线程；
    3. slave重做中继日志中的事件，将改变反映它自己的数据，这里是SQL thread线程。

  • 基于canal&otter的复制技术和mysql复制类似，具有类比性：

    1. Canal对应于I/O thread，接收Master Binary Log；
    2. Otter对应于SQL thread，通过Canal获取Binary Log数据，执行同步插入数据库；

  • 两者的区别在于：

    1. otter目前嵌入式依赖canal，部署为同一个jvm，目前设计为不产生Relay Log，数据不落地；
    2. otter目前允许自定义同步逻辑，解决各类需求；
      a. ETL转化. 比如Slave上目标表的表名，字段名，字段类型不同，字段个数不同等.
      b. 异构数据库. 比如Slave可以是oracle或者其他类型的存储,nosql等.
      c. M-M部署，解决数据一致性问题
      d. 基于manager部署，方便监控同步状态和管理同步任务.

  • canal的工作原理：

    • canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议
    • mysql master收到dump请求，开始推送binary log给slave(也就是canal)
    • canal解析binary log对象(原始为byte流)

使用简述

  1. 对MySQL给canal-server授权
    • CREATE USER 'canal_server' IDENTIFIED BY 'canal_server';
    • GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal_server';
  2. canal使用ZK来做HA，因为涉及多个client时，消费计算的业务较为复杂的问题，所以目前在使用上只是单点部署，基本能满足需求。

使用总结

  1. 可以通过指定binlog文件和position来重放binlog数据：
  2. 如何查看MySQL位点：https://blog.csdn.net/c1052981766/article/details/80604083
    • show master status
    • show binary logs
    • show binlog events in 'binlog.000368' limit 10; //pos 就是位点, 重启 canal
    • 如何查到旧记录的位点？
      1. 由canal-server中meta.dat记录
      2. 通过 mysqlbinlog 命令分析 mysql-bin.xxx 文件内容，确定增量恢复到的时间点（运维协助）。
  3. 除了用pos点的办法进行恢复，也可以通过指定时间区间进行恢复，按时间恢复需要用mysqlbinlog命令读取binlog日志内容，找时间节点。
  4. 重跑。修改instance.properties文件设置重跑起始位点，删除meta.dat文件并重启。注意回放数据时视业务情况，可能要忽略第一个位点对应的数据。
  5. 重启之后batchId会变，所以不能使用batchId来做幂等处理
  6. 使用mysql主从同步和使用canal同步的区别? 同步数据为什么不直接用主从同步机制？
    1. mysql版本不一致，不支持主从同步
    2. 并不是自己的库，只需要同步几张表，运维不会做这种定制化
    3. 完成同步目标后，可方便拆卸和控制
  7. client重启如何对应原来的位点
    • canal client和server交互之间的身份标识，目前clientId写死为1001. (目前canal server上的一个instance只能有一个client消费，clientId的设计是为1个instance多client消费模式而预留的，暂时不需要理会)

canal和MySQL相关资料

  1. 下载：https://github.com/alibaba/canal/releases/download/canal-1.1.4/canal.deployer-1.1.4.tar.gz
  2. canal.instance.gtidon 是否启用mysql gtid的订阅模式
  3. https://github.com/alibaba/canal/wiki/QuickStart
    https://github.com/alibaba/canal/wiki/AdminGuide
    https://github.com/alibaba/canal/wiki/ClientExample
  4. MySQL数据库的授权原则
  5. canal 高可用介绍
  6. canal和otter的高可靠性分析

发表于

改变心态，以前会抱怨业务乱，但是业务在发展过程中乱是很正常的，也要有人来主动整理，同时也在考验和锻炼整理人的能力。

  1. 梳理现有业务文档，进行归类(如果有的话？)
  2. 拉代码，服务本地跑起来，并跑通单元测试
  3. 梳理服务现有的所有监控平台和数据
  4. 梳理服务的依赖关系和超时时间
  5. 梳理服务的依赖组件（MQ，Redis，DB等）和部署情况
  6. 数据库表梳理
  7. 了解服务的部署和灾备架构（机器数，机房，流量入口）
  8. 代码核心逻辑阅读（核心流量接口）
  9. 了解服务的监控情况，常用配置和开关，相关告警配置通知人
  10. 待优化任务和遗留问题接手

扩展

附录1: 交接列表示例（设计与开发）

## 项目管理
    - 项目日程 
    - 会议记录
    - 体制图 
## 项目要件
    - 业务功能清单 
    - 业务流程图 
    - 需求变更记录 
    - 操作说明书/用户手册 
    - 常见问题一览 
## 界面设计
    - UE设计稿
    - 高保真画面设计稿
    - 需求变更一览
## 系统设计
    - 系统架构设计图
    - 部署架构图DB关联图（ER图）和DB详细设计
    - 系统间集成关系图
    - 对接系统一览表和对接系统接口清单
## 开发制作
    - 源代码
    - 代码运行说明
## 测试
    - 系统测试用例与系统测试报告书
    - 性能测试用例与性能测试报告书
    - 用户测试用例
    - 用户测试签字

附录2: 交接列表示例（运维相关）

## 上线相关
    - 上线判定表
    - 上线操作记录
    - 历次上线版本说明
    - 临时对应体制
## 基础设施
    - 硬件资源一览
    - 软件资源一览
    - 服务器/系统账号权限
    - 系统工具 - 付费/免费软件
## 运维体制
    - 运维工作一览表
    - 近半年运维工作应对流程
    - 运维体制
    - 故障对应流程
    - SLA（服务水平协议）
## DEVOPS（开发运维一体化）
    - CI/CD工具与使用
    - 监控工具
    - 备份管理
    - 代码库与分支管理
    - 数据库相关配置与策略

发表于

提高单元测试覆盖率

  • 提高bean类的覆盖率

    1. pojo-tester
    2. lombok [lɒmˈbɒk]
    3. kotlin

  • 定义一些过滤规则

工具

  • mock神器：mockito
  • sql模拟测试：h2
  • 对测试进行参数化: JUnitParams
  • Awaitility: 一个小型的Java领域专用语言（DSL），用于对异步的操作进行同步。
    https://www.ctolib.com/topics-109441.html
  • WireMock: 用于模拟HTTP服务的工具 （对外部服务打桩）
  • Selenium：编写UI驱动的端到端测试

其他

发表于

业务重构似乎是必然且合理的过程。一个项目刚开始为了快速上线和试错，总会或多或少出现不合理的地方。当项目活下来了，为了寻求下一步的发展，服务的稳定和扩展性提升了优先级，自然就需要有人来重构了，这也是项目历史遗留的技术债务。

项目背景

  • 公司原有的业务几乎都是PHP编写的，并且处于一个很大的项目里维护和运行，可以说是大杂烩。随着业务发展和用户量的提升，渐渐得暴露了很多问题：
    1. PHP运行效率较低，业务未进行隔离，出问题时相互影响；
    2. PHP 过于灵活的语言特性，导致后期较高的后期维护成本；
    3. 基础框架和服务对PHP支持不足；
    4. 实现灾备比较困难。

重构语言选择

  • 我们选择Java作为开发语言进行重构
    1. 静态类型，多人协作开发和维护更加安全可靠；
    2. 内部基础组件的 Java 版生态比较完善；
    3. 学习成本低，且开发效率较 PHP 没有明显降低。

重构的工作是什么？

  1. 最简单直接的主要工作：就是充当PHP到Java语言的翻译，将PHP代码转化成Java代码，并保持逻辑不变，对上层业务是无感知的；
  2. 除此之外，对业务逻辑进行优化和简化，提高后续的可维护性和开发效率；对服务架构进行优化，提升服务的稳定性和可靠性。这是重构的主要意义；
  3. 重构完成之后，制定完善的验证和上线方案。

实施过程

  • Step 1. 用 Java 重构逻辑
    • 对外暴露的协议（HTTP 、RPC 接口定义和返回数据）与之前保持一致（保持协议一致很重要，之后迁移依赖方会更方便）
    • 尽量翻译而不是重构优化（至少第一版重构采取这样的策略）
  • Step 2. 验证新逻辑正确性
    • 当代码重构完成后，在将流量切换到新逻辑之前，我们会先验证新服务的正确性。
    • 考验对业务的熟悉程度和翻译的准确度（代码太久远，最熟悉的可能只有你自己）
    • 单元测试保证
  • Step 3. 灰度放量
    • 当一切验证通过之后，我们会开始按照百分比转发流量。
    • PHP入口对接底层新逻辑（验证逻辑正确性；之所以不直接从流量入口切换，是为了保证稳定性，在出现问题时可以迅速回滚。）
    • 外网代理切到新接口（保持协议一致，无需前端修改，切换彻底）

经验总结

  1. PHP代码太复杂，项目又不容易跑起来怎么办？
    • 默默睁大眼睛翻译还能怎样。。。
    • 如何验证是否翻译正确？
    • 找个在线PHP执行平台把复杂的代码片断跑起来，按照执行结果编写测试用例
  2. PHP代码太狗血太久远，万一翻译到半死发现这段逻辑根本已经没用了怎么办？
    • 把你的服务当nginx用，参数不符合条件的转发到旧服务，记录入参和返回结果，打日志和监控观察流量

最后

  1. 不能相信自己
  2. 不能相信别人
  3. 只能相信自己
  4. 乖乖覆盖测试用例