一

我总是在记忆深处探访那些拥有高效率团队的一切特征，并试图从纷繁复杂的记忆尘埃中找出一些共性，庆幸我已经习惯于通过阅读和思考来解读这些内容，我得以用两个关键性的词汇来描述这些点。那就是“目标管理”和“时间管理”。

目标管理：表面上看，是执行者对于来自高层战略的解读，实际上是通过团队间反馈机制的建立，让团队能够快速的理解战略，并从而在执行过程中为团队带来行之有效解决方案。并通过在一次又一次的执行中落实到位，从而使得团队的目标都能协同发展，进而确保了组织的目标得以实现的整个过程。由于目标管理内容较为丰富，我将在下一篇文章中跟大家探讨这个问题。

时间管理：源自每个人对于自身工作专注度、精力、时间的精细分配，以期高效的实现自己的时间控制。我将时间管理分为“控制自己的精力”，“控制会议”，“控制自己的时间”三个层面。

二

毋庸置疑，在这个资讯大爆炸的时代，我们所能收到的资讯其实已经远远超出了一个人正常所能吸纳的范围。例如，如果以某某头条作为我们的收集资讯的输入，那么可以想象，我们的每天24小时都可以被无限制的占满。甚至而言，如果这样的生活真的是我们生活的全部，我们其实也会觉得自身收获充足。

因为那些来自头条的内容，难免会有一些能够给我们带来价值的内容，例如一些鸡汤或时政新闻或社会动态，通过分享这些内容，我们也获得了一些属于自己的收获。例如，我们会产生这样的错觉：还好我看到了这条消息，赶紧分享出去，不然我又会被人称为“Out”了。

尤其是IT领域从业者，打开头条看到的哪些有关新技术的推文，总是让我们在那么一瞬间激情澎湃，设想如果我们的每天都沉浸在这些内容之中，我们的所谓“互联网技术格局”一定会得到巨大的提升。

毕竟通过头条，使得我们能够在互联网新技术的一瞬间迅速“看到”；也有人分享面试经验和面试题，于是通过头条，那些大公司的面试题，我们都能很快看过；看起来只要我们想挑战，随时都可以去。

我们在阅读技术文章的过程中，同样也像看到小说一般，沿着作者的笔触一起去踩坑，一起去解决问题，甚至有时候我们看到作者采取了一些独特的做法，还会一拍大腿，说这个傻逼作者，明显有更好的方法不用，为什么要用这种二逼方法，要我，一定会用从xxx方法（从其他文章中看到的方法）。

有的技术文章写得特别优美，所描述的技术故事让读者心驰神往，却只有少数人能够把这些文章当种子，在自己的心灵深处发芽，在需要的时候使用这些方法来为自己公司解决问题；还有许多人，会把故事当成段子，以为自己已经成为了行业大佬，热衷于向别人分享。

三

然而，那些其实不过是我们自己找的“信息茧房”而已，并一点点的消耗掉我们原本就不多的精力。所谓“资讯大爆炸”，看起来能够给我们带来收获，但是不加过滤的无脑提取，只会让我们成长为一个又一个的思想上的胖子，行动上的矮子。或者，有点像宫崎骏电影《千与千寻》中的无脸男，他一开始个性单纯，乐于与人交往，却不懂得筛选、过滤有用的知识，并最终成长为一个怪物。

显然我们都知道，时间对每个人来说都是均衡的，我们难免想充分利用今天的时间，但也往往会立下许多不切实际的flag，并被抖X和头条把所有的剩余时间全部消耗殆尽，只有那么少数几个人能够真正把握时间的重要性，并充分利用时间，将自己的精力最大化。

我曾向一位老师请教请教一本销量极广的IT书籍作者的高效工作方法，她说：这位老师确实很优秀，他每天几乎有处理不完的邮件，如果他把自己的精力全部投入到处理邮件上，那几乎很难获得今天的成就。正是因为他明白自己的精力有限，他明白哪些事情最重要，因此他能用最高效的方法完成自己工作，使得他能够在一堆混乱的事务中挑出最有价值的珍珠，从而实现了工作、生活的相对平衡。

确实如此，我也曾立了许多Flag，却发现大部分都实现不了，还不如每天就认真干好几件事，一点点的积累起来才更显得弥足珍贵。

尤其是在通讯技术务必发达的今天，沉迷于社交成为许多人的通病，那么多的群，每个群都显得独一无二，有时候能够在其中发表几句看起来有想法的言论，能够获得大家的一些认同，你会认为自己的精神层面获得了极大的满足。

不由得想起有人对人心弱点的评价：贪婪，自大，懒惰，缺乏自信心、容易焦虑、虚荣心。沉迷于群聊或社区，着实能够让人的自信心看起来得到满足，那也恰好体现了自己在自信心上的不足，才必须借助于这些廉价的方式来填补空白。

社交群、公众号、头条等提供了海量内容，恰好能够满足我们的虚荣心，让我们以为自己看到的就是自己获得的、让我们以为社交网络的朋友圈，就是自己真实的朋友圈。

再过几年，自己的热度过去，会不会觉得这是个笑话？

四

我们应当适度的控制自己的精力，让自己尽量专注的把手头的事情干好之余，再去干其他事情，我们应当学会从海量的信息中对信息进行过滤，提取出能够融入到自己灵魂中的宝贵知识，再一点点的对这些内容进行“重混”，形成自己的知识体系。

管理精力，就是管理自己的时间。只有提高精力的专注度，才能充分利用时间，才更有利于打造“全面均衡”的个体。

一 引子

如何快速融入团队，看似是个简单的问题，其实并非如此。

有时取决于你的性格、有时取决于你的机会，有时取决于企业是否拥有开放的心态或那些拥有开放心态的伙伴，还有时取决于企业的愿景、使命和价值观，以及这些因素的综合作用，同时也包括企业与你是否存在基因上的契合，或者企业文化本身，乃至企业的江湖规矩。

二 基因

基因是个奇妙的东西，似乎在吴军老师撰写《浪潮之巅》之前并不怎么引人注目，而随着吴军老师在书中将基因论作为企业能否顺应互联网的浪潮，并取得辉煌成就的关键因素后，就在坊间开始盛行起来。

这个理论最早被美国管理大师Noel Tichy引入的概念，他把企业称为一个具有活力的生命体，来自于资本和劳动力的双螺旋结构，在创始人、机制、技术和文化等环境因素的共同激励下，促使企业以飞快的速度得以成长。

基因看似是很重要的东西，但是也并非每家企业都一定被基因主导。吴军老师也提到了一些公司，从原本看起来不起眼的制造业，转型成为更加具有高附加值的创新型企业，公司管理层所具备的高瞻远瞩精神和善于创新、积极拥抱创新的态度，是企业得以长盛不衰的关键因素，他把这种称为转基因。

从我们的角度来说，或许基因是个很远的东西，是对我们产生了某些看不到、客观存在的影响。

例如，阿里巴巴的电商基因，使阿里巴巴人更具有应对风险和危机的意识，并透过企业管理一系列流程体现在公司的文化中。那些有幸加入过阿里巴巴的人，许多人都具有一种独特的气质，这种气质使他能够在困难面前无所畏惧，同时又能更好的适应变化的存在。大概这种气质也正是来源于阿里巴巴企业基因中最核心价值观的投影。

也有人曾经有人说腾讯为何以前面向B端转型一直不太成果，大概是由于腾讯的基因都是游戏或社交基因，而除了主阵地之外的其他领域几乎都毫无建树，就连有幸邀请吴军老师加盟的腾讯地图，也未能在LBS领域获得多大的市场。不过随着腾讯云的兴起，这些局面已经有所改观，但是腾讯在智慧产业方面的布局，是否能够重现其在云端市场的效果，依然值得期待。

企业基因的客观存在，或多或少会在我们的每一段职场经历产生积极或消极的影响。例如从公司获得了高层资源、人脉、解决问题的方法，这些都会对我们的未来产生商业上积极的促进作用。企业基因或多或少影响了职场基因。如果说初入职场的我们的职场基因看起来毫无特色，那么在职场中的不断挑战和历练，已经让我们的职场基因受到了大量的诱因而不断蜕变，从而形成了今天更加完美的个体。

三 文化

越来越多的人重视企业文化的存在，因为企业文化如饮水、如呼吸般时刻存在，对凝聚集体，形成战斗力，一起共同思考公司的发展方向。优秀的企业文化也是企业得以长盛不衰的驱动力和灵魂。

企业文化的价值在于唤醒和激发团队的每一位成员对于企业的认同感、使命感和价值感。

基因与文化的耦合是如此紧密，以至于“基因和文化不可分离地连载一起，任何一个变化都将不可避免地迫使另一个也发生变化”。文化进化能塑造基因组，但也可以说基因对文化也存在必然的影响。

创业公司或者中小公司或许都不重视企业文化的存在，因为企业认为可以依靠员工的自驱力来实现认同感和使命感，甚至也有许多人认为在创业公司谈文化是一种非常奢侈的行为，因为要刻意营造一个企业文化的氛围，往往需要从公司层面做好规划，例如采取绩效激励的策略，鼓励积极乐观正向有利于企业发展的文化，往往也会导致企业中好不容易招到的人才会逐渐流失，进而影响了创业企业的发展。

但随着公司的逐渐增长，等发展到一定规模时，往往再构建一套企业文化体系，同样会带来不小的阵痛期，因为团队已经形成了一定的“江湖规矩”，如果这样的江湖规矩能够与企业文化完美的契合，或许还能平滑的过度，但是如果彼此发生了抵触，那显然会带来巨大的过度成本，有时候甚至会导致团队分崩离析。

有一个经典的管理学理论“湿猴理论”是这么说的：

