Java 业务开发常见错误 100 例
朱晔
贝壳金服资深架构师
52944 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 48 讲
代码篇 (23讲)
Java 业务开发常见错误 100 例
15
15
1.0x
00:00/00:00
登录|注册

结束语 | 写代码时,如何才能尽量避免踩坑?

完善的监控报警
借助工具帮助避坑
设计评审和代码审查
单元测试和性能测试
官方文档的可靠性
理解原理
尽量少自己造轮子,使用流行的框架
关注框架和组件的安全补丁和版本更新
尽量使用更高层次的框架
避免使用不熟悉的新类
10条建议
避免踩坑的目的
鼓励读者继续学习并分享课程
希望读者养成多研究原理、多思考总结问题的习惯
重点讨论避免踩坑的方法
感谢读者的认可与陪伴
作者:朱晔
如何尽量避免踩坑

该思维导图由 AI 生成,仅供参考

你好,我是朱晔。
这个课程要告一段落了,在这里我要特别感谢你一直以来的认可与陪伴。于我而言,虽然这半年多以来我几乎所有的业余时间都用了在这个课程的创作,以及回答你的问题上,很累很辛苦,但是看到你的认真学习和对课程内容的好评,看到你不仅收获了知识还燃起了钻研源码的热情,我也非常高兴,深觉一切的辛苦付出都是甜蜜的。
相信一路走来,你不仅理解了业务代码开发中常见的 130 多个坑点的解决方式,也知道了其根本原因,以及如何使用一些常用工具来分析问题。这样在以后遇到各种坑的时候,你就更加能有方法、有信心来解决问题。

如何尽量避免踩坑?

不过,学习、分析这些坑点并不是我们的最终目的,在写业务代码时如何尽量避免踩坑才是。所以,接下来,我要重点和你聊聊避免踩坑的一些方法。
所谓坑,往往就是我们意识不到的陷进。虽然这个课程覆盖了 130 多个业务开发时可能会出错的点,但我相信在整个 Java 开发领域还有成千上万个可能会踩的坑。同时,随着 Java 语言以及各种新框架、新技术的产生,我们还会不断遇到各种坑,很难有一种方式确保永远不会遇到新问题。
而我们能做的,就是尽可能少踩坑,或者减少踩坑给我们带来的影响。鉴于此,我还有 10 条建议要分享给你。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

