• 请不要在回答技术问题时复制粘贴 AI 生成的内容
mseasons
V2EX  ›  程序员

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

  •  
  •   mseasons · Mar 11, 2020 · 3968 views
    This topic created in 2278 days ago, the information mentioned may be changed or developed.

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

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

    我现在的想法:

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

    13 replies    2020-03-11 11:30:28 +08:00
    xnode
        1
    xnode  
       Mar 11, 2020
    前排学习
    loongwang
        2
    loongwang  
       Mar 11, 2020
    如果没有专人维护,历经长期考验的放到 framework 里,其他的谁用谁复制一下就行了. 不要想尽善尽美.
    BlackBerry999
        3
    BlackBerry999  
       Mar 11, 2020
    重复造轮子是常态。
    如果你想治理这种情况,也只能在自己的职责范围内治理。
    你如果是团队老大,那你就能治理你们团队;你如果是公司技术老大,那你就能治理你们公司;你如果是集团技术老大,那你就能治理你们集团。
    mseasons
        4
    mseasons  
    OP
       Mar 11, 2020
    @loongwang 没有想尽善尽美,就是在看项目的时候,有一些确实是非常常用的公司内部库,但是他们会很杂乱的引入到各种项目里,而各种项目又有自己的一些 util 类,专有的和可复用的放在了一个文件夹下,如果类不是单独的一个类,则其他项目引入这些可复用包的时候找起来会很累
    mseasons
        5
    mseasons  
    OP
       Mar 11, 2020
    @BlackBerry999 (其实我是实习生)
    xyooyx
        6
    xyooyx  
       Mar 11, 2020
    实习生看不惯公司代码是常态。思考下为什么会出现这样的代码,问题一般都出现在一个两周工作量的需求被要求 3 天内做完的时候。
    mseasons
        7
    mseasons  
    OP
       Mar 11, 2020
    @lqw3030 没没没,没看不惯,这段时间看了很多和软件工程相关的书,觉得把它们抽出来会提升代码可读性和可复用性,不是代码写的不好,只是公用包的组织有些混乱
    passerbytiny
        8
    passerbytiny  
       Mar 11, 2020
    https://i.loli.net/2020/03/11/qtpnwl94H3oIXLS.png

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

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

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

    从事的角度来说,公共库并不会直接产生收益,所以并不会有太多人力来重构。而且,之前用的好好的,你能保证改了不会影响到下游代码的行为?另外就是公共库的需求可能会有调整,。你改了很容易影响到其他项目,还不如复制出来自己改下,这样即保证速度,又不影响其他人,除了代码难看点
    Asimov01
        10
    Asimov01  
       Mar 11, 2020
    @kingzeus 深表赞同。我刚实习的时候也是各种看不惯别人代码,有时候也会去改,但是没改出问题的时候,其实收益仅仅是我自己看着舒服一点儿而已,反而出了问题祸害的不止自己,还要连累大家。工作时间越长越不敢也不会随意动别人的代码,尤其是祖传代码。
    julyclyde
        11
    julyclyde  
       Mar 11, 2020
    这种情况暴露了公司内的沟通问题
    当需要一个功能的时候,如果没有更低的沟通成本让需求方得知团队内已有的成果积累,则选择外来软件和重新造轮子就是更优的选择了
    mseasons
        12
    mseasons  
    OP
       Mar 11, 2020
    @passerbytiny
    @kingzeus
    @Asimov01
    嗯 谢谢前辈们,这个问题之始,就是 leader 给了我一个需求,让我去开个新项目做,但是因为要遵守公司的一部分接口规范,我需要使用一些之前公司使用的这些统一返回值的类、JSON 解析类、HTTP 请求类等等,而公司内部没有一个将这些非常常用的包统一起来的一个 package,我在找的时候要在老项目中 util 中大海捞针,在原来的项目的 Controller 中找 APIResult 是怎么调用的,直接拷过来还不行,我还要在 pom.xml 里面找各种依赖等各种问题,于是提出了这个问题。
    passerbytiny
        13
    passerbytiny  
       Mar 11, 2020   ❤️ 1
    @mseasons #12 这个正确的应对措施不是自己找,而是去要,有接口规范文档就要文档,没有文档就要示例代码,没有示例代码就要人。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   2922 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 62ms · UTC 07:26 · PVG 15:26 · LAX 00:26 · JFK 03:26
    ♥ Do have faith in what you're doing.