在軟體開發週期的差異上，讓我感覺跟現在最大的不同，在於 20 年前左右我在用 BSD 轉 Linux 的那個時候，大概是 Slackware Linux 1.0，然後 Debian Linux 2.0 的那個時代。
我覺得那個時候的軟體開發重視的是支援功能，就是現有的軟硬體很多，怎麼樣周全的支援現有的軟硬體是那個時候 Linux 相關開發套件的重要問題，也是因為這樣我從 BSD 轉到 Linux 去。會棄用 BSD 的原因就是因為相對於 Linux 來說 BSD 的穩定度更好，但是真的要做伺服器以外的用途是有困難的，桌面應用環境不夠完整。那個時候比較重視穩定度，畢竟功能上都是軟硬體相關的服務。所以開發周期相對長，但是軟體的重大問題比較少，效能也相對穩定，不見得是快，有的時候就是跑不快然後只好花錢用硬體換。而且那個時候的軟體功能沒有這麼多，相對來說對開發人員而言算是一個小確幸時代。
現在的軟體開發週期給我的感覺比較像是沒有新功能沒有梗就要擔心沒人用，但是變成公開測試的模式，然後有一些在內部測試應該要解決的問題到了公開使用的階段才發現。現在的軟體開發應該比以前重視流程呀！但是為什麼發現問題的時候，低級的問題常常出現呢？我覺得問題的本質在於市場節奏感的強度優先於軟體安全性跟完整度的問題，多數的服務都走向消費性的概念，像是作業系統一年一定要有一個大更新，兩個小更新之類的這種概念，然後一個功能要做到完善的話大概要三個小更新或者是兩個大更新之類的。
另外一個現實是現實中的 CI CD 概念，其實有一個重大的盲點在於產品階段的使用者測試，因為 CI CD 階段在大部分的軟體服務中並沒有在其中插入所謂的黑箱測試，都是白箱測試，白箱測試其實有很大的盲點，這些盲點在最後上市之後的使用者黑箱測試階段會一次爆發。你說 Windows Insider Program 的參與者能不能算是黑箱測試人員，在我看來是不能算的，因為會參加這個專案的人基本上都對作業系統有一定的了解或者是目的。
黑箱測試的人員基本上只能就自己的日常基本操作去使用，去確認日常生活中原來沒有問題的事情在新版本的作業系統上有沒有問題，所以如果 Windows 10 1903 開始部屬了，如果應用程式比較常見而且不用太多高效能 API，像是 Office 之類的，可以在新的電腦上面直接部屬 1903 是沒有問題的。但是如果工作環境當中有用到比較小眾的軟體，可能就要往前推到 1809 或者是 1803 的版本上，因為不是所有的軟體開發商都可以跟得上作業系統更新的頻率。
所以現在的軟硬體更新，在我的角度來看，除非有重大的資訊安全漏洞需要處理，不然我都會很保守的等到那個軟體版本的支援周期結束才會更換成新的，或者是新的設備跟新的工作環境直接上新的版本也沒有問題，畢竟更換新的軟硬體環境本質上是沒有生產效益的，在避免影響生產流程的前提下，頻繁的調整軟硬體環境其實不是一個好的做法。如果是網路服務的話，我會偏好做一個版本上線服務之後，做相關的安全性跟功能跟新，提供使用者這個服務最短會支援多久，然後在同時把這個服務使用者的意見收集起來，做下一個版本的服務，但是我不預告下一個版本什麼時候會走到正式上線服務的階段，因為需求改變了，不同的需求沒有辦法用一樣的測試時間去保證有一樣的測試品質。
我必須再次說明，軟體開發跟服務開發的結果是要滿足使用者的需求，讓使用者花錢來買這個東西，CI CD 的概念在我的角度來看比較偏向是滿足軟體跟服務開發流程，還有公司產品預期上市流程用的，但是 CI CD 做好只是保證軟體應該會正常運作，但是不保證軟體真的滿足使用者的需求或者是使用者真的會按照開發人員的想法去使用軟體跟服務。
2007 年 8 月份微軟 tcpip.sys 全球更新導致 skype 全球大斷線那個事情我也是受害者，那個時候工作的公司有功能是用被更新的漏洞開發的，所以有一個月的時間大家在研究用什麼方法可以重新實作那個功能。有的時候你覺得是漏洞別人覺得是功能呀！那個時候 tcpip.sys 的更新是微軟幾乎是強迫派送的，所以沒有關閉更新服務的電腦基本上都會被重開機一次，所以那個時候最早的共享經濟服務 skype 就全球大斷線了。結果現在 skype 變成微軟的產品了，真的是商場上沒有永遠的敵人跟朋友呀。
現在的狀況就變成某一個雲端系統服務障礙，我都開玩笑說雲端打雷了，然後日常生活中的特定服務就全球故障，我們都以為雲端服務應該要比較穩定，終究其然我們只是把自己裝網路線電源線伺服器硬體的事情委託給別人做，然後系望這一套系統不要壞掉，然後以前習慣會作容錯系統的服務就還是繼續作容錯，以前沒有作容錯系統的服務上雲端還是一樣沒有作容錯，會掛掉的還是會掛掉，只是這個時候可以把責任外包說 GCP AWS Azure 掛掉了我也沒辦法這樣。
雲端好棒棒。
沒有留言:
張貼留言