百度两年经历：从学生到程序员
还未毕业就在百度实习了，两年多的磨练，有被磨平的棱角，也有精彩的收获；谨以此文献给在百度并肩奋战两年多的兄弟姐妹们。忘不了离职日那场特殊的告别午餐；忘不了这两年和你们的讨论、争论；忘不了脑海中你们的一个个优秀的细节。真想说无论“嫁”到何方，你们都是我的娘家人，我在天猫玩得蛮开心，请不要牵挂！
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 找个项目去炫耀肌肉
透明度
坊间流传（原话找不到出处）程序有两类：一类是设计得足够简单明了，以至于一眼看上去就知道没有大的问题；另一类是设计得足够复杂，以至于看不出是否有问题。想说的是，程序设计越是清晰透明，潜在风险越小，后期维护沟通成本也越小；笔者曾经有过这种念头“设计写得太明白，人家一看就明白会不会太没深度了”，现在想想只能对那时的自己“呵呵”了。
推广技术
优秀的程序员会推广自己的技术
最初不理解，写好代码不就行了吗，干嘛要搞这些？现实是：再好的设计和代码，没有人了解的话就会被扔进历史的垃圾堆！
对自己成果负责的话，就必须努力推动它被更多的人认可；这个推动的过程中往往又可以收到那些看似苛刻但却极为重要的建议；这样就走进良性循环中了。
推广的方式有：团队内分享、公司内部的技术刊物、外部的如博客、微博、微信、IT 咨询站点……
经营博客
最初是觉得“好记性不如烂笔头”，但真正写起来后发现写博客其实能够深化那些停留在口头的结论；写博客让自己更有目的，会促使自己留心积累；功利一点看，无论面试新同学，还是自己被面，都提到了博客，好的文章是极好的面试材料。
开源
笔者写过一篇《为何/如何看源码》；如果时间允许，又是自己感兴趣的可以考虑为项目贡献代码、文档、测试 case、demo 甚至是宣传推广，能做的不仅仅只是 coding。
笔者之前是闲着的时候去逛 github，后来慢慢成了习惯，最后干脆把自己所有的 demo、读书笔记、最后是所有文章和开源项目都扔到 github 上；公司立项前也会习惯地上去找找思路，也避免重复造轮子。
最好 vs 最合适
这是一个取舍的过程，或者说是在理想和现实中寻找平衡点；商业项目往往非常看重时效性，一种原因是合同已经签好了，未按时完成就是违约，所以在这种压力下很多时候就需要精简设计，使用最合理的方案来做。
但是好在有“迭代”。
迭代
不同类型的公司，迭代周期差异巨大，比如电信设备行业会是 1 年至 3 个月，而互联网公司通常会是 1 个月至 1 周，甚至是按天发布；很多迫于时间做出的折中方案往往可以在迭代中改进。
迭代的前提是产品本身允许增量发布，一个有趣的对比是：计算机芯片和互联网公司的门户，显然门户更适合增量发布；为什么需要迭代呢？看到过这些原因：
- 产品需求太庞大；一次发布的话将会把开发周期拖得很长
- 实验性产品；丫不知道下一步要做什么，先扔个版本出去看看市场的反应
迭代需要一个强有力的质量保证，单元测试和自动化测试都是保证质量的有效手段。
技术 vs 工具
比较认同《前端开发的工程之美》中技术和工具的对比：
对待技术和工具，技术自然是最基础的，工具是照着“说明书”就可以很快上手，对工具不必太执念，否则会很快遇到成长的“天花板”。
解耦
书里无数次提到要“解耦”，心想联系得紧密点有什么不好。现实的项目中，尤其是在快速迭代的环境下，要是耦合非常紧，一个小改动就可能拉出一堆回归，等着哭吧。
大巴缓缓开进了九寨景区，望向远方灰白的山脊，似乎看到了山脚下那五彩斑斓的海子……