技术工程师成长之其中一道

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了技术工程师成长之其中一道，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含16512字，纯文字阅读大概需要24分钟。

内容图文

一、找准兴趣点：认识自己

作为新手程序猿，首先要清楚的认识到，从什么开始做起，才能让自己觉得， 工作，是一件非常开心的事情！

作为技术工程师，能选择作为职业方向的也不少，比如：

• Web前端工程师（也称FE，有的公司分的更细，比如Html/Css工程师、Javascript工程师等）
• 后端工程师（也称RD，诸如：PHP工程师、Java工程师等等）
• 客户端工程师（较多公司也将其归为RD，诸如：iOS工程师、Android工程师等）
• 数据分析与挖掘（一些公司叫做BI或DI，平时产品业务会少一些，主要做一些大数据分析和处理，C或者Shell等脚本用的会多些）
• 测试工程师（也称QA，主要负责各种产品功能的白盒/黑盒测试，发现其中潜在的Bug，即质量检测）
• 数据库工程师（也称DBA，属线上运维工程师的一种，不过是着重负责各种数据库的管理）
• 运维工程师（也称OP，主要负责各种开发、测试、线上环境的运维，对线上服务稳定性提供保障；也是命令行用的最多的一个角色）

每一种角色，平时的工作状态必然都是不一样的，通过写码得到的成就感也是不一样的。

作为一个新码农，如果你希望自己写的代码， 能最直观的变现成用户看得见摸得着的东西，因此而获得工作上的成就感，并且因此而爱上这份工作，那么选择Web前端工程师或者客户端工程师，定是较好的。

倘若你更希望每天通过命令行，在线上各个服务器之间跳来跳去，并且 敲一堆别人看不太懂的命令，写一堆别人看不太懂的脚本，并因此获得成就感，感觉更具有 高逼格，那么选择运维工程师，一定没错了！

一些刚毕业的学生，很有必要在投简历求职之前，搞明白自己想做什么；当然，也有大部分学生是通过校招进入到公司的，具体进去以后做什么，可能都是公司随机进行分配；对于这一部分的同学，如果在入职后一段时间内无法在工作上找到兴趣点，就真该考虑申请 transfer到其他Team了。

工作不应该仅仅是是挣钱养家糊口的一个工具，更应该是做人做事、成长道路上的一种乐趣。做自己喜欢的事情，再辛苦，也值得（切莫误解：不是推荐大家加班，哈哈）。

二、注重沉淀：充实自己

沉淀，是能最直接证明自己有收获的一种方式，可以是文档沉淀、技术沉淀，等等

工作过程中，我们肯定会去做一些技术调研、方案分析与评审，这些东西便可以细细整理成文档，统一汇总到一个地方（比如团队的wiki专栏下），自己能去review，组里其他同学也能查看到。

在一些大项目开展过程中，或多或少会针对某一类问题创造出比较优越的解决方案，可能是一种高性能的实现方式、也可能是一种高效率的调试技巧，这些东西，稍微花点心思，都能将其作为一个类库或工具提供给组内其他同学，以此作为技术点，沉淀下来。

简单来说，可以把握这样一个原则：

• 能用 文字记录的做事方式方法，就一定不要只靠口口相传！用嘴巴传来传去，慢慢的也就走了形了，俗话说的好，好记性不如烂笔头！

• 好用且实用的技术实现方式，能抽取成 组件或类库的，就尽量让它最大限度的复用起来，并伴之以尽量详细的使用文档！切莫针对类似的功能，在组内还不停的造轮子！

• 多看多写多调研（有时候需要以玩儿的心态去学习）；但做技术的，若无实际产出，那只叫瞎折腾，知其然而不知其所以然，效果并不佳

就我个人而言，无论是在 百度，还是 美丽说，所有我能够去沉淀或者帮助大家一起去沉淀的东西，一定都不会放过。

如 文档方面，我们搭建了团队专属了文档平台，有项目设计与实现方案的评审文档、有项目总结的分享文档、有大型项目的排期节奏跟进文档、有技术的调研文档、有团队技术分享的文档、更有团队周报的归档专栏等等。

在 技术方面，有符合团队开发规范的集成解决方案、编译工具、开发工具、前后端线上服务监控与报警系统、后端服务性能监控与分析平台等等。

