我想你已经眼花缭乱了，从这么多框架中，如何才能挑选出你心仪的框架呢？...对我们而言，永远没有“最好”的框架，只有最适合自己需求的框架。在考虑一个框架时，你需要考虑的问题通常有这么几个： 我使用的语言和平台支持这个框架吗？ 这个框架和其他我正在使用的框架的兼容性怎么样？...学习这个框架的学习曲线是否太陡？ 它的开发效率如何？ 安全性如何？ 方便进行单元测试吗？ 这个框架的文档支持怎么样？社区够活跃吗？...事务管理：Spring强大的事务管理功能，能够处理本地事务(一个数据库)或是全局事务(多个数据，采用JTA)。 模块分离：Spring框架是由模块构成的。...单元测试：Spring写出来的代码非常容易做单元测试，可以采用依赖注射(Dependency Injection)将测试的数据注射到程序中。
前段日子在社群（点击加入）里看到有人讨论关于Service层接口的问题，DD也经常碰到周围的新人有问过一些类似的问题：一定要写个Service层的接口吗？Service层的接口到底用做什么用的呢？...好像都没什么用啊？ DD的看法是： Service层在业务逻辑不复杂的时候，似乎是没有什么用，但是随着应用迭代，业务逻辑变得复杂了之后，这一层是非常有用的。...主要表现在这几个方面： 1、更适合用来处理复杂的业务逻辑，可能会涉及多张表的操作，甚至还混杂着消息投递、接口调用等一系列的复杂综合性事务，这也是我们常说的事务管理所处的层次。...3、对单元测试的支持，通过单独的一层service实现业务逻辑，那么对于业务逻辑的单元测试会更容易编写，只需要对service来编写就可以了；而web层的单元测试就不需要关注业务本身，只需要关注反馈格式就行了...往期推荐 聊一聊：你平时写不写单元测试？ 聊一聊：下班后的消息，要不要回？ 聊一聊：你都用什么方式回忆青春呢？ 聊一聊：MyBatis和Spring Data JPA的选择问题
认知好的编程概念，走向优秀~ 传送门：《程序员优秀之路：认知 97 个好的编程概念（1）》 区分异常 程序运行时出现异常通常可以归为：技术异常和业务异常，区分二者有利于我们更好的捕获它们。...不相信这种假设，问清楚：“什么时候”在“什么条件下”发生“什么事”，而不是“如果”。...别动生产线 在大多数基于 Web 的开发环境中，架构可以这样分解： 在开发者机器上进行本地开发和单元测试； 完成手动或自动集成测试的开发服务器； QA 团队和用户在其中进行验收测试的临时服务器； 生产服务器...克苏鲁神话 开发过程中，我们偶尔会被同事这样提问： “我这里这里报这个错，你知道是为什么吗？” 搞笑的是：提出问题的人通常比被问问题的人更有能力作出解答。...这些不必要的代码会基于什么样的理由产生： 有人认为将来可能用到它； 有人觉得写了有趣，但不一定有用； 实现起来更容易，比如引入了一个很大的库，但只用其中一小点； 开发理解了额外的需求，实际不存在； 删了只会让你的代码更清晰
唤醒内在的孩子 到底谁在读提交t信息 如果这些变化中的任何一个 购买超宽屏显示器的理由 天才之举 排版是最好的 如果它起作用，它就是起作用 确保它是真正的Bool 测试驱动的最佳开发方式 你敢于扩展吗...在某些时候，它发生在我们所有人身上。你产生了你并不感到自豪的代码。这些代码让你怀疑，"我怎么会写出这样的东西？"这没什么好羞愧的。我们只是人类。有时候，我们就是没有做到最好。...它可以在一夜之间改变。为了防止这种情况发生，最好还是多加小心。 购买超宽屏显示器的理由 冗长的变量名并无不妥。只要它们有助于提高代码的可读性。但有时，我们必须问自己 "多长才算长？”...测试驱动的最佳开发方式 我们必须为使用单元测试的做法点赞。但我不禁要问。如果测试是生成随机数字，会发生什么？ 你敢于扩展吗？ 我们都在某些时候写过复杂的开关语句。然而，一千行似乎有点太多了。...或者如果你有一些可耻的照片要分享，不要害怕在评论中分享它。 我在浏览这些代码片断时感到很愉快。它让我想起了我早期的日子。在我的职业生涯中，我写了一些我并不自豪的代码片段。
捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的内容。...有 try 块放到了事务代码中，catch 异常后，如果需要回滚事务，一定要注意手动回滚事务。...说明:关于 RPC 方法返回方式使用 Result 方式的理由： 1）使用抛异常返回方式，调用方如果没有捕获到就会产生运行时错误。...记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？ 10、单元测试 好的单元测试必须遵守 AIR 原则。...测试框架通常是定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。
看到这个答案，可能有些朋友会一脸懵逼，为啥上个例子把异常捕获了，数据可以插入成功，这次也是同样把异常捕获，数据却无法插入成功 原因： 这就得从spring事务的传播行为说起了，spring事务的默认传播行为是...按照REQUIRED这个八股文的含义是如果当前存在事务，则加入该事务，如果当前不存在事务，则创建一个新的事务 在示例中 @Transactional public void saveTxTestC...，saveTxTestA还能插入，有没有什么解决方法 答案： 在saveTxTestC加上如下注解 @Transactional(propagation = Propagation.REQUIRES_NEW...如果一个事务已经存在，则先将这个存在的事务挂起 场景二：接着上一场景的延伸 示例：在方法上加了Propagation.REQUIRES_NEW注解 @Autowired private JdbcTemplate...中，捕获一下saveTxTestD抛出来的异常 再次运行单元测试，得到如下结果 [在这里插入图片描述] 总结 我们在平时可能会为了面试背了一些八股文，但实际场景可能会远比这些八股文复杂多，因此我们在看这些八股文时
，可能有些朋友会一脸懵逼，为啥上个例子把异常捕获了，数据可以插入成功，这次也是同样把异常捕获，数据却无法插入成功 原因： 这就得从spring事务的传播行为说起了，spring事务的默认传播行为是REQUIRED...按照REQUIRED这个八股文的含义是如果当前存在事务，则加入该事务，如果当前不存在事务，则创建一个新的事务 在示例中 @Transactional public void saveTxTestC...，saveTxTestA还能插入，有没有什么解决方法 答案： 在saveTxTestC加上如下注解 @Transactional(propagation = Propagation.REQUIRES_NEW...如果一个事务已经存在，则先将这个存在的事务挂起 场景二：接着上一场景的延伸 01 示例：在方法上加了Propagation.REQUIRES_NEW注解 @Autowired private JdbcTemplate...中，捕获一下saveTxTestD抛出来的异常 再次运行单元测试，得到如下结果 04 总结 我们在平时可能会为了面试背了一些八股文，但实际场景可能会远比这些八股文复杂多，因此我们在看这些八股文时，可以多加思考
虽然经常有很好的“理由”来解释为什么我们不能写简单的断言，但是当你尝试了很多方式，可能会重新承认标准是一个非常好的主意。简单的断言有时候并不能满足所有的测试需求。...让我们看一下伪代码编写的一个单元测试测试用例： // 这是伪代码 test('add new user to db' { user = createUser('John', 'Smith')...（未显示））都不会影响我们的测试 但是 在上面的示例中，暗示可能为用户提供了id以及创建时间戳。...结论 在断言中使用模糊匹配是一个好技巧，但是当没有其他方法可用时，它必须是最后的选择。...更精确的字段匹配可以消除对模糊性的需求。 ---- 郑重声明：文章禁止第三方（腾讯云除外）转载、发表，事情原委测试窝，首页抄我七篇原创还拉黑，你们的良心不会痛吗？
当然，代码就是设计（Jack W.Reeves, 1992）；代码是最有价值的交付物。我们需要好代码吗？在给“好代码”下个定义之前，这个问题无法回答。那么，究竟什么是好代码？...那么接下来我们深入介绍下，什么是好代码的标准呢，请看下面解释： 一、代码命名规范： 1、 package包名全部由小写的ASCII字母组成，用“.”分隔。...以上几条如果符合就算是好代码了吗？当然不是，这只是代码中最基本的命名规范而已，就算不符合最多就是代码不好看，没什么其他影响。...6、 事务处理 事务范围是否合理；或者说，是否把不必要的操作放到了同一个事务中 事务传播方式是否合理（required，never，new等配置） 7、sql语句 sql语句是否正确 使用mybatis...四、性能瓶颈 在真实工作中，很多程序员其实在开发完程序后不去真正关注程序的性能和响应时间到底如何，凭的是以往开发经验在开发的过程中尽可能的去减少问题点。
此外，还有些技术书中说过：好的代码，不用写注释，因为代码即注释。这也给那些不喜欢写代码注释的人，找了一个合理的理由。 但我个人觉得，在国内每个程序员的英文水平都不一样，思维方式和编码习惯也有很大区别。...方法中的代码块才真正需要事务，其余的方法，可以非事务执行，这样就能缩小事务的范围，避免大事务。...具体用法我就不展开了，有兴趣的朋友可以看看我的另一篇文章《聊聊接口性能优化的11个小技巧》 12.频繁捕获异常 通常情况下，为了在程序中抛出异常时，任然能够继续运行，不至于中断整个程序，我们可以选择手动捕获异常...(user); } 其中的User对象是我们已经定义好的对象，就不会存在什么歧义了。...我见过有些编程高手是测试驱动开发，他们会先把单元测试写好，再写具体的业务逻辑。 那么，我们为什么要写单元测试呢? 我们写的代码大多数是可维护的代码，很有可能在未来的某一天需要被重构。
Integer 有个缓冲池，-128~127这个范围内的直接从缓冲池取出，超过这个范围会在堆中生成新对象，所以 i1 和 i2 不相等。 13. 与(&)、或(|)、异或(^) 操作符你知道吗？...18. java 中的异常体系你知道吗？...抛出(Throw)、捕获(try catch)、声明(Throws)。 20. 你知道 finally 吗？...finally，配合 try catch 使用，try 中写要捕获异常的代码， catch 中写捕获到异常后的操作，finally 中写一定要执行的代码，比如关闭资源、释放连接等。...在 try 或 catch 中调用了 return，finally 还会执行吗？ 会，且在 return 之前执行。
那么，这是怎样的一段代码呢？涉及到哪些知识，又有哪些可以优化的点呢？ 让我们来看一下。 背景 先说一下背景，也就是要知道我们单元测试要测的这个方法具体是什么样的功能。...插入AssetStream方法中，主要是插入一条AssetStream的流水信息，为了防止并发，这里在数据库中增加了唯一性约束。 为了保证数据一致性，我们通过本地事务将这两个操作包在同一个事务中。...Assert 这个相信大家都比较熟悉，这就是JUnit中提供的断言工具类，在单元测试时可以用做断言。这就不详细介绍了。 优化点 以上代码涉及到了很多知识点，但是，难道就没有什么优化点了吗？...这个问题其实我在发朋友圈之前就有想到过，心中早已经有了答案，只不过有多位朋友能够几乎同时提到这一点还是很不错的。 我们来说说问题是什么。...但是还是想问一下，对于这部分代码，你觉得还有什么可以优化的地方吗？
说到全流程测试，就不得不提很多人关心的「单元测试」，而说到单元测试，我又自然的想到了在我浏览器中长期占据一个 tab 页的文章《为什么大多数单元测试是浪费》（后台回复「浪费」获取 URL 地址）。...为什么长期占据我浏览器的一个 tab 页？主要是我作为实用派，一直对单元测试的投入产出比存在疑问，但是自己又没有实际做过单元测试，所以很想知道别人反驳的理由，顺便结合自己的项目，做个取舍。...但是这两种方法都有一个共同的缺点，就是很难发现一些动态执行过程中的问题，比如内存泄露，就是很难确认分配内存和释放内存的匹配操作。那有没有解决方案呢？...，就是通过检测病毒/木马干了啥来判断是否恶意，而判断木马干了啥，一种方式是等木马干活时抓现行（滞后、被动），另一种则是把木马丢到沙箱里面主动运行起来，这是目前一种非常有效的识别手段。...以上，我好费劲的从敏捷测试引到了沙箱动态检测，不知道你看明白了没有？目前，这个方法还只是个猜想，如果大家有其他的方式，请多赐教，如果针对上面的方案有任何问题和建议，欢迎留言一起讨论。
大家好，又见面了，我是你们的朋友全栈君。...2. try…catch异常 在一段业务逻辑中对数据库异常进行了处理，使用了try…catch子句捕获异常并throw了一个自定义异常，这种情况导致了事务未回滚，示例代码如下： @Transactional...在代码中我虽然捕获了异常，但是同时我也抛出了异常，为什么事务未回滚呢？猜测是异常类型不对，于是开始查询原因，翻看了Spring的官方文档，找到了答案。下面是翻译自Spring官网。...17.5.3 声明式事务的回滚 上一节中介绍了如何设置开启Spring事务，一般在你的应用的Service层代码中设置，这一节将介绍在简单流行的声明式事务中如何控制事务回滚。...在Spring FrameWork 的事务框架中推荐的事务回滚方法是，在当前执行的事务上下文中抛出一个异常。
其实这都有现成的方法直接使用。而且相当简单高效！ 虽然简单，但是我们还是先要思考清楚底层逻辑。只学到表面方法，不理解透原理是很容易在变化中失去本来该有的效果。...1、推广拉新前，先想清楚客户为什么来你的店？ 不就是因为要买东西/订单服务吗？这是客户的真实需求。那为什么选择你，不选择别的商家？所以要给出一个充分的理由，才是客户决策的根源。...[节日.jpg] 节假日里人们的购买欲望会更强烈。 有这么方便好用的工具后，首先找最容易的达成合作的。如：自己的员工、亲朋好友（全员营销）。接着就是附近的商家（异业联盟合作）。...[酒店预订完成.jpg] 不仅如此，在连接WiFi的时候。还有WiFi红包！这才是是让客户下次再来最强大的理由。...如果上面三个问题，在脑海有了清晰的轮廓。那么你应该明白了推广拉新不能单独处理。在推广拉新前要准备什么，推广拉新后面该干什么。从而达到成交率提升、客源持续增长、老客户不断沉淀。
每个软件工程师都希望看到好代码，从好代码中学习，并进一步写出好代码。然而，“横看成岭侧成峰”，每个人对好代码的理解可能不尽相同，好代码是每个人心中那个不同的哈姆雷特吗？ ?...4.云解有情花解语——自我解释 尽管注释和外部文档非常有用，但它们不是编写良好的自我解释代码的替代品。好的代码本身就是最好的说明文档，无需解释就能让别人明白，每一行代码都应该是这样。...但是，代码自解释不是不写注释的理由，即使变量、方法、类、函数、模块的名称是自解释的，但这些并不能描述出代码的全貌。 ? 5. 清池不测通沧海——可测性好 只要编写了代码，就可以测试代码。...每次执行代码并检查其效果时，都在测试它，但这不应该是测试代码的唯一方法。单元测试是好代码的一部分，单元测试常常记录了代码的意图。...单元测试用例能成功运行的前提是该方法内部的所有逻辑必须是能正常运行的，编写可测试的代码使其具有了可塑性。 ? 6.伐竹为桥结构同——可被重构 重构是在不改变行为的情况下改变实现。
以下为译文： 有趣的是，我对测试的观点正在发生变化。十五年来，我一直在推广TDD（测试驱动开发，过去也被称为测试优先方式），或至少对于开发者来说，写一些单元测试。...“好，那我们试想来了个无知的开发者，试图更改这些简单的代码，如果相关的单元测试发生了变化，他会做什么，他只会删除它。“ “但是如果你非要写测试怎么办呢？”...悲剧是，不用使用正确的工具，因为没有什么好的理由，我们决定不要用错误的工具。 悲剧是，一旦“所谓的好的做法”成为公司开发主流，我们似乎就会忘了这种做法的应用场景，它的优点是什么，使用它的代价是什么。...那么100％的代码覆盖率是值得追求的吗？ 是的，每个人都应该在一个项目中实现。我认为你必须极端地去了解这么做带来的痛苦是什么。...单元测试（特别是第一种方法）是一个非常好的做法，但我们应该分辨哪些测试是有用的，哪些是适得其反的。 但记住没有什么工具使用起来是毫无代价的，没有工具是万能的，使用前请停下来想一想。
Free Mybatis plugin 推荐指数：☆☆☆☆☆ 推荐理由：在sql的xml里也能智能提示了！...在ide中直接翻译，不需要跳转到网页了，效率神器！ 6、打字效果 Power Mode II 装逼指数：☆☆☆☆☆ 推荐理由：这个就是美化的，装逼用的。喜欢的可以试试，让编码不再单调。...留下重力碎屑就好了 7、快捷跳转Action方法 RestfulToolkit 推荐指数：☆☆☆☆☆ 推荐理由：spring的开发中经常有根据浏览器url找对应action方法的需求，这个可以快捷的根据...自动识别pojo字段的注释，并添加为sql注释。 11、控制台日志 高亮 Grep Console 推荐指数：☆☆☆☆☆ 推荐理由：没什么好说的， 基本是必备！...12、反编译插件 IdeaJad 推荐指数：☆☆☆☆☆ 推荐理由：没什么好说的， 基本是必备！
前言 看到标题你可能会问为什么这一篇会谈到代码测试，不是说代码优化么？前两篇主要是讲了程序的输出及Log4j的使用，Log能够帮助我们进行bug的定位，优化开发流程，而代码测试有什么用呢？...你愿意进行单元测试吗？ 其实，像第一篇文章所说的，对于打印输出信息，我们更习惯于使用System.out命令，所以很多时候，习惯决定了我们的编码方式，那么你习惯于做单元测试吗？...业务逻辑比较简单不值得编写单元测试。 这又是一个理由，而这个理由的深层次的原因，应该是来源于对自己的自信，自信是件好事，但是要掌握好其中的度。...在开发中，对于自己开发的模块，只有在通过单元测试之后，才能提交到SVN库或者Git 库。 再一次强调，你不是一个人，你的代码有问题，同事pull下来的代码也是有问题的，浪费大家的时间。...对于这件事情，我是深有感触的，在去年的一次项目开发过程中，由于我没有做好代码审查和单元测试匆匆上传到代码库，导致其他开发人员也无法正常开展工作，还要帮着我去修改bug，这件事导致我有些自责，也在后续的开发工作中更认真
它做了什么？什么都没做，只是无止境的消耗 CPU。我们能终止它吗？在 Java 中是不行的。只有当你按下 Ctrl-C 来终止整个 JVM 时这段程序才会停止。...在 Java 中没有方式来终止一个线程，除非该线程自动退出。请务必牢记的这一原则，其它东西就显而易见了。 我们将这个死循环放在一个线程里： ? 所以，怎样才能停止一个需要停止的线程？...例如，Thread.sleep() 方法的设计（一种最基本的方法）： ? 为什么要这么做？为什么不能等待并且不用去检查标识变量？我相信一定有一个非常好的理由。...理由如下（如果我说错了，请修正我的错误）：为了让代码变快或是中断准备，没有其他理由。 如果你的代码足够快，你从来不会检测中断标识变量，因为你不想处理任何中断。...知道我想要说的是什么吗？不要丢失 InterruptedException，这一点非常重要。我们不能吞噬该异常并继续运行。这严重违背了 Java 多线程原则。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
