讀書心得--軟體專案開發實務:別只當編程猴(二)

傅勝華
Sep 19, 2022

--

警語:本人沒有合作開發經驗,只有自學、開發一些小專案,因此關於大型專案、合作開發、團隊協作的想法皆從書上以及自己推論而出,必定會有缺漏或理解錯誤的地方,請閱讀時務必小心。

Photo by Matias North on Unsplash

第二章──在持續變革中找出背後的相依性

情境:有個高品質文件架構出的知識庫網站,最近想要建造出搭配的維基網站──讓訪客編輯文件

知識庫網站

維基網站

維基功能

一、製作出雛形,讓訪客編輯的功能

二、因為知識庫網站和維基網站使用相同的儲存機制,空間若被惡意占用,原本的功能也會受到影響。
基礎架構層次相依性

三、掛載在同一部伺服器,伺服器會自動把Markdown轉成HTML,所以只有讓轉換請求超載,處理程序就會停止。

四、災難預防措施
網頁最大數量1000
每張網頁最大500KB
Markdwon轉換程序移到工作佇列(work queue),佇列容量限制最多20個,超載跳error maessage
知識庫網站(官方)加入可用性監控

側欄

情境:希望能在維基網站加入側欄,推薦5個最熱門網頁、5個最近更新、5個隨機網頁,讓使用者探索更多網頁

一、先試做功能,測試難度,也可以預估時間

二、從簡單的著手,5個最近更新、5個隨機網頁

三、發布上線後,到處亂點網頁,重新整理網頁(系統測試)

四、Q:有一些舊網頁沒有時間戳
A:1.將沒有時間戳的資料通通設定成維基推出的時間
2.限定新資訊不能沒有時間戳
資料庫架構,確保資料的一致性
資料層次相依性

五、Q:側欄寬度是彈性的,有些標題太長會擠壓到內容
A:設定最大行寬
2個功能在同一個頁面,要確保不會互相干擾

六、與同事溝通,hottest需要時間設計,並告知前兩項功能的實驗結果。

hottest功能

情境:同事回覆1.hottest很重要2.配色有點太刺眼。

一、開發中的功能在外表上,粗糙跟美觀做個平衡
粗糙的不至於能直接推出
美觀的不至於不舒服

二、Hottest功能得從網站分析服務,即時得抓特定時段的資料

三、Q:每次載入頁面,都要呼叫會浪費效能
A:每四個小時更新資料到資料庫

四、Q:外部服務(API)相依性
API回應速度慢,甚至流量問題拒絕服務要求
突然停止服務(暫時或永久)
回傳null或格式錯誤的回應
產生逾時錯誤
……等等
A:另外寫腳本拿取每張網頁的造訪人數,資料錯誤或逾時通知
跟主程式不相連,腳本失靈最多導致資料過時

五、發布上線,告知同事,code review

網頁出現不知名廣告

情境:有的網頁出現不知名廣告

一、將維基導到維護頁面

二、猜測問題來自於Markdown可以輸入<script>導致,檢查Markdown是否含有HTML
A:維基目前有150張網頁,32張有行內HTML,有12張有<script>

三、產生一份連結表單,分成三類「不含HTML」、「含HTML不含<script>」、「含HTML含<script>」請同事看不含HTML的連結,自己處理含HTML的部分

四、發現有人用<script>把訪客導到廣告,但有些人用HTML呈現表格或內嵌影音來豐富文章閱讀性。
同時意識到<iframe>也是一個潛在的危險。

五、對問題深入了解後,重啟維基的部分功能,從文件抽離所有的<script>標籤,佈署一些程式碼讓網頁只能讀取。

六、通知客服目前問題處理的進度。

七、急迫性暫時度過,開始處理原因。
Markdown給「可信任」的管理者是OK的,但是開放給「不明人士」編輯並不安全。
____相依?
因為兩件使用案例(use case) 「表面」的相似性,所以重複使用工具,卻沒注意到「基本性質」上的差異,忽略了工具在不同情境會產生的不良影響。

八、要建造安全防護措施,但也必須讓影響降到最低。
決定不拔除所有的HTML,只拿掉<script>,並限制<iframe>只能連到特定的白名單網站。

九、評估造成的衝擊,比較原始輸出網頁vs改版後輸出的網頁,有5張網頁需要手動調整

十、編寫一些測試攻擊網站

建議與提醒

一、不要只因為沒有明確修改現在的功能,就忽略了潛藏的相依性。

二、注意自家碼庫外的共用資源,他們構成的「相依性網路」。
儲存機制、處理能耐(processing capacity)、資料庫、外部服務、函式庫、使用者介面等等。

三、運用限制條件和驗證避免區域型的錯誤。也要確保監視裝置,真的發生預期外的系統錯誤,也能發現並處理。

四、在重複使用現有工具和資源,要注意情境的轉變。

SOP

如何避免新功能與舊功能的相依性?

一、製作潛在相依性檢核表

二、比較功能之間的流程圖,挑出相同的地方

三、列出功能,畫出相依性網路圖

與同事溝通,同樣遵守最小產品原則

一、盡量產生出實體的嘗試或選擇

二、盡快給予專業內的評估

與外部API串聯,預想API一定會出錯

一、與主程式做出區隔

二、做監控

危機處理──將產品導到維護頁面或公告,釐清問題,重新啟用不受影響的功能,通知客服問題處理進度,開始處理問題

可深入主題:

程式測試

Code review

監控

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

傅勝華
傅勝華