从研发到发布,试图挖掘一下产品瘦身可能性,并提出“java公司化代码”思路来改造我们的代码。
跟负责打包发布的同事了解咨询,镜像下载优化遇到瓶颈。
从项目代码工程出发,自身进行瘦身。将矛头指向自己,指向工程依赖引入的代码。
先说开发中的3种形态,受这3种思想影响,最终导致工程镜像的膨胀程度。
这种就喊口号“不要重复造轮子”,“节省开发时间,提高开发效率”,依赖进来,拿来主义,用就行了。
有一定的学习和积累,了解并分析依赖关系,会做一些设置和进行排除。
手敲代码,登记比对依赖,托管管控依赖。下面举3例说明下:
ES使用Guice框架进行模块化管理。Guice是Google开发的轻量级依赖注入框架(IoC)。软件设计中经常说要依赖于抽象而不是具象,IOC就是这种理念的实现方式,并且在内部 实现了对象的创建和管理。摘自:《Elasticsearch源码解析与优化实战》_张超。
但是大家有没有注意到AbstractModule代码,在es和在Guice是一样?官方的讨论也可以佐证自2016后就是这种策略。[1]
Intel公司使用Black Duck公司 提供的Protex解决方案,验证软件开发人员在使用开源代码/第三方代码过程中,是否严格地遵守公司所制定的软件许可政策。该解决方案帮助Intel公司大量地减少软件重新编写工作,并将可能面临的商业法律风险控制在最低程度。
Intel公司组成专门的Protex项目团队,代表成员来自不同业务部门、不同职能领域。项目团队工作的一部分就是增强开发人员关于软件许可证问题的培训。项目团队不断寻求改进的验证方案。它要求每个产品都使用经批准的遵从法规的软件代码。在寻找有关解决方案时,项目团队安排一些业务部门试用Black Duck的 Protex 平台,并评估它是否符合Intel的要求。经过评估,Intel认为Black Duck 的解决方案可以有效的帮助他们进行开源软件和第三方软件的合规性检查,并帮助他们有效的管理开发过程中对开源软件和第三方软件的使用。在选择Black Duck 之后,Intel已经在全球部署了多台Protex 服务器。他们经常使用Protex分析将要发布到公司外部的软件。Protex 已经和Intel 其他法规遵从实践相结合,成为Intel 软件开发管理流程的组成部分之一。[2]
父级模块管不了事,它管!
有没有工具可以负责我们分析、排除、优化打包的?
理想状况下,公司应该掌控所有的代码,对于依赖的代码也应进行分析彻底,要逐步吸纳所有优秀架构、工具等进行公司化代码。一个成熟的java代码公司,就需要有自己的代码积木构建,备好所有零部件,登记备案。一、可以避免知识产权纠纷;二、所有工程按需引入积木构建,最少可用,为工程镜像瘦身提供极致可能。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。