两年多工作心得和体会

今天算是正式离职了，算起来还有几个月在此家公司呆了快三年。中间的得得失失我觉得很有必要总结一下，应该算是一个对我个人来说比较有价值的总结吧。下面开始从头屡一下。

一些闲话：

当初来公司的时候是用JavaEE开发后台的职位，同时来的还有一个技术小伙伴，两个人一起开发了公司的一款至今看起来比较牛逼产品的后台；这个产品虽然在后来没有发挥了应有的作用，但是为公司另外一个产品的设计理念和思路在就是在此产品的基础上进行了拓展。这个项目的后台用的Mongodb+spring，算是用Mongodb正式开发的一个项目吧。后来项目开发结束后，在项目负责人的安排下转了android，看了一个星期的android知识后正式上岗上线。

其实在我看来，从JavaEE转android还是挺容易的，当然在初期也犯了各种低级错误；有的需求是自己网上边搜资料边开发的，特别是一个动画效果，当初对我来说可是一点思路都没有，然后就下载网上同类上线的apk进行反编译看看别人怎么实现，最后也模仿出来了，也即是帧动画的效果，当初我都不知道有帧动画，自己用了其他方式都没达到要求。其实我觉得程序员的工作是最有满足感的工作，自己在亲手解决一个自我感觉很困难的问题的时候，那种心中满满的自信，感觉很美妙的。

当然在离职之前又接收了公司的一个后台项目的开发，算是重新把后台拾了起来；并且打算就算辞职了以后后台也需要继续学习和实际开发了；技术总是学无止境的！！！

秀一下满足感：

由于某些原因，基本上都是独立在开发apk,事实上从来公司到离职基本上都是自己在独立开发apk，目前为止自己独立完成的上线项目（算上刚开始上线后来由于各种原因放弃下线的）有5个，这估计在外行人看来很牛逼，居然一个人能开发一款软件，但是呢个人觉得缺点大于优点，优点太闭门造车的感觉，虽然自己开发项目自己决定使用什么技术，也自学过RxJava,butterKnife，okhttp等技术并运用到自己的项目中去，但是总感觉闭门造车的缺点太多了；当然在开发之余也经常阅读自己的代码然后能重构的重构之，能优化的优化之。对我来说最大的收获就是养成了任务或者某一功能完成后阅读和重构自己代码的习惯，这估计是看了《重构改善代码既有设计》这本书的影响吧，来来回回翻看了好几遍，每次看都有不同的感受和收获，在我们项目组codereview的时候我也不止一次向同事推荐过这本书，确实值得读读。参与团队开发的apk就三四个，获取看到这儿会给人一种外包的感觉，然而并不是。

在工作闲暇时间也经常在android相关网站下载大量别人的高仿源码观看，就是想看看别人怎么组织代码，怎么实现某个相同的功能，来吸收别人的经验希望弥补自己闭门造车带来的不足，收获确实很大！就算是至今也时长下载一些别人的源码来瞅瞅，如果某一个知识点不是很明白的话就研究源码或者网上查阅资料弄懂为止。

上面说到代码的重构，我觉得我在公司最大的收获或者成就（自我感觉，可能对也可能错，就算自我感觉良好吧）是把我最初来公司时候android项目应用了好几年的接口给彻底重构了一下。原来的接口封装起来怎么说呢，客观的说代码组织有点乱，太多的不必要的Impl类，太多的冗余代码和方法，经常用起来感觉扩展起来麻烦也Jude不方便，于是我自己花了半天时间研究一下这些impl类之间的关系然后算是利用了Builder模式吧，把几十个impl类全部删除了，提炼之后弄了一个ParamBuilder类来组织构建不同请求的对象并添加了上一页和下一页的功能，结合okhttp重构完成之后应用到自己独立开发的一款项目中去，简单明了使用起来很简单。后来一个同事问我要这个重构过后API的源码，也就是顺便给他了，他有没有用到开发中去就不得而知了，当然现在想想自己修改的API还有改进的空间。

其实我们常说项目经验，项目经验这四个字在我看来可不只是简单的是简历上罗列的项目的个数（也就是说项目经验！=自己参与的项目个数）；其实在开发项目的时候，并不只是完成自己的任务就可以万事大吉了，此时应该做的就是多读读自己的代码或者每隔一段时间读读自己的代码看是否有重构的地方或者有没有其他更简单的方案；或者读读团队开发中其他同事的代码并与自己的观点相互认证，总能学会点别的东西，不断的提高和锤炼自己。坚决拒绝把旧的错误带到新的项目中去！坚决不做一个代码搬运工。其实从一个项目中可以学到的东西很多，比如你可以自己把自己设想成项目经理或者技术经理的角色，如果自己是项目经理会怎么分配工作以及组织后续的开发工作，同时跟团队中的项目经理或者技术经理进行对比总结，自己哪方面可以做的对，哪方便没有考虑到；甚至如果你有心的话，开发中的文档（包括写法，格式等）也是可以让你学一点东西的。

