技术从业者的未来（二）

　　前言

　　新的一年，在暂时没有工作以及家庭的双重羁绊的这个周末给自己放了一天假，这样的时间尤属难得。　　

　　我在《致所有.Net者和有梦想的朋友们 - 共勉》这篇文章中提到过，在如今的工作生活不分家的快速节奏中，为了生活和家庭，我们必须负重前行，即使每天的时间大部分都给了工作以及家庭，但是我们还是要定期给自己清理负面情绪以及释放压力，因为只有自己能持续成长，才能更好的抵御年龄所带来的危机。　　

　　所以，对于职场人来说，成长永远应该放在第一位，关注自己的心态以及需求，这就需要给自己时间和空间思考，给自己喘息思考的时间，才能更好的看清楚方向，才能更好的厉行自己的梦想。　　

　　说话即生产力 　　

　　对于大部分技术人员来说，可能我们都不会注重自己的说话，因为我们很多人都没有意识到说话所产生的生产力。

　　为什么说话就是生产力？

　　不知大家有没发现，跟身边一些思想层次很高的人谈话会非常舒畅，因为这些人能快速的洞悉到问题的本质，一语中的，把问题回归到本质上，而不是任由别人天马行空说到哪就是哪。　　

　　举个例子，如果你是CEO，你希望自己重要的话语能被即刻理解和付诸行动吗？是的，所以你希望的是说话即是生产力。

　　再换个场景，如果一个管理者说话没有突出重点，而是内容或思路比较零散，你会打心底认可这个管理者吗？下属的执行力会强吗？

　　所以好的说话，就是生产力，能够产生很多积极作用。

　　说话其实就是一场看不见的硝烟。大多数人在讲话的过程中，内容或思路比较零散，讲到了这点又忘记了那点，说到了后面前面的话又重复说了一遍，而且还夹杂着大量的口头禅，势必不会带来可观的影响力。

　　一个显而易见的例子是，在会议上，我们较多的人会把话题越拉越远，就像脱缰野马，以致完全脱离主题，久而久之，给人的印象就是，你说的话中，有意义的并不多，可参考度低。这无形中是在降低自己的影响力。

　　展现过人的说话水平，不仅是个人魅力的展现，更是影响他人与事业发展的重要技能之一。

　　如何提高自己的说话

　　我们可能会发现，越是高职位的人，可能说话越是精简，字里行间都是重点。同时他们在公司也更加具有影响力，因此他们的职业或事业发展也更加顺风顺水。

　　因为他们注重说话所带来的生产力，即注重当前说话的中心以及探讨问题的重点是什么，针对明确的重点，发言流利顺畅，使内容清晰有次序。

　　一种显而易见的提高方式是，首先在心里要暗示把自己放在重要的位置上，希望自己的说话能产生生产力，那么自然而然你就会注重自己的说话，就会在说话前进行一定的逻辑梳理，使自己的表述清晰有序。

　　所以一切的东西，都是在于你把自己的一个定位在哪。你在意自己说话是否可以产生生产力，那么你就要把时刻把自己放在高的立场上，注重自己说话。

 　　

　　像CEO一样思考

　　公司最近有这样的培训，遗憾的是个人由于生病错过了，但我能想象得到，核心思想是：把自己的思想层次提高，再提高！

　　你想拥有管理者一样的工作生活方式，那么你就要像管理者一样的思考，思考什么？换位思考，如果换成你来做，你是怎么规划的，你会怎么在执行过程中采用哪些手段来降低失败的可能性的，换言之，你会不会做得更好？

　　不要以为这些很遥远，没有培养这样的意识的人，是很难做到量变引起质变的。

　　我们很多做技术的人，关注的基本都是技术层面所带来的自我成就感，但是如果你想让自己前进一大步，是需要在思想层面做改变了。

　　从企业的角度出发

　　我不是在画饼，也不需要画饼，因为我们没有直接的利益关系，但是对于有缘的朋友，我还是强烈推荐的是，任何事情的出发点，都站在企业的角度去思考。

　　我明白在很多人的心里认为，自己永远都是打工者。拿人钱财，替人消灾，做到跟工资相符的价值出来就可以了，甚至能低于这个收入的价值都行，反正公司又不是我的。

　　短期来说，这是对的。然而对于我们整个职业生涯来说，这是不利的，因为这样做只会让我们贬值，而不会让我们升值，还会固化了我们打工人的心态。

　　站在企业的角度看问题能给我们带来什么？

　　首先这样能培养自己的更高层次的思想维度，这些思维习惯的培养和积累，会促使我们做事的方法论和眼光持续成长，继而会给我们带来一种工作本能，成为自己的一种优势工作思维和技能，使得自己越来越值钱。

