KumoRail2019雜記
KumoRail項目自啓動以來，至今已逾二載。微信公衆號開放也有一年了。最初的版本雖然是能用的，但是裏面有太多的桎梏在限制著運行的效率，也讓整個程序的結構變得複雜，難以理解和優化。於是我從18年8月開始，另起重構了一個KumoRail的版本，命名為KumoRailT。我使用Tornado框架代替舊有的Flask來提高API的承載量和效率，使用SQL型數據庫，使數據的關係聯係更加緊密，構造新的回復語句生成模塊，以及重寫很多新的函數，重新整理這個架構，盡可能的做好一些。 其實最大的想法，一個還是在要優化用戶的查詢語句上面。事實上，大家 用的最多的還是交路查詢 工具，于是我就想著把這個function做到最簡。後面就做了只需要發送車次就可以返回交路以及到點信息的function。雖然這個功能確實是讓判斷查詢類型的函數變得越發複雜，并且還要和正晚點查詢裏面的車次+車站格式區分開，但是最後來看，其實現的效果還是比較OK的。具體來説，是在parse.py中的judge_type()函數中，單獨把 判定前首是不是一個車次 ，或者是車次+車站的邏輯拉出來，寫成了一個judge_train_front()函數，以此預判。在後面，才是判斷以字母打頭的格式化查詢。這樣，確實是方便多了。 然後，還有的就是，在交路查詢裏面，稍微優化了一下格式，若是同一趟車，有兩個車次的，我把它該換為以斜杠來表示，以防產生歧義。 在正晚點歷史查詢方面，我加入了一個查詢最新的一趟車的數據的功能。本來的想法是查詢這趟車的最新的數條有效數據的，但是最終發現實現起來相當麻煩，還要跨數日的數據查詢，遂放棄了（待考）。事實上的效果并不樂觀。 然後還有，配屬查詢的網站後面也是重新開放了，我也重新用Request和bs4庫寫了一個鈎子去查詢上面的信息。之前用正則表達式來做網頁數據清洗確乎是不太合適了，我現在改成了bs4來加以分析。查詢方法是依舊的。 我還加入了獲取車次表和到站表（即是車次到每個站的到站信息）的鈎子。車次表由train_list.js來導入，這裏包含了30天的所有車次安排。對於到站表（arr），則是一個個從web中catch下來。其實這個方法已經不賴。不過比較痛苦的是在調整運行圖之後， 如何合理的更新和安全的儲存新舊數據 。目前沒有看到更好的方法。 seq則爲導入