有一套 web 系统, 会部署到不同的服务器上分别运行, 这套系统类似于市面上的 OA 系统一样, OA 开发商会给不同的企业客户部署一套独立的互不关联的系统, 我维护的这套系统也差不多, 分别被部署在互不关联的服务器上, 当然, 这些系统的代码是同一套, 功能也都是相同的.
前两天, 有客户反馈, 他们系统的某个功能无法正常使用. 我开始排查问题, 发现部署在其它服务器的系统这个功能都是正常的, 唯独这个客户的系统存在问题. 而据我所知, 这套系统功能上对于所有客户都是一视同仁的, 是不存对于不同客户有不同功能的情况, 因为部署在所有服务器上的代码是同一份.
刚开始以为问题是代码不同步导致的, 后来反复确认出问题的那套系统的代码的确是最新. 可为什么大家的代码都是一样的偏偏就它有问题呢? 而出现的这个问题是纯业务逻辑上的问题, 跟服务器环境是不相关的.
反复查看代码, 反复检查配置文件, 反复在开发环境中调试, 始终找不出个所以然来, 百思不得其解.
最终我不得不祭出只有在尝试了所有方法后依然无法奏效万不得已才会去使用的杀手锏: 线上调试.
我登上服务器, 编辑代码文件, 在我认为容易定位到问题所在的代码位置加上打印数据的语句, 然后运行出问题的功能, 观察出问题的数据. 在这里我要感谢运维, 感谢 PHP, 没有他们的帮助, 我还要绕个大圈圈才能干这事.
然后以我观察到的数据为线索, 一步步的向上追踪问题代码, 最终发现, 在某一个很深的角落里, 静静的躺着这样一段代码
- if($_SERVER["SERVER_NAME"] == "192.168.110.233" || $_SERVER["SERVER_NAME"] == www.xxx.com"){
- // 问题系统消失的功能的代码
- }
看到这段代码我心里万马奔腾, 气不打一处来, 并且狠狠的骂了一句: CMNLGB. 紧接着, 一股深深的无力感涌上心头.
使我受尽折磨, 并且付出一下午美好时光的 BUG 居然是由这么一个在正常的代码中绝不因该出现的脑残的条件判断引起了. 不值得啊.
我很想怼写着段代码的程序员, 但是这个任务我完不成了, 因为她离职了, 我就是从她手里接手这套系统的.
于是我去除代码中的这个条件判断, 同步代码, 出问题的系统能正常运行了.
冷静下来以后, 我思考这个问题. 毫无疑问, 对于这个问题, 写出这段代码的程序员当时面对的需求应该是让某个功能只在部分服务器上部署的系统中体现, 于是这个脑残的条件判断应运而生.
如果是我实现这个功能, 我可能会在配置文件里加一个具有描述性名称的 flag, 然后在代码中读取这个 flag 进行条件判断.
然而, 这样做能从根本上解决问题吗? 显然不能. 假如我面对的是这个改进版本的条件判断, 顶多能让我有几率加速定位到问题所在, 也就是我查看配置文件并且眼尖看到了这个配置项目就能明白事情的真相. 如果我不去看配置文件, 或者没有看到这个配置项, 那么到达目标的路径依旧不会有变化, 而且这是大概率事件, 因为这次出现的问题的特殊性, 很难让人将它和配置文件中的配置项联系到一起.
那如何做才能从根本上避免这个问题?
为项目维护一份文档? 不太现实, 代码都来不及写, 哪有时间写文档.
离职交接时把注意事项说清楚? 不太现实, 离职交接都是交接一些宏观的内容, 代码上的细节不可能在这个范围之内.
规范化项目管理, 功能迭代流程, 更新系统功能需要审核? 不太现实, 部门中这样的项目大大小小几十个, 这样做成本太高了.
不给做这样的需求? 更加不现实, 人家需求方分分钟投诉到大领导那, 让我们吃不了兜着走.
那究竟怎样做才能避免这类问题, 才能让我愉快的写代码, 求各位大神支招, 在下感激不尽.
来源: https://www.cnblogs.com/aspwebchh/p/8807654.html