　　—个人的价值在上升，在于你的优秀习惯越来越多，而同时借助于更高的思维格局、技能和经验，在面对各种困难时心中不慌，从容应对，作出正确的决策以及有效的执行计划。

　　其次，没有这样的思想积累，是很难让自己的思想有质的改变，继而是很难为我们后续走到高职位铺路的。

　　你想做老板，翘着二郎腿抱着秘书，听着工作汇报，没问题的，那么你有什么可以支持起你老板的位置？　　

　　我们的目标是什么？让自己变得更好！只有站在老板的角度看待企业，才是让自己成长最快的角度。

　　所以我建议朋友们站在更高的层次去看待问题，即使我们不能即可站在企业的角度出发，但我们还是可以比现有的角度更高一点，就是这种高一点的思想，会给我们职业生涯慢慢带来质变的。

　　关注产品

　　只关注技术所带来的成就感，是技术人的通病，而可能就是过于专注在技术层面，让很多技术人忽视了产品这个层面。　

　　这个层面对于我们技术人来说，意义何在呢？

　　体现技术价值的，是将技术转化为生产力的产品本身。产品其实是各种技术解决方案的集合体，它映射的是，对通用问题的解决模式。如果你是有意在某个行业持续发展成为领域专家的话，那这些模式的积累以及深入，绝对会让你身价不菲。

　　所以关注产品本身，对于技术人员的职业素质的提高是大有裨益的，也是对在职业生涯上有意成为领域专家的重要步伐。

　　技术再好，做出来的产品不能很好的解决用户的痛点，市场是不会买单的，这无疑是对我们技术的一个最大否定。

　　要知道，除非你是在做着自己的专利技术，且这些技术就是公司的生产力，否则技术都是为你的产品业务服务的。　　

　　而且在关注产品的同时，你会发现，自己作为用户的话，基于对技术的追求，免不了会想让客户在使用层面具备极致体验模式，那么产品的体验这部分就会让你的技术价值更加得到验证。你要给客户极致体验，就促使你使用websocket，使用缓存，使用高可用方案来支撑。

　　所以如果你真是一个技术追求者，那么你必须重视你的产品本身，因为这是对技术的一个最好验证。

　　关注需求本身

　　关注产品，其实就是关注需求本身。

　　我们很多技术人员，在做需求的时候，可能仅仅看到需求表面的东西，接到需求就着手编写代码，这样其实是不利于自己的思维培养的。

　　做一个需求，虽然不一定要像CEO以及产品经理那样深刻了解这个功能给客户带来什么价值，但至少知道这个需求是否是某一类问题中的一个，这类问题的常用解决方案是什么，这个需求所要传达的信息，如何能更好的传递给用户？

　　磨刀不误砍柴工，在深入发掘需求本身的同时，会引导我们针对该需求衍生出一类问题的解决方案，在基于这样的解决方案，对于再次过来类似的需求，是可以帮助我们避免做另一套类似的方案来实现的。

　　说到这里，我强烈推荐的是，不要做一个需求直译机，我们需要发现客户的需求，是真需求还是伪需求，继而深入发掘客户真正需要的是什么，抽象出来，作为一类问题的通用解决方案。　　

　　关注客户

　　嗯这个层面对于技术人来说，视乎有点风牛马不相干了。

　　但是如果你注重自己的技术带来的成就感，那为什么不重视你的技术价值最终验证者的反馈呢？

　　产品给公司带来收益，也承载着我们的技术能力，产品的价值，也就是我们技术人关注的所谓技术成就感，是要通过客户验证的。换言之，客户认可了我们的产品，我们的技术才真正产生价值。

　　站在更高的层次看一下这个命题，当我们关注客户后，就会引申出：产品在前期是如何推广进而吸引用户的？ 如何运营留住用户的？在用户的这些反馈数据之上，我们是如何分析并优化产品的？

　　好吧，说到这里，引申出一堆可能在实际工作中跟开发工作不相及的观点，然而我知道，对于有心在自己职业生涯勇攀高峰的人，这些思维的培养，将会对你的职业生涯产生非常重要的影响。

　　君不见管理层乃至CxO，更多的关注点都是在客户身上，关注如何提升用户的满意度等等，而这些的最后，才是考虑使用什么技术服务于这些。 

　　

　　关注客户以及产品这两个层面，才会使自己的视野越来越开阔，也会为自己的职业带来更多资源。

　　提高自己的眼界

　　不管你走向哪个岗位，例如架构师亦或技术管理乃至技术总监或者CTO/CEO，开拓的视野是职业中非常重要的一环。　　

　　当你在三楼时，你能看到可能就是眼前的垃圾堆，但是当你在三十楼时，你就能看到城市的不同风景。但是如果我们不会在爬上三十楼之前，基于每一层的风景对自己的眼界进行开阔，有可能到了三十楼，你眼中还是只是看到这个垃圾堆。