我有时候在地铁上或者闲着的时候也会思考一些不是android的问题（这有点涉嫌无证装逼），比如自己公司项目后台用的到数据库表是怎么设计的，自己在脑海中也模仿设计一些是不是可行等等；有时候在使用一些视频播放apk观看电影的时候突然间脑海里面会蹦跶出来一根问题：为什么别人的apk刷新了很多数据还是包含海报的数据都不会OOM呢，是什么原因？为此我也会暂时停止视频的观看，特地下载相关apk反编译之看看别人怎么实现的（当然更多的时候是反编译失败）。

总之，说了这么多，意思只有一个，用心留意自己项目所开发的任务之外的东西，也是可以学到东西的，哪怕学到的东西你用不到甚至可能忘记，但总比没有东西可以遗忘好是吧，说不定以后会用的着呢！

第二个另外觉得有意思的收获是根据公司项目适配的方式，自己利用业余用java AWT，dom4j技术简单的写了一个dp值自动转换工具，用来做公司项目的适配非常方便，这也是第一款业余是自己开发工具给自己使永的软件，感觉真的很奇妙。

由于公司性质的原因，需要经常出差；第一次是跟一个北京的同事去重庆出差，这个同事在公司都尊称他为李哥，后来也跟他一起出差去参与贵州的项目直到我离职。当通知我去出差的时候我都不知道我还有机会去出差，说实话第一次出差感觉还是很新鲜的，而且是第一次坐飞机那感觉就简直了。后来的几次出差做过几次飞机后感觉就无聊了，然后出差一直都是乘坐高铁。当到达重庆后找到第三方，整个人还没弄明白呢，跟同事两个人就被对方的一个领导劈头盖脸的跟训什么似的。现在想想真是莫名其妙，然后各种喷我们的软件设计的怎么怎么滴，后来又跟同事在宾馆总结了一下对方要求的什么文档，呆了一个星期后就回来了。第一次出差学到了一个不大不小的经验并运用到以后的工作中去----出差的时候或者公司内部会议的时候很有必要带上纸和笔，要不然沟通下来还是很容易忘记或者忽略到一点重要的东西的。

发泄可以、抱怨可以，但牢记这是私底下的事儿！

后来也着手开发了一些软件，总体来说波澜不大。从15年5月份开始基本上一直着手忙活着贵州的项目，感觉跟他们打交道得做好受气的准备，好多时候都感觉很扯淡，他们让我们配置修改一点东西跟催命鬼使得，“哎呀呀，你们这个功能得赶紧弄啊”；当我有些资源需要他们配合的时候真特么跟蜗牛还慢，有的技术人员他们这边的项目协调人都指使不动，想想也是醉了。每次下班过后我都跟李哥抱怨来发泄心中的怨气和怒气！有时候发邮件的时候也会带点情绪在邮件里面，抄送给李哥的时候李哥对这种情况特别跟我做了指导，总体上是说就是对面沟通或者处理问题的是尽量控制自己的情绪吧之类的。后来跟李哥学会了怎么处理这种事情（算是比较灵活了吧或者小油条一枚），起码学会了面对这种情况邮件该怎么发吧。事实上李哥是个经验比较牛叉的同事，从他身上确实学会了不少东西；由于我们两个住在一个标间，说实话他比我的工作多的太多了，白天在贵州忙贵州的项目，晚上回来我看电影或者画画的时候他还得忙公司其他的项目到很晚，偶尔也会听到他对第三方的抱怨和吐槽，但是该做的工作还是仔细认真的完成，这点确实是值得学习的优点！想想我白天还在抱怨这怎么怎么滴，那怎么怎么滴，还真是汗颜。当然不能说后面我都没抱怨过，也会各种吐槽，只是吐槽仍然是私下里吐槽，从来没有带入到工作中去罢了。慢慢学会了心平气和的跟对方沟通了。

要学会说不！

在跟第三方对接的时候，真不能什么都满足他们的要求，该拒绝的时候就拒绝，当然拒绝的时候不是无谓的拒绝，要有理有据，这样才有说服力。刚开始贵州项目要上线的时候对方毫无道理的或者是感觉想懒省事的原因居然要求我把开发好的apk查分成3个独立的apk然后配置三个入口来启动不同的页面；当时我就怒了，先不说拆分起来很麻烦，不用拆分也可以实现他的要求。直接拒绝之！然后按照我提供的启动方式在他们的后台配置好入口一切OK；这是我第一次明确的拒绝别人的要求，所以记得很清晰；当初要是不假思索的答应他们差分成3个，上线后后来又增加的许许多多的需求，其结果简直不敢想象的！

