由于最近工作比较忙,今年的这篇心得比往年来得更晚一些,职场三年多了,每一年都有着不一样的收获,不一样的感悟,回看前两年的分享,依然觉得很有价值,有兴趣的小伙伴们也可以看看去,《写给新入职的毕业生们》 和《写给新入职的毕业生们(二)》。
希望今年的分享依然能够帮助到大家,我还是采取条款式的模写作式吧。
1. 有 “特点” 的程序员,会很吃香
这一条理论可以用于千千万万的行业,如左右脚均衡、长传精准、善于突破的足球运动员;声音有辨识度、曲风独特的歌手;长相有特点、个性鲜明的演员;而在互联网行业,也是一样一样的,下面就拿 Android 程序员举例。
我记得很早的时候,就发过这么一条微博:“ Android 开发,本身并不是一个可以走得多远的方向,真正有价值的地方在于与具体的业务方向结合,比如:Android 与音视频技术,Android 与智能硬件交互,Android 与前端技术的融合与探索,Android 信息安全,Android 源码深度定制等等……早日找到一个感兴趣的方向,深入探索和积累,而不仅仅局限于研究 Android API 本身,这样才能走得更远,才能有更好的前途。”
前段时间,组里招了一个 Android 小伙伴,他不仅仅是熟悉 Android 应用开发,更重要的是他对 OpenGL 有着很深的研究,进来后,在 Android Camera 采集、美颜滤镜、GPU 加速方面做了非常多的优化,极大地补充了整个团队技术栈的深度,我后来无数次地感慨,幸好招到这么一个人,怎么就这么幸运地招到这么一个人了。
所以,要让自己在团队里更加有 “存在感”,要想将来的发展越来越好,你就不应该只满足成为一个会写 App 界面的 Android Programmer,而是要差异化地 “积累” 自己感兴趣的技术,并且成为这个领域的专家。
2. 严格要求自己,不要犯 “低级” 错误
最近有跟第三方合作,用了他们的库,各种 “低级” 错误多次激怒了我,有 NULL 指针异常、有参数配置不生效、有设置了消息回调却没有回调、每次修复 Bug 后又带入新的 Bug,等等等等。
虽然他们做的功能总体来说是很牛逼的,但是这一系列的 “低级” 错误,一次又一次地拉低了我对他们技术的认同度和信任度。
我始终认为,代码中有 Bug 是难免的,但是无论是写 C,C++ 还是 Java,避免 NULL 指针 crash,函数形参检测,这些都是一个成熟的程序员的基本技能,不应该找任何理由和借口。
3. 善于总结排查问题的工具和技能
今年我有遇到一些客户的 Android 开发者,竟然不知道如何在命令行下用 adb 打 log 或者不知道怎么过滤 log,着实让我感到惊讶,打印和分析日志也是程序员的一项基本功,而且我们还不应该仅局限于此,我们还应该在工作中不断去积累一些有用分析手段、分析工具和网站,比如:
- 如何检测 Android 的内存泄漏、CPU 占用、Memory 占用
- 如何用 ndk-stack 分析 Android Native 库的 crash
- 如何用 wireshark , tcpdump 抓包以及分析协议问题
- 如何用 curl, dig, mtr, telnet, netstat 等命令排查网络问题
- 如何验证 YUV 数据、PCM 数据是否正确
- 如何分析 RTMP流、HLS流的异常、卡顿、时间戳等问题
- 收藏一些不错的工具网站,如:http://www.17ce.com,http://ip.cn/,http://www.speedtest.cn/ 等等
我们公司有一个技术支持小伙伴,让我们所有的研发都很惊讶,排查客户问题特别快,回答常见问题基本都是秒回,后来我们才明白,原来他那里有着一套自己的 “数据库”,并且还有着一套一套的排查技巧,前段时间还专门被邀请给全公司的人做了一次培训,真心很佩服并且很看好他的发展。
4. 解决问题不要抱有侥幸心理
写代码的时候,我们可以加些参数和状态的判断,提高程序的健壮性,而解 bug 的时候,一定要找到根源,而不是说我加了个保护应该就不会出现了。
这是 “血” 的教训,不彻底查到根源,你真的会睡不好觉,或者一次次面对客户的鄙视和测试妹子无语的表情……
套用小伙伴的一句话:‘’程序世界里,要正确地对待错误,而不是想尽办法掩盖,否则要花巨额的成本来追根溯源。做人其实也一样。‘’
5. 永远要设定 deadline,完成比完美更重要
我很喜欢这句话,但是我也深深被 deadline 所困扰过,互联网的加班,绝大多数都是因为这个 deadline 带来的,有的时候是程序员自己过于乐观地估计时间、有的是迫于市场、销售、老板的压力,但是身在互联网行业,我也真实地感受到很多时候真的是时不我待,而我们能做的,就是要有一套自己的 “优先级”,先出版本,再谈优化。
有的时候,懂得合理地细化任务,也是一种能力。一般我拿到一个大的需求,肯定会把它细化成一个个小的任务,并且按照如下标准来进行分类和排序,甚至给出每个小任务的 deadline :
- 基础模块,其他工作需要依赖此模块
- 涉及到接口的定义或者修改的工作
- 当前必须支持的功能点
- 可以后期增加的功能点
- 可以后期优化的地方
当然,根据实际情况还可以继续细分。每当做完一个小的任务,就会先充分地测试,保证其正确性和稳定性后,保存一个版本,当必须支持的功能点完成后,至少已经有了一个可交付的版本了。
这里还需要强调的一点是,“完成” 并不是说带着很多 Bug 的完成,而是说一个稳定但不一定功能齐全的版本,因此,千万不要用 “完成而不完美” 作为忽略交付质量的借口。
6. 知其然也要知其所以然
这是一个老生常谈的话题,但是确确实实很多人没有做到,特别是在面试的时候,经常遇到很多人对自己亲自做过的东西理解完全不够,这可能是一个态度问题,不愿意花时间去钻研,或许这种钻研的确是一个比较费脑细胞的过程,但对于那些对技术充满热情的人,其实是一种享受。
这里举个我面试的例子吧,凡是简历中写自己 “做过” 播放器的候选人,我一般会问这 3 个问题:
- 从传入 URL 到第一帧视频渲染成功的整个流程
- 播放器有几个缓冲区,如何管理的,如何设计的
- 音视频同步是如何实现的
每个问题都可以再深挖几层,基本上可以判断其掌握程度和钻研精神,会用第三方播放器的人很多,会用 ffmpeg 的人也逐渐变多,但能改 ffmpeg 能自己解析流媒体协议,能自己编写出播放器的人,才能成为这个领域真正的大牛 。
7. 不要不加思考地提问
这貌似也是一个老生常谈的话题,想起最近我们跟客户的一段对话:
客户:“你们直播 SDK 的美颜模块有没有丰胸的功能 ?“
我们:“嗯,不仅能丰胸,我们直播 SDK 还很快就能在没网络的情况下推流了……”
请大家要尊重帮你解答问题的人,特别是网上那些并没有义务帮你解答问题的 “大牛” 们,遇到问题,自己要有一些基础的分析和排查。
记得我们的技术支持曾私下感慨过:“有2类客户的问题一般会得到优先和快速的解决,一类是超级大客户,另一类是问题描述得很清楚,自己有初步的分析和排查的客户。”
8. 总结
先分享到这儿吧,其实大脑里还有很多感悟,限于篇幅,就留到下次吧,欢迎大家关注我的微博 "@卢_俊",干货很多哦,当然,你也可以关注我的微信公众号 "@jhuster",获取最新的文章和分享。
转载于:https://blog.51cto.com/ticktick/1852932