鸡汤贴（汇聚三观摘要）

鸡汤贴 取自《将夜》，话说宁缺同学在红袖招喝醉了酒，在水珠儿姑娘的挽留下，宁缺打算在红袖招地过夜。因记挂家里的小侍女桑桑，于是随手写了一封信打算差人送回老笔斋。

其内容是这样的:“桑桑，少爷我今天喝醉了，就不回来睡了，你记得把锅上燉的剩鸡汤喝掉。”

内容很普通，但笔法却是惊世骇俗。颜瑟大师在红袖招玩耍，偶然间发现这封信后，临摹了一晚上，并将其取名为鸡汤帖！

人生

首先要的是望远镜，看远！
其次是放大镜，看细！
再就是显微镜，看透！
接下来是太阳镜，看淡！
最后是哈哈镜，笑看人生！

歌曲简单就流行;
装修简单就舒适;
衣着简单就大方;
手机简单就实用;
感情简单就持久;
关系简单就牢固;

朋友简单就靠谱;
生活简单就安稳;
心情简单就愉悦;
思想简单就幸福;
追求简单就知足…

心存希望，幸福就会降临你；
心存梦想，机遇就会笼罩你；
心存坚持，快乐就会常伴你；
心存真诚，平安就会跟随你；
心存善念，阳光就会照耀你；
心存美丽，温暖就会围绕你；
心存大爱，崇高就会追随你；
心存他人，真情就会回报你；
心存感恩，贵人就会青睐你。

别和小人过不去，
因为他和谁都过不去；
别和自己过不去，
因为一切都会过去；
别和社会过不去，
因为你会过不去；
别和老板过不去，
因为他会不让你过下去；

别和往事过不去，
因为它已经过去；
别和现实过不去，
因为你还要过下去
别和配偶过不去，
那你可能就真过不去。

什么都可以不好，
唯独心情不能不好；
什么都可以缺乏，
唯独自信不能缺乏；
什么都可以不要，
唯独快乐不能不要；
什么都可以忘掉，
唯独健康不能忘掉。

事业无须惊天动地，有成就行；
钱财无须取之不尽，够花就行；
朋友无须形影不离，知心就行；
儿女无须贫富多少，孝顺就行；
寿命无须无穷无尽，健康就行！

没有一个朋友能比健康更重要，
没有一个敌人能比病魔更可怕。
与其因为自己的病魔暗自流泪，
不如坚持健身为生命增添光彩。

人生，不过一杯茶，
满也好，少也好，
争个什么？浓也好，淡也好，
自有味道。急也好，缓也好，
那又如何？暖也好，冷也好，
相视一笑。

“心”字三个点，
没有一个点不在往外蹦。
你越想抓牢的，
越是离开你最快，
一切随缘，缘深多聚聚，
缘浅随它去。

人生，看轻看淡多少，
痛苦就离开你多少。
人人都怕自己不清醒，
希望自己心明如镜。

世上人啊，
争什么名，夺什么利。
来时一丝不挂，去时一楼清烟 。
空手而来，空手而去，
何必为难自己，
何必奢求太多，何必抱怨指责。
不和谁争吵，
不庸人自扰，快乐才重要！

成熟的人，不问过去，
聪明的人，不问现在，
豁达的人，不问未来。
曾经拥有的，不要忘记；
已经得到的，更要珍惜；
属于自己的，不要放弃；
已经失去的，留着回忆；
想要得到的，必须努力；
但最重要的，
是好好爱惜自己！

摘自不可知之地

信任如水， 一旦浑浊，很难再清澈 ；真情如镜， 一旦破碎，很难再拼凑。信任，能拉近人的距离， 真情，能融化心的冷冰。被别人信任，是一种幸运， 被别人深爱，是一种幸福。

没输过的人，常常会输得一塌糊涂；没摔过跤的人，跌倒了往往爬不起来；没体会过饥寒的人，贫困注定会成为你的归宿；没历经拼搏的人，属于你的多数不会长久。什么被你轻视了，终会被你看重；你专注于一个方向，终会比别人
走得远些。花香，常在夜色中；奋进，常在孤寂里；成败，常在路途上。