把A、B、C、D、E五只饿了极了的猴子关在一个笼子里，笼子上头掉着一串香蕉，正下方是一个箱子，如果猴子要拿香蕉必须爬上箱子。实验人员装了一个自动装置，若是侦测到有猴子要去爬箱子，就会有大水喷向笼子，这五只猴子马上会被淋湿。首先会有猴子想去拿香蕉，马上水喷出来，它们慌忙用手抱住头，当手离开香蕉的时候，水就立即停止喷射。每只猴子都去尝试了，都得到了同样的结果，开始不明白为什么，但后来知道只要去爬箱子拿香蕉，就会有大水喷来。於是猴子们达到一个共识：不要去拿香蕉！因为有水会喷出来！
后来实验人员把其中的一只猴子换掉，换一只新猴子（称为F猴子好了）关到笼子里。这只F猴子看到香蕉，马上想要去拿，结果被其他四只旧猴子揍了一顿。因为其他四只猴子认为新猴子会害他们被水淋到，所以制止这新猴子去拿香蕉。这新猴子尝试了几次，被打的满头包，还是没有拿到香蕉，当然这五只猴子就没有被水喷到。后来实验人员再把一只旧猴子换掉，换另外一只新猴子（称为G猴子好了）关到笼子里，这支G猴子看到香蕉，当然也是马上要去拿，结果也是被其他四只猴子揍了一顿。那只F猴子打的特别用力,G猴子试了几次总是被打的很惨，只好作罢。
后来慢慢的一只一只的，所有的旧猴子都换成新猴子了。大家都不敢去动那香蕉，但是他们都不知道为什么，只知道去动香蕉会被其他猴子扁。这就是“传统”的由来，这个故事被用来介绍企业文化的建立等诸多管理方面有很好的寓意。

企业文化的建立，就像这个理论中所说，如果在早期采取某些措施有意无意的培养，营造更加积极乐观进取的企业文化氛围，并找对契合企业文化的人才，在发展过程中逐渐的对这些文化意识进行增强，实际上将会对企业的快速发展提供巨大的助力。

四 江湖规矩

“有人的地方就有江湖”。

IT公司也同样如此，许多时候往往还没形成企业文化，反而会先形成江湖规矩。而江湖规矩有许多种。

例如某种大哥文化，在公司发展的早期，往往会依托创始人的个人魅力招揽到一批与其情投意合的人，随着公司的发展，却并非每个人都以打造完美的公司为目标，有的早期员工难免加入公司的目的，就是为了早点占好山头，作威作福。于是公司倒是发展好了，但是大哥却成为最难啃的骨头，或是任人唯亲，或是贪污受贿，或是故意把控住某些关键命门，让全公司都必须看他的脸色行事。

例如某种荤段子文化和烟文化，好吧，听某大型互联网公司朋友说的。在他们的某些部门，荤段子文化特别严重，所以加入了公司就得接受公司的规矩，从能听荤段子开始，到能讲荤段子，那就说明你已经被组织熏陶得非常到位了。除此之外，有的部门烟文化特别严重，像极了某些国企部门，依托烟文化来维系人际关系，不得不说依然是中国人获得人脉的不二法门。

譬如游戏文化，鄙人曾经呆过的一家公司就以团队对战游戏Dota进行团队建设当成公司核心企业文化的一部分，于是那些对Dota这种游戏毫无兴趣、或者不愿意在公司玩RPG游戏、或者不喜欢乱糟糟的氛围的人，就很难融入团队中，直到流失。

即便有了企业文化，往往依然有江湖规矩。如果把企业文化理解为宗教中形而上的思想哲学，那江湖规矩就是具体执行层面的道德约束，如果只是口头上宣讲企业文化的正面，而忽略了同样需要改革甚至破除的影响企业良性发展的“丑陋”的江湖规矩，往往体现了公司在执行层面的巨大缺失，也将为公司的发展埋下隐患。

五 结语

软件企业的发展，往往并非一朝一夕的爆发，更是从内功到外功的修炼之路，始于企业基因，成于企业文化，毁于江湖规矩，恰好就像一个个体的发育过程中精神修炼，那如何强身健体呢？

大概还有团队建设、目标建设、和时间管理吧。接下来的三章，我们来探讨一下这三个问题。

一

不知不觉这个系列已经开始第四篇的，其实我的原始意图只是思考一下如果有幸加入一个新团队，我们在思想和行动上该做哪些准备呢。不过随着内容的逐渐发散，已经衍生成为“如何从加入团队”到思考“如何让团队易于使人加入”的问题。

这其实首先是个组织建设的问题，表现出来就是“使命”、“愿景”、“价值观”、“企业文化”、“企业基因”、“江湖规矩”，其次就是一个团队建设的问题。

二

团队建设，其实无处不在，他在每一天无时无刻都在开展，如果说企业文化建设是构建企业赖以为生的精神食粮，那么团队建设就是为了增强体魄。团队建设好不好，并非是某些部门的事、也并非领导个人的事，实际上是大家都在参与的事情。一支拥有战斗力的团队，并非仅仅惠及领导或企业，实际上也在惠及团队中参与的每个人。

从某种意义上讲，团队建设的目的，并非仅仅是为了构建团队，更是为了让团队中的每个人都能在所谓“建设”中得到成长。华为致力于打造狼性的团队文化，显然不仅仅是为了商业层面的战斗力提升，而是通过让狼性的团队文化深入到团队每一个人的灵魂中，让团队中的每个人都成为值得彼此信赖的人，并最终实现了企业在商业层面的巨大成功。当然，华为人同样也有离职或跳槽的，当他们离开华为，前往其他公司时，也把从华为汲取到的宝贵财富带动了其他团队，进而促进了其他团队的进一步发展。这恰好说明，团队建设的目的，并非是为了建设一个单个团队，而是先建设好个人，其次才能建设好团队。

“三人行，必有我师焉”，我们曾经一度以为，学习是从课堂中学习开始、再学习我们的长辈、学习我们的主管领导、或者学习我们的老板，其实并非如此，学习是发生在每一瞬间，是人类有别于其他生物的一种本能，我们无时无刻不在学习，而在企业中共处时，我们的学习行为也本身就是团队建设的一部分。团队中的每个人，都能成为我们值得学习的一部分，也许他们在某些点上看不出优点，但是往往在其他点上散发出灼热的光芒。

每个人并非生来就是完美的人，而是经过数十年的成长，在日常生活、人际交往、职场中吸取到我们身边其他人身上的优点，然后用其他人的优点构成自己的优点和灵魂，并最终趋于个体健全。同时，我们也把自己的优点投影到其他人的世界中，也在促进其他人的成长。

事实上团队不仅仅是公司的一个部门，我们的一个社区、家庭、或者一个关系融洽的小组织，其实都是一个团队。而当我们加入这一的小组织时，团队建设就已经开始了，我们的一言一行，既对别人产生了影响，而别人的一言一行，也同样对我们产生了影响。

有时每个人都期待与最优秀的人为伍，总觉得那些优秀的人一定无时无刻都在散发着主角的光辉，我们只需从他们散发的光辉中，汲取那么一点点就足以使我们成为一个优秀的个体。其实往往我们应该相信，我们所加入的每个团队其实都是优秀的团队，我们自身每个人都是优秀的个体，只需采取适当的引导措施，都能创造出足够优秀的成绩。

三

布鲁斯·塔克曼将团队建设的过程划分为五个阶段，虽然这个理论已经诞生已经快50年了，但是迄今依然散发着蓊郁的芬芳，可以称为团队建设领域的一块丰碑。他将团队建设划分为“形成期”、“震荡期”、“稳定期”、“规范期”、“稳定期”，他认为每个阶段都是必须、不可逾越的，每个团队的组建过程往往都必须经过这五个阶段。

当然，塔克曼的团队发展阶段理论主要使用于小型团队，但在本文中主要借用来形容一个团队的发展阶段，并非本文的主要内容。

形成期

团队初步建立，人员刚刚加入、或有新的人员加入，还需要对彼此进行认识，了解团队和组织的文化，逐步建立起团队基本的信任过程。在这个阶段人员间往往会比较独立，无法开诚布公的交流问题。团队存在焦虑心理，对团队的发展比较迷茫、甚至不稳定。

震荡期

初步形成了各种观念，并逐步的认识彼此，但是会存在震荡和观点上的碰撞，甚至由于某些技术性的观点会产生一定的冲突。而冲突实际上是说明团队间已经开始寻找彼此沟通的方式，并逐步的适应对方。

规范期

形成了团队的沟通方式和团队文化，团队成员都逐步认识自己在团队中所能承担的角色，并能够为了完成一致的目标而做出自己的努力，在这个阶段彼此间能够流畅自如的进行沟通和任务的执行，并能表现出所具有的一定的自治性。

稳定期

团队运作如同一个整体，彼此沟通融洽，团队能量凝聚一起，彼此间形成的团队能力能够顺利的对任务进行解读并完成目标，同时团队由于已经建立了基本的沟通规则，在一般的事务性问题上已经能够非常独立自治的解决问题。这也是一个战斗力强的团队所具有的基本形态。事实上如果在这个阶段再引入新来的成员，也将重新尽力从形成期开始的阶段。

解散期

又称为“休整期”，任务完成后，团队即将解散，彼此非常珍惜过去来之不易的相处时光，也难免产生失落感。一部分成员将离开团队，团队的战斗力将造成一定的影响，成员对于未来的不确定性将开始逐步占上风。

四

某种意义上上讲，一个团队的形成，有时候像“三个和尚挑水喝”的古老谚语，毋庸置疑，人越少越容易团结、越容易管理、也容易形成自己的团队文化，而团队规模的逐渐增长，也看似会引发这样或那样的问题。尤其是中国人的典型特点，也曾经是在个体时往往具备非常不错的单兵作战能力，但是以集体的形式，会比较难以磨合。

尤其是如果奢望在一个团队中，都是一群优秀的人，其实不太现实，过于优秀的单兵能力凝聚起来，就像是三体星一样，能够维持短期的稳定，却也暗含着不稳定。

（图片来自《DotNET骚操作》公众号，博主说等30秒钟就能看到三体星溃散的效果了。）

而且有时候又渴望通过一定的控制力来维系团队的平衡，其实不见得能产生很好的效果，在一个看似稳定的组织中，引入一些强有力的措施，有时或许会产生下面的效果：

