写代码，从来不是程序员的职责！

“我已经按文档上那样做了，

 但是好像依然不生效”

一

我经常在一些新手开发口中，听到这样的话。好像他已经做了他能够做的所有，但是问题依然存在。

如果你是一个谦逊的程序员，你需要假设每个问题，都是因为你的失误导致的。事实证明，大多数情况下确实如此，当你抱怨某个第三方 SDK 的接入失败，可能只是你遗漏了文档中某个重要的环节；当你疑问某个 API 在某些设备上为什么没有生效时，可能只是因为你不了解它的使用边界。

可加入这真的不是你的错呢？如果错误真的发生在第三方 SDK 中呢？你要记住，哪怕错不在你，但这仍然是你的责任。

程序员的职责

作为程序员，职责应该是按需求高质量的完成功能，有时候会要求优雅的完成它。具体写了多少代码，从来不是程序员的 KPI。

写代码的工作量，并不是程序员的有效产出，在实际工作中，我们写了多少无效的代码？那些最终被我们删除的代码，带不来任何实际的产出。

那什么是程序员的产出？你实现的那些需求，特别是那些，最终在产品中被长期保留的需求，它们才是你的有效产出。工作中，从来不关心你有多辛苦，做了多少工作，大家只关心最终的结果。

在年底考核时，那些考核得分高的程序员，看看都是写的是什么评价？开发速度快、延期少、Bug率低，哪怕是和其他岗位的 Peer Review，说的更多的也是和产品经理、设计师沟通是否顺畅。

在你负责的产品中，所有与技术相关的问题，哪怕错不在你，但这都是你的责任，你要承担它，解决它。

推进解决问题

即使问题发生在其他地方，你仍然有责任去处理它。

1. 错误来自第三方

一个 App，从来不是一座孤岛，我们不会重复的制造轮子，而是会优先使用第三方提供的标准服务。有时候错误来自第三方 SDK，这很常见，毕竟大家都是程序员。

当错误来自第三方时，我们能做什么呢？

• 重读文档，排查是否有不起眼的细节被遗漏。

• 定位问题，查看是否有新版本已经解决该问题。

• 如果这是你发现的新问题，反馈错误报告，并协助他们解决。

• 在代码中添加一些变通的办法，确保这不会让你的应用崩溃。

错不在我们，我们也可以尝试推进解决问题。

2. 来自运行环境的问题

作为客户端开发，我们写的代码都是要运行在用户的设备上。此时运行的环境，可能直接导致我们的产品质量，例如：低内存的情况下更容易崩溃，较高的系统版本中已经修复的 Bug 代码依然运行在较低的系统中，厂商修改的 ROM 导致一些偶现的崩溃。

当一个崩溃能够稳定复现的时候，我们可以通过 Debugger 的方式解决它，怕就是怕一些，我们无法还原现场的那些偶现 Bug，他们只有在一些特殊的场景下才会出现，例如只出现某些设备上，只出现某个系统版本上，但是又不是只要满足这个条件就必现的。

此时怎么办？只能靠技术手段去攻坚，去分析出现崩溃的原因，能够修复的就修复，实在没办法的也要想办法规避。

3. 一些技术无法覆盖的错误

技术有时候确实有局限性，也许在某些场景下真的做不到，也许是解决它的代价太高。此时想一个你能做到的方案，提出来。

这些方案，你让产品去想，大部分情况真的是想不出来。他们不知道技术的边界在哪里。技术方案只能由你这个负责技术的程序员提出来。

必要的时候，技术攻坚是我们的职责，可同时解决问题也是我们的职责。工作中，程序员不是只靠技术手段来推进工作，沟通也可以。

这都是你的责任

当你把代码加入到某个产品中时，与此相关的技术问题，都是你的责任。因此，请认真对待你的责任，承担它并解决它，无论这是谁的错。

本文对你有帮助吗？留言、点赞、转发是最大的支持，谢谢！

---

「联机圆桌」????推荐我的知识星球，一年 50 个优质问题，上桌联机学习。

公众号后台回复成长『成长』，将会得到我准备的学习资料，也能回复『加群』，一起学习进步；你还能回复『提问』，向我发起提问。

推荐阅读：

“寒冬”正是学习时|关于字符编码，你需要知道的都在这里 | 分词，科普及解决方案| 图解：HTTP 范围请求 | 小程序学习资料 |HTTP 内容编码 | 辅助模式实战 | 辅助模式玩出花样 | 小程序 Flex 布局