<s id="xcxsa"></s><rp id="xcxsa"></rp>

  • <span id="xcxsa"><pre id="xcxsa"><rt id="xcxsa"></rt></pre></span>
    <dd id="xcxsa"></dd><tbody id="xcxsa"></tbody>
        首頁 編程技術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://m.abandonstatusquo.com/40943.html

        網友評論comments

        發表評論

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

        暫無評論

        Copyright ? 2012-2022 YUNWEIPAI.COM - 運維派 京ICP備16064699號-6
        掃二維碼
        掃二維碼
        返回頂部
        十分钟免费观看视频高清下载