　　培养CEO一样的思考，不一定会给我们带来即刻的自我增值，但是具备了高阶的眼界之后，就会帮助你在多个场合即刻脱颖而出。  

　　遗憾的是，很多技术人员，可能会更关注眼前的风景，更多的可能连头都不抬。

　　当我们埋头默默耕耘的时候，也要时不时抬头看天。

　　就像上面说的一样，关注客户和产品，让自己的眼界不局限于技术，对比自己产品在市场上的竞争力如何，其他竞品的优势以及劣势，产品如何盈利，对手的商业模式是怎样的，让自己从更宏观的角度看待这个产品的生命力。　　

　　眼界的开拓，让我们具备更多的选择以及做出更好的抉择，合理的让技术为我们服务，这样才会在问题的解决方案上进行更好的抉择。

　　你要知道业界内的解决方案有什么？基于什么情况下选择不同的解决方案？这些都需要你有这样的眼界。

　　当你准备创业或者到了高级别的职位，你就会知道，团队的组建，产品的运营模式，市场的推广方式，流量的流转控制，核心竞争力的建立，这些光景所让人提高的眼界层面，是不同于技术层面所带来的。

 　　未来方向

　　我在《技术从业者的未来》这篇文章中，分享了一些个人的职业感悟，时代发展的太快，技术更新换代的太快，除了面对着家庭以及工作外，在如此高速的科学技术发展洪流中，我们还要保持不断的自我进步，所以我们技术人更加需要明确自己未来的方向是什么。　　

　　基础技术能力　　　　　　

　　曾几何时我认为，走到了管理岗位，技术将不会显得那么重要。

　　在真正做了技术管理之后，发现技术的重要程度并没有减弱。因为我们需要做的技术决策更多了，这些决策是否会成功，就是建立在技术能力基础之上的。　　

　　我们需要扎实的基本功，而这个基本功并不仅仅是熟知面向对象编程即可，还需要计算机原理，网络，部署，算法，设计模式等等。

　　而且在云生态发展迅速的时代，越来越多的企业现在或者未来都会上云，基于云上的技术能力，将也是当今时代的技术人应该掌握的基础技术。

　　当我们决定在技术路线继续走下去时，我们就不能忽视这些基础能力的积累。

　　抽象能力

　　好的设计就是基于抽象能力抽象出本质，让抽象满足更多通用的场景。

　　这里举个例子，我们使用过高德地图App都知道，里面是可以查询车辆的具体到站信息的。比如我每天到公司有两条路线的公交A,B可选，某天我坐了A，但是我到站下车时想知道B车到了哪里。

　　于是作为产品就会很容提出这样的需求：在地图中我要知道坐A车到站时，B车到了哪里。

　　作为开发者，很容易想到给车做一个标记功能，这样就很容易对比车辆的位置，于是乎就往下做了。其实我们往深点想，如果期间用户退出了地图再重新进来的时候，我们如何找到”有状态的“这两辆车？于是乎又想到可以通过个人的账号信息进行关联，标记的车辆可以绑定到个人的相关信息里面。这里面又带来了问题，这样的话就会要求客户强制进行注册，而我们目前的很多地图是没有要求用户注册才能使用。

　　当我们做到这一步的时候，就体现出我们的抽象能力是不够的，可能就会出现我上面说的需求直译机，而这样是对我们的职业生涯没有任何帮助的。

　　产品直接的需求是能对比功能，试想如果我们地图上提供对车辆的一些基本信息例如车牌号，再借助GPS的能力，这样是否就能具备区分Ａ和Ｂ车辆的能力了呢？而且基于这样的能力，我们还能拓展其他的能力，譬如有两辆车靠近的时候，通过公交的基本信息告诉好友自己在哪辆车上。

　　你的抽象程度越高，复用能力就越宽。

　　Devops　　　　　　　

　　试想一下，当我们需要给公司开发一款新产品，从需求到这款产品最终上线到客户手里，我们软件开发者具体做了些什么？

　　我相信大家都会清晰地知道，软件最终能到达用户的手中，有两个层面的事情是不可或缺的：

1. 应用服务开发层面(功能性需求)
2. 部署上线落地层面(非功能性需求) 

　　实际的工作场景中，我们很大部分的人都只是专注在这两个层面中某一块，鉴于工作的内容性质， 运维工程师和开发工程师有着完全不同的思维逻辑。

　　所以在这种情况下，Dev和Ops之间是割裂的状态。

　　那么Devops能给我们带来什么？

　　我们先看一下什么是DevOps？

　　传统的软件开发流程是这样的

 　　而DevOps是这样的

 　　