即在一个稳定的平面空间中，引入了一个重量级的“太阳”，自然而然会对空间和时间产生扭曲力，从而破坏原来平等的局面。

当然，有时候引入“太阳”是必要的。

五

团队建设者不应该奢求依托强大的“组织机器”的力量来维系组织的平衡，有时候团队建设更是应该使用“上善若水”的精神，用如水般柔和的力量为团队间营造一种积极交流、互相倾听的文化，让彼此间能够成为对方的信赖。

例如2019年听闻的“滴滴”北京团队组团游野长城，结果被困的消息，大概体现了团队建设者操之过急的团队建设心态吧。

而同样作为团队建设者的我曾经在组织中实践过一种这样的方法，由于我们小团队的人员来源于不同的公司，年龄也有不同，（30岁居多），所以我试图利用每天给大家倒开水泡枸杞这个小细节来建立起团队基本的沟通方式，除此之外，也建立了一系列操作手法，使得不同经验的人都能够在团队中把自己的有点表现出来，从而使得团队间易于破冰，并打造出了一个具有战斗力的小团队。

团队建设不拘泥于形式，每一个细节其实都可以表现出来。每天上班的一声问候、饭局上的互相寒暄，有意无意的引导，以及适度的积极倾听，把团队的每个人都当做你的家庭成员，可以用的方法太多了。

不要再动不动就选择吃饭了。。多俗气啊~

一

团队激励，有时候虽然被称为“胡萝卜加大棒”主义，这套做法其实和美国人在伊拉克或阿富汗搞的拉一派打一派的民族主义似乎差不多，似乎大家也不太愿意听，但是没办法，我们有时候还是得承认，这就是一个客观存在的现实问题。

归根结底，其实每个人都是俗世中的人，难免逃脱不了对于物质和精神欲望的追求。

不同的人在不同的阶段对于目标往往存在不同的衡量标准，有金钱的利益，也有对于声望上的追求，也有人其实看似没什么追求，其实也许也有追求，例如追求团队的认同感，追求工作和生活的平衡？追求更高层面的精神满足？追求在技术上的自我突破？

二

我们的语言表达方式和肢体动作都是内心实际心理或甚至动机的投影，所以作为团队管理者，虽然不能仅凭一言一行来判断一个人的心态，但是如果他做出了明显异于自身常规做法的行为时，那就或许是在给你提醒了。

例如，假设你们公司有一个同事，平时特别喜欢往公司寄快递，突然有一天不寄了，全往家里寄了，那搞不好就是有什么异常的动向了。或者有一位同事平时都特别易于沟通，然后有一天突然特别容易焦躁不安，对工作的事情开始排斥心理，当你问他问题时，他特别反感，或许就需要采取必要的引导措施，给他以激励，以便让他能够更好的为公司继续奋斗。有时有个人平时热衷于跟你讨论技术问题，但是有那么几天突然腻歪了，以至于让你从他的言谈举止中明显的看出来，那也是在暗示着什么。当然，以上这些表现并非都说明对方有离职的趋势，只是说他可能需要接受一些来自于组织的激励了。

每个人都存在被激励的需求，那哪些需求是对大家来说必不可少的底线？哪些是能够让团队持续保持高昂的战斗力，又能紧密的团结到以老板为核心的组织周围，既能共同进退，又能游刃有余？

管理学大佬赫茨伯格对这个有个总结，并形成了一个备受争议的理论，“双因素理论”，大概能够用来总结这些东西。

三

在这个理论中，包含两个部分，分别是保健因素和激励性因素。

保健因素是指在团队中能产生的效果能够起到“保健”的作用，保健能够从环境中消除对身心造成的伤害，虽然无法带来身心健康，但是他能起到预防疾病的作用。

例如待遇问题。。很现实。有的老板说：我的钱都给足了，你还有什么不能满足的？好吧，其实钱的需求只是最基本的需求而已。他无法给人带来满意，只能使人维持在“既不是满意，又不是不满意的状态”。这种状态，大概有点像“我充满怨言，但是我忍了”。好吧。显然，这是一种危险的状态。当然，如果连金钱的基本需求都无法满足，试图靠XX主义的画饼，又如何能使团队成员获得激励？顶多就是维系了一群能够干事的绵羊，却总呼吁他们要保持狼性而已。

除了金钱所涵盖的工资、福利待遇、物质工作条件外，还有公司政策、管理措施、监督、人际关系等。大概还有劳动生产工具，例如是否给开发者配备双显示器或者更好的机械键盘，这些能够极大的改善团队的保健性需求啊。。当然，如果给团队提供“马杀鸡”服务，虽然很奇葩，但是似乎能够对团队提供一定积极正面的效果？没有，只是让那些有怨言的人，多了个忍耐怨言的借口而已，以及在跟其他公司的人交流公司福利待遇时，多一个可以称赞公司的点。

除此之外还有同事关系，同事关系能够给人带来激励么？大概可以，如果团队都很专业，大家干起来很轻松，确实能够带来激励，但是。。如果团队都不专业，或者虽然大家都很专业，但是天天加班，各种开会，常常因为拖工期而被迫赶工熬夜，哪怕大家平时相处的再好，也会充满怨言。

激励因素是指与工作有关，能够令员工满意，激发员工以饱满的状态全付身心的投入到工作中，并把工作当做实现自己理想的因素。例如工作自身能否充满挑战？是不是过度充满挑战？ 例如工作中的认可、成就和责任感，以及技术进步等。

尤其对于开发者来说，过于简单纯粹的工作并不能带来激励，就在于优秀开发者的心目中总有一种对于技术天然的追求，如果无法从现有工作中发掘到令其技术G点满意的内容，或多或少会使其逐渐离心。所以优秀的管理者乐于让团队钻研技术，并鼓励他们发现现有产品中的固有缺陷，并鼓励大家进行改进，这也能客观上起到激励的作用。Google每周允许开发者拿出20%的时间做与本职工作之外的其他技术工作，反而使得开发者能够更好的利用自己的工作时间，从而创造出了更大的价值。

四

发掘团队的优点与适当的激励团队同样重要，根据每个人的特点选择不同的激励措施，例如，如果拆了四套房的，就别试图给金钱激励了，也许给点荣誉证书，对方就很开心了；而经济条件相对较差的，则不然。

有的技术开发者不太擅长表达自己的技术专注点，但是又都愿意分享自己的收获，并希望能从团队分享中获得激励。但作为技术管理者最大的毛病就是吝惜表达自己的赞美，总是易于忽略对方的心理感受，甚至一根筋的认为对方是和自己一样的个体，当对方表达出独特见解时，甚至也许你的评价会过于锋芒，使得其他人关注于你的情绪，而非具体内容本身，这些同样会使人产生不舒适的感觉。

团队中的每个成员都是有血有肉的个体组成的乌合之众，有自己的情绪，想法，文化倾向，也有抱怨和缺点，该如何适当的发掘团队的能力，使战斗力最大化呢？

战斗力的关键部分大概是目标管理和时间管理，后面我们来探讨一下这个问题。

一

事实上我们总是会认为那些所谓外向的人更容易融入集体，其实这是一个悖论。

对于大多数人来说，其实都是一样的，当来到新集体时，总会感觉到莫名其妙的局促不安，这其中至少有50%的人内心的念头大概都有过这样的念头：

我TM到底能不能在这里干满试用期？这公司这样，我要不要把上家公司的离职报告拿回来？我该如何描述在这里的这几天工作呢？要不要写在简历上？听人说少于3个月的经历尽量不要写，那我还是不写吧。我从这里走了，还得继续找工作啊，要不要干脆在这里干下去，过了年再说吧，反正来都来了。

中国人最善于安慰自己，所以一旦想到了“来都来了”这样的道理，那估计铁定一时半会是不会走了，然后就开始逐渐的被公司的体制一点点感化，最终彻底融入其中，成为公司必不可少的一部分。

必须承认，当我们来到一家公司时，也是怀揣着梦想而来，并期待能在这里干一番大事业的，因此当来到公司的那么一瞬间，或许还激情澎湃，但是当遇到一些阻塞，例如要解决一些问题时，由于各方面的阻塞；有时想获得一些支持时，无人理睬，于是让我们或多或少产生了一些困扰。其实哪怕我们内心知道到每家公司往往都需要经历这样一番阶段，但实际上对于这些依然不太愿意接受，更有甚者会感觉有点迷茫，觉得这样的公司层级森严，沟通困难，迟早得倒闭。

不过有时候得承认，这样的公司并不在少数，我们身边几乎每个人或许都经历过，有些人贸然来到这样的团体时，甚至会无法接受，然后突然就离开了，于是给公司的人留下了非常尴尬的印象。

当然，有时候会与是否匹配相应的岗位、公司硬件条件有一定的关系，也有的时候，确实是主观上觉得无法适应这样的工作氛围，进而离开。

二

在生物学中有一个概念叫做“协同进化”，讲的是相互作用的物种在进化过程中互相适应的进化，例如，看似是人类选择了养猫作为宠物，有没有感觉人类也在成为家猫的宠物？毕竟野生的猫肯定没有家猫挑剔，这不既然已经成为了宠物，那还不是得作弄主人，谁让你们觉得猫可爱呢。

其实加入公司的每一位开发者，看似是在适应公司的环境，难道不也是在协同进化么。我们用自己的劳动力换取了自己的那份收入，同时也在用自己的某些特征在逐渐影响周围的人，甚至有时候会对公司层面更大范围的集体意识产生了影响，而有的特别具有优秀者气质的人，也自然而然在这个过程中实现了个人能力的极大提升，并为他们未来人生发展奠定了坚实的基础。

曾经见到过许多人，他们年轻时是充满了斗志、意气风发、能力和才华都非常的引人瞩目，跟我一样，也寓居小城长沙，但是这样的小城市确实很难找到优秀的企业，于是迫于无奈或者是主动选择的加入了那些一些老态龙钟的企业，在开始还感觉挺不错的，但是后来也逐渐的被企业熏陶，然后被工作强奸。还有一些人却始终充满斗志，他们用自己的某些特质感染了周围许多人，并使得公司取得了辉煌的成就，自身也获得了很大的成果。