一生很短，好好活， 生命无常，用心爱， 累了就歇歇，别太逞强， 难过就吼吼，别总伪装。珍惜身边的，做好该做的， 本分做人，别太圆滑！善良做人，别太恶毒！低调做人，别太嚣张。

老板语录

效率的核心
一次性把事情做对
为什么要一次性把事情做对
软件工程
说到这个话题，首先我们需要理解一个概念和一件事。一个概念指的是“工程”，对创达而言就是“软件工程”。一件事就是：我们都是软件工程师。相对于网络上常用的“程序猿”、“码农”这样的称呼，我认为大家更是一个“工程师”。因为我们每天的工作都是整个软件工程中的一个个工程活动，而所有人的工程活动叠加在一起才能最终形成我们可交付的软件。
那么我们为什么需要软件工程呢？因为如今的软件规模和复杂度早已经超越个人的能力极限，必须通过多人分工合作来完成整个软件的开发和维护。这就好比踢足球，个人技术再好，也踢不赢一场比赛。需要有一系列战略战术，全队配合，才能取胜。软件行业的战略战术，就是软件工程，当然跟踢球一样，软件工程没有正确的，只有合适的。
工程环节的错误积累
我们一般的软件项目，都会分成好多个阶段或者环节，每个阶段对应某个角色的某个工程活动，形成了一个流水线。比如:

• 需求人员拿到客户的需求，通过分析形成需求分析矩阵
• 架构师根据需求去设计架构形成设计文档
• 研发根据设计文档去写代码实现功能
• 集成组把所有的代码编译集成，生成软件制品
• 测试拿到制品，安装后开始测试，生成测试报告
• 最后PM根据测试报告判断是否可以交付。
  这是一个典型的流程，涉及到6个角色和环节，几十个人和工程活动的参与。按照软件工程的理论，每个环节和工程活动都需要达成一些目的，同时也存在一定概率会引入一些问题（也就是bug）。假设每个活动引入问题的概率是10%，那么10个工程活动引入问题的概率就是65%。误差是积累的，因此每个环节如果不做对，最后结果误差就完全不可控了。
  很多人都说，好像我们在平时工作中没有发生这么大的偏差啊？这主要是因为整个过程本身具备一定的自我纠偏的能力，比如研发看到架构师的设计，觉得不对头，就回去跟架构师讨论，把问题解决了才会去编码，这样就在一定程度上避免了一部分错误传递，但是这个纠偏机制的功能是有限的。在汽车BG的项目中曾经出现过，一直到交付给客户了，才发现一个功能还没开发呢，最后往上溯源，才发现是一开始的需求分析就漏掉了这条功能，而后面的各个环节都无法检查出这个遗漏。因此就引出一个新的问题。
  TDD是对的吗
  我们很多人都习惯所谓的“测试驱动开发”-TDD，也就是开发人员代码随便写，靠测试来发现问题，然后改bug。这个并不是真正的TDD，只能算是“Bug驱动开发”——BDD。真正的“TDD”是什么，我们后面再说，但是BDD是一种不可取的方式。为什么呢？因为它传递的理念是：“大家只管犯错，后面有测试兄弟们顶着呢”。我习惯拿足球来类比，上一个这么干的球队是巴萨，刚刚在欧冠被拜仁打了个8比2，即使球门前站着当世最好的守门员也不行。作为一个皇马球迷，看见巴萨被打爆还是忍不住暗爽的。不过再回想一下，上上一个这么干的球队就是皇马，心里又不免难受了下来。

事实证明，再好的守门员也守不住被对手狂轰滥炸，软件工程理论也告诉我们，测试永远无法发现所有问题。更严重的是——试错成本太高了！因为我们发现问题的时间点过于靠后了。最终结果是由几十个工程活动组成的，我们需要逐个排查是哪一个环节出的问题；找到问题以后，还需要把出问题的环节修正，同时还需要对以后的环节都逐个排查是否需要同步修正。这个成本是非常高的。这就是为什么软件行业一直流传的，在下工程（bugfix过程）解一个bug的成本是上工程（设计、开发过程）的10倍，因为需要返工的地方太多了。