在 玩儿技术的这一点，比如 Web前端助手(FeHelper)就是在百度做前端的时候，玩儿Chrome扩展，一步步沉淀下来的。记得当时CSDN还举办了一个Chrome浏览器插件开发中国区大赛，这FeHelper也迷迷糊糊拿了个三等奖。

再后来微信公众号兴起，在朋友圈铺天盖地的转发都是只有一个标题，很土；正碰上那一段时间 2048小游戏在PC和Wap上特别火，于是我也写了一个放到自己公众号，本着让大家一起能够在微信里玩儿起来的心态，于是搞了一套基于微信公众号分享的SDK，应用到这个小游戏里；这就是大家后来一直在使用的 WeixinApi。在微信一直没有推出官方版的js-sdk之前， WeixinApi造福了许多人。

任何形式能让别人看得见摸得着的东西，才叫做沉淀，更是可以用来衡量价值的参考。

三、做一个项目负责人：历练自己

接受Leader的命令，并能单枪匹马的把产品功能做完上线，这顶多能够算得上 能做事，离 会做事、 懂做事还差得远

如果有一天你觉得自己能够独当一面去负责一个产品功能，不再需要导师和Leader的协助，那么，是时候从更全的维度去历练自己了： 主动挑起一个项目，作为项目负责人，将其推行到底！

你至少可以从这几个方面，得到更多的收获，找到更多的成就感：

• 分析需求，判断该项目需要涉及到的相关角色

• 组织各角色进行项目需求评审，并分析产品功能上的技术可行性、时间成本等

• 对需求进行功能模块合理拆分，落实前后端工程师的工作范围

• 组织前后端工程师进行技术方案评审，并结合需求指定的上线时间判断是否需要分优先级分批次开展

• 合理分工，产出研发排期，并汇总联调、自测、以及QA的测试工期，统一输出项目的排期

• 跟进项目进展，结合排期Review项目产出，及时发现风险点，及时调整并通报

• 较大的项目，更有必要组织定期的站立会，以确保项目整体进展顺利

• 项目过程中有临时新增需求、或需求变更、或技术实现方案调整，更要能条理清楚的与所有角色进行分析，放眼大局观，结合项目的整体上线要求，输出最终的调整方案，保证项目稳健开展

• 测试前期，需要和QA明确其中的核心测试点，对于技术实现较复杂的地方，需要明确告知测试的力度，以免测试用例覆盖不全

• 项目上线前，需要与运维工程师完成一切线上环境部署与配置，确保项目上线毫无障碍；对于涉及到边缘产品较多的项目，更需要考虑到灾备预案情况

• 项目完成测试后，如果是较大的产品需求，需要和产品同学讨论，是否进行公司内部体验，或者线上小流量（灰度）测试；并提供合理的问题反馈渠道，收集并整理用户反馈，快速优化

• 项目上线后，需要密切关注服务稳定性，关注用户反馈，稳定后，能进行项目上线通报

• 组织项目组所有角色进行项目总结，分析各角色在项目配合过程中出现的问题，总结经验教训；同样也记录项目中良好的问题处理方式，最后将项目总结分享到团队；以此结束整个项目！

枪打出头鸟，只要你是带头大哥，项目出现任何问题，Leader必然都会唯你是问，整个项目过程中，必然是会产生压力的！但是，如果你永远都不敢迈出这一步，又怎能知道自己能力究竟有多大呢？

所以，大胆去做吧，团队一定都是更喜欢 敢于主动挑起责任担子的人的！

四、做一个导师：学会育人

将所有成熟的工作方式，倾囊相授，也从新人身上做自我反省

优秀的做事方式，应该得到传播， 让更多的人花更少的时间去变得优秀。工作中，最好的方式，就是在自己成长以后，做一个导师，协助新人一起成长，比如：

• 结合新同学的工作能力、业务范围、技术兴趣点，一同分析Ta成长过程中真实存在的阻力（或盲点）

• 为新同学量身定制短期、中期、长期的成长规划，定期Review成长得失，及时纠偏

• 带着新同学一起去尝试一些大于Ta现阶段工作能力的事情（业务功能、技术Topic等），帮助新同学挑战自己，逐步突破自身的能力极限

• 学会放手，做好引导和后备支撑，让新同学完完整整的去搞定一件事；栽了跟斗也不要紧，任何人成长的过程中都应该经历一些坎坷；不经风雨，又怎见彩虹？

