Java项目工程实例代码分析

本篇内容介绍了“Java项目工程实例代码分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！实际上，咱们平时嘴中常说的“好”和“烂”，是对代码质量的一种描述。“好”笼统地表示代码质量高，“烂”笼统地表示代码质量低。对于代码质量的描述，除了“好”“烂”这样比较简单粗暴的描述方式之外，我们也经常会听到很多其他的描述方式。这些描述方法语义更丰富、更专业、更细化。我搜集整理了一下，罗列在了下面，一般有几下几标准，分别是可读性、可维护性、可扩展性、可复用性 、灵活性、可测试性等等可读性 readability软件设计大师 Martin Fowler 曾经说过：“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”翻译成中文就是：“任何傻瓜都会编写计算机能理解的代码。好的程序员能够编写人能够理解的代码。”Google 内部甚至专门有个认证就叫作 Readability。只有拿到这个认证的工程师，才有资格在 code review 的时候，批准别人提交代码。可见代码的可读性有多重要，毕竟，代码被阅读的次数远远超过被编写和执行的次数。  我个人认为，代码的可读性应该是评价代码质量最重要的指标之一。我们在编写代码的时候，时刻要考虑到代码是否易读、易理解。除此之外，代码的可读性在非常大程度上会影响代码的可维护性。毕竟，不管是修改 bug，还是修改添加功能代码，我们首先要做的事情就是读懂代码。代码读不大懂，就很有可能因为考虑不周全，而引入新的 bug。  既然可读性如此重要，那我们又该如何评价一段代码的可读性呢？我们需要看代码是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等。你应该也能感觉到，从正面上，我们很难给出一个覆盖所有评价指标的列表。这也是我们无法量化可读性的原因。  实际上，code review 是一个很好的测验代码可读性的手段。如果你的同事可以轻松地读懂你写的代码，那说明你的代码可读性很好；如果同事在读你的代码时，有很多疑问，那就说明你的代码可读性有待提高了可维护性 maintainability  一般指的是在不破坏原代码设计的前提下，快速修改bug或增加代码，不会带来新bug，表明该代码的维护性比较好。落实到编码开发，所谓的“维护”无外乎就是修改 bug、修改老的代码、添加新的代码之类的工作。所谓“代码易维护”就是指，在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码。所谓“代码不易维护”就是指，修改或者添加代码需要冒着极大的引入新 bug 的风险，并且需要花费很长的时间才能完成。可扩展性 extensibility  代码面对未来新需求的变化能力，一般来说，开发新需求的时候，不修改原代码或很少修改，即可达到需求开发的能力，通常会预留一些功能扩展点。可复用性 reusability  尽量避免重复造轮子，即能够沉淀免费云主机域名出一些通用的代码逻辑，保持与上层业务代码的解耦灵活性 flexibility  这个词比较宽泛。通常与可维护性、可扩展性以及可复用性类似可测试性  主要反映在写单测的时候。从两个方面体现：1.单元测试是否容易编写；2.写单元测试的时候，不能依赖环境，远程调用其他服务的借口，尽可能进行mock数据，保持服务之间的解耦。虽然要团队每人都按这个规范走很难，但我们团队有一个强制要求，就是每个功能函数不能超过50行代码，而且要求代码越短越好。这几个维度是评判代码维度比较重要的几个指标。  高内聚低耦合几乎是每个程序员员都会挂在嘴边的，但这个词太过于宽泛，太过于正确，所以聪明的编程人员们提出了若干面向对象设计原则来衡量代码的优劣：开闭原则 OCP (The Open-Close Principle)单一职责原则 SRP (Single Responsibility Principle)依赖倒置原则 DIP (Dependence Inversion Principle)最少知识原则 LKP (Least Knowledge Principle)) / 迪米特法则 (Law Of Demeter)里氏替换原则 LSP (Liskov Substitution Principle)接口隔离原则 ISP (Interface Segregation Principle)组合/聚合复用原则 CARP (Composite/Aggregate Reuse Principle)  这些理论想必大家都很熟悉了，是我们编写代码时的指导方针，按照这些原则开发的代码具有高内聚低耦合的特性，换句话说，我们可以用这些原则来衡量代码的优劣。我相信每个工程师都想写出高质量的代码，不想一直写没有成长、被人吐槽的烂代码。那如何才能写出高质量的代码呢？针对什么是高质量的代码，我们刚刚讲到了七个最常用、最重要的评价指标。所以，问如何写出高质量的代码，也就等同于在问，如何写出易维护、易读、易扩展、灵活、简洁、可复用、可测试的代码，但要写好代码，也不是一蹴而就，需要非常多的实践与积累，下面简举例说明：  抽象思维是我们工程师最重要的思维能力，因为软件技术本质上就是一门抽象的艺术。我们工程师每天都要动用抽象思维，对问题域进行分析、归纳、综合、判断、推理，从而抽象出各种概念，挖掘概念和概念之间的关系，然后通过编程语言实现业务功能，所以，我们大部分的时间并不是在写代码，而是在梳理需求，理清概念，对需求有一个全局的认知。而抽像能力让我及团队切身感受到，它给我们在编码和设计上带来的质的变化。案例一：异步Excel导出其实导出Excel功能在我们工程里随处可见，特别是咱们的运营希望一次性导出越多数据越好，为了不给我们系统带来太大压力，对于大数据量的导出一般异步进行，针对于这样一个简单的功能，那么应该如何抽像呢？普通的写法：抽像写法：我们其实可以把每个异步导出看作是一个异步任务，而每个任务可导出的内容是不一样的，因此完全可以把导出抽像一个方法，由每个具体实现类去实现导出不同的内容，具体如下：案例二：系统通知在微服务化流行的今天，为了提升系统吞吐量，系统职责越来越细，各系统模块需要频繁交互数据，那么对于复杂的数据交互场景，比如我们调拨单，调拨单在扭转的过程中需要与很多系统交互，跟门店、仓库、库存模块有非常多的交互，我们又该如何抽像呢，以下是调拨与各系统交互的代码示例其实我们在与其它系统交互的时候，我们可以把每一个交互动作抽像成一个通知事件，每次交互的时候，写一个事件通知事件即可。  关于组合/聚合复用原则，其实我们在项目过程会经常遇到，比如项目里会经常管理各种单据，像采购单、调拨单、收货单等，而对于每种单据都会有各种各样的较验，我们先来看一段建调拨单代码，具体如何下：“Java项目工程实例代码分析”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注百云主机网站，小编将为大家输出更多高质量的实用文章！

相关推荐: vue element-ui里的table中表头与表格出现错位如何解决

这篇文章主要讲解了“vueelement-ui里的table中表头与表格出现错位如何解决”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“vueelement-ui里的table中表头与表格出现错位如何解决”吧！现…