是什么让他们或是沉沦，或是进取呢。

大概是那三个关键性的东西在默默的发挥着关键的作用吧。

三

“使命”、“愿景”、“价值观”。

有时候我们不愿意相信这些东西，以为这些东西是老板用于洗脑的鬼话，甚至有时候公司还会刻意请一些外来的咨询公司来进行所谓的企业文化培训，这些总是会让大家反感。大家都是经历过思想政治课教育出来的优秀人才，别跟我整这些花里胡哨的东西，我们就想搞点实在的。

但是有时候还真得承认，使命、愿景、价值观真的是让大家得以团聚，能把事情干好的必要条件啊。

使命，通俗的理解就是公司正在做的事。我做的事情是否属于公司正在做的事、是否属于公司的主航道？有时候每当我们接到一个任务时，总是会产生这样或那样的疑惑。如果是符合公司使命的任务，我们干起来或许会斗志昂扬，而不属于公司使命的任务，难免会有点气氛消沉，甚至充满的负能量。

愿景，就是公司想实现的目标。公司干这个事，是真的想做这件事，该不是玩票的吧？公司干这个事，想实现什么目标？我能从这个目标中获得哪些收获？愿景会让人对未来充满想象和希望，而一个人充满了希望，他就愿意为了实现目标付出更多的努力。

价值观，是完成任务过程中会采取的方法论或指导原则。在《华为方法论》中提到，你可以不喝酒，但是不能喝假酒。讲的是有一个分公司的人，为了跟客户打成一片，就在餐桌上喝酒，但是他身体不好，不能喝那么多酒，所以他在酒里面掺了水，然后被人举报，公司严肃的批评了他这种行为，并指出“如果身体不好，要么就别喝酒，喝假酒就是错的”。具体而言，当我们要实现某个东西时，不同的人有不同的方法。

例如要搞定某个客户，我们可以把方案做得特别炫、功能做得特别完美，我们也有人会选择采取特殊的手段（例如PY交易），这样会让那些不认同这种价值观的人反感。

又例如，我们搭建了一个架构，费了很长的时间，然后突然有一个人空降过来，把所有的成绩都归功于自己的功劳，而且还升官发财，而其他人则累死累活，这样的价值观简直恶毒。如果这样的人最终留下来，也意味着所有与他价值观不符的人，要么接受他的价值观或甚至被带下水，要么选择离开。

四

一群拥有相同的使命、愿景和价值观的人，一起为了一个共同的目标而奋斗，其所能产生的动力往往是最大的。在2020年的今天，要把事情干好，并不取决于你的技术水平或知识领域，而是取决于公司能否聚齐这一群人。

同样，当你来到一个团队时，你得衡量的并不仅仅只是团队间的沟通形式，有时候融入团队确实需要时间，但一旦你能够真正融入其中，你将获得自身难以体会的宝贵财富。

下一篇，我想跟大家探讨一下，基因、企业文化、江湖规矩。

《必然》是来自凯文凯利的书，我看到的是2016年的第一版中译本，从2019年12月28日开始看，到2020年1月4日看完，耗时一周左右，这也是2020年看完的第一本书，而我的计划是今年要阅读50本书，下一本还是凯文凯利的一本老书，《失控》。

一

我还记得若干年前，美团和大众点评合并，滴滴和快的合并，中国互联网电商的几大品牌阿里巴巴、京东、当当网、唯品会等都相继在美股或港股上市，这些互联网巨头的崛起一度让我以为，中国互联网经济已经到了饱和期，几乎再也不会出现新的大型平台型公司了。显然，我产生的错觉，恰似从《浪潮之巅》中所看到的那样，在二十世纪九十年代末期互联网泡沫破灭的前夜的美国，也同样是这样看似互联网蛋糕都被瓜分完毕，新加入的玩家在巨头下苟延残喘，短期内看不到希望的那个时代。

毋庸置疑，大家会嘲讽我的短视，曾经电商们几分天下，也有拼多多逆势崛起，凭借微信平台，在社交电商领域挤成了一个行业前三；手机市场曾经被苹果、HTC、诺基亚、三星、中华酷联们占据了主要市场，但是随着小米、华为荣耀们居然还能笑到今天，甚至日子越过越红火，而昔日的中兴、联想、金立们，早就成为明日黄花；汽车市场，有特斯拉和蔚来们在搅局；就连航空航天市场，SpaceX已经开始成为主角，而中国的民营航天市场，也大概到了市场化的十字路口。

这些企业是科技的象征，对于年轻的我们来说，其实已经看不清科技发展的方向了，甚至于，我们每个人所深深经历的这个时代，早已经以想象不到的速度，在一点一点的发生改变，我们已经很难用现有的智慧来预测未来的发展，那是因为基于现有知识体系，我们总是只能看到的一片平衡。

而那些大智慧者眼里，看到的是一片混沌市场，是无穷机会。

二

凯文凯利说：今天，我们生活中的每一项显著变化的核心都是某种科技。科技是人类的催化剂，万物不息，万物不知，万物未竟。这场永无止境的变迁是现代社会的枢轴。。。。在过去两百年里，我们最伟大的发明恰恰是科学流程其自身，而非某个特定的工具或玩意儿。。。。永无休止的变化是一切人类的命运，我们正在从一个静态的名词世界，前往一个流动的动词世界。

我们今天的所有一切，其实都处于不断变化之中。

传统国有企业们为何会逐渐的迷失方向，是仅仅由于体制政策的限制，让他们忽略了基础科学技术的积累，而最终被新来着们降维打击，然后逐渐走向衰微么？传统媒体们，是如何在新媒体之下，一点点的把过去的红利给消耗完毕，以至于走上了今天的下坡路？传统交通运输公司们，是如何在以滴滴为代表的互联网租车新模式下，不仅失去了机会，甚至连人心都失去呢？是一股怎样的力量在指引着时代的前进，该如何做才能顺应时代的发展？仅仅只是互联网的速度提升，和摩尔定律带来的硬件效率提升么？无从得知。

遽然想去，如果我们今天所处的一切，回归到20年前、三十年前、甚至一百年前，大概就像王莽要重新回归到孔子的《论语》所述的一片仁政时代一般，不仅无法适应，而且还会被时空之子干掉吧。历史的车辙滚滚向前，没有任何东西可以阻挡，我们只需想到，我们今天所有的以前，其实是过去三十年飞速发展的科技所带来的巨大成就；同样如此，在未来三十年，可以真正主导生活的重要科技还没发明出来。我们将一次又一次地成为全力避免掉队的菜鸟，永无休止，无一例外。

三

新兴技术在席卷全球，这股快速发展的力量，将、且正在经过一系列潜移默化的步骤持续稳定的改变着我们的文化、我们的思维方式、我们的价值观、我们的存在。它将经历这些步骤：形成、知化、流动、屏读、使用、共享、过滤、重混、互动、追踪、提问以及开始。

形成 Becoming:科技的未来并非乌托邦，也不是反乌托邦，而是“进托邦“，进托邦并非目的，而是一个变化的过程，是一种进程。它是一种”形成“，它是一种变化方式不断变化的进程。我们所瞄准的未来，是当下就能看见，”形成“这种进程的产物。我们将亲眼见证眼下的一切将会成为未来的变化。包括互联网，从禁止将互联网”大范围用于私有实物和个人事务”，到今天，再到2050年。或许正如凯文凯利所说，没有哪一天会比今天更适合创造，没有那一个时代，会比当前、当下、此时此刻更有机遇，更加开放。

知化 Cognifying:人工智能毋庸置疑，将代替我们的工作。

流动 Flowing：数字经济无处不在，时刻都在流动。

屏读Screening：无处皆屏幕。屏幕将是未来生活。

使用 Accessing:从减物质化、到按需使用的即时性、到去中心化、到平台协同、到云端。未来我们或许不能拥有任何事物，但是我们能使用更多东西。

共享Sharing:从分享到合作、再到协作、再到集体主义，我们的成功、我们的失败、我们的情绪、都将“共享”。

过滤 Filtering：当今时代制造的信息、产品已经远超我们所能消费的，我们需要创造一种新的方式来过滤信息和个性化定制，以凸显我们的差异。

重混 Remixing：我们从海量信息中，重混出属于自己的价值。

互动 Interacting：从虚拟现实、到谷歌眼睛，互动的程序在提升，并将继续提升。未来的技术发展很大程度将取决于新兴互动方式的发掘。

追踪Tracking：无处不在的追踪，将意味着更多信息的产生，而更高层次的自我追踪带来的可能性，也将使我们感到震惊。

提问Questioning:提问远比回答更有力量。

开始Begining：我们正在在开始的时刻。

四

我们将迎来的是怎样的时代，他需要我们该做哪些准备？

1 从理论开始

什么是DevOps?

近年来，随着DevOps理念的逐渐深入人心，企业逐渐意识到从看似重复的手工劳动中实现自动化流程处理，对于提高企业劳动生产力已经非常重要，尤其是面向互联网的开发者，往往每次上线时，最大的挑战并非需求的走查或测试和改bug，而是由于发布的流程不够规范，将成果发布到目标环境后可能造成的配置错误或引发其他已知未知问题所造成的额外工作量，使得生产环境的发布流程总会存在不顺利。

而DevOps则致力于统一整合软件开发和软件运维，其特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化监控。目标是缩短软件开发周期，提高部署频率和更可靠的发布，与业务目标保持一致。

在实际操作过程中，对于许多公司而言，开发者和运维者并没有明确的界限，而且即便将运维与开发的岗位职责分开了，也并非意味着双方的职业发展方向将大不相同。实际上在实际操作过程中，开发人员和运维人员依然会使用相同的工具、统一的流程、一致的管理思想，并通过一系列管理手段和工具实现流程的优化。

什么是持续集成和持续交付？

持续集成（Continuous Integration）与持续交付(Continuous Delivery)也正是DevOps中最为基础的两种企业级研发和交付活动。

