大型報表項目

本人曾經Lead過一個微軟的報表項目。一年多的時間裏，項目規模從只有我一我的發展到五我的再到最後部門重組被砍掉，期間親手爲微軟開發和維護了361份SQL Server Reporting Services報表，其它類型和格式的報表更是數不勝數。這以後的工做也或多或少地涉及報表開發，所以箇中坎坷能夠說是有深入體會。一些切膚之痛，不是隨便玩玩的人可以感覺到的。

首當其衝的即是開發組的經驗在成員之間難以分享。說白了，我不知道你作了什麼怎麼作的，你也不知道我作了什麼怎麼作的。由於一般來講，一份報表每每是由一位開發人員獨力完成的，協做開發同一份報表的狀況並不常見。整個開發過程，包括數據源的訪問方式，數據讀取的限制，業務邏輯的各類處理，到頁面呈現的各類設置，甚至配色和數據格式的講究，都只有負責開發的人清楚。萬一某個報表開發人員休假，其他的人很難接手他的工做，只能勉力維持報表正常運行。爲了解決這個問題，一般會有PM或者業務方面的人管理報表，然而人力老是有限，並且項目規模大起來記性經常不夠用，一不當心就忘了什麼。爲此我曾經提議應該每日或者每週彼此回顧(review)一下近期的工做，惋惜迫於報表用戶給的進度壓力(有很多微軟高層)，老闆不太支持。過後看來，當報表項目發展到必定程度，實際上是頗有必要的。

第一個問題帶來第二個問題，就是不知道咱們已經作了哪些工做，容易致使重複開發。今天來我的請求某個數據的環比，咱們給他作了，再過十天半個月又有人來要某個比率，其實就是前面的環比換個名稱，但做爲非業務部門咱們不知道這倆是一回事，因而又開個Task再作一遍。呵呵，一個數據能夠作出兩倍的工做量來，顯得好像咱們「工做很充實」（有理由多要點年終獎），不仔細全面地回顧還真是難以意識到。這還只是比較好察覺的狀況，更麻煩的還有。當一個項目轉變爲長期項目，就要特別考慮人員的更迭，報表項目也不例外。咱們這個項目在我加入時已經作了兩年了，一些報表是很早很早之前作的，咱們都很難搞得清它們的具體做用以及包含的數據——報表數量實在太多了。萬一有人要求的數據，其實剛好在那些老報表中已經存在，咱們是沒法察覺的，最終仍是一不當心就開個task出來。還好當時的PM待的時間夠久，極大的避免了這種狀況，不然咱們再招十我的都不夠用！但即使如此，仍然發生過很多這樣的情況，實在使人爲難。每一個人只能盡力確保本身不作重複的工做，可是團隊有沒有作重複的工做，就全看PM給力不給力了。

第三個問題，就是報表風格不統一。項目組中我算相對較資深的，即使沒什麼美工基礎，什麼地方什麼數據應該如何強調，實際上是有一套天然規律存在。這就跟紅燈停綠燈行同樣，人們看到某種顏色某種形狀某種字詞就會提升注意力。可是團隊成員未必對此有一致的認識。這就致使，雖然咱們的報表是一個工廠生產的，卻花樣百出各類規格都有！美工這種東西，很考驗天賦，其次是意識，再次是精益求精的態度。我說那個數據太高應該用警惕色，他說他就喜歡藍色，只要客戶不說，配色全看開發的心情，你說能有什麼辦法？這些很主觀的事情，沒人規定這種顏色就是比那種顏色更好，你怎麼說理去？只要要求的數據都給到位，一般客戶不會爲此來找茬，通常的報表開發人員也懶得去摳細節，可是作得好看一點，確實讓人賞心悅目。最初我意識到這個問題，可是沒有美工基礎我也不知道應該作成什麼樣子，因而便千方百計把SSRS報表作成Excel的表格樣式，這樣報表用戶切換着看Excel報表和SSRS報表的時候視覺上就不會有突兀感(畢竟不少報表用戶都會同時看Excel報表和SSRS報表)。僅僅是這樣小小的變化，竟然收到本項目組的歷史最高榮譽——一份來自微軟高層的表揚信！可見，有些事情用戶不說，不表明用戶沒意見。這在報表領域是個專門的主題，有人寫很厚的書講報表設計。或許集體學習報表設計理論是個比較好的辦法。

第四個問題，是報表性能的退化。這是大多數人沒法意識到的問題，由於不多人可以長期觀察大規模報表項目的性能表現。報表在開發的時候通常性能仍是不錯的，至少總有辦法讓它們「看起來不錯」。可是當這些報表運行一年兩年後，性能是否還可持續？這是個大問題。一般，會有一個甚至若干個數據庫專門爲報表提供數據。一份報表剛推出那會兒，沒有別人競爭資源，徹底感覺不到性能壓力。過個一兩年，幾百份報表上千名用戶時刻都在從這些後臺數據庫中同時讀取數據，對數據庫產生的壓力已經不亞於一箇中小型網站。所以，當初快得飛起的報表，可能也顯得老態龍鍾了。一些公司配有DBA的還好，能夠從技術層面持續優化，沒有DBA的團隊就慘了。不過即使有DBA，因爲報表需求是逐步逐步產生，報表也是一份一份開發，這致使雖然一兩份報表單獨來看是設計良好的，可是全部報表之間缺少從全局着眼的總體設計。A報表從a表出數據，B報表從b表出數據，但其實a表b表徹底能夠合併起來用而且性能更好也易於維護，然而由於A報表和B報表是在不一樣時期由不一樣的開發人員作出來的，沒有人可以認識到這一點。有時狀況則反過來，A報表和B報表都從某表取數據，二者的性能都很差，但其實A報表所需的數據只是該表的一個很小的子集，拆分紅a表和b表來用，B報表可能仍是很慢可是A報表就能快很多。隨着時間推移，數據表的增多增大，數據庫中重複的冗餘的數據也愈來愈多，愈來愈難以管理。若是報表項目夠大夠長，或許按期重構是個好辦法。

最後，許多人說SSRS報表性能很差，SSRS報表不美觀什麼的。離開那個項目後我也接觸了使用其它報表工具的一些項目，比較之下，我的感受SSRS在開發效率上無出其右，很是適合大規模報表開發。但畢竟SSRS作出來的年代比較早，也多是出於兼容性考慮（SSRS報表必須可以導出爲通常書面文檔格式），SSRS報表都是靜態報表，跟如今那些動態效果豐富的報表在美觀上確實無法比。不過最近微軟收購了DataZen並用他們的產品更新了一下SSRS，看起來有所改觀，尤爲是在移動設備上的顯示效果較以前好不少。性能方面，雖然也算是B/S結構的產品，但其實SSRS並非個重量級的報表工具，性能問題基本都出在數據庫查詢上，報表呈現並不會產生多大的性能壓力。在SSRS的後臺數據庫有視圖以ExecutionLog爲前綴，能夠查看報表生成過程當中不一樣階段的耗時，以個人經驗主要仍是DataSet裏面寫的數據庫查詢有問題。

 

掃描如下二維碼參與更多討論