实习概述
按照我校软件工程专业培养计划，学生需要通过实习提高自己对社会的认知能力，学以致用，更好地适应社会的发展及毕业后的就业。
依照学校的指导方针，本人在今年四月份参加了腾讯暑期实习生校招流程并顺利通过终面，最终在八月份来到深圳进入腾讯公司进行实习。我在腾讯实习的岗位是“后台开发”，归属于腾讯PCG事业部的微视后台开发团队。腾讯 是一家以互联网为基础的科技与文化公司。 我们的使命是 “通过互联网服务提升人类生活品质”。 关于我个人对公司的观察与看法将在其他章节中描述。
作为校招实习生的任务相对简单，我在团队中主要负责与“用户信息触达”相关的开发工作。用户在进入APP或活动后需要将用户信息下发至APP以提高用户用户留存与活动的转化率，并且不能在用户正常使用APP时打扰用户的使用体验。因此如何在有限的时机与时间内将不同渠道的信息综合并推送给用户是该项工作的难点。用户信息触达承载了产品活动的大部分内容，是产品活动能否推动用户大盘上涨、提高业务转化率的关键工作。（我也不知道为啥大佬把这么重要的工作丢给我了）
工作总结
在腾讯实习的三个月，我对团队业务的了解与介入是逐步进行的，起初我负责的工作是将其他服务从“C++”、“PHP”等编程语言改造为以Golang为语言的微服务模块，改造是在重写的基础上需要补足对未来服务发展的需求。在刚刚进入腾讯实习时，我以为这些工作的内容没有什么难度与挑战，都是简简单单的循规蹈矩按部就班，但是随着业务的展开与需求的加入，模块设计的难度越来越高。此时各方需求对后台开发的通用性和可复用性都提出了较高的需求。
WNS服务改造
作为新人进入团队，这是第一个需要我完成的项目，这个项目的完成也帮助我了解了微视后台的服务结构。该服务主要的功能是在后台起到“指南针”作用的模块。
从服务名称上我们就可看出，该服务是“WeiSee+DNS=WNS”，其重要功能也如同DNS服务一般。微视的服务在多数场景下是C/S结构的服务，在B/S场景下也是前后分离的数据交互模式，因此数据在前后流动时需要依赖路由对数据的去向进行分发，WNS模块就是后台数据分发的核心模块，当前端数据到达后端时，该模块将负责记录数据日志以及服务流量分流的工资。可以说WNS是后台业务模型上是最大的、第一级的代理层，该层的出现将前后端的数据路由完全解耦，使得后台业务可以以微服务的方式进行自由组合。同时在该代理层上的日志与用户画像等通用能力也能帮助其他模块的开发实现高效率的代码调试与异常监控。
WNS不是网络结构上的均衡负载，而是业务层面上的软路由。当网络请求进入后台后，将由均衡负载服务器分发到具有业务路由能力的WNS模块集群。WNS模块根据前端命令字与其他参数信息选择合适的后台服务，之后服务将会被转发到具体的模块。那么数据是否该被转发，转发时又是否需要依赖版本、IP、地理位置等信息而有所差异，这些都是Proxy层所需要考虑的事情。
同时Proxy层必须十分高效，用户的网络请求平均需要在2-3s内完成。因此Proxy层的响应速度一定不能影响业务的处理时间，通常应该在15ms-20ms内完成处理并转发，记录日志等操作需要通过异步请求的方式完成。因为服务是全局数据的入口，因此还要保证服务的高可用，每次的服务更新与发布一定是无损的发布。如果出现了什么偏差，那可能就是四级或者五级事故了。
虽然这层服务这么牛逼，但是我做的工作却很微小。我只是将其中的数据拦截功能进行了改造。当请求在查找对应的服务时，需要根据多个维度的信息过滤与分流，我所完成的就是数据的过滤部分。以Cache的方式缓存配置并按照以往的规则完成过滤即可实现功能。
PSF服务改造
在第一项任务完成之后，新的需求确定之前。导师安排了一项技术性服务改造任务，需要将服务从PHP环境改造为Golang。该服务的功能是负责过滤和清洗用户的文字信息，包含但不仅限于昵称、评论、账号名等。
众所周知，互联网不是法外之地，因此维持一个纯净健康的网络环境是各个IT公司都需要重视的工作。在腾讯的业务机制中，用户的一次发布操作需要经过“信安”与“业安”两道自动审核工作。当业务数据出现风险时，程序将自动对用户进行“打击”。但是为了避免一些很常见的安全因素，需要由业务方先自行完成数据的筛选与过滤，因此我所负责的模块就是对用户发布行为的第一次过滤。
除了安全性和敏感性的问题，PSF模块中还包含了对用户服务发布的通知以及业务资源的保留。类似于靓号与特别含义的号码是拒绝用户进行注册的。用户在发布信息后，也将通过后台存储消息的内容与用量，以便实现服务的自动缩扩容服务。
从编程的角度来看，这些都是一些简单的模版问题。通过正则、前后缀匹配、算法删选等方式便很容易就完成这些服务。
活动引导页面
活动引导服务是我接收“用户信息触达”相关工作的第一步，也是熟悉业务和全流程的开始。顾名思义“活动引导”就是对某项活动内容的承接，需要通过图文的方式指导用户找到参与活动的入口。以提高活动上线后的参与度，降低用户的流失。
但是引导页面的下发也不是很轻松的事情，首先活动方需要在下发数据时将活动的参数预埋在用户的操作数据中，之后APP将用户参与的活动以参数的回传给后台。此时后台服务需要依照用户的特性与行为确定是否下发引导信息，以及下发哪种样式的引导信息。
众所周知B/S结构天然的缺点就是客户端的需改需要依赖于新版本的发布，但是作为一款大众性的产品，想让用户全部更新到新版本是不切实际的。因此许多功能点需要以后台配置化的方式下发到客户端，而2客户端只是一个展示数据的工具。如何让参数更加灵活，减少客户端的特殊逻辑以最大程度兼容未来的功能点是新建一项业务的最大难点。
弹窗服务改造
关于微视的弹窗服务，可以说是全部由我一个人承包了。从最小的一个小模块成长为一个收纳了无数种形形色色的弹窗形态的服务。经历了无数次发版与政论，有过错误的设计、有过错误的预期、有过差点宕机的BUG。一步步的由我将服务改造为了“ShellWindow X Ultra Extreme PRO Plus Max S”
弹窗服务最开始是一个小小的PHP模块，下发弹窗的方式也非常单一。仅支持以运营模式、任务模式两种方式下发弹窗。样式固定不可配置，每一次新增样式都需要添加一种类型并且发布新的版本。如此一来、产品经理便不愿意使用该服务来将信息触达到用户。从我接手改造后，该模块继续一个大更新，不仅仅是代码语言的调整，更是能力的全面提升。
对于一项业务的改造首先我们需要兼容所有的旧逻辑，这就意味着必须摸透原本服务下发信息的整条链路与数据格式，有了前面几项服务改造经验的基础，我已经明白如何理解数据的流动与常见的代码模型。因此在通读了多次PHP的代码后，我注释了大量与业务本身无关的log、es上报等代码，保留了原本就不怎么富裕的代码注释。理顺了原本仅有的两种数据下发模式。
根据新的业务需求，我需要为所有的业务方提供弹窗的下发能力。弹窗的内容要异化，弹窗的内容又要实时计算。因此所有业务逻辑代码都将是我的下游，从业务逻辑上来看，这些服务需要理解的数据与内容不是所有业务共享的，因此我摇身一变成为了弹窗信息的Proxy。所有的数据由我完成分发与流程控制，这个流程与上文的WNS服务极为相似。依赖于当时头疼医头脚疼医脚的思维。我在改造的基础上加入了向业务方直通的服务能力，即模拟“活动引导服务”的逻辑，当客户端携带由活动页面预埋的活动名时，便将流量定向到其他的微服务。这个链路是可配置化的，活动名、目标微服务和参数响应含义均有配置化的方案。在服务上线后，边打通了从端外活动到端内活动的全流程数据链路。
以后凡是产品经理需要新加入一个活动，只需要在后台配置化的加入名称与指定的微服务即可实现业务的对接。数据的流向将会配置化的改变，同时Proxy层也将在没有特定参数时读取用户的任务弹窗与运营弹窗，以此兼容旧逻辑。一个貌似有模有样的业务改造就开始落地开发了，但是谁能知道后期的服务发展远远的超乎预期。不仅仅是一个弹窗下发，在数据下发的过程中还需要完成弹窗互斥、优先级控制、AB实验控制等功能。原本业务三分的服务已经不能满足这些复杂的需求。弹窗服务的再次升级已经迫在眉睫，在编写本总结的同时，全新的弹窗收归与服务升级工作正在按期展开，设计的掌舵由组内的两位大佬拍板，我来制定整套设计的方案。每次开会都会调动前后端以及多方产品的人力资源，我还没见过这么大的阵容，慌了慌了。预知后事如何，且看下回总结。
工作成果
在实习的三个月过程中我完成了多个服务的改造，有冰山一角的修改，有多次迭代的大改造。这些代码的设计与编写完全不同于往常的实训或者小规模的开源项目。每一次发布背后都承载着微视千万DAU的压力，不希望出现半点BUG。
在我负责的四个工作中，体量最大的模块当属弹窗服务了。该模块在改造后成为APP调用的主要几个服务之一。每日服务的调用量仅比核心模块少了一个数量级，但是核心业务模块不是微服务的架构，因此一个业务模块的调用量最多的就是弹窗服务了。在刚刚过去的十一国庆，腾讯在手Q等平台上投放了大量的引流资源，希望能在国庆期间拉高整个大盘。从后台观察来看，我的弹窗模块也在活动资源投入的几天内出现了爆炸式的流量。
| 日期 | 北方机房 | 南方机房 | 合计 |
|---|---|---|---|
| 十月一号 | 68980000+ | 45690000+ | 114670000 |
| 十月二号 | 99430000+ | 47240000+ | 146670000 |
| 十月三号 | 76920000+ | 47420000+ | 124340000 |
| 十月四号 | 81650000+ | 50370000+ | 132020000 |
| 十月五号 | 98910000+ | 58650000+ | 157560000 |
| 十月六号 | 87930000+ | 51760000+ | 139690000 |
| 十月七号 | 81580000+ | 48440000+ | 130020000 |
| 944970000 |
从数据上来看，国庆期间弹窗服务的调用量也就四舍五入每天一个亿。流量就是金钱，流量就是需求。我从未有过如此接近在网络上如此巨大的流量，难以想象这每天一个亿的请求是从我的代码上流过的。每次看着十几台看不见的机器静静的躺在容器管理的列表中，看着资源占有率的各种曲线和调用量曲线在不同时间节点的跳动，就会扎扎实实的感受到什么是“网络”、什么是“流量”。也会想到为了这几个亿的流量，公司从机器层面一层层的堆叠和优化，才有了能让我这种实习生都就接触到真实的流量。网络的架构、服务的组合、设计模式的解耦再也不是PPT上铺满的图片与概念，再也不是我构想中的服务与业务代码。教科书中的每一个概念在这里都是一个庞大而系统的体系，甚至有不止一套体系与代码在支撑这这些功能的平稳运行。
技巧提炼
在公司的软件开发非常具有时效性和紧迫感，由于腾讯的公司特点，软件产品算是一种产品主导的开发模式。同时由于腾讯自身的体量庞大，用户群体广泛，因此即使平日看来不是很出众的短视频软件“微视”也具有巨大的市场与用户流量。那么在这种环境下与个人开发和小公司的开发有和不同呢？我在技术角度简单总结一下。
开发环境
首先在公司内部有一套十分完整的开发部署方案，这对开发的效率提升是至关重要的。一套开发友好的环境能极大提高开发效率，能增强开发之间的协作效率。
在公司内部的开发流程大致为：需求评审>>PM排期>>业务开发>>P0自测>>开发联调>>产品体验>>测试介入>>灰度发布
主干开发
说到开发环境，首当其冲的就是以Git主干开发为模型的协作方式，在公司内部Git上有项目的公共Git分支该分支仅用于项目的发布，这就意味着所有合并到该分支上的代码都是可编译的、可发布的。即使是微服务的也是以文件夹的方式划分模块使其不互相干扰，这样一来开发人员既可以通过一个项目（IDE）看到所有人员的代码与其之间的关联关系，又可以正常的安排服务发布流程。
每个开发人员都需要的Git上fork主仓库的代码，并在自己fork的仓库中修改代码。当开发认为自己的代码完成开发后，需要申请向主干仓库合并代码（PR）。由于向Git合并代码时由于Git环境的权限管理，个人是无法将代码合并在主Git分支中，必须又另一位开发人员Review代码并且通过后才能合并代码。通过这一系列的流程，既保证了代码环境的清晰，又保证了服务的可维护性与可发布性。
测试环境
那么在代码合并前开发人员应该做什么呢？当然是测试程序啦，虽然有负责测试的同学，但是对于开发人员要求通过P0测试，也就是验证程序正确性的基本测试。由于环境的层层叠加，因此仅在开发的开发机器上是无法建立测试环境的。外加比较有钱，腾讯采用的是开发机与测试机的开发测试环境，开发人员的代码编写完成后需要通过工具自动上传到开发机环境，也就是编译环境。在编译环境中，编译脚本将自动拉取最新的基础代码库并开始编译代码。在编译完成后，开发人员需要将编译产物转移至测试机（当然这一步是自己编写个小脚本就能完成的）。在测试机器上完成自动化的部署后，开发的测试环境就完成了部署。
为什么这么简洁呢？因为测试数据从APP到服务器的均衡负载到命令字解析到名字服务的解析过程，全部是通过携带“test”标记来标明自己的环境。也就是说其他的开发大哥们已经将测试的链路由客户端到后台业务模块全部打通，请求上来的测试数据会自然的流向测试的机器。当然这一套服务是与外网环境完全相同的结构，所有的机器也都是虚拟化的容器，在需要时可以快速申请多个虚拟主机用于测试。当测试的机器不止有一台时，可以通过“染色”的方式为某位用户的某种请求指定方向，以此来实现多个需求在开发时的测试环境冲突问题。
日志上报
无论是在联调还是外网问题排查，开发人员都必须依赖强有力的工具来实现问题的排查。首先在开发自测阶段，开发人员可以在网页上模拟客户端的请求（QTP测试工具）发出任何需要模拟的数据到测试机，在这一过程中避免了后台开发人员理解客户端代码，无需客户端配合也可以实现接口测试。同时配合解码工作与存储查询工具排查数据链路上的异常情况。
在模块完成开发的最后需要通过代码上报每一条请求的关键信息到ELK日志服务。当测试或外网反馈异常时便可通过检索的方式排查出某位用户的全部请求与响应内容，同时后台系统将在后台Proxy层也记录日志，用来捕获请求的原始信息。这一系统能快速定位问题所在环节，在较长的数据链路中找出问题的来源的。也可通过日志的信息复现BUG或者还原现场。日志系统的存在就如同福尔摩斯的放大镜，追踪着数据在后台的全部流程。
在代码中上报信息之外，系统还将自动上报其他的信息。例如服务器的CPU使用率、内存使用率、模块调用成功率等从外部的角度观察一个模块的工作情况是否正常。这些监控数据的异常波动可能不影响数据的正确性，但是对于一个高可用的服务还是有参考价值的。例如服务器如果经常内存占用过高导致服务重启，就有可能在代码中出现了内存泄漏的问题，那么在流量高峰的时候就会出现多台机器大面积重启，在此过程中就可能会造成部分用户的服务中断。因此外部的观察变量对于服务质量的评估和缺陷观察也有重大意义。
BUG定位
对于开发经验较少的开发者，定位问题是最麻烦的事情，尤其是在代码十分冗长，反复嵌套链路冗长的情况下更是难以理解。传统意义上这些内容都是“经验”之谈，但是实际上是一个心态和思维逻辑的考验。开发者如果能在设计之初就通过Log的方式将所有关键的信息记录下来，那么在理顺错误数据的来源时，这些关键性的Log就能辅助开发人员把握错误数据走向，当发现数据进入的错误的处理分支时，距离解决问题就很接近了。
在对于非自己开发的模块，可能处理逻辑与代码风格会有很大差异，一些写法甚至会引起不适。在这种状况下要善于把握主要流程，抛弃细小的分支（挑主要的看），善用IDE的跳转工具实现数据链路的跟踪，DEBUG环境是没有的，只能在自己的思维逻辑中去分析数据的变化，在冗长的数据链路中排除所有可能出现的漏洞。
如果仅仅是代码出错了，反而可能是好事。当写代码最大的难点不是有没有BUG，而是性能好不好时，问题排查的思路又发生了变化。有些时候BUG的产生不一定是数据出现了错误，而且在程序运行的过程中消耗了不必要的资源，或者没有释放资源，或者处理时间过长导致请求超时等等非错误数据的问题。这种问题的排除往往比直接的数据BUG根据难排查，原因在于没有明确的标准能判断对错。此时就需要根据多种曲线在不同时间点的抖动状况与日志量的关联性分析问题，当然不同曲线的不同抖动模式也可以看出问题的端倪。在确定问题的分类后需要在代码中排查数据的整个链路，或者使用工具分析代码中每个函数的资源消耗状况。此致才能详细的确定有嫌疑的代码片段，试着怀疑，试着分析。在优化了部分代码后，需要一点点流量来测试修改优化的部分是否有效。如果曲线的异常波动消失了，那么问题就基本锁定了。如果没有变化或者产生了新的波动，就需要回滚操作排查其他链路。宏观来看，对于非业务数据的错误的BUG分析，需要深刻理解计算机资源变化与波动的原因，本质上是编译原理和计算机原理的实践。
持续交付
如果有什么内容是老师在上课完全没交过的，那就是持续交付了。在课本上我们虽然了解了许多开发模型，但是我发觉没有一种是关注与服务长期变化与维护的模型。大部分模型的开始都需要一个明确的需求和优秀的设计，但是这对于一个长期服务的C/S系统来说是不可能的。系统设计之初是有需求，但是这个需求是一定不完美的。因为谁都无法预测产品在未来两三年的发展，产品在未来需要哪些功能，需要具备哪些特性，这是完全无法描述清楚的事情。不同于外包式的项目，“养成式”的开发维护场景下，产品的的发展是螺旋式的发展。此时产品不仅要实现最新的能力，还要兼顾已有的服务逻辑。这对服务的开发是个挑战，往往更新的更好用的服务上线后，老版本的用户就无法体验到新的交互逻辑，有些服务还可能会出现奇怪的掉链子的情况。
这太难了，如何拆分需求，如何做好服务的横向与纵向扩展对于业务的设计者是个难题。我没有什么很好的解决方案，因为我就深陷其中无法自拔。大哥竟然把服务的方案设计工作交给我，也太看得起我了吧。但是这可太难了，只希望我下个阶段设计的方案别出什么差错导致项目延期，我可担待不起。
持续集成
在软件完成开发测试后需要向外网发布更新。但是一个拥有如此大流量的服务发布起来可不是那么容易的。
首先我们的代码在合入Git的主干分支后，需要先使用CI组件完成代码的编译和环境打包，生成一个预发布的版本。在该CI的流程中，不仅要检查编译的结果是否正确，还会检查代码的圈复杂度，可能的内存泄漏等问题。并在预发布环境上自动发布测试。
在完成流水线打包后，开发人员需要向团队leader申请本次模块发布的权限，在申请时需要标明发布的内容与影响。在拿到权限之后，开发人员需要在线上的数十台机器中选择一台机器进行单机灰度发布。新的软件包会被部署在一个容器内，并且该容器的流量占比不会很高，避免出现BUG影响过多的线上用户。在单机发布后需要连续观察15分钟确认各项曲线符合预期、模块调用的成功率没有下降、所有流经该机器的数据表现均正常。之后需要发邮件向开发小组内所有人通告发布计划，发布前需要模块的负责人（owner）以邮件方式同意继续发布才可。
第二次发布只能发布全部机器的30%，之后再观察一小时各项数据。数据正常后仍需负责人同意才可以全量发布。这一发布流程看似冗长，但是有效的减少了随意发布带来的不可逆后果。毕竟这么大的流量，如果出现了问题那可能就是成千三百的用户的损失，也是公司的损失。如果定一个四五级的“事故”，那大家可能就要开复盘报告了。毕竟那种全开发组都会紧张的外网BUG，谁的不想多体验两次。体验一次就是一次心跳加速与高血压的体验。
工作环境
内部IT部门
腾讯虽然作为一家IT行业的公司，但是如很多公司一样也有内部的IT部门。这个部门是从实习开始就能有深刻感受的部门，所谓内部IT就是向公司内部的员工提供IT设施与服务的部门，最重要的KPI就是其他员工咨询问题后的反馈好评率。
在实习开始前，IT部门就会通过系统询问需要选择的电脑型号与配置，并在员工到岗之前就放在工位上。同时在员工进入公司的整个过程中，看到的大部分指引也都是IT部门标记的，从如何使电脑标准化到电话机应该如何安装，从付费软件的采购到应该如何在内网使用网易云。IT部门为所有员工的办公细节提高全方位的在线支持，这些能力仅仅是一个内部微信就能办到的，网络不通、权限没开、系统升级只要不是行政问题，问IT部门总没错。虽然大家都是整IT行业的，但是对内和对外服务差别好大呀。我感觉如果以后我去其他的公司如果没有这种优质的内部IT服务，估计会难过的想离职。
内部文档
最想让人吐槽的就是公司内部的文档了，可能是部门特色吧。对新手的友好程度基本等于0，由于太想讲的详细，于是框架画的非常大。但是又因为实在懒的写，于是每个部分又讲的非常粗略。外加经常性的不更新，导致刚到岗的前几天都处于一脸懵逼的尴尬情景。很多问题还是要问导师或者周边的同事才能了解清楚真实的业务面貌。
团队管理
可能是我从小接触的环境比较稳定而单纯，对于办公室内的思维习惯和变化不是很能理解。我对于办公室中的团队文化有三点不太能适应：职位评级、人员变动和业务交接。
在我看来职位评级是一个很了不得的东西，因为这能反映出一个员工的努力程度、工作年限和工资收入。但是在我观察办公室的同事后，感觉虽然大家的评级相差很多，但是在沟通交流上好像并没有太多障碍和恭维，也没有评级高就很牛逼能达到定乾坤的神奇程度，即使评级很高的同事也是穿拖鞋、侃大山、恰烧烤。不点开他们的个人卡片，都不知道自己和大佬之间的差距是如此之大。和你争论设计方法的可能是一个十几年开发经验的（接近）顶级大佬。嘤嘤嘤、还是自己太菜了。
另外有让我很不舒服的是办公室中的人员变动。无论是以前在家还是在学校，身边人员的变动（包括爸妈朋友的人员变动）都是很久很久才会发生，大家一般都不会调整自己的岗位更不愿意调整自己的公司。也许是因为这是IT企业，人员流动性非常大。暑期时实习生多，即使每天早上很早去签到，在实习生中也只能排名2000+。但是到了现在，即使晚上要回家时再签到，也仍然是1000名以内。另外不仅仅是实习生，正式员工的变动也是非常频繁，在我刚刚到岗一个月后，就有一个同事在试用期就离职跳槽到其他公司了。之后又有两位同事流动到了其他的部门，最难受的是我的导师在近期也决定要去其他部门了。一时间好像所有人都在逃离这个部门，身边的空位也越来越多，每个人身上的业务也越来越多，一时间我这个没走的实习生也被当作正式员工管理业务，因为没有人和我一起主备了。
与人员变化相关的是业务的交接，在有同事离职或者流动后。同事原本负责的代码和模块就要交接给其他同事来管理，但是令人不愉快的是，交接的形式往往都是名义上的交接。对于代码层面，模块的接受者往往完全不知道这些模块是做什么的，他的逻辑是怎样的，这个模块的历史和相关联系人也都完全不知道。可能是我比较单纯吧，总认为代码交接就像是自己的孩子委托给别人照顾，需要把方方面面的特点和小问题都全部梳理和沟通。但是公司内的这种交接却令人有点点失落，公司服务于用户的很多关键功能模块就这样轻易的被交接了出去。没人知道这些代码未来会怎样发展，我甚至庆幸我每天用的软件是完全正常运转的。
时间安排
不得不说的一点是，鹅厂对于代码生产的工业化管理还是比较让我满意的。一项业务的开展与推动是有标准化流程与方式的，也就是每项任务开始前的工作排期。对于一个小团队来讲，工作的开展也许就像是老大让做什么就做什么，做完了就歇着。但是在鹅厂内，每一项工作的开始前都需要进行需求评审，在需求评审时就需要确定工作的时间周期，这个周期也许很宽松，但是也一定协调各方共同制定。一旦时间确定后开发的日程也就变成板上钉钉的事情了。
及时有合理的排期也不难完全规避风险，于是还会引入风险管理和依赖管理。哪些业务的优先级高、哪些业务有延期风险这些都会在开发或开发前暴露出来，而项目经理会捕获这些问题与矛盾，妥善的处理多个需求之间的冲突。如果出现了大的问题，可能会向上升级报给大领导来决定。
开发的时间也不会想想象中的一帆风顺，尤其是比较大佬的开发同学。经常会被叫去解决各种问题或者评审新的需求能否实现，可以说有些时候一整天都没法安安静静的写代码。我虽然不比大佬，但是由于一个人担负这样一个高流量的模块，也常常有许多业务会来对接。明明是很想开发的时间，却不得不要解决问题。“没有完全整片的时间给你开发的”，在大佬的不断教诲和实际情况所逼迫下，自己要懂得如何进行碎片化的代码开发和尽可能详细的设计与尽可能快的开发，另外也需要知道什么是高优先级和必要做的事情，每天找来问问题的人许许多多，如何把握各方的进度的平衡也是个业务级的难题呢。
未来展望
对于我个人来及，所接触到的技术实在是太少了。先不说如何设计一个一个大型的网络软件架构，我就连实习期间所接触到的所有服务组件都没听说过几个，单单一个数据存储结构就把我讲的稀里糊涂，更别说各种中间件和网络结构了。原以为我对公司内的软件开发流程和软件设计是有所了解的，但是实际上来看，我所了解的还是过于空泛与抽象，没有把每一个细节与缘由搞搞清楚。虽然现在负责的模块莫名其妙变成了一个超高流量的模块，每天无数的数据从代码中流过，但是我只是一个普通的业务开发，超出了这一范围的所有内容对我来说都是黑盒的，我观察那些复杂的监控曲线就如同观望马里亚纳海沟的波涛，及时表面数据风平浪静，但是却了解不到这些信息是如何汇总分析与展现的。每次大哥们介绍的辅助工具对我来说都是非常“高级”并且高效的，这都说明在我之前已经有许许多多的先辈发现了工具的缺失并且开发了这些辅助开发的工具，我的使用无非就是成人之美，并无深刻的技术含量。反观我自己的网站建设过程，一个小小的功能点都可能会因为要从0开始而变得尤为艰难。
不会沟通就没有结果。团队形式的开发也是我很少接触的内容，更别说在上百人的团队中协调人员。曾经没见过的“PM排期”、“需求评审”、“方案协调会”都是这个团队和机制所带给我的。团队协同、跨部门、跨BG的沟通，每次都是全新的体验，因为你能感受到这是一个相互连接的，有血有肉的庞大组织。在与他人沟通时的那种描述问题与需要的能力是十分必要的，在我看来我所做到的只是刚刚“及格”。因为我目前只是一个能够描述问题，解决问题的角色，并没有做到提出问题、协调各方、推动进度的强者角色。许多事情只能由大哥去推动，我负责跟进与协调，这不够这不够，我需要能更加主动，更有能动性，更多的参与沟通与讨论。将我手下的业务Push起来。
没有见过的要积极去了解，没有学习的要积极去尝试，不怕多付出了什么，只因为在收获时能更有成就感。