持续集成来源于敏捷项目管理思想，其核心是团队成员应该经常集成他们的工作，通常每天要求集成一次，当然也可以要求团队成员每天集成多次。每次集成之后，会通过持续集成工具自动运行自动化的构建手段（例如编译、单元测试、集成测试、系统测试），并对集成后的成果进行验证，从而实现了企业管理流程中尽早的发现未知问题的目标。而在传统的软件交付中，可能会将所有问题积压到系统整体测试或甚至UAT（用户验收测试）环节，使得软件的测试时间被拉长，甚至使得软件的问题流入到客户现场，让客户成为小白鼠的情况时有发生。

实际上而言，看似简单的集成，却并非简单，他应该是企业管理过程中的一项铁律，只有严格执行，才能确保软件时刻处于可用状态；否则就意味着所谓交付过程中完成进度的百分之多少，只不过是一个虚无缥缈的空口白话。

持续集成往往离不开持续交付，在乔梁老师翻译的《持续交付》一书中，作者Jez Humber说：持续交付是一种能力，也就是说，能够以可持续的方式，安全快速的把代码变更（包括特性、配置、缺陷和试验）部署到生产环境中，让用户使用。这本书的作者也在书的最后一章中指出：它（持续交付）不仅仅是一种新的软件交付方法论，而且对依赖软件的业务来说，也是一种全新的范式。

持续交付与持续部署看似类似，其实有所区别，前者往往是指将环境推送到用户面前，使用户能够触及和使用它们；而部署则仅仅只是把软件包安装到目标计算机上，用户可能还无法直接使用。

对于面向互联网的软件企业来说，往往都已经在过去若干年间已经建立了一套完整的持续集成/持续交付流程，但对于某些处于飞速发展期的企业来说，依然相对而言后知后觉，主要是由于企业过去飞速发展的背后所依托的人力物力资源，能够足以保证企业的产出能够适应企业发展的需要，然而随着团队规模的发展赶不上企业业务发展的需要时，重复劳动和看似毫无价值的等待期、后期积压的测试任务、无法有效度量的软件功能实现，实质上也会造成企业的管理成本进一步提高。

从哪里可以获得系统的方法论？

对于需要搭建一套完整环境的开发者来说，网上资料很齐全，本文也试图尽可能的对各方面的内容进行综述，努力为开发者提供一个开箱即用的操作流程，但是对于那些想系统的学习持续交付或DevOps领域的知识的开发者来说，你其实不仅仅满足于把环境搭起来，那么你应该看看书。

在持续集成和持续交付领域有大量优秀的作品，而我觉得来自乔梁老师的作品《持续交付2.0》堪称精品，乔梁老师是一位经验丰富的行业专家，在他的职业生涯中积累了与该领域相关非常丰富的产品研发经验，他也身体力行的参与到许多企业的持续交付流程优化过程中，这些经验都让他能够从更全面的视角来分析持续交付的问题。在这本书中介绍了许多直接拿来就可以使用的管理方法、项目案例、工具，能够让有需求在该领域有所作为的开发者带来不少思考。

实质上对于一家要实践持续集成/持续交付的企业来说，将工具搭建完成并非核心难点，难点依然在于如何使用敏捷项目管理的思想，实现软件的细粒度任务拆分，并能够对单个任务进行更好的测试，或许TDD是一种不错的模式，但是却可能给开发者的基础技能提出了更高的要求，这将导致TDD无法落地。

如何快速验证产品需求？在《持续交付2.0》中提出的了一系列的方法，例如装饰窗、最小可行特性法、特区法、定向搜索法、稻草人法、、最小可行产品法等六种方法，通过建立快速验证模型，提高软件从需求到实现的整个流程，能够为企业带来不少便利。

而在研发阶段，可以采用特性分支和特性开关的手法，利用git源代码管理工具分支的妙处，将需求和代码有机的耦合在一起，同时又依托项目管理工具，实现从需求=》实现=》发布的完整闭环，从而为需求的验证提供了双保险；特性开关我最早在刘华老师的《猎豹行动-敏捷转型》一书中看到，通过使用软开关的形式，避免未开发完成的提前上线造成巨大的风险，而在这边书中也同样提到了这样的方法。在.NET中同样也可以使用特性分支组件，后期我将尝试一下。

而对于如何减少等待期，作者提到的方法是：

1、通过“拉动”让价值流动起来，例如，如果是一个生产线的滞留，通过扩大瓶颈的处理能力，让更多的需求能够快速交付，这种手法看似能够临时提高环节处理能力，保障团队的产出，但是显然不是个良好的措施，更合理的措施就是根据下游的生产能力来确定上游的处理能力，由下游来拉动上游的需求。这客观上要求将任务和需求的粒度进一步均匀化，将需求划分成更加易于执行、工作量类似的小需求，使得开发过程更加平滑。

2、任务自助化：也就是让团队掌握某些通用技能，以便在其他人员阻塞时，能够同步完成相关任务，避免了某些关键任务阻塞造成了整体流程的滞后。

在此我就不过多描述书中的精华了，有兴趣的可以入手一本，绝对物超所值。

2、总体流程和环境部署

接下来我将进入本文的主题，首先我将构建一个简单的企业级持续集成/持续交付的管理流程，然后再对流程的实现过程进行较为详细的介绍。

流程图

在这个流程中，使用了master/dev的分支模式。

1、对于dev分支提交的代码，经过代码编辑、静态代码扫描、自动化单元测试的流程，在运行通过后，有测试人员进行代码的测试，并在代码测试通过后，通过pull request提交给master分支的审查人员进行代码检查和合并。

2、测试人员对dev提交的代码进行确认，并由master分支代码审查人员进行代码审查，通过后对代码进行确认，并生成用于发布的生成包。

涉及的组件和说明

在流程中，使用了以下工具，依次安装即可。

1、安装OpenJDK

2、安装Jenkins和相关插件

3、安装PostgresDb

4、安装SonarQube

5、安装dotnetsdk3.1

6、安装git

7、安装nexus包管理器 for windows版用以实现包管理。

8、安装Qy Wechat Notification或HTTP Request 用以实现企业微信提醒。

好吧，环境安装就不介绍了。。

安装补充说明

1、其中jenkins安装的版本为2.190.3,OpenJDK安装的版本为openjdk12.0。安装完jenkins和openjdk后，需要进行环境变量的设置。

2、SonarQube安装的版本为7.9.1，根据官方网站的说明，推荐使用的数据库包括：sqlserver\oracle\postgresdb，在7.9.1和更高版本中，已经不再推荐使用mysql。

3、SonarQube默认使用了基于H2内存数据库的嵌入式数据库，可以在测试环境下使用，但是不建议用于生产环境。

5、安装完sonarqube、和数据库后，需要修改sonarqube/conf/sonar.properties文件中的数据库配置地址，并将sonarqube的服务重启。

在windows系统中，点击sonarqube-xxx\bin\windows-x86-64文件夹中的InstallNTService.bat用以安装SonarQube的服务，而StartNTService.bat则用于启动SonarQube的应用服务。如果数据库配置失败，则SonarQube会启动失败，并提示以下错误：

[sonar-1510653879773] exception caught on transport layer [[id: 0x346b46fb, /127.0.0.1:59330 => /127.0.0.1:9001]], closing connection
java.io.IOException: An existing connection was forcibly closed by the remote host

6、由于使用了自行搭建的Nuget包源管理器，所以在进行构建时，会提示错误，jenkins会使用

Jenkins的项目类型

在jenkins中提供了自由风格、单流水线、多分支流水线、多配置项目等不同类型的项目，可以根据实际情况进行取舍，在本人的尝试过程中，分别总结了三种不同类型的项目可适用的场景：

自由风格项目

操作流程简单，无需配置groovy脚本，即可简单的完成项目的自动化构建。

在自由风格模式的项目中，实现代码编译的过程主要在构建窗口中，主要使用dotnet -相关命令来完成。包括：

1、dotnet restore 还原依赖包。

2、dotnet build 编译

3、dotnet publish -o ./bin/release 发布到指定目录下。

4、如果需要使用sonarqube来进行静态代码检查，需要在服务器上安装dotnet-sonarscanner组件，这个组件是基于.net core构建的静态代码检查组件，安装的命令为：

dotnet tool install –global dotnet-sonarscanner –version 4.8.0；

5、如果采用.net framework 传统框架，则可以继续使用原来的SonarScanner.MSBuild.exe组件进行代码检查结果的上传。

6、如果需要在自由风格项目中使用powershell脚本，可以在jenkins=》插件管理=》可用插件中搜索powershell即可。

单流水线项目

单流水线项目：可适用于只有一个分支和一套环境需要部署时的项目构建，其发布流程需要使用groovy脚本来实现。点击查看pipeline的语法

1、在流水线项目中，都在项目文件的根目录中添加jenkinsfile文件（无扩展名）作为jenkins编译时的脚本文件，而这个文件的脚本语法采用groovy语言，并支持开发者按照脚本语言进行扩展。

2、在单流水线项目中不支持groovy的分支判断条件，支持逻辑比较简单的脚本。

3、与编译有关的结构均写在jenkinsfile中，因此jenkins的UI界面可以理解为配置与项目相关的环境变量信息。

4、可以在jenkinsfile中定义输入的参数，例如：