后来也拒绝过其他项目的一些毫无道理的要求，都是有理有据的拒绝，对方也对拒绝的理由表示接受。拒绝也是需要方法滴！

最后别忘了挤点时间给自己充电

对于开发人员来说，是需要对自己不断充电的，这样才会不会做一个只会粘贴复制的程序员（其实当你在粘贴复制一个功能的时候，难道不会想到这或许是代码重构或者提炼的契机吗？），要时长吸收新鲜的血液来补充自己。下面罗列一下自己充电时阅读的相关书籍：

《android第一行代码》（算是android入门书籍，也是自己转android后阅读的第一本android书籍，大致翻翻即可）

《android群英传》自己出差期间周末闲着没事逛书店的时候免费翻看完了 ,里面的有些东西也是可以借鉴的。

《android内核剖析》这个书比较深，当然有些章节还是可以查看的

《android开发艺术探索》（android进阶用比较不错，也是自己时不时查阅的书籍）

《android设计模式源码解析与实战》（这本书写的很好，很实用，对android源码中用到的设计模式进行了说明，极具阅读价值）

《代码大全》：这不书很厚，厚不仅是指页数多，内容也很“厚”，里面好多项目经验和代码经验可以参考应用到实际项目中去；简直是一个词典。

《java编程思想》：这本书不论何时都是查阅相关资料的经典书籍！

《Effective java》：也看了几遍，每次查看都有收获。

《重构，改善代码既有设计》：这本书前前后后翻看了好几遍，上面的例子在看第一遍的时候也都敲了一遍，是很牛逼的一本书，很值得开发人员读一读。

《java多线程编程》：这本书也是比较经典的，单独来看的话会比较枯燥，我第一看的时候看到了一半就看不下去了；但是后来结合ImageLoader和picasso的源码在查阅这本书，顿时感觉收获满满，目前列为以后必读书籍之一。

《java8实战》这本书也感觉不错，对java8的学习很有帮助，目前还在阅读学习中，这本书是出差的时候周末没事去书店逛荡，然后看了一部分顿时感觉很有买的必要就果断入手了。

《人月神话》：大学时候看过，没看懂；目前又买了一本正在翻看中。

《人件》：这本书看起来，怎么说呢，也是每次看都有不懂的感受和收获，算是比较经典的软件工程类的书籍了。

《程序员你惹不起》：业内牛人的经验总结，算是一本程序员鸡汤书籍，闲暇的时候也可以读读。

android和java开发优化方面的书籍也翻阅了那么几本，并且收获还不错！什么groovy、Python，nodejs也自学过（甚至nodejs论坛的源码也读了个遍），不过没怎么用到项目中去，估计都忘了，技术这玩意不用就忘很正常。

当然也不能总是被技术开发封闭了眼界，一些其他有用的书籍也是可以看看的

《在小吃店遇到凯恩斯》《王二的经济学故事》《微观经济学》等经济类书籍也可以读读，开阔眼界或者用来装逼用也是好的！

总之要不断有意识的学习和扩展视野

在这两年多的时间里也着实写了好多篇技术价值一般般的博客，虽然技术价值不高，但是写博客这个习惯我觉得我还是有必要保留下去，多做总结总比不总结强，当然也要提高写博客的质量，即可装逼也可提高自己对技术的理解何乐而不为呢!

自己的失

有得就有失，由于自己转了android后完全放弃了对后台开发的研究和学习导致好多后台的东西都忘光光了，虽然后来在android开发期间也开发了一个后台，但是好多知识点还是忘光光了，现在在重新拾起来还真得下一番功夫！

还有正如什么所说，自己团队开中的经验相对而言有点少了（虽然也参与了公司几个项目的团队开发），算是比较缺少团队开发中的沟通交流的经验吧！前面虽然对重构做了很多的讲解，其实在自己开发的几个项目中，现在只有最后一个项目的代码组织还像点样子，还算比较满意吧。其他的项目虽然也做到了部分提炼和重构，但是整体上代码看起来还是很混乱，因为前期的考虑不是充分，现在要全面的提炼或者重构的话会也会花费不少时间和工作量，当然我不会再对他们进行重构了（虽然脑海里也有些感觉不错的组织方式）从某方面来说设计模式这种东西理解了思想灵活运用之更重要，就用这些组织混乱的代码作为失败产品，以此为鉴吧！

还有一个自我感觉很失败的地方：就是从头到尾没有主动跟领导提过加薪的要求（口笨，不知道如何开口，鄙视下自己）。

总结就到此吧，感觉写的乱七八糟的毫无章法

顶

4

踩