还未毕业就在百度实习了,两年多的磨练,有被磨平的棱角,也有精彩的收获;谨以此文献给在百度并肩奋战两年多的兄弟姐妹们。忘不了离职日那场特殊的告别午餐;忘不了这两年和你们的讨论、争论;忘不了脑海中你们的一个个优秀的细节。真想说无论“嫁”到何方,你们都是我的娘家人,我在天猫玩得蛮开心,请不要牵挂!
创新互联建站专注于南州晴隆企业网站建设,自适应网站建设,商城网站制作。南州晴隆网站建设公司,为南州晴隆等地区提供建站服务。全流程按需网站制作,专业设计,全程项目跟踪,创新互联建站专业和态度为您提供的服务
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都会来上一句“我们是结果导向的”,当时很配合的点点头,以示理解(其实压根没听懂)。两年下来,我对结果导向的理解变成了:
个人
承受压力
尽管笔者在学校的时候已经做了一些小项目,初到公司环境还是有点发懵,人家提的需几乎不加判断地接受了,导致初期工作量奇大,压力剧增。这个过程持续了1-2个月,高负荷的工作带来的副作用竟然是承受压力的能力变强了,好神奇!
仔细想想,压力还是可以细分的,各个击破:
透明度
坊间流传(原话找不到出处)程序有两类:一类是设计得足够简单明了,以至于一眼看上去就知道没有大的问题;另一类是设计得足够复杂,以至于看不出是否有问题。想说的是,程序设计越是清晰透明,潜在风险越小,后期维护沟通成本也越小;笔者曾经有过这种念头“设计写得太明白,人家一看就明白会不会太没深度了”,现在想想只能对那时的自己“呵呵”了。
推广技术
优秀的程序员会推广自己的技术
最初不理解,写好代码不就行了吗,干嘛要搞这些?现实是:再好的设计和代码,没有人了解的话就会被扔进历史的垃圾堆!
对自己成果负责的话,就必须努力推动它被更多的人认可;这个推动的过程中往往又可以收到那些看似苛刻但却极为重要的建议;这样就走进良性循环中了。
推广的方式有:团队内分享、公司内部的技术刊物、外部的如博客、微博、微信、IT咨询站点……
经营博客
最初是觉得“好记性不如烂笔头”,但真正写起来后发现写博客其实能够深化那些停留在口头的结论;写博客让自己更有目的,会促使自己留心积累;功利一点看,无论面试新同学,还是自己被面,都提到了博客,好的文章是极好的面试材料。
开源
笔者写过一篇《为何/如何看源码》;如果时间允许,又是自己感兴趣的可以考虑为项目贡献代码、文档、测试case、demo甚至是宣传推广,能做的不仅仅只是coding。
笔者之前是闲着的时候去逛github,后来慢慢成了习惯,***干脆把自己所有的demo、读书笔记、***是所有文章和开源项目都扔到github上;公司立项前也会习惯地上去找找思路,也避免重复造轮子。
*** vs 最合适
这是一个取舍的过程,或者说是在理想和现实中寻找平衡点;商业项目往往非常看重时效性,一种原因是合同已经签好了,未按时完成就是违约,所以在这种压力下很多时候就需要精简设计,使用最合理的方案来做。
但是好在有“迭代”。
迭代
不同类型的公司,迭代周期差异巨大,比如电信设备行业会是1年至3个月,而互联网公司通常会是1个月至1周,甚至是按天发布;很多迫于时间做出的折中方案往往可以在迭代中改进。
迭代的前提是产品本身允许增量发布,一个有趣的对比是:计算机芯片和互联网公司的门户,显然门户更适合增量发布;为什么需要迭代呢?看到过这些原因:
迭代需要一个强有力的质量保证,单元测试和自动化测试都是保证质量的有效手段。
技术 vs 工具
比较认同《前端开发的工程之美》中技术和工具的对比:
对待技术和工具,技术自然是最基础的,工具是照着“说明书”就可以很快上手,对工具不必太执念,否则会很快遇到成长的“天花板”。
解耦
书里无数次提到要“解耦”,心想联系得紧密点有什么不好。现实的项目中,尤其是在快速迭代的环境下,要是耦合非常紧,一个小改动就可能拉出一堆回归,等着哭吧。
大巴缓缓开进了九寨景区,望向远方灰白的山脊,似乎看到了山脚下那五彩斑斓的海子……
原文链接:http://blog.jobbole.com/38996/
分享题目:百度两年经历:从学生到程序员
URL网址:http://www.shufengxianlan.com/qtweb/news8/21658.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联