parameters{
string(name:’ProjectName’, defaultValue: ‘Enter Your ProjectName’, description: ‘Enter your project name here’)
string(name:’Contact’, defaultValue: ‘“@All”,”xxx”‘, description: ‘Enter Your Contract’)
string(name:’RepoUrl’, defaultValue: ‘https://gitee.com/xxx/xxx.git', description: ‘ gitee代码路径’)
}

在jenkins界面中，可以显示成

在具体场景下就可以通过jenkins界面传入相关参数进行编译的测试了。

多流水线项目

多分支流水线项目：使用于一个仓库下各分支不同环境需要部署时的项目构建，其发布流程也需要使用groovy脚本实现。

1、多流水线项目支持使用分支判断条件的语法，因此可以使用的场景更多。

2、其他的总体上和单分支流水线差不多，此处就不在赘述了。

以下编写了一个简单的示例，仅供参考。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

pipeline{
    agent any 
    parameters{
        string(name:'Contact', defaultValue: '"@All",""', description: 'Enter Your Contract') 
        string(name:'RepoUrl', defaultValue: '', description: ' 代码路径')
        string(name:'SonarUrl', defaultValue: 'http://localhost:9000', description: ' sonar代码路径')
    } 
    stages {
        stage('When Master') { 
            when {
                expression {BRANCH_NAME==~/(master)/}
            } 
           steps{        
               checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'xxx', url: params.RepoUrl]]]) 
            }
        }
        stage ("When Dev"){
            when {
                branch 'dev'
            } 
            steps{ rojectName}") 
                checkout([$class: 'GitSCM', branches: [[name: '*/dev']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'xxx', url: params.RepoUrl]]])
                bat "dotnet restore ${params.SlnName}"
                bat "dotnet-sonarscanner  begin /k:\"${params.SlnName}\" /d:sonar.host.url=\"${params.SonarUrl}\" /d:sonar.login=\"${params.SonarToken}\"" 
                bat "dotnet build ${params.SlnName}"
                bat '''if not exist bin\\release mkdir bin\\release'''
                bat "dotnet sonarscanner end /d:sonar.login=\"${params.SonarToken}\""
                echo "CodeCheck Success"
            }
        } 
        stage("test"){
            when{
                expression{return true}
            }
            steps{
                echo "OK"
            }
        }    
        stage('Web Dev Build') {
            steps{
                echo env.BRANCH_NAME
                echo params.RepoUrl
                echo params.SonarUrl
                  bat "dotnet build ${params.SlnName}"
                bat '''if not exist bin\\release mkdir bin\\release'''
                bat '''
                dotnet publish -o ./bin/release 
                '''
                echo 'Publish Success'
            }
        }  
    }
    post{
      success{
        SendToWeChatWork("CI Task success,ProjectName is ${params.ProjectName}") 
        echo 'Publish Success'
      }
      failure{
        SendToWeChatWork("CI Task Failure,ProjectName is ${params.ProjectName}") 
        echo 'Publish Failure'
        }
    }
}
def SendToWeChatWork(content) {   
    def command = """{
          "msgtype": "text",
          "text": {
          "content": "${content},See the detail in Control Panel:${params.Jenkins}",
          "mentioned_list":["${params.Contact}"]
          }
         """
    echo(command)
    response = httpRequest (consoleLogResponseBody: true,
      contentType: 'APPLICATION_JSON',
      httpMode: 'POST',
      requestBody: command,
      url: "${params.WeChatWork}",
      validResponseCodes: '200')
    return response
}

多配置项目

如果组件代码需要在不同的配置、不同的环境下重复部署，其基本逻辑类似，只是配置不同，就可以使用多配置项目。

好吧，我就没有尝试了，因为我已经用了多流水线项目来实现了。在这篇示例中对多配置项目有比较详细的用法，需要可自取。

总结

将企业级持续集成的环境搭建起来本身并不难，难的是如何将整套体系与公司现有的开发流程相结合，考虑到受康威定律的影响，不同的组织对于新事物的接受程度总是不同的，原有组织或许已经习惯了基于手工拷贝再部署的模式，而目前采用这种持续集成、持续发布的模式，会产出哪些问题，这需要随时做好应对的方案。

一

我们难免需要离开一个圈子，加入一个陌生的集体。毋庸置疑，离开熟知的圈子，走向未知的圈子难免会产生许多畏惧甚至情怯，这都是人之常情，但不同的性格驱使我们会做出不同的决定。

外向者也并非时时刻刻外向，但他们习惯于把自己表现在更多陌生人面前，这使得他们总是看起来易于被人接受。

而内向者总是纠结于自己可能会犯错，而失去了展示自我的机会。他们纠结于自己的小圈子，总是需要花特别长的时间才能真正融入集体。

二

一个人加入一个新团队，就像一滴热水突然坠入一片冰河之中。

有时候总需要一场破冰行动，说不定这场破冰行动会成为撕裂冰河的关键力量，在类似于蝴蝶效应的作用之下，整个河面最终都会融化，变成一片充满活力的美好世界，那时的你往往会觉得周围的一切是如此的亲切。

其实往往只需一念之间，不必寻求取悦他人，不必担心自己会不会犯错，只需单纯的选择一个恰当的时间，然后展示出自己，一切无需机遇，无需刻意安排，仅此而已。

其实人群中的每个人都不见得一定是具有才艺的个体，拥有才艺的往往是那么少数。也很少有喷子或者毒舌，那些习惯于没事嘲讽别人、看不到别人优点的人，其实很难在一个圈子中留下来，往往恰好是自己融不入圈子而逐渐的疏离。

在一个团队中的大部分人，都是富有包容心的。所以不用担心自己的表现会使自己的形象受损，恰好相反，有时候在展示自己的才艺时一不小心搞砸了这样看起来很没面子的事情，反而会更容易让大家把你记住，并认为你是一个非常有趣的人，而易于跟你打交道。

其实加入一个新集体就是这样简单，无需矫揉造作，无需刻意讨好，是什么就是什么。

你当然应该在乎你的形象，但是那是靠经常修剪自己的羽毛来完成的，而不是刻意扮演出一个多么独特的形象。真正决定你的形象的，并非这样的一瞬间，而是平时自己的一点一滴的积累和努力，并能与时俱进，保持进取。做一个专注的人，静下心来沉入到一个事情中，并努力的使自己专业，一定更容易让人重视，并也将使你得以在社会职责中扮演更加重要的责任。

三

笔者亲历了一位内向者到社区发起者的成长之路。

他是长沙互联网社区的领袖唐胡子，他说当他才20几岁时，也是一个非常内向的人，甚至比一般的人还要内向，到29岁时，谈过好几个对象都因为过于内向而未能修成正果。

直到后来由于一次偶然的机会，他决定做出改变，然后他开始积极的放开自我，以更加积极的心态去接受陌生人，不再畏惧丢脸和面子，而是抓住一切机会表现自我，有圈子就融入圈子，没圈子就创造圈子。

首先借助于网络，成为网络社区的积极份子，然后把人从线上拉到线下，通过面对面沟通来加强凝聚力，使得虚拟圈子逐渐的变成稳定的大圈子，然后又不断的有新人加入，有人离去，血液不断，细水长流，源远流长。可以说以他为中心的许多圈子都被带活了，数千人为之获益。

要说他做了什么了不起的事情么，也许许多人会嗤之以鼻，不就是拉人头，搞活动，自我介绍，闲聊，聊技术话题么？

运营一个社群其实就是这样看似简单，但是却同样不简单，优秀的运营者总是能在一片陌生人的世界中开创出属于自己品牌的小圈子，然后借助于圈子创造出更大的价值。

四

有时我们应该积极的去拥抱陌生的领域。因为我们每个人都是独立存在的个体，独立的思维方式和行为的方式决定了我们跟周围人的区别，这恰好是人与人之间相处最大的乐趣，求同存异，在别人的世界中寻找自己，并探寻属于自己的未知领域，从而使自己的知识面进一步扩展。

“你有一个苹果，我有一个苹果，我们交换一下，一人还是只有一个苹果；你有一个思想，我有一个思想，我们交换一下，一人就有两个思想。

我们可以怎么做呢？

1、利用一切可以利用的资源，例如从网络开始，或者从花名册开始找人交流，寻找一些能够开启话题的方面，例如姓氏或兴趣爱好、或者籍贯等这些看起来无关紧要的东西。当然，有时你挑起的话题可能对方不感兴趣，没关系，至少冰层会一点点的融化开。这次不行，还有下次。

2、跟你周围的陌生人打招呼。多打招呼，对方将从你的每一次笑容中认识你。

3、去试图融入他们，从聆听他们的沟通开始，坐在陌生人的周围，营造一些沟通的机会。

4、抓住每一次团队建设的机会，这就是破冰的良机。优秀的企业都会有团队建设，通过团队建设，你将有希望看到在你所处的组织架构的一维世界之外的另外一层维度，这将使你对组织有更新的认识。

然后你将逐渐收获特别多的朋友，关键是你掌握了在陌生环境下生存的方法，这将成为你最重要的一种财富。

不知不觉，一晃年关将近，即将翻开2019，进入新的一页。

这周已经在朋友圈看到了来自公众号《恰同学少年》《Edi.Wang》和《吃草的罗汉》几位老师写下的年终总结，他们的年终总结让我感想颇多，对自己的2019年也感想颇深，对2020年也充满期待，是时候对过去一年的一些感悟做一个简单的总结了。

关于“云程序员”

在2018年的年终总结中，与其说是一个总结，不如说是写了一堆漂亮话，其实真正落地的flag太少，而且总结不够彻底，没有起到总结经验，反思教训的意义。

总体上来说，我应该做个对技术充满热情和追求的开发者，而在去年的年终总结大概也只表达了一个意思，不要做云程序员，不要做云程序员，不要做云程序员。

而2019年，我的目标就是回归本质，不做云程序员，从现在来看，至少从思维模式上，已经发生了很大的变化，至少“我觉得xxx技术也不过如此”“我以为xxx技术不过是xxx”这样的主观评判的口气已经不会在说了。

之所以成为“云程序员”，大概是来源于过去若干年有意无意的习惯使然。

有时候得承认，越是中小公司，越容易培养所谓通才，因为公司的发展尚处于摸石头过河的阶段，往往需要在纷繁复杂的混沌乱局中寻找一切可以生存的机会，这也意味着中小企业对开发者的要求几乎都是招之能来，来之能战，战之能胜的通才。中小企业也并没有太多职业生涯规划或培训指导的工作安排，所以工程师的成长往往需要靠自己的方式。