• 引导并督促新同学进行文档和技术各方面的沉淀，协助新同学在团队里找准自己的定位，站稳脚跟

• 引导新同学学会分享、学会与其他角色的沟通技巧、并逐渐学会把控项目的全局观

当然，你也需要从新人成长的过程中，不断的反思自己，新人做的不够好，是我的原因吗？新人做的很好，我有功吗？

• 新人某个功能没做好，是不是自己没有提前Review他的项目实现方案？或者自己给他的方案本身就是有问题的？

• 新人某个项目Delay很严重，是不是自己没有多去Review他项目的进展？或者自己也没搞明白项目的上线计划是什么？

• 新人某个项目Bug太多，是不是自己没有尽到一个导师的指责，为他做好Code Review？或者自己平时的项目就是Bug频出，新人只是效仿而已?

• 新人在其他角色面前总是沉默寡言，是不是自己没有告诉他，应当大胆表达自己的想法？或者自己也不敢在人前多说话，自己也怕被拍？

• 新人在与其他角色沟通过程中，冲突不断，是不是自己没有教给他更好的沟通方式？或者自己也不会与人沟通，自己也经常与其他角色闹得不愉快？

• 新人用一些很巧妙的方法把某件事情完成的很漂亮，得到大家的赞许，是不是自己给了他很好的引导？或者从这件事上面，你发现自己也有不如新同学的地方，你们需要互相学习？

• 新同学主动找你一对一沟通，进行成长总结，自我批评，这又是不是你平时的做事方式，让他学会了积极领悟？再或者，你需要思考自己是否具备这样的一个主动性，以及能够批评和自我批评？

• 你对你的新同学足够了解吗？你对自己足够了解吗？

一个好的导师，永远都不要担心 青会出于蓝而胜于蓝，因为这是好事，这是他的能力，更是你的本事！他若真能胜之于蓝，说明他足够优秀；我们要学会与优秀的人在一起，那样才能更快的成长。

五、密切关注行业动态：站得高才能看得远

技术的革新都是非常迅速的，我们绝不能仅靠项目上的产出来充实和提高自己；码农界聪明的人太多，必须把好的技术思想都吸收进来

逐渐的，需要将自己视作一个技术负责人。当然，若条件允许，可作为团队技术负责；若团队各方向划分较细，可作为某业务方向技术负责人。

多分析团队工作上遇到的一些技术难题，总结并归类，互联网行业发展至今，你所在团队遇到的绝大部分问题，在别的公司必然都经历过了。跳出来，想方法从各渠道了解发展较为成熟的公司、较成熟的技术Team都在用过什么样的方式来解决这一类的问题；虽然不能照搬照抄，但最起码能从中得到更多的启发。

新技术更新的很快，尤其在Web前端方面，不过多久就又出来一种新的解决方案。你应该作为一个技术痴迷者，密切关注行业的动态，看看人家都在搞什么，为什么会出现这么多新的框架、类库、工具等。举个例子，搞明白：

• 在没有 jQuery之前，大家用原生的DOM也能把功能开发的很好，那为什么会出来jQuery？它是为了解决什么样的问题而出现的？用它与不用它，在项目上会有什么不一样的地方？

• jQuery已经很好用了，那百度WebFE以前为什么还要在公司内部搞一个 Tangram？是单纯的造轮子，还是因为它的确可实现各种Api定制化打包？对于jQuery的老手，如果使用 Tangram，会有些什么不一样的地方？

• 后来大家又一致吹捧的 AngularJS、 Backbone.js、 Ember.js这些又是什么鬼？都是哪个公司哪个团队基于什么样的问题才造出来的？他们用这些工具只是因为某一个产品功能，还是说这货可作为一类通用的解决方案而存在？倘若要把它们引进到自己的项目组，是否真正适用？你能从中得到什么启发，大家又能学到什么？

• Nodejs为什么会出现？ io.js为什么又会作为其分支，单独发展？后来为什么又还是merge到了一起？

• 再比如跨平台的移动开发工具， PhoneGAP、 Titanuim、 Xamarin、以后今年火起来的 React Native，为什么解决同样问题的东西，会出来如此多，更新如此的快？最后出来的东西，是否都已经具备了 先辈的优良品质？它们所针对的用户群体是什么？为何能得到大众的青睐？它们和原生Native有何区别？

