皮皮网

1.如何评价Mars老师的Java4Android
2.delphi源码,计件三层源码中间件
3.请问，工厂ERP软件哪个好哪个比较好一些？
4.Java开发规范：关于提高开发体验的源码源码分享记录

如何评价Mars老师的Java4Android

       ä½œä¸ºæ•™å¸ˆï¼Œè·Ÿè®¡ä»¶å·¥ä½œä¸åŒï¼Œä¸èƒ½ç”¨åŸ¹å…»å¤šå°‘学生为评价标准，因为你培养多少学生，是学校的安排，不是像孔子那样，有人找上门来，手里只要提溜一块干肉就可以了，而是由学校招生，分成班级，然后给你派任务，让你去完成。如果你的班级出了个大才子，那有好几位老师脸上有光，因为你的班级一定不止你一个人，而才子的培养——如果他/她确实是你们培养出来的——一定是集体劳动的结晶，跟你有关系，但不必大包大揽。 那么，用工作量来历计算如何？也不行。还是上述原因，你的工作是领导分配的，工作多少，往往是你自己难以干涉的。（当然，时下的大学教师中，多数已经不把教学工作当成自己的主要工作了，尽量少上课，多在家里干科研，或者别的什么事情。但是，这是可以引导的。）同时，干的工作数量多的，不见得是好老师，相反，干的少的，不见得不受学生欢迎。 那么，看一个老师受学生欢迎的情况来定吧？我觉得尤其不行。一则，学生的眼光和趣味是因个人或某个集体而不同的，我们很难相信，这个个人或集体就是绝对的公平的。比如，一位老师上课笑语声喧，那一定是受欢迎的，但是未必有内容（当然，多数上课活跃的，内容也充实）；相反，有的老师习惯于一板一眼，头头是道，这样的老师有时是不受欢迎的。尤其是那些不太怎么样的学校，不要相信学生的眼光。 名牌大学的学生是否就可以信赖呢？我认为正相反。之所以能考上名牌大学，并不是由于他/她具有独到的眼光，而考上名牌之后，由于争胜心、人事关系的变化等原因，学生的心理也会受到影响。他们很难以很客观的眼光去看老师。同时，这些孩子总的来讲跟一般学校的学生，甚至是很差学校的学生没有本质差别——我们常常有个认识：班里最难琢磨的是两头，最差的和最好的，他们具有同样的发展轨迹，因此，如果你不相信差生，也最好同样不必相信好生。 最难琢磨的就是外国留学生，现在我们基本上所有大学都有留学生，他们来自各种国家，在各种文化下生长，对于给老师打分的事情，他们的反应真的是五花八门。但不管怎么说，总的来讲，有三种情况：一是好好型，不管这个老师怎么样，总要给面子，打高分；二是认真型，要坚持自己的看法，而且相信这种看法会真实地反映到校长那里去。关键是，他/她相信自己的感受一定是最客观的，不容许别人说三道四。所以，这些人，要么打分很客观，要么意气用事但死不悔改。常常发现有同学学，老师，某某同学给你打了最低分，甚至有的零分。你去看那位同学，正是你特别欣赏的，但不知道什么时候，什么东西，让他/她感到不爽了。三是手电筒型，看着老师那里都不好，有很多缺点，所有的，所以，离理想中的老师的标准差得很远。这种人也很多。 一般来讲，中国学生的打分相对集中一些，一般最低分也能让老师过得去，即便有个把怪诞的同学，在一个班里也就是一两个；而留学生则否，他们常常有多个同学反应失常，而这些时常的同学又常常给你的分让你很跌眼镜。 学生打分，对老师的副作用很大，有的老师为了得到高分，对学生软硬兼施。比如，有的老师请学生吃饭，给学生礼物，买好学生；有的则告诉学生，你门的四年都在我的掌握之中，如果不好好表现，那么有你们好看的。结果当然不是都见效，但是只要一种方法必然引导出奇怪的招数，那一定有问题。 现在常常实施的考核办法是学术当先：核心期刊的文章数量——质量都不讲。有时候讲质量，就拿社会反应说事——你有人给你写吗？哪怕是骂你的话，都算数呀！你有拿到奖金吗？哪怕你的奖金是贿赂等见不得人的方式取得的。你有项目吗？哪怕你的项目是你的导师通过某种不政党的途径获得的。这样的后果是，得到好处的人，他的好处会继续送来；得不到好处的人，下次好处也离你很远。文章的发表也是：你发表过核心了，下一次就好一些。；如果没发表过，别人都没见过的你的名头，那你就死抗吧！ 专著是另一个硬头货，但是时下出钱就出版的事情不再少数，他能够保证质量吗？ 什么办法是最好的——不要说最好的，因为还没有好的——可行的？我还想不出来。如果有理想的学者来主持公道，那么，学者自己的评价是最好的。但是，隔行如隔山，现在的学术就是这样，如果专家的学术隔得太远，很难说上话；如果每个专业的每个部分都设专家，那很难保证专家的公证。人心是可以变化的，也是很难琢磨的。目前的状况是，没有办法。