大部分所谓成长，其实是在憋工龄，在一个又一个圈子中绕来绕去。你会用到许多东西，实际上你无法学到真正属于自己的技能。有时候会贪图掌握更多知识，尤其是新技术，于是就开始走在了云程序员的路上。似乎许多中小企业出来的开发者更喜欢自称为全栈工程师，并自称自己什么都会，有的甚至会因此而对那些真正从事技术领域的专业开发者带有偏见，以为他们是死脑筋，其实往往是井底之蛙的个人之见。

专业公司的培养形式是以提高效率为目标的工业化培养形式，对专才的要求也越来越高。IT是一个复杂程度丝毫不亚于其他产业的系统工程，它涉及的领域和技术非常多，几乎每一个方面都值得人花一辈子去认真探究。事实上只有优秀的公司才有可能培养出专才，而且才有这样的土壤，能够让一些开发者能够把时间花在某些专业领域持续学习和研究，然后让知识产生价值。

规模越大、越优秀的公司越容易对开发者产生吸引力，除了其待遇问题外，往往是因为这些公司专业化程度更高，也意味着你更容易快速成长，因为专注于一个领域显然比无法专注于一个领域更能带来更快的成长。从软件研发岗位来说，当你在某些技术方向上的深度上到一定程度，再来扩充广度时，也更容易吸收到有用的东西。当然，现在互联网公司也逐渐开始往通才发展，因为掌握全局思维的开发者更容易做出产品，但是互联网公司和中小企业的通才区别依然比较大。互联网公司需要的是具备互联网思维，能够把自己一块小天地处理完美，还能兼顾其他人工作的可复用型T字型人才，而小企业要的大概是一字型人才。

尤其对于长沙这座小城市而言，更难以发现专注于某些领域的开发者，或许与企业规模和职业定位有一定的关系，其实哪怕优秀如BAT或华为，也或许无法找到太多某些领域的专业开发者，除了公司的客观因素，与开发者们的主观选择也有关系。当然，不管在大公司或小公司，这不能妨碍我们成为专业开发者，只是意味着如果我们要成为某些领域的大牛，得花更多的时间和精力来经营自己的领域。

当然，专业/不专业，云程序员/非云程序员或许本身不重要，毕竟对于大部分开发者来说，选择IT知识混口饭吃。而对于有追求的开发者来说，更应该长期的职业发展全局均衡，而不要仅仅关注眼前的利益。尤其在目前这个时代，你的每一段职场，其实不仅仅在为金钱工作，而是为你的简历工作。如何从你的职场中积累对未来发展有价值的东西，才是核心关键的因素。不论你在哪家公司，总会有许多让你收获颇多的东西。常怀感恩之心，用心去发现价值，总能让你成为正能量的传播者。这样的你，既是公司最宝贵的财富，也同时会让你成为人群中的闪光点。

关于软件研发技能

如前文所说，软件领域是一个非常复杂的系统工程，每一个专业领域都值得人花一辈子去努力钻研，但是对于大部分开发者来说其实无需如此，往往只需花几年时间，就能快速吸取到IT软件发展的精髓，并成长为公司的核心人员。

当你成长起来之后，或许会以为框架就是技术的王道；也会以为软件就是工具+框架的结合，而忽略了更具有普遍意义的基础技能和算法能力；在抽象化思维上，在过程式思维这条路上越走越远，也极大的局限了开发者的成长；你会以为只有底层代码才是代码，业务代码或增删改查就不是代码；你会以为写文档、写PPT的人都是吹牛逼的。这些都是开发者的怪毛病

软件研发技能确实是一个值得仔细探究的核心领域，哪怕简单到一句需求的描述，也需要用系统性思维来思考这个问题。

回顾过去，我总是在想，我真的懂得做项目么，真的懂得如何做好一个软件么？我做的项目是否还有进一步可以提高的空间？如何优雅的收集客户需求，如何优雅的打造完美的产品？如何优雅的做好一个项目？如何让每一个项目都成为标杆项目？如何从失败中吸取经验教训。好吧，我有点啰嗦。

做一个软件真的并非想象中那么简单，需要将行业思维与IT思维更加完美的融合，既要从更高的战略层面思考问题，又要从代码的微观层面思考问题，有思考有设计、有碰撞有火花，这恰好是软件工程最大的魅力所在。

关于读书

2019年看了大概20-30本书，并写了超过15篇书评。包括以下书籍，我认为这些书籍给我带来的无穷收获，远超这些书本身的货币价值。

《领域驱动设计-软件系统核心复杂性应对之道》：这本书来自埃文斯-埃里克的书，是一本经典的领域驱动设计的书，在2018年8月我开始认真阅读其中的每个文字，并让我对领域驱动有了更深层次的理解；今年我还通过GitChat购买了张逸老师的领域驱动设计的课程，张逸老师不愧为领域驱动设计方面的专家，他用自己的经验解释了领域驱动设计，让我对这本书、以及相关知识都有了系统而全面的了解，同时还通过这一个课程了解了更多的知识领域，对健全我的知识体系产生了巨大的作用。

《中台》：来自阿里巴巴钟春老师的中台，这本书介绍了阿里巴巴中台建设的历程，这本书造出了一个独特的中国概念，也刷新了我的知识观，虽然短期来看我所经历的企业都没有中台的打算，但能够让我具备全局性思维来思考IT体系建设的问题。

《小团队、大架构》：来自张清辉老师，这本书介绍了携程的.NET技术架构转型过程，让我对.NET架构的演进方向有了明确的认识。当然这本书过多的介绍轮子，许多读者或许不喜欢，如果跟《微服务架构模式》一起交替的看，一定会产生不错的效果。

《构建之法》：来自邹欣老师，这本书介绍了软件工程师的成长和微软的IT管理模式，让我能够静下来思考当下自己的发展方向。作为一个拥有十年工作经验的开发者，已经陷入了一个以自我为中心的乖蹇，而周筠老师对我的悉心教导，也让我非常感动，我也要持续努力，坚定自己的发展方向，努力做一个脚踏实地的开发者。

《浪潮之巅》共两卷：这是吴军老师的作品，吴军老师的质朴清新，不刻意使用过多的辞藻铺垫的写作风格让我获益匪浅，同时讲述的一个个故事又是如此的引人入胜。从故事中，我们看到了一群充满梦想的年轻人们，他们在互联网的浪潮之下做出的选择，是如何一点一点的改变了世界。

《实例化需求》：这是一本介绍BDD模式的书，介绍了行为驱动开发这种模式，让我获得了新的知识。当然短期内用不起来，但多学一点总不会吃亏。

除此之外还有：《代码整洁之道》、《重构-改善既有代码的艺术2》、《持续交付2.0》、《PMBook》（好吧，考了12月的pmp，把pmbook看了四遍）、《程序员的三门课》、《Http/2基础教程》、《混乱：如何成为失控时代的掌控者》、《我的世界观》、《算法图解》、《未来简史》、《刷新》、《修炼之道》、《猎豹行动》、《单元测试的艺术》和刚刚读完的《华为方法论》。

这20几本书都是不同方向的书，与能够读完50本书或更多的优秀前辈们相比确实还存在一点差距，当然这些书有精读有略读，甚至有的其实是牛嚼牡丹，值得以后细细品味。

有的书着实发人深省带来了许多启迪，有的书则让我的知识体系进一步全面，不过从书到知识到技能，还需要进一步实践、修炼和理解，不然依然是走在云程序员的路上。

关于社区

2019年比较大的成绩，拉了一个技术社区应该算是一个；从2月的酝酿，到4月的落地，花了不少的精力，而且这些都是利用业余时间完成的，连筹款都是靠社区大佬、微软、腾讯运加以及社区朋友们的大力支持。也把公众号从80开始，做到了目前的5000+，这些也算是小收获吧，不过没什么骄傲的，毕竟那么多人都是从零开始，做到万粉大号。

从某种意义上来说，社区似乎离大家都比较远。有时候会感觉试图打造社区来凝聚开发者，其实是一厢情愿。技术社区，或许只会给那些拥有开放性基因的企业和开发者带来好处，并有望助力企业的进一步腾飞。尤其在长沙，究竟有几家企业拥有开放的技术心态？这是个问题。长沙的技术氛围着实令人窒息。

我们总是渴望打造一个优秀开发者社区。其实优秀开发者本身是一个不好衡量的问题，毕竟成为前百分之二十已经是优秀者，而张一鸣口中的那百分之一的精英，本身就并非一朝一夕所能炼成。

最终还是落在产出上，你助力企业腾飞、或者你做出了优秀的产品、或者你能够具备自己的系统性思维，并能写出一辆本书；优秀有太多种了，每一种都来之不易。

一个所谓社区，如果没有形成长期有价值的积累，没能打造优秀的平台，最终走向消亡反而会是“众望所归”。如何让社区避免成为水群、如何发掘更多优秀开发者，形成精英小圈子，我想说每个人都得继续努力，最起码不能成为一个菜市场，否则这样的圈子，其实毫无价值。

有时候会发现，每个群都是那么几个固定的人，沉迷于群其实根本不能带来个人成长，真正的成长还是得静下来自己认真学习。

要成为优秀开发者，有时候三天打鱼，两天晒网的刻意憋一点大招，表面上看能带来一点好气象，但是过了那个热度就被客观条件或主观条件抛弃。技术这东西真得坚持个三五年，才真的能够成长起来。有的人，看到这个火，就追逐这个，看到那个热门就赶潮流搞那个，一边写着代码，一边想着明年是不是该转行，这样的学习方式如何能够提高自己？

从这一点上来看，我只想说我已经在努力朝着好的方向进步，但是还远远不够，与那些已经坚持优秀习惯五年、十年之久的开发者相比，我需要做的远远不止眼前这一点点。

关于2020年的计划

有时候不太想列过于宏大的计划，因为往往计划会变成插红旗，然后在自己的背上插满了红旗，变成了一个京剧里面的大英雄。这样的计划或许毫无意义。

所以还是得认真思考，踏踏实实的做几个能够落地的计划：

