1. <em id="vzzs9"></em>
      <tbody id="vzzs9"></tbody>

    2. <span id="vzzs9"></span>
      <progress id="vzzs9"></progress>
      首頁 編程技術2個動作,讓研發效率提升120%,代碼減少50%

      2個動作,讓研發效率提升120%,代碼減少50%

      運維派隸屬馬哥教育旗下專業運維社區,是國內成立最早的IT運維技術社區,歡迎關注公眾號:yunweipai
      領取學習更多免費Linux云計算、Python、Docker、K8s教程關注公眾號:馬哥linux運維

      簡介

      本文以云智慧數字化運維數據平臺DODB產品為例,由云智慧研發團隊通過分析對比產品歷史版本與新版本中的Java代碼行數、Java文件個數、代碼注釋占比、發布包大小、組件依賴等關鍵數據,找尋出歷史版本開發過程中存在的代碼、項目管理及開發人員等方面問題,最終梳理總結出改造代碼、制定規范等可提升研發效能的有效方法。

      一、數據對比

      通過下方圖表數據可以看出,在新版本中,代碼注釋占比降低了近150%,項目分支數減少了近100%,其他各項數據也均有了明顯的變化。

      代碼行數統計

      • 過去

      2個動作,讓研發效率提升120%,代碼減少50%插圖

      • 現在

      2個動作,讓研發效率提升120%,代碼減少50%插圖1

      代碼注釋比例

      • 過去

      2個動作,讓研發效率提升120%,代碼減少50%插圖2

      • 現在

      2個動作,讓研發效率提升120%,代碼減少50%插圖3

      sonar掃描

      • 過去

      2個動作,讓研發效率提升120%,代碼減少50%插圖4

      • 現在

      2個動作,讓研發效率提升120%,代碼減少50%插圖5

      數據匯總對比

      指標 過去 現在 對比結果
      項目module數量 12 8 減少33%
      代碼總行數 174252 136484 減少22%
      Java代碼行數 90310 50719 減少44%
      Java文件個數 982 583 減少41%
      代碼注釋占比 3% 7% 提升133%
      sonar-bugs數量 92 0 減少100%
      對外http接口數量 160 100 減少37.5%
      對外dubbo接口數量 100 25 減少75%
      發布包大小 226M 170M 減少25%
      項目分支數 300(參考) 20 減少93%
      寫入性能(單條10K) 88W/min 187W/min 提升113%
      組件依賴 ignite、vertx 刪除ignite、vertx 5.3.1以redis替換ignite,徹底刪除vertx
      微服務 1 3 5.3.1支持服務以存儲模塊或者非存儲模塊獨立運行

      二、歷史問題回顧

      通過上述各項數據的對比分析,本章節對歷史版本開發中存在的代碼、項目管理、開發人員等各方面問題進行了回顧分析,詳細可查看下文:

      代碼側問題

      • 項目module數量多,部分不再使用的模塊仍存在;
      • 各module模塊沒有統一的包名區分,導致大量全限定名一致的類存在,加載順序不一致引發各種問題;
      • 項目中存在大量不再使用的代碼塊,增加了新人的學習成本及排查問題難度;例如dubbo接口,外部僅使用25個,對外提供了100個;
      • 項目中重復代碼較多,相似業務復制粘貼現象較嚴重,維護成本較高;
      • 重復造輪子較多,如HttpclientUtil等;
      • 注釋率不夠,大量代碼無注釋,無測試用例;
      • Vertx框架改造為SpringBoot容器不徹底,仍有眾多Vertx邏輯和Springboot共存;
      • 增加新模塊需要寫很多sql,需要手動編寫Controller、Service、Dao層的“基礎”代碼;
      • 項目依賴ignite組集群,導致服務是有狀態的,大多人員對ignite不熟悉,導致解決問題較困難;

      項目管理側問題

      • 沒有強有力的規范無法支撐更多的成員高效的協同開發;
      • 分支管理無規范,導致分支數過多,活躍分支數量少,幾百個分支維護困難;
      • 以分支形式交付,交付后分支仍有提交,導致追蹤發版版本困難;
      • 無代碼管理規范,多次出現功能遺漏、多功能等導致分支回退;
      • 沒有代碼review制度,無法保障代碼質量,沖突強行解決的問題時有發生;

      開發人員側問題

      • 大多成員對代碼不夠熟悉,或僅熟悉部分代碼;
      • 很多成員不敢修改代碼,更不敢刪除代碼;打著不影響其它功能的旗號,復制粘貼大量的重復代碼和邏輯,導致維護困難;
      • 早期代碼設計較為合理,隨著人員不斷增加,很多代碼重copy輕設計,只求完成功能,不考慮維護性拓展性,毫無設計可言;
      • 部分人員git不熟練,導致強行覆蓋遠程分支的情況時有發生,無權限管控;

      部分問題示例

      • 全限定名完全一致的類

      2個動作,讓研發效率提升120%,代碼減少50%插圖6

      2個動作,讓研發效率提升120%,代碼減少50%插圖7

      • 重復造輪子

      2個動作,讓研發效率提升120%,代碼減少50%插圖8

      三、解決問題方案

      為解決產品歷史版本開發過程中存在的代碼、項目管理等各方面問題,云智慧研發團隊制定了開發、接口等相關規范;同時,通過限制代碼倉庫權限等其他操作也保證了規范的嚴格執行。

      制定相關規范

      無規矩不成方圓,切實可行的規范是保障團隊戰斗力的前提。規范制定應本著提高團隊水平,又不限制成員積極性為目標。

      • 開發規范
      • DODB接口規范
      • 開發規范實行計劃
      • DODB版本tag命名規范
      • 開發設計模板
      • 提測模板
      • 會議規范

      保障規范嚴格執行

      工欲善其事必先利其器,規范里提供了相應的工具,用好可達到事半功倍的目的;同時有相關提交流程保障規范落地,不能讓規范流于形式。

      • 設置gitlab權限,保障強制代碼review

      禁止任何人向保護分支提交代碼,必須走merge流程

      2個動作,讓研發效率提升120%,代碼減少50%插圖9

      merge列表界面

      2個動作,讓研發效率提升120%,代碼減少50%插圖10

      merge詳情界面

      2個動作,讓研發效率提升120%,代碼減少50%插圖11

      • 完成后遠程分支強制刪除

      2個動作,讓研發效率提升120%,代碼減少50%插圖12

      • 以tag追蹤生產交付,要求測試交付時一定要有tag

      2個動作,讓研發效率提升120%,代碼減少50%插圖13

      禁止刪除tag

      2個動作,讓研發效率提升120%,代碼減少50%插圖14

      標簽tag列表

      2個動作,讓研發效率提升120%,代碼減少50%插圖15

      標簽tag詳情

      2個動作,讓研發效率提升120%,代碼減少50%插圖16

      四、如何對現有代碼進行改造

      改造原則

      • 不影響現有開發和交付進度,必須互不影響,類似于空中加油機,既要加油,飛機也不能停;
      • 保證兼容性升級,改造后原有數據和業務不受影響;
      • 對外接口(如dubbo)原則上不能修改,保證調用方功能正常,特殊情況可溝通配合(如dubbo方法重載必須修改);
      • 不需要的代碼一律刪除,以后需要從歷史版本找回,禁止批量注釋掉代碼;
      • 代碼設計要遵循 高內聚低耦合 的原則,保證可重用性、移植性;
      • 目標一致,改造循序漸進,保證充分測試。

      部分改造邏輯

      • 對不再使用的代碼直接刪除,歷史可在gitlog中查看,例如bdp-plugin-sdk、bdp-plugin-zabbix等模塊直接刪除;
      • 集中解決重復造輪子的問題,對部分通用邏輯,如HttpClientUtils、db操作等使用已有工具類替換;
      • 書寫數據庫代碼繁瑣,引入mybatis-plus操作mysql
      <!-- mybatis-plus操作數據庫 -->
      
      <dependency>
      
        <groupId>com.baomidou</groupId>
      
        <artifactId>mybatis-plus</artifactId>
      
        <version>${mybatis-plus.version}</version>
      
      </dependency>
      
      • 對外dubbo接口bdp-rpc和bdp-rpc-model合并為bdp-rpc-core對外提供,通過編譯各調用方項目,刪除未使用的接口
      • 徹底刪除vertx和ignite依賴

      2個動作,讓研發效率提升120%,代碼減少50%插圖17

      2個動作,讓研發效率提升120%,代碼減少50%插圖18

      • 對各module的功能和命名做了統一規范,對原有代碼做統一修改調整
      模塊名稱 功能 包名前綴
      bdp-api Restful API和業務邏輯實現、只能被bdp-standalone依賴 com.cloudwise.bdp.api
      bdp-base 業務對象和接口定義 com.cloudwise.bdp.base
      bdp-commons 通用工具common util com.cloudwise.bdp.commons
      bdp-pipeline pipeline數據處理實現 com.cloudwise.bdp.pipeline
      bdp-rpc-core rpc接口聲明及rpc實體類定義,不能依賴其它模塊,對外rpc接口請慎重修改 com.cloudwise.bdp
      bdp-standalone 主項目,DODB主入口類為DodbServiceApplication com.cloudwise.bdp.standalone
      bdp-store-ck ClickHouse存取實現 com.cloudwise.bdp.store.ck
      bdp-store-common 數據層存儲接口聲明 com.cloudwise.bdp.store.common
      • 調用gitlab-api對長期不活躍分支集中清理備份
       /**
      
       * github-api
      
       * https://github.com/help/api/api_resources.md
      
       */
      
      private static final String GITLAB_URL = "https://github.com/api/v4/projects/2393/repository";
      
      private static final String PRIVATE_PARAM = "*****************";
      
      
      
       /**
      
       * 清理分支,已合并分支直接刪除,其余刪除前以tag形式備份
      
       */
      
      @Test
      
      public void cleanBranches() {
      
          Map<String, Object> paramMap = Maps.newHashMap();
      
          paramMap.put("private_token", PRIVATE_PARAM);
      
          paramMap.put("per_page", 10086);
      
      
      
          String body = HttpUtil.get(GITLAB_URL + "/branches", paramMap);
      
          List<Branche> branches = JSON.parseArray(body, Branche.class);
      
          // 按最后一次提交時間由小到大排列
      
          branches.sort(Comparator.comparingLong(o -> o.getCommit().getCommitted_date().getTime()));
      
          log.error("分支數量:{}", branches.size());
      
          branches.forEach(item -> log.info("{}", item));
      
          // 清理長期不活躍分支
      
          .....
      
      }
      

      發布包進行瘦身

      首先了解發布包是如何構建的,參看assembly.xml配置

      • 發布包里有什么

      2個動作,讓研發效率提升120%,代碼減少50%插圖19

      • 不要把配置文件重復打入jar包中
      <plugin>
      
         <groupId>org.apache.maven.plugins</groupId>
      
         <artifactId>maven-jar-plugin</artifactId>
      
         <configuration>
      
            <includes>
      
               <include>com/cloudwise/bdp/**</include>
      
            </includes>
      
            <archive>
      
               <manifest>
      
                  <addClasspath>true</addClasspath>
      
                  <mainClass>${start-class}</mainClass>
      
                  <classpathPrefix>../lib/</classpathPrefix>
      
               </manifest>
      
            </archive>
      
         </configuration>
      
      </plugin>
      
      • 重點關注lib包,可從以下幾個方面排查

      重點關注過大的包是否是項目必須的

      2個動作,讓研發效率提升120%,代碼減少50%插圖20

      是否有重復依賴問題

      例如netty-all是眾多netty-*的合集,不要去重復依賴,如果版本不一致還會引發問題;

      2個動作,讓研發效率提升120%,代碼減少50%插圖21

      batik-all是batik-*的合集,排除各個子包

      2個動作,讓研發效率提升120%,代碼減少50%插圖22

      排查后通過相關插件追查依賴源,精確排除

      <plugin>
      
         <groupId>org.apache.maven.plugins</groupId>
      
         <artifactId>maven-dependency-plugin</artifactId>
      
         <version>${maven.dependency.version}</version>
      
      </plugin>
      

      1、開發人員應清楚依賴包是做什么的,不要不管三七二十一依賴一堆沒用的包,無謂增加發布包大小,還會帶來隱患;

      2、代碼審核時,依賴文件(maven工程的pom.xml文件)的修改需要重點關注,禁止隨意引入和修改依賴;

      3、各產品線可在統一各依賴版本的基礎上,調整構建方式,大幅減小集成包的大小。

      改造總結

      • 優化不求一步到位,可逐步進行,目標明確即可;
      • 復雜是一切問題的根源,能用一行代碼解決的問題,就不用兩行;
      • 一切功能都是靠代碼實現的,寫好代碼很重要,不能把寫好代碼當成一件小事,只是為了完成所需功能而堆砌代碼很簡單,但編寫清晰易懂且能完成所需功能的代碼并不簡單;
      • 你永遠無法編寫出“完美”的代碼,要用工具和流程規范來保證這一切,要充分測試;

      本文鏈接:http://www.abandonstatusquo.com/40943.html

      網友評論comments

      發表評論

      您的電子郵箱地址不會被公開。

      暫無評論

      Copyright ? 2012-2022 YUNWEIPAI.COM - 運維派 京ICP備16064699號-6
      掃二維碼
      掃二維碼
      返回頂部
      久久久久亚洲国内精品|亚洲一区二区在线观看综合无码|欧洲一区无码精品色|97伊人久久超碰|一级a爱片国产亚洲精品