系統架構師站在系統與使用者之間，替使用者翻譯他們的需要，又要解釋給工程師知道技術方向該怎麼設計，技術的採用都會影響到後面的系統發展，評估階段就是一種專門的職業。
你知道的我不知道
書中提到假設一個詞語意義，一直會用到，但我認為他的意思和你認為的可能不一樣，這個差異沒講清楚可是會讓叉路越走越遠，例如我們都認同產品不該有明顯錯誤產生，但我認為的重點是「錯誤」，你認為的重點可能在「明顯」，各自解讀會讓後續開發始終無法順利朝同樣的目標前進，所以聚焦是很重要的事情，架構師有責任要讓大家聚焦在同一件事情上面。
藕斷絲連
系統技術方面，此書還是以軟體為主軸的方式解讀，軟體可以有很多方式建構系統，很多技術的不同，會有不同的效果與優缺點，例如常用的同步與異步的傳輸方式，會造成不同的慣用風格，技術耦合程度也會綁定的平台的應用，常用的資料格式例如|JSON、XML都有它的擁護者，沒有絕對正確的方案，只有適合用在的地方。不錄不錄
後面提到幾種部屬方式值得好好研究，例如煙霧測試、藍綠佈署、金絲雀釋出，是否我們都有見過這樣的發布方式呢，在一些大型系統裡面，幾千幾百萬的使用者，有一次修改佈署下去，總不好一次發布，有問題一次爆炸起來，收拾後果可是忙不過來，除了忙以外，還會大幅失去信心，所以需要各種佈署方式，用來驗證市場的反應，讓損失得以控制，另一本書「與熊共舞」就在講風險，佈署就是一種高風險的事情，卻又一定要進行，多數是為了修改錯誤，或是增加新功能，都是有必要的佈署，那麼每次都該好好執行經過前人改良的佈署方式吧。消費者不是神
最後個人最喜歡的一句話，「要測試旅程，而非故事，由消費者驅動的測試」，好的產品經過測試要從消費者角度驅動，才不會淪為技術控，做的工程師高興，但是發布之後對於使用者在意的項目，都變成垃圾，這樣多數人的角度看起來還是一團垃圾，旅程將會是體驗的重點。買書這裡
https://www.books.com.tw/products/0010938435?sloc=main
留言
張貼留言