• PHP 7都发布了，为什么你们先上服务还在使用 PHP 5.3.29？升级PHP到最新版，在代码上是否需要做些兼容？开发上是否和以前有变化？带来的性能提升是否可大幅度减少服务器的数量？

• 全文的搜索引擎， Sphinx和 Solr都是啥？索引的效率、搜索的性能、对中文分词的支持、以及对实时索引的支持，这些维度都有什么不同？如果项目上需要使用，结合实际的需求，选择哪一个更为合适？

• 再比如，你的团队需要对线上服务进行多维度监控，市面上已经存在的 Zabbix、 Nagios、 Open TSDB、或者 Open Falcon，是否都知道这些东西能监控到那个层级？线上部署与应用的成本如何？后期的水平可扩展性又是如何？假如你要自己写一个，你能否先画出一张清晰的监控布局图？

总之，闲暇的时候，把技术眼界放宽些，多逛逛 Github，或者一些国内外牛人的 Blog，看看别人都遇到了什么问题，都在解决什么样的问题，多做一些假设： 如果这个问题是你遇到了，你会怎么做？

六、多思考多做事：多一些证明自我能力的机会

公司不是养老院，发你工资，你就必须创造价值。任何一份工作（一个产品功能、一个技术系统、一套开发规范、抑或一套工作流程）都必然有它的问题所在，多思考多分析，发现问题并解决问题，这样才能创造价值，我们也才能成长！

也许你所在的团队就好比一坨浆糊，一团糟，同事们都已懒得抱怨，只在乎工作能干完上线就成。也许你所在的团队一切都顺风顺水，同事们一团和气，工作之余有说有笑，开心的不得了，甚是满足。

但是，世上没有100分的人，必然也没有100分的团队；凡人皆有缺点，团队亦然。不要被乱七八糟的团队吓到，也不要觉得团队看起来太好了，便无从下手！

• 大家平时的开发方式是什么样的，是否都在重复的做一些体力劳动？如果是，是否可通过 开发一些工具来自动化完成？

• 如果每位同学都自成一套开发体系，这样的代码必然是很难维护的，团队里旧人去新人来，看着各式各样的代码，哪有不抱怨的理？在 开发流程和规范上必须要有统一的标准，推动并协助切实执行！

• 一个线上的技术系统，是不是都因为它是一个庞然大物，不敢轻易调整，所以对于新功能都是不断的打补丁？久而久之，团队里的每位同学必然都只知道补丁，而不知道它真正的功能，真正的工作原理！所以必须要迈出第一步 牵头去重新梳理、归置，将核心的部分独立出来，展现它应有的功能！并伴之以详尽的文档说明！

• 对于一个臃肿的业务系统，是不是大家都因为已经习惯了现在的开发、测试、部署等方式，所以不愿意去 做纵向拆分？如果这样的一个系统已经拖慢了工作效率，那就必须动手梳理整治，让它变成多个功能独立的子系统，小而美，业务分明，项目之间更不易产生冲突，可维护性也能大大提高！同时推动团队给每个子系统安排不同的owner！

• 如果以上技术团队本身的问题不存在，则可以从产品功能的线上服务稳定性着手考虑。线上是否有频繁的报警？各业务日志是否都正常？用户是否对某些常用功能有频繁的反馈或吐槽？总之，能用工具自动监控报警的，就一定不要用体力解决。能够通过工具平台让运营或产品同学自助查询问题原因的，就一定不要再让研发手工去操作。

只要愿意静下心来，从细小的点着手开始分析，发现问题，并利用一切可利用的资源，推动去解决它，不怕事小，只要一件件逐渐积累下来，定能体现出自己的价值，老板们要的就是： 因为有你，所以团队变得更好！然而，你这样的收获，是无法简简单单只用金钱就可衡量的，更是别人拿不去的财富。

七、带一个团队：规范化流程化

当然，这也不是每个人都有这样的机会能被提升为Team Leader；工作上可没有裙带关系，哥儿俩感情好就把团队也交给你；必须是你平时的工作已经能充分证明，你具备了带领这个Team一起发展的能力！

当然，在我看来，更重要的是做事，而不是在行政位置上的那个Title；只要你现在正在做的事情，就是带一个团队，至于是否是经理职称，根本不重要。有时候一个小公司的技术总监，到了大公司，也得老老实实的做一线研发，不是吗。你若真牛逼，公司又亏待你了，你走了，那只能是公司的损失。所以，还是老老实实的做事吧，该来的自然会来。

