xueling 最近的时间轴更新 xueling 最近的时间轴更新 | xuelingV2EX 第 641078 号会员，加入于 2023-07-31 07:39:05 +08:00 |
dtstep.com
| coze 要收费了，还有什么替代方案推荐吗? 程序员 xueling 2024-07-04 14:41:55 PM 最后回复来自 MaKuRo | 37 |
| 开源 B 端大数据项目 xl-lighthouse，欢迎大家点评一下 开源软件 xueling 2024-04-03 12:45:29 PM |
| 开源 XL-LightHouse 与 Flink、ClickHouse 之类技术相比有什么优势 Java xueling 2023-08-16 14:22:12 PM |
xueling 最近回复了
2024-09-22 18:14:36 +08:00 回复了 vertigo 创建的主题 奇思妙想 想做一个低代码表格平台,请教大家有没有竞品 |
可以 github 搜索了解一下我的开源项目：xl-lighthouse
2024-07-11 11:10:32 +08:00 回复了 awesomePower 创建的主题 Java 一个方法很多参数，算是好的设计还是不好的设计 |
太多参数不好，完全没有复用性。
2024-07-10 12:46:38 +08:00 回复了 NiGuAnHeShang 创建的主题 程序员 各位爸爸，有没有开源的报表推荐？？ |
@yanzuwu 完全开源，放心使用，全程提供免费技术支持~~
2024-07-09 18:20:29 +08:00 回复了 NiGuAnHeShang 创建的主题 程序员 各位爸爸，有没有开源的报表推荐？？ |
了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse ，不基于 SQL 实现，不过集成了指标计算、指标存储、指标管理和指标可视化等功能，开源免费、功能强大、使用方便。复杂的报表自定义设计等功能，我现在正在开发，不过属于商业版的功能。当然如果你非要基于 SQL 的方案，那请忽略~
2024-07-09 17:48:50 +08:00 回复了 txzh007 创建的主题 程序员 如何平衡开发效率和代码优雅性? |
1 、原来的代码暂时不动，通过简单修改包路径防止互相交叉，新写的代码完全按新逻辑开发，要充分考虑兼容老代码逻辑，保证按时完成；
2 、陆续按模块迁移老逻辑的代码到新模块中，这个过程的进度完全根据自己可支配时间决定，然后陆续删除老逻辑；
3 、工作汇报、周报中尽量避免用 “代码逻辑优化、重构”这种模糊字眼，要不然就算你做了再多别人也会认为你在摸鱼。
4 、评估排期时，实际所需时间和评估时间，要尽量控制在 2:3 以内，这样你剩余的时间可以充分进行想要去做的优化工作；
5 、设计数据库字段、表结构、接口协议时要充分思考，因为这些地方设计的不好，上线后再改可就麻烦了。
2 、陆续按模块迁移老逻辑的代码到新模块中，这个过程的进度完全根据自己可支配时间决定，然后陆续删除老逻辑；
3 、工作汇报、周报中尽量避免用 “代码逻辑优化、重构”这种模糊字眼，要不然就算你做了再多别人也会认为你在摸鱼。
4 、评估排期时，实际所需时间和评估时间，要尽量控制在 2:3 以内，这样你剩余的时间可以充分进行想要去做的优化工作；
5 、设计数据库字段、表结构、接口协议时要充分思考，因为这些地方设计的不好，上线后再改可就麻烦了。
2024-07-08 15:56:08 +08:00 回复了 JsGuiGe 创建的主题 推广 一个小团队整出来的，颠覆会计行业的 App |
支持，看着做的挺好的，小团队确实不容易，可以用我的开源项目快速搭建数据化运营系，辅助产品迭代，https://github.com/xl-xueling/xl-lighthouse 我的项目开源免费、功能强大，使用方便~~
2024-07-07 18:34:54 +08:00 回复了 hh54188 创建的主题 程序员 我最近逐渐感受到，作为个体开发者在拓展技术深度上越来越难了 |
行业发展健全的同时，也会让程序员的”工具人“属性愈加明显。越来越多的程序员都是没有基础的，而只是一种或几种的工具运用者，既不了解某种技术的由来，也不能预判未来发展的走势。程序员还是应该更多的保持思考，否则真就成了工具人了。另外，lz 也可以了解一下我的数据统计项目： https://github.com/xl-xueling/xl-lighthouse 。
2024-07-06 16:29:36 +08:00 回复了 sun82kg 创建的主题 职场话题 总是不自觉划水，一点没有写码的动力，是不是有什么病了 |
心理方面、身体方面的原因肯定是有的，但如果 80%的时间都在短视频上面，我觉得不光是这些方面的原因，懒惰是人的本性，我也在很长很长的时间里跟你一样，但现在不同了，天天跟打了鸡血似的，每天都觉得时间不够用。根本原因就是一点，你目前还没有找到一件愿意长期投入、执着去做的事情。总之，要给自己找一件值得长期投入的事情。可以了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse ，欢迎使用~~
2024-07-05 18:33:41 +08:00 回复了 beryl 创建的主题 程序员 技术方案讨论，移除实时日志中的敏感数据 |
对于这种处理方式，并不是特别认同，此类问题更应该从源头进行修正，而不是采取这种“补救”措施。
2024-07-04 19:36:45 +08:00 回复了 nnegier 创建的主题 程序员 怎么应对复现不了的 bug？ |
说一下我的看法，这种问题排查不要只从能否复现的角度处理，应该主要从两方面着手，1 是日志，2 是监控。
1 、app 程序层面的问题，分为普通异常日志和崩溃日志，一般来说异常类日志都有较完整的调用链信息，定位问题相对容易。但造成崩溃的原因比较多，可能是内存问题，用户设备问题、也可能只是某个参数校验失败或空指针异常处理不当导致的，不同情况下崩溃日志有可能完整也可能不完整。所以从日志层面上可以添加全局的异常信息捕获，并将全局异常日志上报，防止漏掉异常信息，而导致排查无从下手。
2 、app 的异常监控体系不完善，可以使用我的开源项目，快速搭建起异常监控体系，https://github.com/xl-xueling/xl-lighthouse ，基于通用型流式统计实现，接入方便、使用灵活、性能强大，轻松实现任意细粒度、任意维度的数据监控。将手机型号、手机系统版本号、app 版本号、页面、模块、错误码等关键信息上报。全面监控各类异常的次数和频率等信息（我自己感觉我的开源项目是应对这类问题业内最强大的工具了~~）。
总之，我觉得 app 问题处理，侧重点应在两方面：一是全局异常日志（代表你没有正常处理的异常），二是普遍性错误（比如：某个 app 版本或某个机型错误率或崩溃率在 0.5%以上的异常），公司内部可以对异常阈值确定一个标准，比如灰度时发现影响超过 0.5%的用户的异常必须测试人员复测解决，该版本不能继续发布，而影响范围较小的偶发性问题、不容易复现的问题，可以暂时忽略或陆续解决。要做到应对领导的所有盘问一切以数据说话，只要日志和监控体系建立起来，你对线上故障的驾驭能力会得到极大的提升。
1 、app 程序层面的问题，分为普通异常日志和崩溃日志，一般来说异常类日志都有较完整的调用链信息，定位问题相对容易。但造成崩溃的原因比较多，可能是内存问题，用户设备问题、也可能只是某个参数校验失败或空指针异常处理不当导致的，不同情况下崩溃日志有可能完整也可能不完整。所以从日志层面上可以添加全局的异常信息捕获，并将全局异常日志上报，防止漏掉异常信息，而导致排查无从下手。
2 、app 的异常监控体系不完善，可以使用我的开源项目，快速搭建起异常监控体系，https://github.com/xl-xueling/xl-lighthouse ，基于通用型流式统计实现，接入方便、使用灵活、性能强大，轻松实现任意细粒度、任意维度的数据监控。将手机型号、手机系统版本号、app 版本号、页面、模块、错误码等关键信息上报。全面监控各类异常的次数和频率等信息（我自己感觉我的开源项目是应对这类问题业内最强大的工具了~~）。
总之，我觉得 app 问题处理，侧重点应在两方面：一是全局异常日志（代表你没有正常处理的异常），二是普遍性错误（比如：某个 app 版本或某个机型错误率或崩溃率在 0.5%以上的异常），公司内部可以对异常阈值确定一个标准，比如灰度时发现影响超过 0.5%的用户的异常必须测试人员复测解决，该版本不能继续发布，而影响范围较小的偶发性问题、不容易复现的问题，可以暂时忽略或陆续解决。要做到应对领导的所有盘问一切以数据说话，只要日志和监控体系建立起来，你对线上故障的驾驭能力会得到极大的提升。
Select Language