　　DevOps 是字面上 Dev 开发 / Ops 运维两者组合，是一种重视"软件开发人员(Dev)"和"IT 运维技术人员(Ops)"之间沟通合作的文化、运动或惯例，实际上它是一种文化 + 愿景 + 方法的统称。

　　DevOps 强调的是高效组织团队（文化）之间如何通过自动化的工具协作和沟通（方法）来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件（愿景）　　

　　我们为什么需要DevOps？　　

　　当我们面对快速发展的互联网行业，稍纵即逝的商机，业务需要快速迭代，不断试错，更快地交付产品和服务是我们所有公司赖以生存的条件，也是我们所有公司的愿景。

　　因此，在这样的愿景下，用科学的方法学来指导企业通过快速的对应，迅速地部署，实现了一流的稳定性/可靠性/安全性的系统服务，让企业拥有持续交付的能力。　　

　　在这里，跨职能的团队的合作并不仅仅是为了实现用户要求的功能，他们保障的是：快速的对应在整个价值流中不会带来对内或者对外的混乱和困扰。

　　DevOps打破原来的开发和运维之间的界限，将分离的两个流程融合到了应用的研发过程中。通过自动化"软件交付"和"架构变更"的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。这些改变的目的是为了支持和适应应用快速、安全、可持续和频繁的版本发布。

　　我们如何实践DevOps?　　　　　　

　　文化

　　首先DevOps是一种文化的背景下，文化的推行，肯定要涉及到思维的转变。

　　DevOps并不是简单的在组织机构上把开发团队和运维团队合并起来，我们上面提到它包含着思想，所以在思想层面上，需要企业文化和思想观念的变革。

　　那么想要将DevOps真正落地，第一点就是思想改革。不仅是运维的思想要变，开发也要变。员工要变，领导更要变。

　　DevOps并不仅仅是组织架构变革，更是企业文化和思想观念的变革。如果不能改变观念，即使将员工放在一起，也不会产生火花。

　　方法

　　想要充分落地DevOps，离不开工程和平台的支持。

　　在更快的交付愿景下，映射出来的是在整个产品交付环节的效率提升的，所以我们将在效率工程上进行效率提升。

• 开发效率

　　在这里引入了敏捷开发，敏捷开发大幅提高了开发团队的工作效率，让开发专注于每个迭代内需交付的最小闭环功能，让版本的更新速度变得更快。

• 测试效率

　　当开发团队的效率提升后，不可避免的需同步提升测试效率。而自动化测试流程将会在DevOps设置的上下文中起作用，而且这还将需要持续测试（CT）。

　　如果没有持续测试，也就不能对持续集成进行及时验证，自然就无法做到有效的持续交付。

　　自动化测试是一项艰巨的技术活动，如果没有有效实施，它就有能力破坏总体的DevOps策略。

　　虽然在持续集成中要尽可能的使用自动化测试，但是难以避免有些情况是自动化测试难以覆盖。所以手工测试还是必不可少的，但是在测试团队的持续改进中必须将手工测试尽可能的优化，不能让其成为自动化测试的瓶颈。

• 部署效率

　　减少部署层面的重复性和出错可能性，自动化手段是必不可少的，所以我们需要提供基础设施平台的支撑，其中包括我们耳熟能详的术语：CICD，观测面板，容器化（虚拟化），编排工具，服务网格等，其中CICD是DevOps的基础核心，没有CICD自动化的工具和流程，DevOps是没有意义的。

　　在我们上面做了这些效率工程之后，我们的将会大大缩短产品上市以及换代的时间，这就是我们DevOps的愿景。

 

　　在有了基础支撑之后，很重要的一点是， 我们的工作是有交互的。

　　在DevOps的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案来支撑自动化和研发工作。

　　而开发人员也会在运维的初期参与到系统部署中，了解部署架构以及基础设施平台是如何运转的，在资源管理、监控、网络、安全等方面提供系统部署的优化建议。　　

　　在这期间，自动化测试工程师和开发工程师一起基于场景以创建测试脚本，并在产品经理的帮助下扩大其测试范围，并且在基础设施平台集成这些代码和脚本作为持续测试的基础。

　　后记

　　在这不容易的过去一年中，如果你的2020年是平安美好的，那我们应该感谢自己以及家人和朋友，如果你的2020没有那么美好，那么让我们忘掉这段记忆，在2021年重新启航。

　　其实不管在哪个行业，如果你许诺了给自己或者家人一个美好的未来，那么我们都将需好好规划这个未来，而这个未来，我相信，并不会轻易就达成，所以我们在这之前一定要先自醒，清晰自己的方向，不能了解自己真实的状况，就不会找到有效的办法去改变现状。

　　让我们继续加油！