xueling 最近的时间轴更新
xueling

xueling

V2EX 第 641078 号会员,加入于 2023-07-31 07:39:05 +08:00
xueling 最近回复了
太多参数不好,完全没有复用性。
@yanzuwu 完全开源,放心使用,全程提供免费技术支持~~
了解一下我的开源项目: https://github.com/xl-xueling/xl-lighthouse ,不基于 SQL 实现,不过集成了指标计算、指标存储、指标管理和指标可视化等功能,开源免费、功能强大、使用方便。复杂的报表自定义设计等功能,我现在正在开发,不过属于商业版的功能。当然如果你非要基于 SQL 的方案,那请忽略~
12 天前
回复了 txzh007 创建的主题 程序员 如何平衡开发效率和代码优雅性?
1 、原来的代码暂时不动,通过简单修改包路径防止互相交叉,新写的代码完全按新逻辑开发,要充分考虑兼容老代码逻辑,保证按时完成;
2 、陆续按模块迁移老逻辑的代码到新模块中,这个过程的进度完全根据自己可支配时间决定,然后陆续删除老逻辑;
3 、工作汇报、周报中尽量避免用 “代码逻辑优化、重构”这种模糊字眼,要不然就算你做了再多别人也会认为你在摸鱼。
4 、评估排期时,实际所需时间和评估时间,要尽量控制在 2:3 以内,这样你剩余的时间可以充分进行想要去做的优化工作;
5 、设计数据库字段、表结构、接口协议时要充分思考,因为这些地方设计的不好,上线后再改可就麻烦了。
13 天前
回复了 JsGuiGe 创建的主题 推广 一个小团队整出来的,颠覆会计行业的 App
支持,看着做的挺好的,小团队确实不容易,可以用我的开源项目快速搭建数据化运营体系,辅助产品迭代,https://github.com/xl-xueling/xl-lighthouse 我的项目开源免费、功能强大,使用方便~~
行业发展健全的同时,也会让程序员的”工具人“属性愈加明显。越来越多的程序员都是没有基础的,而只是一种或几种的工具运用者,既不了解某种技术的由来,也不能预判未来发展的走势。程序员还是应该更多的保持思考,否则真就成了工具人了。另外,lz 也可以了解一下我的数据统计项目: https://github.com/xl-xueling/xl-lighthouse
心理方面、身体方面的原因肯定是有的,但如果 80%的时间都在短视频上面,我觉得不光是这些方面的原因,懒惰是人的本性,我也在很长很长的时间里跟你一样,但现在不同了,天天跟打了鸡血似的,每天都觉得时间不够用。根本原因就是一点,你目前还没有找到一件愿意长期投入、执着去做的事情。总之,要给自己找一件值得长期投入的事情。可以了解一下我的开源项目: https://github.com/xl-xueling/xl-lighthouse ,欢迎使用~~
16 天前
回复了 beryl 创建的主题 程序员 技术方案讨论,移除实时日志中的敏感数据
对于这种处理方式,并不是特别认同,此类问题更应该从源头进行修正,而不是采取这种“补救”措施。
17 天前
回复了 nnegier 创建的主题 程序员 怎么应对复现不了的 bug?
说一下我的看法,这种问题排查不要只从能否复现的角度处理,应该主要从两方面着手,1 是日志,2 是监控。
1 、app 程序层面的问题,分为普通异常日志和崩溃日志,一般来说异常类日志都有较完整的调用链信息,定位问题相对容易。但造成崩溃的原因比较多,可能是内存问题,用户设备问题、也可能只是某个参数校验失败或空指针异常处理不当导致的,不同情况下崩溃日志有可能完整也可能不完整。所以从日志层面上可以添加全局的异常信息捕获,并将全局异常日志上报,防止漏掉异常信息,而导致排查无从下手。
2 、app 的异常监控体系不完善,可以使用我的开源项目,快速搭建起异常监控体系,https://github.com/xl-xueling/xl-lighthouse ,基于通用型流式统计实现,接入方便、使用灵活、性能强大,轻松实现任意细粒度、任意维度的数据监控。将手机型号、手机系统版本号、app 版本号、页面、模块、错误码等关键信息上报。全面监控各类异常的次数和频率等信息(我自己感觉我的开源项目是应对这类问题业内最强大的工具了~~)。

总之,我觉得 app 问题处理,侧重点应在两方面:一是全局异常日志(代表你没有正常处理的异常),二是普遍性错误(比如:某个 app 版本或某个机型错误率或崩溃率在 0.5%以上的异常),公司内部可以对异常阈值确定一个标准,比如灰度时发现影响超过 0.5%的用户的异常必须测试人员复测解决,该版本不能继续发布,而影响范围较小的偶发性问题、不容易复现的问题,可以暂时忽略或陆续解决。要做到应对领导的所有盘问一切以数据说话,只要日志和监控体系建立起来,你对线上故障的驾驭能力会得到极大的提升。
@zhoudaiyu 光测试我倒觉得用处不大,很多线上环境中的问题,测试服务暴漏不出来。不要觉得云服务多么完善似的,人家只分配给你固定资源,不要想当然以为出了问题这些云服务厂商会一直给你排查。他们只处理整个集群层面的问题,如果只有你自己的服务出了问题,主要还得自己处理。就像你说的线上故障,本身定位到 pid_max 的故障原因都花了很多时间。线上问题的排查需要逐一排除各种可能的原因,云服务厂商有可能给你提供全方位的服务吗,毕竟对于云服务厂商来说,这里面涉及太多比如用户数据隐私、人力成本等等因素了。你说的监控告警指标,网络搜集就足够了,比如: https://cloud.tencent.com/document/product/457/39820 你自己网上找找,把这些云服务的监控指标汇总一下就 ok 了。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3317 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 17ms · UTC 05:04 · PVG 13:04 · LAX 22:04 · JFK 01:04
Developed with CodeLauncher
♥ Do have faith in what you're doing.