delphi源码,三层源码中间件

       这套Delphi源码设计用于企业级应用系统开发，如ERP、分享MES、平台HRMS和库存管理系统，计件相较于常规中间件，源码源码linux安装gcc源码它具有更丰富的分享功能和更直观的开发体验。对于需要处理高并发、平台跨平台、计件高效实时系统的源码源码开发者，可能需要自行优化。分享该框架不依赖第三方控件，平台以简单明了的计件方式封装常用功能，注重实用而非复杂技术。源码源码

       开发环境方面，分享原基于Delphi ，已升级至Delphi ，采用DataSnap架构。服务器使用SQLite存储配置参数，客户端使用MS SQL数据库，并结合DevExpress VCL和FastReport控件。

       服务端部分，专注于功能实现而非图形展示，而客户端则是一个针对制造业的MES系统，核心功能包括计件工资计算、产量分析和生产进度跟踪。此外，还有一个Java版APP和H5手机端应用，用于数据上报和查询，但并未包含在公开分享的源码搭建app价格内容中，如有需要，可单独联系获取。

请问，工厂ERP软件哪个好哪个比较好一些？

       工厂需要什么样的管理软件，如何引入ERP生产管理系统，主要有哪些功能，能解决什么管理问题？相信这是正在选型中的制造业老板都想了解的问题。

        

       带着这些问题，我们一起深入探讨一下制造业如何通过管理系统，打造数字化工厂，实现智能化管理！

        

       我们以实际案例来阐述，中之杰公司服务的一家中小型制造企业-苏州良浦。该企业主营砂加气混凝土砌块、灰加气混凝土砌块、五金、设备、油品等。伴随着他们企业的快速发展，传统管理模式下的各类弊端展露无遗。随着公司业务量的增长，车间管理人员发现，每日生产、销售、库存、财务等数据无法及时汇总，且采用手工统计，不仅效率低下，还容易出错。股道稳赢背离源码在生产环节上，无法有效控制产品的生产、库存和发货，容易造成大量成本浪费。而良浦这家企业的产品又多是非标定制化，产品的库存库位管理极度复杂，如果无法精准定位产品及物料的库存位置，那么，要找某个产品就非常困难。

        

       良浦的信息化负责人曾经告诉我们，有一次他们要找一块板（水泥板墙），他们十几个人在六万平方米的露天仓库找了一天没有找到，由于赶时间，重新生产了一块，结果几天后又在某个角落里找到了这块板，实在是让他们哭笑不得。这不仅使工作效率下降，还造成成本的增加。以小见大，企业的管理问题都是在这种细节中体现出不足，然而，激烈竞争之下，企业抢占的就是1%的效率和价格差异。

        

       所以，企业到底应该如何使工厂管理进入数字化阶段呢？中之杰专家认为，靠单一的企业管理系统只能解决部分问题，并不能从根本上扭转局面。在良浦公司的项目上，中之杰的庄家精准抄底源码项目服务团队通过详细的需求调研，对良浦现有业务流程进行了重新梳理，确定项目范围后，为良浦量身打造了一套数字化转型解决方案。

        

       通过ERP+MES的集成性数字化解决方案，结合条码等智能终端硬件设备，在经过一年多的运营后，良浦各方面的效率得到了大幅提升。能够实时反馈生产数据，结合数据报表，批量打印每块产品的检验表格，减少了每月将近张表格的制表工作，统计室员工由原来的8人减少为3人，而且数据准确性也提升到%以上。通过PDA实时扫码入库，实现了实时的产品出入库，满足了库存精准定位的需求，大幅减少仓管人员的工作量。而且，在库存积压这一块得到了根本性的解决，仓管人员告诉我们，现在他们库存里的积压还是在使用ERP+MES系统之前的积压，上系统后都是按单采购，按单生产，基本零库存积压。

        

       我们总结一下，管理工厂生产环节，需要根据公司具体业务和管理流程的需求，且需要一套ERP+MES系统的集成解决方案，从产品、年会抽奖excel源码业务、执行和管理上全面实现数字化。这样你的生产管理问题就不再存在啦！