作为一个业务&技术团队的管理者，至少需要做这些事情：

• 按照团队所负责的各业务进行清晰地规划， 切莫吃大锅饭，还是小团队作业的好；一支精锐的部队，责任感会更强，每个人会更清楚自己要做什么。

• 每条业务线， 需求范围明确，跨部门的需求，必定要有清晰的界限，保证组内各Team的工作能更顺利开展

• 组内各小Team必须有 统一的开发规范，攘外必先安内，如果自己Team内部的开发规范都一团糟，提供给第三方部门的接口还如何统一？

• 组内各小Team必须有 统一的项目全流程，在每个环节都应该注重实实在在的产出（沉淀）

• 组内需要沉淀公共的组件库、类库、公共服务层，它必将形成一个团队的主心骨，绝大部分的开发工作都能围绕着它转。如果有一个需求，团队里任何人 不需要思考，直接就能完成，那就够了。

八、团队培养与发展：健康并可持续发展

一个大于10人的团队，必须考虑有效的梯队建设，各方向的业务&技术负责人培养

• 在各业务方向上培养小组负责人，并让该负责人培养自己的Backup

• 在团队内培养技术方向负责人，源源不断在团队内输出更多可供选择的技术方案

• 团队内形成良好的导师制度，Leader带方向负责人，方向负责人带一线研发；同时也需要将梯队扁平化，打造一个无障碍的沟通和汇报机制

• 有团队周例会制度，每周至少保证有一次机会，能让大家聚集在一起，知晓团队过去一周的项目整体状况，以及下周的工作节奏

• 团队内部必须形成良好的技术分享机制，至少每周一次，可以是大型项目的技术实现方案分享与评审、可以是大型项目的项目总结分享、可以是项目上某技术点的深入分析与应用介绍、可以是某工具平台的构建思路或工作原理分析、可以是工作中必备小技能（奇淫技巧）的发散讨论、也可以是行业前沿技术的调研报告分析、也可以是一些新技术的尝后感、更可以是跨团队甚至跨公司的技术交流。总之，需要让大家切实感受到：在这个团队，有东西可做，有东西可学！

• 与同学们进行不定期的一对一沟通，助其排忧解难，有问题也要直接指出来，并授之以渔！帮助同学们成长，这是做导师做Leader的职责！

• 明确合理的奖惩原则，公司不养闲人，也不养不长进的人；与优秀的人一起，团队才能健康可持续的发展

• 不定期进行团队建设（Team Building），可大可小，需要创造一些条件，能够让大家能够聚在一起，讨论一些工作之外的东西。身心愉悦了，哪还怕代码写不好？

做Leader的，无论哪个Level，就应该想着：你何时才能把自己现在正在做的这些事情，都交给自己的Backup？

只有你自己能完全从团队现在的事情上抽离出来了，你才有机会去考虑对团队来说，更多更重要的事情，这是给Backup的机会，也是给自己的机会。

九、学习一些其他的技术：跨界、全栈

俗话说，技多不压身，用更多的技术知识来武装自己，真有一天要上一个陌生的战场，那也完全不在怕的。

当然，技术工程师成长过程中，全栈并不是必须要走的一条路，不过在深入掌握其中一门技术以后，眼界看得更开些，总是好事。

假设你是做前端的，一个前端Team能完全Hold住了，可以逐渐涉入后端，服务端、客户端，做事的方式其实都一样。不用花心思再去把每一门技术都重新学一遍，只要把该领域内的核心技术摸熟了、其中的工作原理掌握了、与其他领域的区别搞明白了，就够了。

如果自身能力有限，领域，精一门儿足以，用同样的做事方式，融会贯通，其他的技术领域必定不会太难。

回想自己工作的这么几年，先做 Java，再做 VB.Net、在做 C#.NET、接着再做 Web前端，一做就是三年；后来又学 iOS、再转 Android；回过头来又继续带 Web前端Team、再带 PHP后端Team；说实在的，方法对了，事情也就好办了。

内容总结

以上是互联网集市为您收集整理的技术工程师成长之其中一道全部内容，希望文章能够帮你解决技术工程师成长之其中一道所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端