码迷,mamicode.com
首页 > 其他好文 > 详细

后台开发入职三年的经历和体会

时间:2014-09-10 23:51:51      阅读:563      评论:0      收藏:0      [点我收藏+]

标签:使用   strong   文件   问题   sp   代码   on   工作   时间   

本人本科毕业之后一直在一家大型网站工作。

主要经历

第一年前半年里,熟悉技术,不太懂工作上的事情,摸索了很久,感觉也没什么进步。做事情停留在表面,没有系统的联系起来,都是提心吊胆,结果不确定。当时组里的同事给我讲了很多系统的架构之类的东西,我感觉没有深入的理解进去,到现在也忘掉了。同时,做的事情优化和修改也不够多,也就是回顾的很少,于是经验积累很有限。其实就变成了熟悉编程语言了。

第一年后半年里,随着项目组一起去做另一个业务,然后发现自己写业务核心代码根本不行,漏洞百出,经验完全匮乏。于是被安排到后台做编辑系统,做的还挺用心的。不过常常是没有开发完善,很多细节没有处理就提测了,然后导致测试同学不停的提bug,比较埋怨我。当时对完善的开发和自测没有一个清晰的认识,于是做的东西质量也不高。

第二年上半年里,开始做一个ipad上的阅读客户端后台逻辑。做了一个索引优化的需求,连续2个月不停优化。这一次程序代码在功能上的拆分,优化做的很到位,整体很优雅。唯一一个问题是细节测试不行,部分接口和函数逻辑不完善,漏洞比较多,然后查问题比较慢。不过还好问题比较少,整体没有耗费太多时间。

第二年下半年里,开始做一个新的iphone上的阅读客户端,当时基本上是从头开始,没有用户量,也没有流量。一个哥们R给我安排事情,每次把事情的来龙去脉讲的特别清楚,怎么做,为什么这么做,都讲的很好。这对于我提高经验帮助很大。从那开始,我具有了分析业务细节的能力。

第三年上半年里,从一个新需求的具体程序员,开始转向后台功能。是另一个哥们N移交的业务给我,一个核心的模块,文章的评论。这里的更新机制,速度优化策略,整体业务逻辑,产品特殊需求,都跟我介绍的很清楚,拉上我一起分析如何优化,如何从后台功能去思考一个新需求的实现。收益良多。

第三年下半年里,我开始独立负责开发新需求,能够从全局的角度开始思考业务的整体实现细节。我接到新需求之后,开始消化和设计,将整体方案跟同事N进行商量。同事N提出了很多质疑,我能解释的解释,不能解决的就把方案拿回来继续思考和优化,最终从他那里通过了,然后开始动手开发。这个时候对代码的处理能力就已经是比较强了,代码质量很高。不但能够整体规划代码分割方法,还能够很好的实现细节的容错。但是感觉当时对进度的把握不够好,总是为了保证质量而拖慢了节奏。于是领导并不是很满意。

第四年上半年里,算是已经有了一两个月了。现在的我不但能够结合现有业务特点,对新需求做评估,还能够找到业务的瓶颈,进行优化。同时,业务节奏也把握的很好,能够快速上线见效果。领导开始有了新的要求,那就是不但要做好自己的业务,还要能够协助其他同事,必要时出来补位。这里就需要平时关心和了解其他业务的逻辑,持续关心。

 

主要体会

1.了解需求的人永远掌握主动权

不管你是什么级别或者水平的开发人员,如果你不了解需求和业务,你就没有发言权,你的所有构思和创意都将收到挑战和质疑。因为架构和资源都是围绕产品属性来定义的,一个架构如果费力实现,最后发现不适合业务逻辑,重构的代价是很大的,风险是很大的,责任也是很大的。在不确定性面前,谁知道的更多,谁就掌握了发言权。谁能确认,谁的主导权就更大。所以产品思维对于开发人员来说是很重要的,你比其他开发更懂产品,那么你就更能够选择合适的架构和实现方法。

2.不是所有的事情都要现在做,但是要保证以后做也很容易

你是开发人员,那么你知道某个东西的重要性,开发的复杂性,耗费的时间。当然,你不知道,你可以持续锻炼,最后掌握这个能力。但是对于领导和产品同学来说,可做可不做的东西其实很多。那么他们是要求你做还是不做,现在做还是以后做呢?如果现在做了,耗费大家时间,整体工期拉长,情绪不高。要是不做,那么领导过问是责任,后续不能实现了,产品同学就不敢承担这个责任。所以,如果你说某个东西,产品认为不太着急或者不太重要,那么你要及时告知,这个东西以后补上也行,很容易。产品会很乐意放过这个需求点,大家都轻松。

3.要在领导定的基本框架内做事情

不要认为自己突然想到的颠覆性的想法多么的牛逼,任何已有的东西,如果是用心做出来的,都不应该被颠覆,都是有其适用性的。所以,在前人的框架内做事情很重要,领导容易对你放心,你也就更容易放开手脚实现自己的想法。如果你挑战了领导的基础逻辑,你将付出更大的时间成本和沟通成本,最后领导还要质疑你的做法,如果有问题了,那么就是搬起石头砸自己的脚。

4.不要挖坑或者少挖坑

没有经验的人,需要多多细致思考方案,那么这样做出来的东西,比较容易达到自己的最佳水平。如果还能够得到资深人士的认同,那么这个方案就具有很好的实践性,坑也会比较少。在麻烦和坑面前,宁愿自己辛苦一点,也要让整体流程轻盈顺畅,查问题和节点方便,监控和追溯方便。如果加加班能够把一个事情做的特别漂亮,那么就加班吧,完成之后你会睡的更加踏实。

5.专业的人做专业的事情

这句话看上去是提高效率的一句话,在任何人之间的配合上,肯定是这么分工处理的。在不同的项目组合作的时候,特殊情况跟这个不太一样,一般情况下也是如此。特殊情况是,你不做点事情领导就不放心,这时候与你无关的事情,风险比较小的,你也要找点来做。在代码处理上也可以这么做。逻辑按照功能从代码文件上做到分开,保证最高效率的个性化调用能够实现。同时,跨项目组合作的时候,使用接口、透明调用、透明传输、各自处理熟悉的部分等等,都是很好的办法。

6.有时候不是努力就可以的

这个就是人际的含义。有的人,一开始就注定是接班人,你争不过他。你的成绩有时候跟你处于的位置挂钩,也许你做的事情没什么含金量,不牛逼,但是这个位置重要,领导同样对你刮目相看,器重有加。在领导需要有人在岗的时候,你的应答声会格外有力。不是努力就可以,不努力肯定不可以。在合适的位置努力,风口上的猪都会飞。

最后,技术的提高是缓慢的,且行且努力。

后台开发入职三年的经历和体会

标签:使用   strong   文件   问题   sp   代码   on   工作   时间   

原文地址:http://www.cnblogs.com/Hiker/p/3years.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!