在这篇文章中,作者分享了在半年多时间里创作课程和回答学员问题的经历,总结了130多个常见坑点的解决方式,以及根本原因和常用工具的使用方法。他提出了10条建议,包括避免使用不熟悉的新类、尽量使用更高层次的框架、关注框架和组件的安全补丁和版本更新、尽量少自己造轮子、理解错误原理、依赖官方文档、进行单元测试和性能测试、进行设计评审和代码审查、借助工具帮助避坑以及做好完善的监控报警。这些建议可以帮助开发者更好地理解和解决代码开发中的挑战,提前发现Java开发中的一些坑、避免生产事故,或减少踩坑的影响。通过这些内容,读者可以更加有方法、有信心地解决业务代码开发中的各种问题。文章内容丰富,涵盖了Java开发中的常见问题和解决方法,对于开发者来说具有很高的实用性和指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Java 业务开发常见错误 100 例》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(46)

  • 最新
  • 精选
  • insight
    非常感谢老师的课,这是我第一门在极客时间听完的课,让我学到了很多东西,解决了很多编程中遇到的问题,流处理的教学也让我打开了新大门,爱上了这种工具,期待老师的新课程!

    作者回复: 大家的留言我就不一一回复了,如果觉得有帮助欢迎大家推荐给身边的朋友,也欢迎提出意见建议,或者是说说你想学的内容,你的困惑,说不定还有第二季,还是这个风格还是这个味道,继续一起学习和进步。有成长学习的问题也可以在这里留言,技术相关问题可以继续在相关主题的文章下留言。

    2020-05-28
    2
    20
  • Darren
    谢谢老师,学到了很多,也收获了很多,期待能出下一个专栏

    作者回复: 课代表来了

    2020-05-28
    4
    15
  • 👽
    我都没发现,居然都半年过去了。 这应该是我第一个,从第一篇追到结语的专栏了。 无疑,这个专栏学习的过程,也是自己成长的一个重要过程之一。 学习专栏,经常要去分析,去思考,去总结。然后留下自己的理解,期待老师的点评与回复。得到回复也是非常及时,应该是全专栏回复速度最快的老师没有之一! 去期待老师的思考以及认可,是个很奇妙的过程。为了能得到老师的认可与翻牌子,也同样需要大量思考。这就促进了一个被动学习之外,主动思考的习惯。必须承认,在这个过程中受益良多。 无法说自己有什么翻天覆地的成长,也不敢说自己学到了什么。知识是不断的积累的,形成质变是一个过程。但是,学习到的思维方式以及习惯,却是扎扎实实的。我近两年来的一句口头禅,理论不足,思想先行。有一个成熟的思维方式,我觉得是超脱单纯的知识点的。所以,也是十分幸运,能在这篇专栏中,从老师的思维方式中受益良多! 期待老师的下一期专栏,同时也期待能让老师看见更好的自己! 谢谢学习路上的陪伴!

    作者回复: 是的,专栏能带给大家的知识点是有限的,正确的思考思维方式对以后自己解决问题就很有用了,加油

    2020-05-29
    8
  • 阿怪
    很走心的一门课

    作者回复: 感谢认可

    2020-09-02
    2
  • 梦倚栏杆
    这一篇看的非常有压力:发现提到的某些坑竟然已经忘记了,我明明也下载了老师的代码,跟着跑了。 老师这门课程真的非常给力,有一些确实是想当然的再用,也没发现问题就以为没有问题。老师能再加一篇技术设计需要考虑的点吗? 我最近遇到一个问题:明明是一个很小的需求(计算任务->发送消息->执行任务),我们迭代了六七版,里面有一些业务边界问题没考虑到,也有是纯粹技术问题:比如灰度开全量时,计算任务同步改异步;任务之间是有关联性影响的,没有考虑任务积压或者执行过长:导致一个任务积压,后续任务变大,越来越积压的恶性循环。 感谢老师

    作者回复: 其实你说的问题不是绝对意义上的坑。对于一个高并发的分布式系统,看似运作稳定,其实哪怕有任何一个小改动,都可能影响到平衡引起重大问题。所以一般这样的系统都需要定期全链路压测,每次重大发布都需要独立模块压测,通过压测才能确定系统的整体吞吐是否可以满足要求。我们也遇到过增加一个insert的SQL这样的小需求增加了2ms的时间导致队列堵塞(服务处理能力不够)的问题,所以不能看需求是不是小,关键还是在于知道系统的容量余量。

    2020-05-29
    2
  • 子一
    感谢老师的付出,毫不避讳的说对于一个30个以上专栏的用户来说基本上属于我心中的top3,课的实战性很强,期待老师的下一门课程,提点建议老师能付考虑一下来个测试实战的专栏,测试用例是一个老大难的问题啊

    作者回复: 感谢认可

    2020-05-29
    1
  • 郑先生
    感谢老师的专栏,学到了很多,有很多知识还不是很了解没消化,准备再慢慢学习积累消化,也期待老师的下一期专栏

    作者回复: 如果觉得好可以多分享转发

    2020-09-14
  • 子休
    个人觉得这是至今为止最实用的一门课,不玩虚的,一切从实际出发,希望下一次课依旧是这种风格,期待。

    作者回复: 感谢支持

    2020-09-08
    2
  • xuzhibin
    老师,请教一个问题,在做批量操作时候,通常是怎么样判定成功或失败的依据呢?比如说,批量新增50条记录,其中3条失败了,这时候通常的做法是算成功还是失败?谢谢

    作者回复: 批次成功失败不重要 这些失败的记录下一批处理的时候需要在处理 服务端继续客户端的批次数据给数据 不代表一批就只能是这些数据

    2020-09-03
  • winner_0715
    意犹未尽,老师有别的课程计划吗
    2020-05-28
    8
收起评论
显示
设置
留言
46
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部