那么真正的TDD是什么呢？这是在需求不明确的情况下，用测试来模拟用户需求，通过快速迭代来达到确认需求、完善功能的目的。这是敏捷开发的一种手段，当然也不是唯一的手段，而且是有一定的前提的。比如TDD要求开发到测试再到开发的迭代周期很短，这样才能尽快确认需求，而不至于变成频繁的需求变更，这对于CI/CD乃至DevOpt的要求其实是很高的。再比如，TDD要求用户需求很容易通过测试来体现，主要是偏用户体验类型的产品，而非用户体验型的需求（如系统型的需求）就不适合用这种方式来推进。所以不符合这些条件的TDD都是伪TDD，其实是打着TDD的旗号想在研发流程上偷工减料，最后必将被结果打脸，比如巴萨，再比如皇马。
“一次性把事情做对”的意义
那我们应该怎么做呢？首先需要有一套合适的战术，也就是我们精心定义的软件开发过程。是4-3-3还是4-4-2？每个位置的球员承担什么攻防任务？不同位置的球员之间怎么配合？PM、Arch、Dev、Tester应该怎么分配？架构师应该怎么设计？设计书写成什么样才能交给研发？研发应该从那几个角度去理解设计书？应该怎么去写对应的代码？还是那句话，没有正确的流程，只有合适的流程。

接下来就是每位球员，严格的按照这套战术和自己的角色，不断地通过训练、比赛，把战术执行到极致。对于软件工程师而言，也就是所谓“一次性把事情做对”，让每个环节的实施者，保证本环节的交付结果达到交付标准。什么叫达到交付标准，就是按照要求完成技术动作，完成战术目的，比如概要设计需要明确定义对外接口，写的函数要检查参数、没有内存泄漏，测试需要确保每一个步骤都执行到位。当然我们没法要求每个人每个环节都不犯错，但是绝对不能放任错误从眼前过去。比如带球突破很可能丢球，但是丢了球不能干看着，要么积极反抢，要么赶紧跑位补位；比如Code Review，不能马马虎虎看看就放过，而必须严格按照checklist去逐条检查是否有violation。用一句通俗的话讲，就是“不要随便让别人给自己擦屁股，谁也不是天生的卫生纸”。

为什么要强调“一次性”
那么我们为什么要强调“一次性”呢？因为不坚持一次性，就意味着容忍犯错再改错，而改错的成本都是很高的。其实换个角度就好理解了，从最终的结果来看，我们是必须要把事情做对的，否则项目不就失败了嘛。因此单单要求”把事情做对“，其实基本上就是没有要求。加上“一次性”就不一样了。“一次性把事情做对”强调的是每个工程活动的正确性，确保每个环节都是靠得住的，这样才能让我们在整个工程的过程中不会随时提心吊胆，时时刻刻担心哪儿爆雷。因此，我们必须尽量减少犯错的次数，降低改错的成本，也就必须让每个人都理解犯错的代价，坚持”一次性“把事情做对。
持续改进
“一次性”之后是什么呢？工程活动是在持续进行的，我们在每个“一次性”活动之后，要做的就是“持续改进”。比如我们现在能力有限，一次提交会做入5个bug，那么目前我们就认为Coding活动的标准是每次提交<5个bug达标，后期用补充测试的方式来防止bug流出。然后我们就得想办法来提升效率和质量，比如通过加强Code Review或者提升人员编码能力来使这个数字变成每次提交<3个bug才达标，那么我们就可以相应减少测试投入了。再然后，我们可以继续改进，把这个数字变成1、0.5、0.1。持续改进到什么时候为止呢？我们只要理解，持续改进都是有成本的，在经济学上有个名词叫“边际效益”，当“边际效益”小于0的时候，持续改进就可以暂停了，直到下一次“边际效益”>0的时候再开始。