Java开发规范：关于提高开发体验的分享记录

       前言

       大家有没有想过程序员为什么这么累，其实作为一个程序员对于个人来说，技术很重要，但是对于工作来说，编码的习惯比技术更加主要。工作中你面试的大部分技术都不需要用到的。工作中，因为你的编码习惯不好，写的代码质量差，代码冗余重复多，很多无关的代码和业务代码搅在一起，导致了你疲于奔命应付各种问题。

       良好的编码习惯加上各种开源的工具可以是提高我们的生产效率，减少很多不必要的加班时间。衡量一个开发人员的产出、质量和效率不是流水线一样计计件越多越好，在我看来有以下几点

       可阅读性(团队开发，高效协作)

       可拓展性(面对需求更变，高效开发)

       健硕性（少点BUG，就算出了BUG更容易定位问题）

本次会议的目标

       改善大家编码习惯，提高代码可读性与开发效率，降低维护与问题定位的成本

       使用开源框架降低不必要的重复造轮子时间

编码规范装一个代码规范插件

       首先推荐装一个阿里的插件：alibaba-java-coding-guidelines，可以帮你更正很多不健康的写法

POJO类命名规范

       概念：像DTO、Entity等业务对象统称POJO

       关于对象类的后缀，业界没有一个硬性统一，只要做到好理解，同一个项目规范统一就好了，比如实体类，有的项目叫Entity，有的叫Model。以下是我个人觉得最优的方案：

       视图对象Result：返参结果，例：OrderResult

       视图对象VO：用法跟Result一致，个人觉得Result更有辨识度，所以推荐使用Result

       数据对象Entity：跟数据表名对应，例：OrderEntity

       业务对象BO：内部使用的类，无需暴露在外面（不能在controller使用）

       关于CRUD操作相关DTO的全命名方式推荐格式：{ 业务单词}{ 动作}{ 后缀}.java

       例：TeacherQueryDTO、TeacherUpdateDTO

       反例：ClasscourseDTO(无法从命名获得业务场景)

Controller编写规范

       接口返参一定要使用泛型，除非只是返回成功或失败的操作，如：Result<此处一定要写返回的类>

       原因：可读性强，调用方可直接查看返回的对象属性，并且Swagger、smart-doc等框架支持自动生成文档

       Controller原则上只能做参数校验、属性补充、格式转换等操作，不能写业务逻辑，就算有也不能超过5行

       原因：解耦，职责问题，不同的类有不同的职责

       领域层若只是返回简单的数据，不需要错误提示的接口，如获取xx详情，可不使用Result<>，直接return对象即可

       原因：若不需要错误提示信息，没必要再包一层，直接返回所需对象即可

       不建议在Controller类加上@RequestMapping，请直接在方法的@PostMapping或@GetMapping写接口全路径

       原因：方便搜索且方便根据业务拆分重构Controller时可随意copy移动代码

       禁止使用request.getParameter()获得参数，请直接声明在方法体，若参数过多请使用DTO

       原因：可读性，且符合文档自动生成规则

       禁止使用Map/JsonObject入参或返参

       请不要为了方便就这样写，不利于阅读与维护

       不建议使用@PathVariable

       原因：调试时(浏览器F)无法直观查看接口的参数名是什么；springmvc下非RESTful的风格的接口响应性能会比RESTful风格高2倍（因为涉及正则解析）；另外对URL进行权限控制的时候也不好做

控制代码宽度

       方法参数数量请控制在4个内，如果不是%肯定以后不会加参数，请建一个DTO，像多条件查询的方法，一定要建对象，不然以后加需求就无线叠加方法参数，后果就是：

       另外请控制代码长度，太长的方法请学会换行，原则就是不能出现滚动条，例：

