一位工程师的两年百度工作经历-电子发烧友网

还未毕业就在百度实习了，两年多的磨练，有被磨平的棱角，也有精彩的收获；谨以此文献给在百度并肩奋战两年多的兄弟姐妹们。忘不了离职日那场特殊的告别午餐；忘不了这两年和你们的讨论、争论；忘不了脑海中你们的一个个优秀的细节。真想说无论“嫁”到何方，你们都是我的娘家人，我在天猫玩得蛮开心，请不要牵挂！

3月底，离职前的闲暇跑了趟蜀地，去九寨的山道上触景生情，整理出这么一篇，多是从细节总结出来的心得，不喜勿喷可轻拍，各种原因拖到今天才发上来。

大巴行驶在通往九寨的环山道上，望着奇险的山景，睡意全无……

团队

随着时间的推移，对于团队的理解在不断改变和加深。团队中一些有趣的现象，比如：

误解往往来自于缺乏沟通；原来的团队中角色众多，因为不了解其他角色的工作而发生的不愉快经历是难免的，发生了就要沟通，大家坐下来聊聊天化解误会就好了；这种事情我经历过两次，大家平心静气地谈过后彼此更加信任，完全不会因为误会而交恶。

团队间的合作分工是有讲究的，互相补充、制衡、各尽其责；在遇到紧急问题时也能表现出一贯的效率，最终推动问题的解决；这有点像《寒战》中的情节。

曾问“技术和产品是什么关系”，答曰“合作的关系”，何尝是与产品，技术与任何角色不都是合作的关系吗？

合作

笔者在百度的两年经历中，作为团队中的客户端（web前端+移动app）tech leader有一年的时间，需要频繁和各类角色打交道，为了让工作更加平滑地开展，需要了解每一种角色关注的焦点，与他们密切地合作。在一个产品的生命周期中，依次会接触到这些角色：产品、设计师、前/后端、测试，之间还穿插着和老板以及其他tech leader的沟通。

产品

需求的发起人。这群人能说会道，砍他们的需求就和要他们的命一样；一般情况下“砍”不如“拆”，需求可以分期做，通常双方都能接受；特殊的情况需要说明下，漂亮mm带着水汪汪的大眼睛死死盯着你的时候，你的思路一定要保持清晰：）

设计师

需求像水一样流到设计师这里。设计师一般分为交互和视觉；交互根据产品方需求提供交互稿原型，视觉在交互稿基础上丰富页面元素、配色、细节调整等；和设计师尤其是视觉要处理好退化的问题，真不是所有的设计师都能够理解“渐进增强，平稳退化”的概念，这个需要沟通；之前在圆角问题上遇到过阻力，通过和视觉的沟通，视觉最终还是接受了前端的退化处理（border-radius）建议。

前/后端

之前，前端无论与业务端后端还是服务器后端的合作都是很顺畅的；前后端之间应该尽量解耦，只通过规范接口通信是最理想的状态；以java环境的业务端为例，jsp和freemarker（fm）二选一，应该选fm，因为fm是模板语言，尽管仍包含逻辑控制，但在前后端解耦上优于jsp；再进一步，fm和整站ajax通信（js渲染页面）相比，显然选ajax，因为这样前后端的耦合又更小了。

业务系统中是否选择ajax需要根据业务类型来考虑，引用ER框架中的一段描述：

整站式Ajax应用不利于搜索引擎抓取。故ER框架不适用于内容提供的WEB站点。

测试

见到过技术和测试掐架的场景，实际工作中这两块人的合作远多于分歧；而且必要的掐架是对项目负责的表现，大家吵完架还是可以坐一桌吃饭的。有一点应该注意，不要等到项目快结束了想到让测试介入，这样测试很被动，对整个项目的进度也可能带来风险；应该尽可能拆分手头的需求，安排开发计划，让测试能尽早介入，技术和测试能够交替完成各自任务是最理想的。

选择团队

新团队机会多，但是可能会缺乏足够的指导

新团队往往没确立在公司的地位，对个人晋升有可能造成影响

老团队高手云集，如果没有好的新人成长计划，要想杀出重围也不容易

总体来说建议在老团队学习，打下基础，寻找合适的机会去新团队闯一片天地

这些观点仍然很泛，请具体情况具体分析。

带新人

带新人是老板对你能力的认可，是好事

带新人对自己的能力提高是显著的，因为有一个机会把业务和技术的基础回顾一遍，给自己查漏补缺甚至是理解得更深刻

安排好自己的时间，因为要想带好新人是要花精力的

新人可能随时会打断你，要有忍耐力

如果新人太多，应该考虑找人帮忙带，都揽下来的话对自己和新人都是不负责任的

结果导向

面试过的互联网公司，HR都会来上一句“我们是结果导向的”，当时很配合的点点头，以示理解（其实压根没听懂）。两年下来，我对结果导向的理解变成了：

上下班时间可以自由，但是要干满8个小时或更多，因为活就在哪里，不离不弃

半年或年度考核时，KPI可能是唯一的评价标准

团队的结果不够好，个人肯定受影响，因为结果导向嘛

个人承受压力

尽管笔者在学校的时候已经做了一些小项目，初到公司环境还是有点发懵，人家提的需几乎不加判断地接受了，导致初期工作量奇大，压力剧增。这个过程持续了1-2个月，高负荷的工作带来的副作用竟然是承受压力的能力变强了，好神奇！

仔细想想，压力还是可以细分的，各个击破：

高负荷工作量带来的压力；和主管客观地沟通自己的上限，上限可以慢慢提高，要知道高负荷也可能给项目带来潜在的隐患，比如累挂了

不熟悉的业务场景带来的压力；有时候看文档缓解不了压力，就找人多问，给你演示，然后自己先用起来，再去看文档就会好一些

从未接触过的技术带来的学习压力；和业务场景是一样的处理，只有理解了“是什么”，才能更快地掌握它

技术复杂性远超过心理预期产生的压力；冷静下来！看清复杂性到底是结构很庞杂，还是某个算法超难理解；如果是结构复杂理不清头绪，尝试下类似断点调试的办法，还不行的话找人帮忙看看；如果是算法太复杂，也务必找到资料或人详细了解算法的作用、使用场景、局限性等，一般上来就直接看代码是很痛苦的

还遇到一种情况比较特殊，代码中用了很个性化的写法（不知道魂淡当时怎么想的），而且对方已经不在公司了，最后放弃了，只能重写！这种情况比较极端，不过也给我们一个经验，代码还是通俗点比较好，耍酷可以在github找个项目去炫耀肌肉

透明度

坊间流传（原话找不到出处）程序有两类：一类是设计得足够简单明了，以至于一眼看上去就知道没有大的问题；另一类是设计得足够复杂，以至于看不出是否有问题。想说的是，程序设计越是清晰透明，潜在风险越小，后期维护沟通成本也越小；笔者曾经有过这种念头“设计写得太明白，人家一看就明白会不会太没深度了”，现在想想只能对那时的自己“呵呵”了。