zoukankan      html  css  js  c++  java
  • 阿里巴巴Java开发手册———个人追加的见解和补充(四)

    前言

    手册在(一)中有原版下载,在(三)中有在线版本,建议对照手册食用。

    在本文发布的时候前几天好像阿里做出了修改,在(一)中的地址下载的版本为1.0.2可能对一些之前的改动和修改。

    本文依旧还是针对1.0.0的版本写的,不过出入应该不大。

    有关编程规范(一)http://www.cnblogs.com/linkstar/p/6413402.html

    有关异常日志(二)http://www.cnblogs.com/linkstar/p/6415788.html

    有关数据库的(三)http://www.cnblogs.com/linkstar/p/6429770.html

    该说的我觉得(一)里面我都说完了,那么就直接进入正题吧。

    工程规约

    对于工程来说,其实规范很多,细节要注意的地方很多,而且这些规范其实很多都不是个人自己学习的,而是看见别人这么做,你也这么跟着模仿,最终形成的,保持工程的统一不仅是对于在编程的时候对可读性有帮助,而且对于重构的时候,特别是对于非项目组成员来帮忙的时候有很大的帮助。

    1、下面是手册中给出的图

    image

    这边其实给的已经算很全了,不过根据项目的不同,里面的层也会根据实际情况进行删减的,但是大致肯定是这样没错。分层的思想应该在一开始做项目的时候就很好的建立起来的习惯,并且需要一直保持。

    下面就几个层中比较难理解的进行说明。

    一、开放接口层,PRC:很多人看见这个缩写就懵逼了,因为没见过,因为确实在简单小的项目中不常见,RPC是远程调用的简称,它是一种协议,如果不好理解,你可以理解为HTTP,这个用的可能是最多的协议了,或者webService都可以,这些都是一些接口的定义,而PRC的好处在于,在一些分布式的应用程序还有在一些不同语言所编写的组件需要互相通信的时候,PRC就很有优势了。

    二、终端显示层,velocity:这个是一个工具,是用于辅助前后端分离:后端接口开发人员可以专心于提供数据、前端人员可以使用占位符(模板文件)暂时代替数据。我在手册前面就看见过,因为生成的文件后缀为.vm,所以习惯称为vm,可能阿里的工程师用这个比较多。因为公司前端能力和人手不足,所以没有用过,因为暂时前后端还没有做到完全分离,所以现在还是使用的jsp,如果有机会完成前后端分离的话会考虑使用。

    三、manager层:说实在话,这层在我们的项目中是没有的,但是有和他功能相似的层,主要是用于处理缓存和第三方的。这里手册中说的特别好的一点就是对DAO的业务通用能力进行封装,这对于程序员在写代码的时候思想的注意就有关了,我见过有很多厉害的人,封装和共用的思想很厉害,很多时候他写的代码可能少,但是已经足够用了。

    四、DAO层:这里主要注意的点是,缓存的数据访问也是放在这里的,我习惯把redis这种缓存的数据访问也放在DAO,因为它也是属于数据的存放和访问。

    2、这点和我现在可能有些出入,其一、我DAO是不抛异常给上层,我们的原则是层的异常当层解决,出现异常后返回给上层应该是对应的错误码和没有查询到数据的结果。其二、我的DAO是打印日志的,因为在前期Debug的时候,DAO的日志最能准确的定位到那一句sql出现了问题,而上层的日志的话只是在业务逻辑上面出现问题的时候才打印日志。不过也只是作为参考。

    3、我在(一)里面已经对模型都进行了说明,需要请在最上面的链接查看。

    二方库规约

    首先解释一些什么是二方库,很多人会奇怪这个名字。一方库:本工程的模块互相的依赖。二方库:公司内部的依赖库。三方库:公司之外的开源依赖库。

    一方库就不多说了,二方库主要是我见过很多公司开发项目的时候,采用的是jar包的方式,很多模块开发完成之后会打成jar包然后进行使用,所以需要规约。三方库的话现在流行使用的是maven进行管理,后面会提到的。

    然后装了B之后赶紧回来,嘻嘻,本人还没有使用过二方库,主要是考虑到几个点,害怕jar包冲突,这个真的很坑,在没有maven的时候,每次导入jar的时候到会仔仔细细的,报错之后也是不停的查,到底是哪里冲突了,所以从来没有使用过,给不出很好的建议和补充,但是这也提醒了我,之后会学习使用的,因为毕竟当项目大了之后封装原来使用过的模块能增加开发的效率。

    服务器规约

    我总觉得不知道是不是写手册的人有点偷懒了,还是真的太多了来不及写了,总之一句话,服务器规约比这个多的去了。。。我还非常希望有高级的服务器运维工程师来讲讲经验,因为服务器这东西,哇塞,出的问题你没有经验真的很难解决。这里我也只能就这几点讲讲我所遇到的一些重要的,不能列举出全部,本人毕竟经验有限。

    首先服务器的选择:除非是。NET开发,不要用windows服务器,坑死你不偿命。

    服务器存放文件规则:前期一定要定义好文件的存放规则,因为很多人玩linux,真的是玩会的,装很多软件的时候都是随心所欲的放,这样会让后来维护服务器的人造成维护上面很大的困难,特别是当一些软件的安装路径不同时,环境变量和配置文件也会变化。

    防火墙:看到很多偷懒的,一上来就把防火墙关掉的数不胜数,别告诉我你也是,防火墙是可以配置规则的,只要开放你需要的端口就可以了,不然被黑是迟早的事情。

    注意各种软件的配置:很多软件在服务器上面的版本是和windows默认配置差异很大,即使你本身的开发平台并非windows,还是有差异,所以,对于任何软件都请先查询并且修改你需要的配置。这边举几个例子,如tomcat,你需要配置项目路径,端口,日志。还有很容易忘记的JVM配置,手册中也提到了,OOM这个错误有时是不会在项目的日志中出现,而会在tomcat这样的容器的日志中出现,当项目的小的时候,默认的内存当然够用,但是当项目大了之后,内存肯定是不够用的,当出现问题再去修改配置的话可能就晚了。

    除非是测试服务器,正式服不允许出现任何测试性质的软件或工程。因测试工程而导致主服务器宕机,那真是要不得的。

    服务器权限:有能力最好做一下权限的管理,服务器权限分的细,这样真正出现问题的时候才好去追究责任,不是说一定要有人背锅,只是不希望别人只是因为有了服务器的密码而当替罪羊。另外,服务器的操作最好每次都有记录。

    文件的权限:linux文件的权限可厉害了,不要只知道777,有时候权限不够会导致一些问题,注意就好。

    注意备份:注意备份文件,数据库等,在服务器上的数据都是很重要的,不备份,出问题,你找谁?

    经常监控服务器:包括服务器的性能,日志等各个方面,预防问题的发生。

    都是比较大的点,细的我这里就不一一列举了,因为我也不是专业的服务器运维工程师,上面也只是经验之谈罢了。

  • 相关阅读:
    sp2010 升级sp2013 用户无法打开网站
    powerviot install in sharepoint 2013
    can not connect cube in performancce dashboard
    westrac server security configure user info
    添加报表服务在多服务器场
    sharepoint 2013 office web app 2013 文档在线浏览 IE11 浏览器不兼容解决方法
    delete job definition
    目前付款申请单内网打开慢的问题
    item style edit in sharepoint 2013
    Could not load file or assembly '$SharePoint.Project.AssemblyFullName$'
  • 原文地址:https://www.cnblogs.com/linkstar/p/6439871.html
Copyright © 2011-2022 走看看