創新式開發探索（二） —— 發現不同尋常的問題

        談到創新， 通常會讓人想到， 如何絞盡腦汁地去想出一個美妙的創意。  不勞您費神， 現實自然有很多問題有待求解。

         何謂不同尋常 ？

          舉例一，  要做一個針對訂單和使用者的增刪查改的功能， 當然， 對於做了半年開發的你也不是什麼難事。 那麼， 如果又做要針對訂單的管理， 針對產品的組態管理， 很快就會面臨一大堆類似的需求。 怎麼辦？ 花費相同的氣力， 一次次重複嗎？  

           能否做一個帶搜尋的增刪查改的分頁資料控制群組件， 具體的業務只需要少量的配置和方法填充就可以很輕易的完成 ？ 

 

           從具體到通用， 這是一個不同尋常之處。 

           舉例二， 大多數系統都配置了資料庫，這很簡單，放在 Spring 設定檔裡，一切交給 Spring 就可以了。對於產品營運系統來說，往往要涉及多個資料庫連接，必須做到動態切換和訪問多個資料庫，怎麼辦？ 

           一個監控API， 可以根據傳入的監控組名稱及指定時間段返回相應的監控項資料， 比如 query('cpu') 可以返回 CPU_USER, CPU_SYS, CPU_WAIT, CPU_IDLE; query('mem') 可以返回 MEMTOTAL，BUFFER，CACHED， FREE， query('disk_io_speed') 可以返回 rkb, wkb , query('net_traffic') 可以返回 RECV_BYTES, TRANS_BYTES 等, 那麼，你必鬚根據使用者的需求，解析資料並產生報表類似如下

           CPU_USER    CPU_SYS   CPU_IDLE   MEMTOTAL  FREE rkb  wkb  RECV_BYTES  TRANS_BYTES 

           但你並不清楚使用者的需求。可能有的使用者對 CPU_USER CPU_IDLE ,  rkb, wkb 感興趣， 有的使用者對 RECV_BYTES, TRANS_BYTES 感興趣。 你必須找到一種方式， 能夠允許使用者做些配置， 產生使用者感興趣的監控項的報表。 如何做 ？             

            從靜態設定到動態配置， 這是一個不同尋常之處。 

            舉例三，  一個資料庫的流量表， 有 ip 地址, port 連接埠和 bps 流量資料 三個欄位。 要找出記錄中 bps 最大的 十個不重複的 ip:port 。 當然， 這不是什麼難事。 

                      select distinct vip from (select concat(ip, ':', port) vip from table order by bps desc )  vips  limit 10 

             如果這個表有 1000W 層級的記錄數呢， 那麼上述 SQL 將會運行 50s 左右。 你有能力最佳化它， 或者用更快的方案來解決這個問題嗎？

            從小資料集處理到大資料集處理的效能問題， 這是一個不同尋常之處。 

            舉例四，  你需要繪製一個VIP 隨時間變化的流量曲線圖， 然而，不同VIP 的流量值範圍分布很廣泛。 有的 10 - 100 之間， 有的 10000-100000 之間， 有的甚至 10000 - 10000000。 刻度設定小了， 大的流量值無法顯示（尤其是值得關注的峰值）， 設定大了， 小的流量值又變成了直線。 如何設定你的刻度，使之適應如此廣泛分布的值範圍？

           你的遊戲伺服器對外提供24小時不間斷的服務； 最初容納100個人線上遊戲； 然而，突然有一天使用者人數激增， 結果伺服器不堪重負， 原來的程式無法容納這麼大的遊戲使用者容量； 短時間修改又不可能， 你的程式是否能夠通過僅僅部署多台分布式的伺服器就直接增強其處理能力 ？  換句話說， 你的程式具有彈性麼 ？  

           從固定僵硬到彈性適應，  這是一個不同尋常之處。

           舉例五， 你需要訪問多個叢集的資料庫去訪問某些記錄， 最初， 叢集較少， 處於安全和簡單考慮， 採用了串列訪問的方式。 然而， 隨著叢集的增加， 要訪問的資料庫也越來越多， 查詢效能直線下降； 於是， 你希望採用並發訪問的方式， 這樣， 多個資料庫的總訪問時間大約縮減到1-2個資料庫的訪問時間了。

           從串列執行模式到並發執行模式， 這是一個不同尋常之處。

 

           舉例六， 做 GUI 程式是很繁瑣的，介面要調整到比較賞心悅目的程度會耗費很多時間和精力； 能否將一些通用的排版策略抽離出來，做到萬用群組件中， 其它組件直接繼承該萬用群組件，就能複用其排版設定，最大程度減少介面排版的工作量； 此外， GUI 測試也是個很麻煩的事情，難以像背景程式那樣做自動化的測試。 那麼， 如何做到GUI測試的自動化呢？

           從瑣碎隨意到自動化與規範， 這是一個不同尋常之處。

           問題往往是相互關聯的。 大資料世界更期待動態、彈性適應能力， 並發執行模式， 自動化、規範地測試和營運 ， 要儘可能複用，這就要求對日常重複開發工作通用化， 一次解決， 使用多次。 

       具有挑戰性的問題往往是創新的重要驅動力。 發現不同尋常的問題， 踏上創新式開發之旅。