本人來上海蔘與某個銀行的某個項目將近一年，針對甲方提出的三個點做具體的分析。這三個點是（這三個點應該是整個行業的通病）：
- 開發效率低
- 系統運行效率低
- 質量差（BUG多）
在分析這三個問題之前，我需要先闡述本項目的開發流程。如下圖：
由於系統還未上線，所以以上流程不夠全，只能發現現有流程的問題，同時本人畢竟只負責一部分，遇到的問題並不全，僅拿自己遇到過的作分析。
這麼長的流程，有句話說得好，有人的地方有有江湖，在軟件這個行業，有人的地方就會出錯。每一個環節都會出錯，每一個環節的出錯都會影響進度。
首先分析開發效率低
關於木桶理論，我覺得它不是適用於提高開發效率的理論。開發是一個非常複雜的流程，效率低的因素很多，但是都被忽視，領導關心的就是最明顯的那個因素，似乎解決了最明顯的那個效率就是提高，其實不然，這些問題都得解決，因爲只有量變纔會發生質變。
影響開發效率低的原因如下（以下爲思維導圖，圖後會詳細分析每一條原因）:
對日誌的要求前期要求越少越好，但是真正去做到日誌又少同時又能很快排查問題很難，需要很強的技巧，像剛工作兩三年的很多人都沒有這個意識，所以在前期應該允許日誌量多，在功能穩定沒有bug後再去優化日誌。因爲按他們的要求去掉很多日誌，導致前期排錯困難，有時少打一個字段都要花費近20分鐘的排查時間。
前期過份追求性能，而不是業務的準確性，可讀性，可維護性。比如RPW改造直接破壞了系統的可讀性，可維護性，其中賬單RPW改造直接將兩三個功能耦合在一起，維護起來真是個坑，在這種業務邏輯相當複雜的項目中，應該是準確性第一，可讀可維護性第二，性能第三。
非功能任務插入到開發期。非功能的任務插入到開發期，勢必壓縮業務邏輯開發優化的時間，在人力資源時間有限的情況下肯定會以犧牲代碼質量作爲代價，然後低質量量的代碼出現bug拖慢開發和測試，同時低質量的代碼使可讀可維護變差。爲什麼優先級不能排到最後？每個迭代測試都要測試一遍，因爲有大量改動，最後一次測試纔是最終測試，測試人員在這個過程中除了驗證部分代碼正確，最重要的是熟悉了整個業務，在最後一次測試中發力，所以優先級放到後面是可行的。
大方案變更，小方案變更，數據結構變更。大方案如分庫分表，小方案如批量查詢，數據結構變更更是因爲沒有數據字典字段名變來變去，數據類型，數據是否爲空各種變。這些變更時刻打斷開發人員。
方案討論耗時。像函數式編程、springbatch封裝這樣的問題還要去深入討論，去質疑可讀性和性能，完全沒有必要浪費時間。
直接分配一些非計劃內的任務。比如某某直接給遷移組分配任務。有些不合理的任務完全可以拒絕掉，本不屬於自己負責範圍內。還有在應該執行內部測試案例執行的時候強行插入聯調任務（最終聯調質量不行）。
缺少能把控全局的架構師，即懂業務又懂技術。有些方案都是各自爲各自組，很多時候基於工作量的考慮而不是從整個系統的層面考慮，設計出來不好的方案讓開發人員買單。
某些任務不放權給乙方，甲方事情太多，導致甲方成爲瓶頸，出錯次數增多，導致乙方花更多時間彌補。比如甲方某某負責數據結構維護，經常出錯，出錯後直接影響開發人員。
很多方案沒有人拍板，都怕擔責任，遲遲不定。很多方案後面一直沒有結果。
任務分配不合理。比如讓賬務幫髮卡用卡開發了一部分功能，佔用賬務的人力資源。
內部消化的東西隨時改標準。比如數據庫文件同步一週聯調，四天成功都說慢。
部署流程太長，耗時太長，一天發佈兩次，次數少。其實前期最重要的是測試業務的準確性，規範之類的可以滯後。
日誌權限不給開每次都要申請，還有有效期。都是內網搞什麼權限？流程繁瑣浪費時間。
新同事入場後賬號開通太慢，無法提代碼，影響進度。比如我組某某兩三個星期後才提代碼。
概設詳設沒有意義還要佔用開發時間。概設詳設要有指導意義的話，給的這點時間，這點人力，根本不夠。給一部分時間搞個交付物實在不是務實，浪費時間。
聊天工具只能保存7天的記錄。有時候更早的信息是很有用的，但是找不到以前的聊天記錄。重新找回會有困難，也會浪費時間。
開發軟件不全，電腦裝軟件有限制。比如想裝一個新版本的ue看字符編碼，但是不好裝，各種限制。得有Administrator用戶權限。大文件傳輸聊天工具和郵件大小都有限制，太費勁，也不讓裝飛秋。
郵件太亂，無關的郵件也會收到。各種無關的會議郵件天天收到，一天幾十個郵件，真正有用的就那麼幾個，找有用的郵件也費勁，這種協作方式有待改善。
Jenkins機器配置低，集成慢。加點硬件資源能花多少錢?硬件成本高還是軟件成本高？算不清賬？
maven有時不能用，git掛掉，conflunce沒有下載權限。
sonar規則跟本地不一致，導致本地掃描結果跟集成時掃描結果不一致，只能在上面看。一些不合理的規則沒人排除掉，比如返回克隆後的list對象。
早上看新聞。開那個早會看新聞有啥用？
各種考試。形式主義的考試有什麼用？
各種賬號過期，賬號鎖定，一鎖定半小時幹不了活。在內網裏，這麼不相信開發人員爲什麼不讓自己人幹？
不能熱部署，啓動太慢，啓動加載好多不屬於自己的job。底層包我看過源碼，沒法去掉這些無關的job，話說底層包寫個了啥。
底層改動後導致項目無法啓動。無法執行全流程測試。
未連數據庫的單測，無法進行全流程測試，導致改bug後很難自測。只測service層屬於殘疾測試，自欺欺人的做法，自己Mock返回自己斷言，也就測一些低級的問題。不好自測導致bug重現。本來這種批量測試跟聯機不一樣，每一次跑批機會非常珍貴，這樣浪費掉機會。
ERM生成dao，每次編譯dao，浪費時間。不能單獨打包放到私服上，其它工程引用嗎？
通過ERM生成腳本，不能通過EXCEL或直接讀數據庫生成嗎？否則多一層就多了出錯的概率。
框架沒有文檔說明，有的源碼還拉不下來，沒有培訓，很多東西不知道怎麼用。比如自帶的RestTemplate，分頁接口，總是開發完了有人才說底層包裏有，可以直接用，然後再改，浪費時間。
測試人員無法理解業務來找開發解釋，浪費開發人員的時間。尤其是pre-uat的測試人員，能力不行。
測試人員無法看懂日誌，明顯的數據問題還要找開發解決。sit和pre-uat都有，有的很明顯的哪個參數不存在還要找開發確認，白白浪費開發的時間。
開發中遇到問題沒有尋求其它同事的幫助，一個人死摳。開發人員要有確認問題是否應該自己解決的能力。有的問題可以在網上搜找到答案，有的需要問別人，開發人員要拿捏好，需要問別人的應該及時問，保證進度。
排查問題效率偏低，日誌打印不夠好。很多日誌都是想當然的去打，並沒有考慮，假如我拋異常的地方拋了出去斷批了，測試人員還有自己是否能夠根據日誌快速定位問題。很多異常並沒有拋出關鍵信息導致排查困難，浪費時間。
測試問題修復後沒有自測。對於小改動還好，但是對於大改動，出錯的概率就是很大，沒有自測讓測試人員再打回來，白白浪費測試人員的時間，影響整體進度。
開發人員一個人不細心導致代碼編譯問題，影響其它人。漏提交代碼等等原因導致編譯問題，如果出錯地方少還好，其它開發人員可註釋掉，繼續自己的工作（比如自測），但是如果是大範圍的報錯，其它開發人員就是隻能等待。
部分開發人員git使用不熟練，覆蓋他人代碼。有同事這樣做過，發生過幾次，其它開發人員只能被動等待。
部分開發人員沒有提問題解決開發效率的意識。很多開發人員只是把任務完成後就下班，平時以及日報中也沒有提及遇到的問題，如何去解決，主動性不夠，只是把自己當成一個鏍絲釘，但是即使是鏍絲釘也要做一個積極的鏍絲釘。
日誌打得不夠詳細導致測試一斷批就找開發。打出日誌量少並且足以讓測試和開發快速排查問題的日誌並不簡單，很多人以爲隨便打出一個字段就OK，其它這個字段對後面的排查根本沒什麼作用。每次打日誌應該能預見到代碼裏可能發生的問題。
FSD變更頻繁。SA的變更不提，只說從舊主機中梳理需求。在這種沒有需求文檔只有代碼的系統裏，本人曾經在上個項目梳理過需求，從COBOL語言的代碼裏反推出原來系統的需求，簡單的還好，某些關聯性強的需要梳理出其它功能才能理解本功能爲什麼這樣設計。有一些在沒有梳理出來之前，自己的理解本身就是錯的。在這種情況下寫出FSD，後面就有了再改的動作。
數據結構變更頻繁。由於主機的設計跟現在新系統的數據庫不一樣。導致數據結構不能正確映射成新系統中合理的數據結構。比如：日期，字符串，字段命名。
人員不確定性大，開發進行時調走。我組的人變化較大，經常被調走支援其它組或其它項目，而人員補充不及時，即始補充了，因爲剛接手，也需要熟悉一段時間，這一段時間拖慢了進度。
沒有一套成熟的技術方案，然後各種扯皮摸索耽誤時間。老闆的戰略方向有問題，不應該重業務輕技術。因爲畢竟我們是一個實施團隊，裏面有各種角色，甲方不會僅憑你的業務解決方案來評價系統做的怎麼樣。另外，我們是根據項目組的團隊，雖然同事能力還可以，但是如果是根據團隊接項目的話，戰鬥力會更強，比如拿出一個專門做信用卡的團隊。
各種報工，公司管理平臺報，行裏管理平臺報，開發組長報，公司站會報，行裏站會報。這些小問題每天發生，乘以兩年的天數，可想而知，也會有影響，是不是可以精簡一下。
會議時間過長，容易發散，討論到某個細節，佔用開發時間，無關人員參與不懂得主動離席。
一個人好多事，任務沒有優先，來回切換。有的功能的實現需要整塊時間來思考，各種事情的打斷只會讓想出的方案變差。機器多線程可以提高效率，但是人不行，人串行做事效率質量最高。
由於各種因素導致的加班使錯誤更容易產出，錯誤的增多增加了更多排錯工作量，所謂加班寫bug，有時會形成一種惡性循環。
對進度的認知。思考也是進度，並不是堆出代碼纔算進度，思考比寫更有技術含量，更有價值。但是行裏總認爲堆出代碼才能算進度。
技術方案的複雜度增加開發工作量，比如分庫分表，批前批後同步。
然後分析執行效率低
review不到位，review時應該關注性能問題。比如日誌打到雙層for循環裏，用反射等。
開發人員技能和經驗不足。開發人員提前預見，寫SQL複雜的需要查看執行計劃提前調優。
框架問題。比如甲方給的框架本身啓動就耗時較多，開源框架也有相當的耗時。
最後分析質量差BUG多
素質不一，風格不一。根據項目組建團隊的方式，認爲只要來個人能幹活就行，但是能幹活的標準如果是實現功能的話也無妨。但是如果要考慮到代碼質量，這就是一個比較大的問題，因爲新來的人如果是新手，需要一段時間學習，如果是老手，需要一段時間改掉自己原來的習慣。
沒有代碼潔癖，職業素養不夠強。有的連空指針都懶得去判斷，空指針這個細節直接能反應出這個人的編程素養。各種重複代碼，複種idea提示的問題也不去修復。
對業務的理解不夠清楚也不去問BA就開發。這種情況下開發出來的都是業務Bug。
review業務代碼不夠質量把控不到位。技術上的問題需要review，業務上的也需要，要更細。某些情況下很多活都壓到組長身上，組長做了很多簡單但是量大的活，而不是關鍵的活，沒時間review。
FSD設計漏洞或描述不嚴謹被開發誤解。
單測方案問題，不連數據庫測試的單測方案本身是有問題的。
各開發商從工作量角度設計系統，而不是全局考慮。
技術方案問題。比如RPW改造，尤其是賬單部分極大降低了可讀可維護性。分庫，批前同步，批後同步，這種方案帶來了更多的開發量，更多的開發量意味着更多的bug。
文件方式看報表，不能用HBASE？什麼年代了還是用文件看。
問題已分析完，但是我不想寫解決方案，因爲上面的大部分解決不了，大項目，大公司太不靈活。本人乃一個小鏍絲釘，有心殺敵，無力迴天，只能盡力解決自己能解決的問題。某些分析沒有講具體的例子，是因爲回想不起來，但是本人肯定經歷過，不會憑空捏造。
最後附一個讀書筆記《代碼整潔之道-程序員的職業素養》，經典之作，拿來評價這個項目再合適不過了。
