第九章 百度两年经历：从学生到程序员.pdf

百度两年经历 ：从学生到程序员 摘要: 还未毕业就在百度实习了 ，两年多的磨练 ，有被磨平的 角 ，也有精彩的收获 ；谨以此文献 给在百度并肩奋战两年多的兄弟姐妹们。忘不了离职日那场特殊的告别午餐 ；忘不了这两年和你们 的讨论、争论 ；忘不了脑海中你们的一 … 还未毕业就在百度实习了 ，两年多的磨练 ，有被磨平的 角 ，也有精彩的收获 ；谨以此文献给在百 度并肩奋战两年多的兄弟姐妹们。忘不了离职日那场特殊的告别午餐 ；忘不了这两年和你们的讨论 、争论 ；忘不了脑海中你们的一个个优秀的细节。真想说无论“嫁”到何方 ，你们都是我的娘家人 ， 我在天猫玩得蛮开心 ，请不要牵挂 ！ 3月底 ，离职前的闲暇跑了趟蜀地 ，去九寨的山道上触景生情 （照片扔在我的微博相册中@徐凯-鬼 道 ），整理出这么一篇 ，多是从细节总结出来的心得 ，不喜勿喷可轻拍 ，各种原因拖到今天才发 上来。 大巴行驶在通往九寨的环山道上 ，望着奇险的山景 ，睡意全无…… 团队 随着时间的推移 ，对于团队的理解在不断改变和加深。团队中一些有趣的现象 ，比如 ： 误解往往来自于缺乏沟通 ；原来的团队中角色众多 ，因为不了解其他角色的工作而发生的不愉快 经历是难免的 ，发生了就要沟通 ，大家坐下来聊聊天化解误会就好了 ；这种事情我经历过两次 ，大 家平心静气地谈过后彼此更加信任 ，完全不会因为误会而交恶。 团队间的合作分工是有讲究的 ，互相补充、制衡、各尽其责 ；在遇到紧急问题时也能表现出一贯 的效率 ，最终推动问题的解决 ；这有点像 《寒战》中的情节。 曾问“技术和产品是什么关系” ，答曰“合作的关系” ，何尝是与产品 ，技术与任何角色不都是合作的 关系吗 ？ 合作 笔者在百度的两年经历中 ，作为团队中的客户端 （web前端+移动app ）t ech leader有一年的时间 ， 需要频繁和各类角色打交道 ，为了让工作更加平滑地开展 ，需要了解每一种角色关注的焦点 ，与他 们密切地合作。在一个产品的生命周期中 ，依次会接触到这些角色 ：产品、设计师、前/后端、测试 ，之间还穿插着和老板以及其他t ech leader的沟通。 产品 需求的发起人。这群人能说会道 ，砍他们的需求就和要他们的命一样 ；一般情况下“砍”不如“拆” ，需 求可以分期做 ，通常双方都能接受 ；特殊的情况需要说明下 ，漂亮mm带着水汪汪的大眼睛死死盯 着你的时候 ，你的思路一定要保持清晰 设计师 需求像水一样流到设计师这里。设计师一般分为交互和视觉 ；交互根据产品方需求提供交互稿原型 ，视觉在交互稿基础上丰富页面元素、配色、细节调整等 ；和设计师尤其是视觉要处理好退化的 问题 ，真不是所有的设计师都能够理解“渐进增强 ，平稳退化”的概念 ，这个需要沟通 ；之前在圆角 问题上遇到过阻力 ，通过和视觉的沟通 ，视觉最终还是接受了前端的退化处理 （bo rder-radius ） 建议。 前/后端 之前 ，前端无论与业务端后端还是服务器后端的合作都是很顺畅的 ；前后端之间应该尽量解耦 ，只 通过规范接口通信是最理想的状态 ；以java环境的业务端为例 ，jsp和f reemarker （f m ）二选一 ，应 该选f m ，因为f m是模板语言 ，尽管仍包含逻辑控制 ，但在前后端解耦上优于jsp ；再进一步 ，f m和 整站ajax通信 （js渲染页面 ）相比 ，显然选ajax ，因为这样前后端的耦合又更小了。 业务系统中是否选择ajax需要根据业务类型来考虑 ，引用 R框架中的一段描述 ： 整站式Ajax应用不利于搜索引擎抓取。故 R框架不适用于内容提供的W B站点。 测试 见到过技术和测试掐架的场景 ，实际工作中这两块人的合作远多于分歧 ；而且必要的掐架是对项目 负责的表现 ，大家吵完架还是可以坐一桌吃饭的。有一点应该注意 ，不要等到项目快结束了想到让 测试介入 ，这样测试很被动 ，对整个项目的进度也可能带来风险 ；应该尽可能拆分手头的需求 ，安 排开发计划 ，让测试能尽早介入 ，技术和测试能够交替完成各自任务是最理想的。 选择团队 新团队机会多 ，但是可能会缺乏足够的指导 新团队往往没确立在公司的地位 ，对个人晋升有可能造成影响 老团队高手云集 ，如果没有好的新人成长计划 ，要想杀出重围也不容易 总体来说建议在老团队学习 ，打下基础 ，寻找合适的机会去新团队闯一片天地 这些观点仍然很泛 ，请具体情况具体分析。 带新人 带新人