由于最近工作比较忙，今年的这篇心得比往年来得更晚一些，职场三年多了，每一年都有着不一样的收获，不一样的感悟，回看前两年的分享，依然觉得很有价值，有兴趣的小伙伴们也可以看看去，《写给新入职的毕业生们》 和《写给新入职的毕业生们（二）》。

希望今年的分享依然能够帮助到大家，我还是采取条款式的模写作式吧。

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"，获取最新的文章和分享。

本文出自 “Jhuster的专栏” 博客，请务必保留此出处http://ticktick.blog.51cto.com/823160/1852932

写给新入职的毕业生们（三）