大部分程式上線前在接受靜態掃描(白箱測試)時，如果像通過機場安檢會是怎樣？

安檢線大排長龍，然後班機延誤。如果你選以色列航空，那就是常態。

在比較大的組織或是客戶要求，通常程式碼需要通過靜態分析SAST。而做集成分析的時間通常會讓開發團隊在最後交卷時刻樂不思蜀，回不了家。 (不過我某位同學跟我抱怨是因為版控軟體會斷線，所以才回不了家)

靜態程式碼分析通常靠兩大技術，第一個是已經落伍的型態比對；另一個是編譯模擬或編譯擷取(wrapper)，再做分析。分析的好壞見仁見智，我因為有利害關係所以不予置評。

使用上集成方式，型態比對是與原始碼版本管理結合，編譯型態要能與CI/CD Server集成外，最重要的商業功能要求就是

1. 夠快。 剛剛寫完沒幾天的功能馬上打退給開發者，這樣改起來才快。因此同時會有一些是提供內建在IDE的plugin。
2. 夠狠。 毫不留情的點出就是誰commit進來才造成的。但這可以細分軟體能力，有些商業軟體是可以做到「是新來的加的code，但是老鳥的架構那行leak，算老鳥的」的blame，然後結案是軟體判斷，不是人去判斷。
3. 夠準。 這就不用廢話了。

曾經看過有一港片，裡面製作贗品的高手很惹人厭。老大問：「一個祖母綠扳指，三個月可以交貨嗎？」『可以』。老大再問「那一個禮拜？」『也可以』。老大再問「明天？」『也可以』。老大生氣了，覺得這真是太荒謬了。但是他忘記了一件事，造假不管花多久時間，都是贗品，都會被看穿。

那到底靜態程式分析會不會節省你的時間？施主這就要看你的專案目標了。提升軟體品質就跟提升人品一樣的道理，當然如果你有心好好提煉自己，成為日月精華人上人 脫離人渣行列，可以自己沒事就開始整自己的code，作為撰寫習慣的一環。正所謂『為學日益，為道日損』，然後壞習慣「損而又損，至於無為」。然後再構思與敲出來的時候，level就是不一樣。

那今天工商服務一下，如果你是OpenSource專案，可以申請Synopsys Coverity的SAST服務，在https://scan.coverity.com/ 整你的專案。

整了以後會怎樣呢？俗話說：千金難買早知道 ，花完千金不知道 。 好吧，筆者曾經也觀察(Observe)一兩個專案，又要來一圖解千文了，一張圖解裡面通通都是文字。

看來這修補趨勢，用jenkins的人感覺應該"很有感"。再來一個

看得出來2018年OpenWrt 18.06版推出是很OK的，不是bug滿天飛的趨勢。難怪本次參賽發文主題過半一定都要扯到它