最近在整理公司一些内部公用包的时候有些疑问，想问问大🔥

[mseasons]

最近在看公司代码的时候发现很多项目都用了相同的 util 包，比如公司内部封装的 APIResult 类用于返回值、Json 包用于解析 JSON 字符串等等，想把这些东西整理出来作为一个单独的模块，于是思考了一些问题

使用这些公用包的项目有 ssm 项目，也有 SpringBoot 项目，各种不同的分布，而且很多还依赖了第三方库，想问一下大家，大家的公司内部是如何处理公用包的？

我现在的想法：

按不同功能分不同文件夹，每一个要用到项目中的类都写一个 main 类+注释来表明类的使用方法

[xnode]

前排学习

[loongwang]

如果没有专人维护,历经长期考验的放到 framework 里,其他的谁用谁复制一下就行了. 不要想尽善尽美.

[BlackBerry999]

重复造轮子是常态。
如果你想治理这种情况，也只能在自己的职责范围内治理。
你如果是团队老大，那你就能治理你们团队；你如果是公司技术老大，那你就能治理你们公司；你如果是集团技术老大，那你就能治理你们集团。

[mseasons]

@loongwang 没有想尽善尽美，就是在看项目的时候，有一些确实是非常常用的公司内部库，但是他们会很杂乱的引入到各种项目里，而各种项目又有自己的一些 util 类，专有的和可复用的放在了一个文件夹下，如果类不是单独的一个类，则其他项目引入这些可复用包的时候找起来会很累

[mseasons]

@BlackBerry999 （其实我是实习生）

[lqw3030]

实习生看不惯公司代码是常态。思考下为什么会出现这样的代码，问题一般都出现在一个两周工作量的需求被要求 3 天内做完的时候。

[mseasons]

@lqw3030 没没没，没看不惯，这段时间看了很多和软件工程相关的书，觉得把它们抽出来会提升代码可读性和可复用性，不是代码写的不好，只是公用包的组织有些混乱

[passerbytiny]

https://i.loli.net/2020/03/11/qtpnwl94H3oIXLS.png

你看看光 StringUtil 都有多少个，Util 形式的东西，都是代码简单但高度定制化的工具，传播主要靠“复制-粘贴-整理”而不是发行依赖包。你之所以觉得杂乱，是因为人员或者 Util 一多，就很难再细心的“整理”了，直接偷懒的引用包，连没有整理的纯“复制-粘贴”都懒得做了。

不要想着整理公用工具包，迄今为止唯一一个整理成功的公用工具包是 Google Guava，那是人家“公开摸鱼”才做出来的。并且你看看 Google Guava 的 Stirings 类，比其他的各种 StringUtil 精简多了，因为定制化太高的工具并不适合所有人，要强行删除。

[kingzeus]

顺其自然就好

从人的角度来说，大家都是吃这碗饭的，不管是不是科班出身，软件工程都是学过的，所以你明白的，其实大家都明白，为啥存在这样的结果，必然是当时最优的选择。如果有空，不妨照着标准试着治理下，代码规范，测试用例，文档说明 包 /版本管理 一步一步做完，其实还是很锻炼人的。

从事的角度来说，公共库并不会直接产生收益，所以并不会有太多人力来重构。而且，之前用的好好的，你能保证改了不会影响到下游代码的行为？另外就是公共库的需求可能会有调整，。你改了很容易影响到其他项目，还不如复制出来自己改下，这样即保证速度，又不影响其他人，除了代码难看点

[Asimov01]

@kingzeus 深表赞同。我刚实习的时候也是各种看不惯别人代码，有时候也会去改，但是没改出问题的时候，其实收益仅仅是我自己看着舒服一点儿而已，反而出了问题祸害的不止自己，还要连累大家。工作时间越长越不敢也不会随意动别人的代码，尤其是祖传代码。

[julyclyde]

这种情况暴露了公司内的沟通问题
当需要一个功能的时候，如果没有更低的沟通成本让需求方得知团队内已有的成果积累，则选择外来软件和重新造轮子就是更优的选择了

[mseasons]

@passerbytiny
@kingzeus
@Asimov01
嗯 谢谢前辈们，这个问题之始，就是 leader 给了我一个需求，让我去开个新项目做，但是因为要遵守公司的一部分接口规范，我需要使用一些之前公司使用的这些统一返回值的类、JSON 解析类、HTTP 请求类等等，而公司内部没有一个将这些非常常用的包统一起来的一个 package，我在找的时候要在老项目中 util 中大海捞针，在原来的项目的 Controller 中找 APIResult 是怎么调用的，直接拷过来还不行，我还要在 pom.xml 里面找各种依赖等各种问题，于是提出了这个问题。

[passerbytiny]

@mseasons #12 这个正确的应对措施不是自己找，而是去要，有接口规范文档就要文档，没有文档就要示例代码，没有示例代码就要人。