关于如何做到“一次性把事情做对”，之后几天，几位同事会从不同的角色角度给大家介绍，我就不赘述了。这里我只是简单提几个容易犯错的误区。
容易犯错的误区
误区一：“一次性把事情做对"≠“不允许犯错”
“完美主义”作为个人的一种追求是没有错的，但是在工程领域，“完美主义”是需要杜绝的！因为只要做事就可能犯错，“不允许犯错”会导致执行者寸步难行。比如我们如果看见严重bug就把写代码的人一通批评，吓得人家以后写完代码，非得找4~5个人review完了才敢提交，那反而是资源的极大浪费。我们允许犯错，只是不能无视犯错。比如发现了错误就不要放任它在那里，这次就改好，或者加个标记，下次再来改；已经犯了错要检讨犯错的原因，找到对策，避免下一次犯同样的错误。

当然，需要强调的是，安全方面的错误是不允许犯的，这个是红线。毕竟对一个人、一个公司而言，命只有一条，没了就没有改正的机会了。因此我们要的其实是一个正常的世界，不需要它是完全无菌的，得了感冒就休息两天，等病好了，免疫力就增强了，半年之内就不会感冒了。但是新冠病毒是不能放它进来的，毕竟得了就可能挂了，还会影响一大群人。
误区二：“一次性把事情做对"≠“一步到位”
很多时候，一个功能、一个项目、一个产品的完成是需要多个迭代的，迭代的过程可能是曲折的甚至是丑陋的，我们必须要接受这个过程，不能要求一步到位。比如之前有一个项目，CameraService模块，我们的研发同学攒了2万行代码，一直没有提交过。就因为一开始觉得功能不够完善，还得再改改才能提交。就这么改来改去，从2千行攒到了2万行，越攒越多，攒到后来，找不到可以review+2的人了，因为代码太多太杂，看完就得花一个星期。其实如果一开始，这位同学把整个模块分成一小块一小块，一个功能OK了就提交一次，后面就不会这么麻烦了。因此“一次性把事情做对”要求的是“步步到位”，小碎步前进就好，而不是“一步到位”，步子迈大了容易扯淡。
误区三：“一次性把事情做对"≠“一次做好”
说来惭愧，一开始我们给自己定的题目就是“一次做好”。后来在高人的指点下，才改成“一次性把事情做对”。“一次做好”是一个很好听的口号，可是它错在哪儿？关键就在于，”好“是一个不明确的形容词，软件工程里面要求的就是明确、不模糊。什么叫做好？每个人有每个人的定义，而做“对”，只有对与错之分，符合交付条件的就是”对“的。这个似乎有点不合情理，好就是好，不好就是不好嘛，尽力做好就对了嘛。这里我们就得再强调一下，我们是在完成一个工程，每个人都是在完成所谓的工程活动。每个人都是在执行工程活动，执行到位了就是对的，不到位就是错的。有句话叫”过犹不及“，但是过不过很多时候不是每个人自己判断得出来的，比如一般职业球员，教练都会要求在场上积极跑动。很多球赛直播，球员下场，屏幕显示跑动距离9KM，评论员说这个球员很积极；10KM，评论员表扬说这个球员很拼命。但是如果是梅西，每场7KM正常，8KM，这场跑动多了，战术执行不到位；要是9KM，恩，这不可能，跑够8KM，就必须得被换下场了。对不对这事儿，得教练说了算。

