索尼Xperia|程序员平时的工作如何体现一个人的技术深度?

索尼Xperia|程序员平时的工作如何体现一个人的技术深度?


思考:做需求与做需求的差异
再回答问题之前 , 我想先抛开「技术深度」这次词 , 讲讲做需求这件事 , 说说我对做需求的理解 。 每一个程序员都是从刚毕业做需求开始 , 为什么有的人逐渐成为大牛 , 主导大型技术项目或走向团队管理岗位 , 而有的人一直还在做需求 。 我觉得这里面的差异在于 , 每一个对做需求这件事的理解有所不同 。
这里面的差异在于 , 你是抱着一种什么样的心态去完成这个需求 , 是把这个需求做到极致 , 还是只是当做任务完成这个需求 , 达到产品想要的功能就行 。 这两个表面上看似差不多其实相差极大 , 差异在于 , 你有没有站在更高的角度 , 希望这件事做到完美 。 从需求角度有没有思考产品设计当中的缺陷 , 能不能反向为产品设计提供建议 , 从技术角度能不能做到高质量高兼容性无bug , 以及下次再有类似的需求能不能快速高效率的迭代 。
用一句话来描述就是 , 能不能跳出自己是一个程序员是一个被动执行人的角色 , 而是将自己当做产品当做技术负责人的心态去做这件事 。
业务需求该怎么做知易行难 , 如果一开始做不到 , 那就先着眼小事 , 关注细节 , 从需求开始的需求评审 , 编写技术方案文档 , 设计文档 , 到开发的代码注释 , 结构设计 , 保证高质量 , 完善无漏洞的代码逻辑 , 再到异常埋点 , 指标监控 , 线上可用性运维等等 , 认真对待一个需求的每一个环节 。
当你自认为已经做好整个流程的每一件小事之后 , 接下来可以 通过深入细节 , 思考整个流程是否存在问题 。 做需求过程中沟通协作的有没有问题 , 流程规范的有没有问题 , 机制环节哪方面问题 , 代码公共基础能力的是否有缺失 , 开发过程中你所遇到的问题是不是一个通用问题 , 能不能抽象出一个公共库解决大家的问题 , 能不能制定一个SOP的解决方案流程 , 亦或是提炼出一个最佳实践在组内外分享经验 。
通过这些一件件小事来锻炼自己解决问题的能力 , 以及更深层级的发现问题的能力 。 再通过不断的发现问题 , 思考问题出现的原因 , 拿出解决方案 , 最终落地解决了自己或组内或协作方的问题 , 锻炼自己的综合能力逐步慢慢成长 。
再说「技术深度」说了这么多 , 你可能会说 , 这跟我问的技术深度有什么关系?我想说:抛开业务需求谈技术深度都是耍流氓 。
举一个例子 , 数据可视化方面3D three.js , 视频直播方面的编解码压缩 , 客户端安全方面的攻防渗透 , 每一个都是有技术深度的事情 , 但问题是即使你掌握了这些领域拥有了非常高的技术深度之后呢 , 不能应用于业务需求 , 不能解决产品急迫要解决的问题 , 不能完成你老板的OKR , 达成部门的战略目标 , 还是英雄无用武之地(当然你也可以选择一个可以用得上的团队 , 那是就是另外一回事了) 。
由于这些单点的有技术深度的事情 , 不能为你带来直观和显而易见的 「回报」(也就是颜如玉 黄金屋与金榜题名) , 也就间接的打击了积极性(当然自己对某门技术感兴趣而钻研的不再本次讨论之列) 。 所以提升自己的技术深度 , 最好的方式还是在公司业务中 , 发现有深度的事 , 然后去在攻克这个问题的过程中 , 提升了自己的技术深度 , 即跟随公司业务的发展的同时自身也获得了成长 , 你用技术能力为公司解决了业务发展过程中的问题 , 自然也就从公司获得了该有的回报 。 这是一个ROI投入产出比最高的获得技术深度的方式 。

相关经验推荐