• 1、勿忘初衷，踏实前进：不吹水，不装逼。做一位优秀的专业开发者，在专业方向上持续形成系统性思维。
• 2、减法和加法：
  • 有感于今年随着参与了社区活动，加的群也越来越多了，2020年得在这一点上多做减法。
  • 有时候追逐于信息的热度，其实大部分都与我毫无关系。为何关注这些东西？还是八卦性思维的束缚，这一点也有做减法。
  • 而知识体系的厚度上则需要做加法，多看书，多思考。朋友圈做加法，并非多交更多的朋友，而是都跟优秀的朋友交流沟通，吸取他们的优点，转化成自己的优点。
• 3、写满一百篇博客，看五十本书。
• 4、也得学Edsion周同学锻炼身体了。
• 5、努力践行积极乐观向上的团队文化、努力培养一支有战斗力的学习型团队。

超过30岁的开发者总是会焦虑于自己的职业发展，不知道自己的未来该如何选择，那大概是由于想得太多，做得太少。

行走在IT这条路，成长太快反而不是好事，只有脚踏实地，一步一个脚印，才能真正无所畏惧。 “易定者无感，易感者无定。”，谋划好未来，并经营自己的当下，才有美好未来。

起因

这是我无意中在筛选简历时，看到一位朋友发布的求职说明中，明确指出，外包勿扰，并给出了他做出这个决定的理由：

过去若干年间，他一直在中软国际从事.NET方向的软件研发，虽然工作了很多年，但是做的项目类型特别多，总感觉没什么积累，而且工作很累，经常要加班，压力很大。不仅如此，由于外包类型的项目，往往需要驻场开发，一旦在客户现场进行开发，其实都会成为封闭式开发，每天投入工作的工时往往会超过十几个小时。而且在客户现场的开发时，有时候就是低等公民，得承受来自各方的压力。

前不久也刚刚看到一位来自西安软通动力的资深Java工程师，由于长时间加班后引发身体疾病，并最终猝死，还得不到工伤补偿的新闻也触动了我们的心。

这边的互联网公司从业人员还可以吐槽每天996，让自己成为被公司圈养的小绵羊，更是让自己的家庭生活都受到了无穷影响；那边的外包公司从业人员们显然没有互联网公司这么多的露脸机会，哪里有时间运营自己的公众号啊，每天都被客户压榨得死死的，还得跪下来对客户说：爸爸，再爱我一次！

当然，坦率而言，现在国内的IT行业现状其实压力都很大，无论是外包公司、还是互联网公司，如果是几年前大环境还好的时候，或许大家压力大点，至少不会饿肚子，现在冬天来了，不仅压力大，而且还吃不饱穿不暖，一旦遇到公司困境，还得面临被裁员的后果。

好吧，在这篇文章中，我还是不输出焦虑了，只单纯的讨论一下这个问题。

在外包公司做增删改查有前途么？

有没有感觉，这是一个通用的句式：干xxx有前途么？

例如，在百度里面输入，“干程序”，首先会自动提示的就是“干程序员有没有前景”？好吧，有没有前途我也说不准，我就单纯的探讨几个问题，什么叫有前途；在外包公司有前途么；做增删改查有前途么？

什么叫做有前途？

世俗的说，金钱、名誉和地位大概就是许多人在追求的前途。而在IT领域，由于无法与从事公务员和经商的其他同龄人相比，往往会用待遇和岗位来形容。例如有时候总会以为技术总监一定是值得追求的前途；或者为了更高的收入，会选择一些特定的行业。例如这几年相继爆雷的P2P行业，在这些行业中的开发者的工资往往都非常高。

然而，当公司的套路被人揭穿之后，无数投资人的巨额投资化作一堆废纸，这些P2P企业公司的开发者们在这段时间从公司获得的所有收入都会被列入非法所得，必须上缴给公安机关，以便清偿债务。

不仅如此，有时候还不能过度的宣传自己在这些行业的职场工作经验，不然可能会被下家认为心术不正。

爱因斯坦说：我坚信，世界上的财富无法促进人类发展，即使它掌握在哪些仍想达到此目标的人手中也无济于事。金钱只能滋生人们的自私自利，并使其不能自持地加以滥用。

当然，当今时代终究是个世俗的世界。但追求金钱和Title所谓的看似有前途的工作，还是得建立道德和法律的基础上。

在外包公司有前途么？

外包公司的主要盈利点，其实是软件研发过程管理或者软件项目管理能力，一套优秀的软件项目管理流程体系，往往能够实现软件开发过程中的生产力最大化，进而为企业的发展带来巨大的利润。

在外包公司，主要的收入其实是来源于项目参与人员的人工费用，一般会采用“工料合同”的形式。这种合同又称为单价合同，一般会根据产品在研发过程中的实际投入或服务来计算合同总价。

当然，其实许多外包公司会采用这种方式来进行工作量的评估，然后再用总价合同的形式来签订合同，毕竟“工料合同”其实浮动空间很大，容易造成甲方的成本超支严重，而使用总价合同就可以将风险转嫁给乙方，对于甲方来说自然而然就实现了利益最大化了。

而总价合同的特点是应该明确设定需求、对功能的工作量评估都应该尽可能的科学，问题是，客户明白他想要什么么？大概率客户并不懂他想要什么，或者他以为他懂他想要什么，而且你以为你也懂他想要什么。于是陷入双方需求的拉锯战，软件的风险急剧提高，让苦逼的乙方程序员们成为砧板上的肉，被迫每天牺牲自己的时间，拿有限的生命投入到无穷无尽的需求大坑中。

而且有时候由于行业不同，还会陷入需求陷阱中，各行如隔山，客户想要的，往往与你能提供的，存在很大的差异。例如，连微软都会被武汉上诉，要求赔偿其在智慧城市项目中造成的大几千万损失，一般般的外包公司就更不用说了。

如果遇到这种情况，请勇敢的选择拒绝，或者使自己成为更专业的人。努力花更多的时间学习行业知识，然后用数据或阶段性成果让客户尽可能的无话可说吧。

当然并非所有的外包公司都是这种情况，例如像SAP或者Thoughtworks，其实也可以被世俗的理解为外包公司，他们也是为客户提供外包服务，但是由于他们是行业内的领先者，能够为客户需求提供更加专业的建议，所以他们有资格找客户签署“工料合同”。

例如一个SAP的服务工程师，从上飞机起就开始计算工时费用，每天动辄万元的服务费，服务工程师的工资自然而然也低不到哪里去了。我一位同事他哥哥就是从事SAP的外包服务，他说他哥哥每年只上半年班，工资超过3万一个月。。。嗯,好吧，这种外包就等同于有前途。

依然有许多公司会走在签署总价合同的外包公司的道路上，毕竟企业生存是第一要务，万一哪天接到一个合适的项目，让公司能够顺利的摆脱外包公司的这块皮，进入细分市场，获得进一步的生机呢？

不过大部分外包公司或许其实并没有那么好的命，而且还会由于内卷化（指优秀员工逐渐流失，而新人难以加入，最后被中庸的老员工主宰企业的命运）最终越来越丧失竞争力，并最终只能凉凉。而且缺乏核心主业的外包公司确实很难获得技能上的积累，这需要开发者能够提高自己的技术学习能力，努力使自己成为最专业的工程师。

做增删改查有前途么？

许多开发者都吐槽，每天的工作都是CRUD，也有许多开发者经常吐槽身边的那些开发者没前途，只会增删改查。

怎么觉得这个问题为啥这么魔性呢？难道你和他们不是同一拨人么？

有时候还会看到有人吐槽，说每天都在做CRUD的业务开发，感觉自己人都要玩废了。还问我怎么想。

我个人认为CRUD才是公司业务的常态，只有能够把CRUD玩得非常好，公司业务才能获得更快的发展。从表面上看，CRUD工程师的主要职责就是建表、封装接口、然后让接口输出数据符合客户端需求。实际上这里面依然牵涉到许多充满技术含量的东西。

例如，该如何建表呢？从海量的用户需求中，分析出与系统息息相关的核心部分，并分析出符合用户需求的核心领域，这种业务分析与设计能力是一位软件工程师非常重要的核心技能。

例如，以前都是撸sql，现在都用orm了，是不是觉得很香？增删改查一样也充满了期待啊。

该怎么建表，也并非想象中那么简单。例如主键是用自增序列，还是用UUID，该怎么设计索引，如何设计缓存，如何运用分表分库策略？这些看起来很简单的东西，往往并不简单。

除此之外，代码的质量本身，也是一件值得深入钻研的方面，例如《代码整洁之道》和《重构改善既有代码的艺术》这两本书就专门介绍了如何写代码和如何把代码写好。这也是一件看起来简单，却并不简单的事情。

除此之外，沟通技能、架构能力、风险意识，也都会在这些CRUD的开发过程中得以体现。

为什么总是会认为CRUD毫无挑战呢。如果你已经成为软件开发领域的大牛，请收下我的膝盖，否则大概率是因为你已经走在了云程序员的路上，把一切问题都想象得太简单了吧。

突然想起之前看的的一张段子，说火箭其实没什么技术含量，因为中国古时候早就有了。还有之前看的郭德纲的段子，他说：如果我跟一位火箭工程师讨论火箭的燃料不应该用氢氧，应该烧煤，对方正眼看了我一眼，那就是我输。

嗯，云程序员们，咱们离专业开发者还有不少差距啊！

# 总结

回到主题：在外包公司做增删改查有前途么？

1. 在外包公司也好，非外包公司也好，努力使自己成为专业的人，都会有前途。
2. 不管在哪家公司，如果你觉得不开心可以离去；但是如果留下来了，请珍惜每一段时光，上帝既会给你关门，也往往会给你开一扇窗户，只要用心去发现，你总会有所收获。
3. 其实认真干好每一件事情，都会充满前途。如果过于敏感，总觉得干这个没前途，干那个没前途，那大概你应该去选择创业。那里你可以找到属于你的好归宿。
4. IT的职场的时光说漫长也漫长，说短暂也短暂。干得好就是四十年，干得不好，就是五年。
5. 或许每个人都有机会花五年时间成为技术总监，但是却只有少数人，能够成为真正合格的工程师。