/***获取所有表单模板*@paramformId*@paramonlyShowChecked只返回需填的字段*@return*/List<PduFormListResult>getFormDetail(@Param("formId")intformId,@Param("onlyShowChecked")booleanonlyShowChecked);控制代码高度

       一个类的代码与方法不宜过多，如果可以预见的是一个类会有很多方法，应该根据单一设计原则进行拆分，比如教师拥有教师资料、教师下单、教师数据同步等等，拆分成多个Service，不建议一个Service完成所有的职责，一个文件行数超过千行后，维护成本会渐渐变高。

       一个方法的行数也不应该太多，根据阿里的规范，一个方法超过行就应该拆分出来。

异常处理原则

       能不使用trycatch就不要使用，大家不要害怕有异常就隐藏掉它，只要交给全局异常处理器就可以了，一切异常往外抛

/***不推荐*/@PostMapping("/test1")publicAjaxResult<TeacherSyncDetailDTO>test1(HttpServletRequestrequest){ try{ //业务代码returnAjaxResult.success();}catch(Exceptione){ returnAjaxResult.fail("错误啦");}}/***推荐*/@PostMapping("/test2")publicAjaxResult<TeacherSyncDetailDTO>test2(Stringid){ if(1!=1){ thrownewNsbCommonException("错误啦");}returnAjaxResult.success();}

       原因：业务代码不应该自己捕获异常，不要关心异常怎么处理，交给全局处理器来处理，这也是职责的问题，解耦代码，错误的日志、邮件通知等等的逻辑可以交给全局异常处理器记录，这样就可以做到代码的复用，更重要的是代码美观，可读性更强。

       比方说我要对某个异常出现时特殊处理，比如发邮件，如果用trycatch那是不是我要写很多重复的代码？就算你封装成一个方法，那也得在很多的catch中调用，那也一点都不优雅。

//例：业务异常，尽情往外抛@TransactionalpublicvoidsubmitUnConfirm(OrderTourConfirmDTOdto){ OrderBaseModelbase=orderBaseService.getByOrderNum(dto.getOrdernumber());OrderTourModelorder=this.getByOrderNum(dto.getOrdernumber());if(!order.getStatus().equals(OrderTourStatusConst.REVIEW)){ thrownewCommonException("提交失败,该订单非审核中状态");}if(base.getAdultQty()==null||base.getAdultQty()==0){ thrownewCommonException("提交失败,请填写订单的成人数、儿童数");}if(base.getPduId()==null){ thrownewCommonException("提交失败,请选择商品和规格");}order.setStatus(OrderTourStatusConst.APPOINT);order.setSubmitTime(newDate());this.updateById(order);}合理的注释

       这个大家都懂，只要你维护过没有注释的代码你就明白这个事情的重要性。

       在此提出几个建议

       重要流程请加上注释

       无用的代码请删掉，不要一顿注释就完事

       废弃但不能删除的代码请使用@Deprecated告知

       可分模块的流程善用分割符=========优雅的注释可以降低很多维护成本

关于service层的写法

       我们在定义Service层的时候有两种常规做法：

       直接一个service实现类

       定义service接口+serviceImpl实现类

思考1：使用service

       在日常业务开发中，在常规的三层架构（controller+service+mapper）中写业务，使用service+serviceImpl其实没有带来设计上的优点和使用interface的初衷，反而带来一些不必要的工作量。

       开发/维护的时候我需要改2个文件，实现类也没法直观查看接口注释，浪费了一些开发时间，而且阅读的代码的时候链路多了一层

       在大部分业务开发场景不需要一个service一个impl，因为你的实现类基本只有一个，无法体现接口的初衷，也没有所谓的解耦

       这里有一篇更完整的文章大家可以看看：/s/ykEno7L5Xr1VHQ-ItQ-FYQ

       所以大部分开发业务的场景，并不需要使用interface定义一层接口，如果不需要多实现，也没有用到设计模式去解耦，直接定义一个实现的Service其实开发效率更高

       当然了，也有缺点就是：

       不用使用接口，使用this.xx()调用本类方法会使AOP失效，如事务；当然也有解决方法，有兴趣自行百度。

       当一个类的方法太多的时候，不方便查阅，但其实可以缩进，而且一个service层不应该承担太多的职责，代码行数是可控的

思考2：使用service+serviceImpl

       其实网上很多开源项目大多数都是使用service+serviceImpl，只是我觉我们日常业务开发没有把这种模式的优势发挥出来，比如：

       需要用到一些设计模式，比如策略模式、工厂模式等

       我和同事分别做项目的2个不同功能模块,但是同事的功能中却需要调用我这头实现的部分逻辑.为了让他有一个"占位符"可用,我可以快速的写个接口扔给他

       某个service需要多继承

       结论引用网络上的文章：这些情况其实可以说是接口好处的体现,所以java有面向接口编程的建议.但是说回Service层一定要有接口吗?那到未必,因为说到底,多一个接口仅仅是扩展性和某些情况下有优势,但是是否会用到接口的便利性,不确定的情况下我们未必一定要为"可能"买单.只是多写那几行代码,付出一点就可能避免"未来"的大"麻烦",何乐而不为

       所以这里给到的建议是根据实际情况按需使用。

工具类编写规范

       相信大家都知道Hutool这个神器，建议写工具类的时候去看看这个文档，如果有重复的就不要再造轮子了

       但是如果遇到没有的呢，比如在做学段学科需求的时候发现，CollUtil就没有取两List的笛卡尔积，那请新建一个ExtCollUtil，并且继承它，这个类即同时拥有hutool的方法，也有自定义的方法。

       PS：其实公司应该有自己一个工具工程，原则上开发人员不可以偷偷在各自的工程写Util，若有需要提PR到专门的工具类工程，可以有效降低重复造轮子的时间

Lombok更优雅的用法

       Lombok相信大家都会用，但除了@Data还有更多优雅的用法

       在对象上加上注释@Accessors(chain=true)，可以使用链式写法

this.save(newMemTeacherEntity().setId("id").setTeacherTypeName("名字"));

       @RequiredArgsConstructor替代@Autowired构造注入,多个bean注入时更加清晰

@RequiredArgsConstructor@ServicepublicclassMemTeacherSyncService{ privatefinalMemTeacherServicememTeacherService;privatefinalMemTeacherEduServicememTeacherEduService;}

       @CleanUp清理流对象,不用手动去关闭流

@CleanupOutputStreamoutStream=newFileOutputStream(newFile("text.txt"));@CleanupInputStreaminStream=newFileInputStream(newFile("text2.txt"));byte[]b=newbyte[];while(true){ intr=inStream.read(b);if(r==-1)break;outStream.write(b,0,r);}包分级与类的存放

       合理的代码结构可有效降低代码的维护成本，在常规的项目中一般有2种存放的思路

       按照技术角度或者文件类型来分（by-techorby-type），下文简称by-tech

       按照业务功能来分（by-featureorby-business），下文简称by-biz

       先了解一下这两者具体是什么

by-tech

       以文件类型作为顶层包，其次再以业务进行划分

com└─github└─heys1├─common│├─exction│└─util├─controller│├─student│└─teacher└─service├─student└─teacherby-biz

       以业务作为顶层包，其次再以文件类型进行划分

com└─github└─heys1├─common│├─exction│└─util├─controller│├─student│└─teacher└─modular├─student│├─dto│├─mapper│└─service└─teacher├─dto├─mapper└─service

       使用modular/modules根据业务对类进行拆分

       controller比较特殊类似聚合层，可以按by-biz拆分，也可按by-tech拆分，根据业务情况选择即可

       通用的util、异常、处理器、拦截器等等放在common包

如何选择

       在我以往的项目中我是采用第二种，理由如下：

       开发方便，只需在一个包下即可开发，左侧的IDE菜单无需切来切去；

       要添加或者移除一块业务时通常更加方便。比如大的应用做拆分，一般都是按照业务功能拆分的，则直接拆出某个包到新应用即可；

       通过应用的包结构目录，就能大致知道这个模块在做什么，贴近DDD的思想，以controller作为聚合层、module作为领域层，结构清晰。

       在《聊一聊DDD应用的代码结构》一文中作者写到：

       按照业务来分包的思路在网上占绝对优势

       所以建议选择方案二。