因此“对”的标准既是相对的，又是绝对的。“相对”指的是相对于标准，高于标准就是对，低于标准就是错。“绝对”指的是结果是绝对的，在工程层面，只有0分和60分，没有80、90、100分之分，也就是说结果只有对错，没有好坏。所以，对大家的要求就是，按照规定来，达标即可，而不是说谁跑得多就是球场英雄，谁代码写得多就是劳模，还有UT、IT的要求、交付时间的要求，测试pass率的要求。再比如我们的需求分析，按照要求把输入条件、处理过程、输出结果写清楚了，交付没有延期，这就是”对“的；如果为了把需求写得尽善尽美，把各种可能不可能发生的情况都考虑得明明白白，处理流程各个分支都考虑得清清楚楚，这个没错，但是如果结果延期了，这就是“错”的。因此我们只要“对”，不要“好”，
误区四：“一次性把事情做对"≠“一次性只把自己的事情做对”
其实我们在前面就已经说过了，研发流程本身就是具备一定的纠偏能力的。因为每个环节都是承上启下的，上一个环节的输出就是下一个环节的输入，每个环节都天然的承担着对上一个环节输出结果的校验责任。每个人在完成本环节的工程活动时，自然地就需要帮别人去拾漏补缺。比如测试发现测试的场景不完整，就得提醒需求分析的人，需求分析分析得不到位，有遗漏的场景。再比如研发人员写代码发现设计的漏洞，就应该提醒架构师，设计上有问题，需要修补，甚至还可能牵扯到需求的遗漏。只有当这些修补工作都完成了，测试的场景才能补充完整，研发的代码才能跟正确的需求和设计匹配，事情才能算是做对了。
那有的人就得问了，你刚刚不是还说，每个人都别让别人给自己擦屁股吗？现在又让每个人去给别人拾漏补缺，这不是矛盾的吗？那我们刚才还说了，允许犯错呢。人犯错都是难免的，但是立法上也分故意和过失和无过失：无心犯错或者能力所限，属于过失或者无过失；知错不改和放任错误，这叫玩忽职守，属于故意。我们允许过失和无过失的错误，但是不能容许故意的错误，哪怕是间接故意，放任别人的错误从我的环节溜过去，就属于间接故意，是不能允许的。因此“一次性把事情做对”是要把我眼前的这件事情”全部做对“，哪怕是别人的锅，我也得一起背着走下去。

结语
很多年前，我看过一部电影，冯小刚的《集结号》，一个连坚守阵地，掩护大部队撤退，没听到集结号，就是战斗到最后一个人都得坚守下去，不放一个敌人通过阵地，这是作为战士的责任。作为一个软件工程师的责任，就是保证每个工程活动按时按质完成，不让一个应该被完成的功能漏掉，也不能让每一个应该被发现的bug漏过。“一次性把事情做对”其实传递的是一个态度——“负责任”的态度，在团队中，只有负责任的人才是值得信任的。

换位思考一下，身在一个团队，随时都有要为不负责任的同伴背锅，我会愿意呆在这样的团队吗？如果我是一个客户，看到给我提供服务的人满嘴都是各种“没办法”：“我们能力不足，我也没办法”、“都是XXX的错，我也没办法”、“你不给我们XXX，我也没办法”，我心里会怎么想？

由人推己，我应该做什么样的人？首先让我们做到“一次性把事情做对”，做一个靠谱的人吧；当大多数人都做到“一次性把事情做对”，我们就成为一个靠谱的团队；当我们一直都在靠谱的做事，创达才能成为靠谱的公司，客户认可的公司，一个值得人尊敬的公司。所以，让我们一起努力吧。谢谢大家！

摘自电视剧《天道》，小说《遥远的救世主》改编

本是后山人，偶做前堂客。
醉舞经阁半卷书，坐井说天阔。
大志戏功名，海斗量福祸。
论到囊中羞涩时，怒指乾坤错。

其中应是前堂客，不是堂前客。
这句话出自出自豆豆的《遥远的救世主》，说自己本是后山人，没见过世面、没有学识的人；偶做前堂客:偶然的机会登上大雅之堂；醉舞经阁半卷书：学了一点点知识；坐井说天阔：坐井观天说大话。福祸得失用量海水的办法计算。只是到了自己没钱时，指着老天对我的不公平。
该小说讲述了商界怪才丁元英用“文化密码”疯狂掠夺中国的钱财，良心发现后退出公司，并受到严重的惩罚。最后和芮小丹相爱的故事。

标签：鸡汤,一次性,一个,汇聚,环节,犯错,三观,我们,每个
来源： https://blog.csdn.net/weixin_35597398/article/details/114124962