自己做的网站如何连接入数据库,wordpress+论坛类,做物流网站模块,百度域名验证网站文章核心其实#xff0c;本不想把标题写的那么恐怖#xff0c;只是发现很多人干了几年java以后#xff0c;都自认为是一个不错的java程序员了#xff0c;可以拿着上万的工资都处宣扬自己了#xff0c;写这篇文章的目的并不是嘲讽和我一样做java的同行们#xff0c;只是希…文章核心其实本不想把标题写的那么恐怖只是发现很多人干了几年java以后都自认为是一个不错的java程序员了可以拿着上万的工资都处宣扬自己了写这篇文章的目的并不是嘲讽和我一样做java的同行们只是希望读者看到此篇文章后可以和我一样心平气和的争取做一个优秀的程序员。讲述方向由于一直从事移动互联网相关工作java开发中经常和移动端打交道或者做一些后端的工作所以本篇文章更可能涉及和移动端的交互或者与后端的交互方式笔者希望以自身的一些学习经验或者开发经验可以带动认真阅读本篇文章的读者们让大家对java有一个更好的态度去学习它它不只是一个赚钱的工具而已。笔者身边有很多与笔者年龄相仿或年龄更大的朋友或同事经常有人问我“你现在还在学习吗我觉得没什么好学的这些东西都差不多”我总是回答只要有时间我就要看一会书这个时候大家都会露出一副不屑的眼神或笑容。其实非常能理解身边朋友或同事的看法以目前状态来讲大多都是工作至少5年的程序员了对于公司大大小小的业务需要以目前的知识储备来讲都可以轻松应对“没有什么好学的”其实这句话没有多大的问题但是如果你对编程还有一点点兴趣只是不知道如何努力或改进希望本篇文章可以帮到你。技术点本文不是一个吹嘘的文章不会讲很多高深的架构相反会讲解很多基础的问题和写法问题如果读者自认为基础问题和写法问题都是不是问题那请忽略这篇文章节省出时间去做一些有意义的事情。开发工具不知道有多少”老”程序员还在使用eclipse这些程序员们要不就是因循守旧要不就是根本就不知道其他好的开发工具的存在eclipse吃内存卡顿的现象以及各种偶然莫名异常的出现都告知我们是时候寻找新的开发工具了。更换IDE根本就不想多解释要换什么样的IDE如果你想成为一个优秀的java程序员请更换intellij idea. 使用idea的好处请搜索谷歌。别告诉我快捷键不好用更换IDE不在我本文的重点内容中所以不下想用太多的篇幅去写为什么更换IDE请谷歌。在这里我只能告诉你更换IDE只为了更好、更快的写好java代码。原因略。别告诉我快捷键不好用请尝试新事物。beanbean使我们使用最多的模型之一我将以大篇幅去讲解bean希望读者好好体会。domain包名根据很多java程序员的”经验”来看一个数据库表则对应着一个domain对象所以很多程序员在写代码时包名则使用com.xxx.domain 这样写好像已经成为了行业的一种约束数据库映射对象就应该是domain。但是你错了domain是一个领域对象往往我们再做传统java软件web开发中这些domain都是贫血模型是没有行为的或是没有足够的领域模型的行为的所以以这个理论来讲这些domain都应该是一个普通的entity对象并非领域对象所以请把包名改为:com.xxx.entity。如果你还不理解我说的话请看一下Vaughn Vernon出的一本叫做《IMPLEMENTING DOMAIN-DRIVEN DESIGN》(实现领域驱动设计)这本书书中讲解了贫血模型与领域模型的区别相信你会受益匪浅。DTO数据传输我们应该使用DTO对象作为传输对象这是我们所约定的因为很长时间我一直都在做移动端api设计的工作有很多人告诉我他们认为只有给手机端传输数据的时候(input or output)这些对象成为DTO对象。请注意这种理解是错误的只要是用于网络传输的对象我们都认为他们可以当做是DTO对象比如电商平台中用户进行下单下单后的数据订单会发到OMS 或者 ERP系统这些对接的返回值以及入参也叫DTO对象。我们约定某对象如果是DTO对象就将名称改为XXDTO,比如订单下发OMSOMSOrderInputDTO。DTO转化正如我们所知DTO为系统与外界交互的模型对象那么肯定会有一个步骤是将DTO对象转化为BO对象或者是普通的entity对象让service层去处理。场景比如添加会员操作由于用于演示我只考虑用户的一些简单数据当后台管理员点击添加用户时只需要传过来用户的姓名和年龄就可以了后端接受到数据后将添加创建时间和更新时间和默认密码三个字段然后保存数据库。RequestMapping我们只关注一下上述代码中的转化代码其他内容请忽略:User 请使用工具上边的代码从逻辑上讲是没有问题的只是这种写法让我很厌烦例子中只有两个字段如果有20个字段我们要如何做呢 一个一个进行set数据吗当然如果你这么做了肯定不会有什么问题但是这肯定不是一个最优的做法。网上有很多工具支持浅拷贝或深拷贝的Utils. 举个例子我们可以使用org.springframework.beans.BeanUtils#copyProperties对代码进行重构和优化:PostMapping
BeanUtils.copyProperties是一个浅拷贝方法复制属性时我们只需要把DTO对象和要转化的对象两个的属性值设置为一样的名称并且保证一样的类型就可以了。如果你在做DTO转化的时候一直使用set进行属性赋值那么请尝试这种方式简化代码让代码更加清晰!转化的语义上边的转化过程读者看后肯定觉得优雅很多但是我们再写java代码时更多的需要考虑语义的操作再看上边的代码:User 虽然这段代码很好的简化和优化了代码但是他的语义是有问题的我们需要提现一个转化过程才好,所以代码改成如下:PostMapping这是一个更好的语义写法虽然他麻烦了些但是可读性大大增加了在写代码时我们应该尽量把语义层次差不多的放到一个方法中比如:User 这两段代码都没有暴露实现都是在讲如何在同一个方法中做一组相同层次的语义操作而不是暴露具体的实现。如上所述是一种重构方式读者可以参考Martin Fowler的《Refactoring Imporving the Design of Existing Code》(重构 改善既有代码的设计) 这本书中的Extract Method重构方式。抽象接口定义当实际工作中完成了几个api的DTO转化时我们会发现这样的操作有很多很多那么应该定义好一个接口让所有这样的操作都有规则的进行。如果接口被定义以后那么convertFor这个方法的语义将产生变化他将是一个实现类。看一下抽象后的接口:public 虽然这个接口很简单但是这里告诉我们一个事情要去使用泛型如果你是一个优秀的java程序员请为你想做的抽象接口做好泛型吧。我们再来看接口实现:public class UserInputDTOConvert implements DTOConvertuserinputdto,user {Overridepublic User convert(UserInputDTO userInputDTO) {User user new User();BeanUtils.copyProperties(userInputDTO,user);return user;}}我们这样重构后我们发现现在的代码是如此的简洁并且那么的规范:RequestMappingreview code如果你是一个优秀的java程序员我相信你应该和我一样已经数次重复review过自己的代码很多次了。我们再看这个保存用户的例子你将发现api中返回值是有些问题的问题就在于不应该直接返回User实体因为如果这样的话就暴露了太多实体相关的信息这样的返回值是不安全的所以我们更应该返回一个DTO对象我们可称它为UserOutputDTO:PostMapping
这样你的api才更健全。不知道在看完这段代码之后读者有是否发现还有其他问题的存在作为一个优秀的java程序员请看一下这段我们刚刚抽象完的代码:User user new UserInputDTOConvert().convert(userInputDTO);你会发现new这样一个DTO转化对象是没有必要的而且每一个转化对象都是由在遇到DTO转化的时候才会出现那我们应该考虑一下是否可以将这个类和DTO进行聚合呢看一下我的聚合结果:public class UserInputDTO {private String username;private int age;public 然后api中的转化则由:User user new UserInputDTOConvert().convert(userInputDTO);User saveUserResult userService.addUser(user);变成了:User user userInputDTO.convertToUser();User saveUserResult userService.addUser(user);我们再DTO对象中添加了转化的行为我相信这样的操作可以让代码的可读性变得更强并且是符合语义的。再查工具类再来看DTO内部转化的代码它实现了我们自己定义的DTOConvert接口但是这样真的就没有问题不需要再思考了吗我觉得并不是对于Convert这种转化语义来讲很多工具类中都有这样的定义这中Convert并不是业务级别上的接口定义它只是用于普通bean之间转化属性值的普通意义上的接口定义所以我们应该更多的去读其他含有Convert转化语义的代码。我仔细阅读了一下GUAVA的源码发现了com.google.common.base.Convert这样的定义:public 从源码可以了解到GUAVA中的Convert可以完成正向转化和逆向转化继续修改我们DTO中转化的这段代码:private 修改后:private 看了这部分代码以后你可能会问那逆向转化会有什么用呢其实我们有很多小的业务需求中入参和出参是一样的那么我们变可以轻松的进行转化我将上边所提到的UserInputDTO和UserOutputDTO都转成UserDTO展示给大家:DTOpublic api:PostMapping当然上述只是表明了转化方向的正向或逆向很多业务需求的出参和入参的DTO对象是不同的那么你需要更明显的告诉程序逆向是无法调用的:private 看一下doBackward方法直接抛出了一个断言异常而不是业务异常这段代码告诉代码的调用者这个方法不是准你调用的如果你调用我就”断言”你调用错误了。bean的验证如果你认为我上边写的那个添加用户api写的已经非常完美了那只能说明你还不是一个优秀的程序员。我们应该保证任何数据的入参到方法体内都是合法的。为什么要验证很多人会告诉我如果这些api是提供给前端进行调用的前端都会进行验证啊你为什还要验证其实答案是这样的我从不相信任何调用我api或者方法的人比如前端验证失败了或者某些人通过一些特殊的渠道(比如Charles进行抓包),直接将数据传入到我的api那我仍然进行正常的业务逻辑处理那么就有可能产生脏数据“对于脏数据的产生一定是致命”这句话希望大家牢记在心再小的脏数据也有可能让你找几个通宵jsr 303验证hibernate提供的jsr 303实现我觉得目前仍然是很优秀的具体如何使用我不想讲因为谷歌上你可以搜索出很多答案!再以上班的api实例进行说明我们现在对DTO数据进行检查:public api验证:PostMapping我们需要将验证结果传给前端这种异常应该转化为一个api异常(带有错误码的异常)。PostMapping
BindingResult是Spring MVC验证DTO后的一个结果集可以参考spring 官方文档拥抱lombok上边的DTO代码已经让我看的很累了我相信读者也是一样看到那么多的Getter和Setter方法太烦躁了那时候有什么方法可以简化这些呢。请拥抱lombok,它会帮助我们解决一些让我们很烦躁的问题去掉Setter和Getter其实这个标题我不太想说因为网上太多但是因为很多人告诉我他们根本就不知道lombok的存在所以为了让读者更好的学习我愿意写这样一个例子Setter
看到了吧烦人的Getter和Setter方法已经去掉了。但是上边的例子根本不足以体现lombok的强大。我希望写一些网上很难查到或者很少人进行说明的lombok的使用以及在使用时程序语义上的说明。比如:Data,AllArgsConstructor,NoArgsConstructor..这些我就不进行一一说明了请大家自行查询资料.bean中的链式风格什么是链式风格我来举个例子看下面这个Student的bean:public 仔细看一下set方法这样的设置便是chain的style调用的时候可以这样使用:Student 相信合理使用这样的链式代码会更多的程序带来很好的可读性那看一下如果使用lombok进行改善呢请使用 Accessors(chain true),看如下代码:Accessors这样就完成了一个对于bean来讲很友好的链式操作。静态构造方法静态构造方法的语义和简化程度真的高于直接去new一个对象。比如new一个List对象过去的使用是这样的:List看一下guava中的创建方式:ListLists命名是一种约定(俗话说约定优于配置)它是指Lists是List这个类的一个工具类那么使用List的工具类去产生List这样的语义是不是要比直接new一个子类来的更直接一些呢答案是肯定的再比如如果有一个工具类叫做Maps那你是否想到了创建Map的方法呢HashMap好了如果你理解了我说的语义那么你已经向成为java程序员更近了一步了。再回过头来看刚刚的Student很多时候我们去写Student这个bean的时候他会有一些必输字段比如Student中的name字段一般处理的方式是将name字段包装成一个构造方法只有传入name这样的构造方法才能创建一个Student对象。接上上边的静态构造方法和必传参数的构造方法使用lombok将更改成如下写法RequiredArgsConstructor 和 NonNull:Accessors测试代码:Student 这样构建出的bean语义是否要比直接new一个含参的构造方法(包含 name的构造方法)要好很多。当然看过很多源码以后我想相信将静态构造方法ofName换成of会先的更加简洁:Accessors测试代码:Student 当然他仍然是支持链式调用的:Student 这样来写代码真的很简洁并且可读性很强。使用builderBuilder模式我不想再多解释了读者可以看一下《Head First》(设计模式) 的建造者模式。今天其实要说的是一种变种的builder模式那就是构建bean的builder模式其实主要的思想是带着大家一起看一下lombok给我们带来了什么。看一下Student这个类的原始builder状态:public 调用方式:Student 这样的builder代码让我是在恶心难受于是我打算用lombok重构这段代码:Builder
调用方式:Student 代理模式正如我们所知的在程序中调用rest接口是一个常见的行为动作如果你和我一样使用过spring 的RestTemplate,我相信你会我和一样对他抛出的非http状态码异常深恶痛绝。所以我们考虑将RestTemplate最为底层包装器进行包装器模式的设计:public 然后再由扩展类对FilterRestTemplate进行包装扩展:public 包装器ExtractRestTemplate很完美的更改了异常抛出的行为让程序更具有容错性。在这里我们不考虑ExtractRestTemplate完成的功能让我们把焦点放在FilterRestTemplate上“实现RestOperations所有的接口”,这个操作绝对不是一时半会可以写完的当时在重构之前我几乎写了半个小时,如下:public 我相信你看了以上代码你会和我一样觉得恶心反胃后来我用lombok提供的代理注解优化了我的代码(Delegate):AllArgsConstructor
这几行代码完全替代上述那些冗长的代码。是不是很简洁做一个拥抱lombok的程序员吧。重构需求案例项目需求项目开发阶段有一个关于下单发货的需求如果今天下午3点前进行下单那么发货时间是明天如果今天下午3点后进行下单那么发货时间是后天如果被确定的时间是周日那么在此时间上再加1天为发货时间。思考与重构我相信这个需求看似很简单无论怎么写都可以完成。很多人可能看到这个需求就动手开始写Calendar或Date进行计算从而完成需求。而我给的建议是仔细考虑如何写代码然后再去写不是说所有的时间操作都用Calendar或Date去解决一定要看场景。对于时间的计算我们要考虑joda-time这种类似的成熟时间计算框架来写代码它会让代码更加简洁和易读。请读者先考虑这个需求如何用java代码完成或先写一个你觉得完成这个代码的思路再来看我下边的代码这样你的收获会更多一些:final 读这段代码的时候你会发现我将判断和有可能出现的不同结果都当做一个变量最终做一个三目运算符的方式进行返回这样的优雅和可读性显而易见当然这样的代码不是一蹴而就的我优化了3遍产生的以上代码。读者可根据自己的代码和我写的代码进行对比。提高方法如果你做了3年的程序员我相信像如上这样的需求你很轻松就能完成但是如果你想做一个会写java的程序员就好好的思考和重构代码吧。写代码就如同写字一样同样的字大家都会写但是写出来是否好看就不一定了。如果想把程序写好就要不断的思考和重构敢于尝试敢于创新不要因循守旧一定要做一个优秀的java程序员。提高代码水平最好的方法就是有条理的重构(注意是有条理的重构)设计模式设计模式就是工具而不是提现你是否是高水平程序员的一个指标。我经常会看到某一个程序员兴奋的大喊哪个程序哪个点我用到了设计模式写的多么多么优秀多么多么好。我仔细去翻阅的时候却发现有很多是过度设计的。业务驱动技术 or 技术驱动业务业务驱动技术 or 技术驱动业务 其实这是一个一直在争论的话题但是很多人不这么认为我觉得就是大家不愿意承认罢了。我来和大家大概分析一下作为一个java程序员我们应该如何判断自己所处于的位置.业务驱动技术如果你所在的项目是一个收益很小或者甚至没有收益的项目请不要搞其他创新的东西不要驱动业务要如何如何做而是要熟知业务现在的痛点是什么如何才能帮助业务盈利或者让项目更好更顺利的进行。技术驱动业务如果你所在的项目是一个很牛的项目比如淘宝这类的项目我可以在满足业务需求的情况下和业务沟通使用什么样的技术能更好的帮助业务创造收益比如说下单的时候要进队列可能几分钟之后订单状态才能处理完成但是会让用户有更流畅的体验赚取更多的访问流量那么我相信业务愿意被技术驱动会同意订单的延迟问题这样便是技术驱动业务。我相信大部分人还都处于业务驱动技术的方向吧。所以你既然不能驱动业务那就请拥抱业务变化吧。代码设计一直在做java后端的项目经常会有一些变动我相信大家也都遇到过。比如当我们写一段代码的时候我们考虑将需求映射成代码的状态模式突然有一天状态模式里边又添加了很多行为变化的东西这时候你就挠头了你硬生生的将状态模式中添加过多行为和变化。慢慢的你会发现这些状态模式其实更像是一簇算法应该使用策略模式这时你应该已经晕头转向了。说了这么多我的意思是只要你觉得合理就请将状态模式改为策略模式吧所有的模式并不是凭空想象出来的都是基于重构。java编程中没有银弹请拥抱业务变化一直思考重构你就有一个更好的代码设计!你真的优秀吗真不好意思我取了一个这么无聊的标题。国外流行一种编程方式叫做结对编程我相信国内很多公司都没有这么做我就不在讲述结对编程带来的好处了其实就是一边code review一边互相提高的一个过程。既然做不到这个那如何让自己活在自己的世界中不断提高呢“平时开发的时候做出的代码总认为是正确的而且写法是完美的。”我相信这是大部分人的心声还回到刚刚的问题如何在自己的世界中不断提高呢答案就是:多看成熟框架的源码多回头看自己的代码勤于重构你真的优秀吗 如果你每周都完成了学习源码回头看自己代码然后勤于重构我认为你就真的很优秀了。即使也许你只是刚刚入门但是一直坚持你就是一个真的会写java代码的程序员了。技能UML不想多讨论UML相关的知识但是我觉得你如果真的会写java请先学会表达自己UML就是你说话的语言做一名优秀的java程序员请至少学会这两种UML图类图时序图clean code我认为保持代码的简洁和可读性是代码的最基本保证如果有一天为了程序的效率而降低了这两点我认为是可以谅解的除此之外没有任何理由可以让你任意挥霍你的代码。读者可以看一下Robert C. Martin出版的《Clean Code》代码整洁之道 这本书可以参考美团文章聊聊clean code也可以看一下阿里的Java编码规范无论如何请保持你的代码的整洁。linux 基础命令这点其实和会写java没有关系但是linux很多时候确实承载运行java的容器请学好linux的基础命令。参考鸟哥的《Linux私房菜》总结java是一个大体系今天讨论并未涉及框架和架构相关知识只是讨论如何写好代码。本文从写java程序的小方面一直写到大方面来阐述了如何才能写好java程序并告诉读者们如何才能提高自身的编码水平。我希望看到这篇文章的各位都能做一个优秀的java程序员。原作者-Rest原文链接细思极恐-你真的会写java吗 - rese-t - 博客园 原出处博客园
