2017年度总结

Author Avatar
XibHe 12月 30, 2017
  • 在其它设备中阅读本文章

转眼间2017就要结束了,回首过去的一年,有过彷徨,有过不安,也有收获的感动与喜悦。过完17年我就拥有四年开发经验了,一直觉得四到五年的阶段是区别高级开发与初中级开发的分水岭。但这并不使我感到高兴,我深知这四年时光中一多半是在蹉跎中度过的。往之不谏,来者可追!2018!我来了。

家庭

对我这个年龄来说,结婚的很少,更别提孩子了。但我已经为人夫,为人父了!似乎用两三年的时间走完了别人十几年的路。太过年轻的我,总会时不时忘记自己身为父亲的责任,我媳妇(花花)总会不厌其烦的唤起我作为父亲该承担的责任。家里的大事小情,在花花的安排下井井有条。孩子的奶粉,尿不湿也不用我来操心,为了分担我的压力,花花早早给儿子断了母乳,离家挣钱。对花花我即心疼又愧疚,我不能一直用年轻作为借口,逃避身为男人的责任。家庭永远是第一位

每个人都有属于自己的人生遥控器,它无时无刻不掌握在你自己的手中,你可以随时按快进键让时间从你的手中逃走,你也可以按回退键,想想自己曾经的错过与失误,你也可以按跳过键,它的另外一个名字叫做逃避…… 从前有个精灵一直在寻找彩虹那端的金罐,但最后,他发现那只是一罐麦片。

博客

年初给自己定下了一个目标:每周至少写一篇博客。到目前为止,算上这篇,一共是25篇。这25篇文章中,有5篇是译文,5篇是个人感悟,剩下15篇是技术上的分享。技术上的分享有些很肤浅,和大咖们由浅入深的技术文章比起来有些相形见绌。但我还是会坚持写下去的,须知泰山非一日之功。

写一篇鞭辟入里的爽文真的很费时间,前期需要阅读大量的相关文章,技术文档。最难得还是将所要描述的知识点与实际的代码,产品需求结合起来。因此,当你在自己的项目中解决了一个棘手的bug,或者实现了一个复杂的产品需求时,你再将这些解决问题的方案写成博客,就会有一种“下笔如有神”的感觉。就好比最近写了一篇名为利用JenKins持续集成iOS项目时遇到的问题博文,通篇写下爱特别顺畅。因为这些流程都是我切身经历过得,在这里也只是再复述一篇操作流程而已。

相比之下这篇文章 — AFNetworking到底做了什么? 写起来就不那么顺利,自己没有切实经历过,整个AFNetworking的源码,马马虎虎的读了两遍,不能透彻理解其中的精髓。也只能转载别人的观点。

自从给自己定下了一周至少写一篇博客的目标后,每到周末就特纠结,搜肠刮肚的想着如何结合实际开发构思出一篇好博文。有时实在没有好的点子,就翻译Medium湾区日报上推荐的英文文章,或者写一些个人心得体会。

今年写的一些技术性文章也有不尽如人意的地方,有些文章,写的很粗浅,没有刨根问底追溯到本质上。有些文章是迫于一周要写一篇博文而拼凑成的,今年不会如此只求量而不求质了。但以文字的形式记录分享开发心得的习惯,一旦养成,就不会轻易舍弃,这算是2017年一个明显的收获吧!

读书

今年看完了《图解HTTP》《黑客与画家》《软技能:代码之外的生存指南》。正在看的有《人类简史》《啊哈!算法》。看《啊哈!算法》时,看的快忘得也快,还是没有结合实践,将书上的算法,用代码实现一遍。

黑客与画家

在这些书中,《黑客与画家》这本书书对我启发最大,里面很多论述让我有种醍醐灌顶的感觉。现在回想起来,书中很多内容已经忘得差不多了,唯一记得的是:编程和绘画一样,是需要走心的,需要绞尽脑汁去构思的。

偶然在知乎上看到你是怎么看完《JavaScript权威指南》《JavaScript高级程序设计》等这类厚书的?的提问,摘录其中一个赞同数最高的回答:

与其说看书不如说看目录,从目录里找到感兴趣的章节,看掉,看到中途没兴趣了,就放下下次再看。工作中碰到什么问题不明白需要参考了,还是看目录,才大概会在什么章节里,探索一番,中间如果碰到感兴趣的,看掉,看到中间没兴趣了,放下,下次再看。要不了多久,整本书的70%-80%都翻遍了,其中有20%-30%翻了不止一遍,这些往往是核心的知识;至于剩下的20%没看过的,以后或许有机会的,没机会也不要紧,很多时候自己已经通过各种机缘学到了。

所以看技术厚书不在于多块或多慢,而是从容。

其中,我认为结合书中知识点,理论联系实践是最为有效的掌握知识点的方法。读一些非技术的书籍,最重要的是能够让自己心安。

此心安处是吾乡

关于买书,今年没有买一本书。因为去年买的书,大概有七八本吧!只看完了三本,还有向公司申请采购的3本技术书籍,手中库存的书足够我看了。2018年在此立一个flag:看完6本书!

新部门

今年12月份时被调到一个新部门,开始接触到公司最为核心的项目。想想就有些小激动啊!因此,也会给自己提出更高的要求,写功能模块时要注意与其他功能的耦合性,兼顾需要考虑程序的性能,容错机制的相应。现有的开发模式,耦合性太高,如何实现高可用的组件化,降低功能模块间的耦合性?将是我们这个团队在18年需要重点考录的问题。希望能为这次项目模块的优化重构尽自己的一份力量。

新技术

9月初接触微信小程序,和部门另外两个H5一起开发公司的一款小程序。中间吃了小程序产品原型还是是基于原生App思维而设计的亏,同时,也由于自己没有完全吃透小程序开发文档,在实现一些功能时踩了

这次小程序开发经历使我意识到自己的技术短板,陷入对技术的狂热之中。因为崇拜某项特定的技术,只是因为自己熟悉这种技术。我很自然的会相信自己选择的是最好的,然后这会让我经常忽略一些与之相悖的意见。由于不了解其他技术,就倾向于选择自己最熟悉的技术并先入为主的认为它是最好的。因此陷入了对自己熟悉技术的狂热之中而无法自拔。这样只会使我们变得自以为是,固步自封,墨守成规。自以为找到所有答案,却只是裹足不前。

请勿陷入对技术的狂热之中

若是早已习惯了这种堆代码、堆逻辑的开发流程,渐渐麻木,在技术上不再积极进取,不再学习新技术。这种开发者被称为“码农”,“搬砖工”。很不幸,我自己就是这样的“码农”。

2018年,新的一年,要在原有技术的基础之上找到突破口,将自己以前囫囵吞枣的知识点再好好品味一番。同时,也不能仅仅局限于iOS一方面的技术。

今年最直观的感觉是自己对于新技术的渴望,缺少那种如饥食渴的痴迷感。苹果开发者大会上的ARKit,CoreML,SiriKit这些新技术,对于我这个iOS开发者竟然毫无吸引力可言。这是我身上存在的一个大的缺陷,也是程序员堕落,不思进取的开始。对于程序员来说,最大的悲哀并不是35岁后被华为辞退,也不是42岁后跳楼。 而是:

不再向往新技术。

stay hungry,stay foolish.

愿景

家人朋友身体健康,自己技术日臻成熟。

–EOF–

若无特别说明,本站文章均为原创,转载请保留链接,谢谢!