[Golang] gqlgen: Get started

    Golang    GraphQL    gqlgen    GORM 

▌Introduction

[Architect] 產品及專案架構設計思維

最近常常被問到，如何為一個產品或專案設計好的架構？ 

我回答得很簡短：「首先要了解目的，然後因應當時的環境、時間和資源，評估可以達成這個目的的架構和流程，就是當時最適合的方式。」

然後就會得到

趁著最近比較有空，我把一些自己的想法整理在這篇文章。
但是在更往下之前，我想先談談自己對於 "架構" 這個詞的定義。

架構

我們知道產品和專案都有自己的生命周期。 而我自己心目中的架構是支撐它們可以在各自生命週期運行良好的軟硬體、流程和方法。  例如：

• 功能開發完成後，團隊可以多久和以多少信心佈署到正式環境？
• 新進員工加入多久，可以獨立開始作業？
• 線上有問題時，流程是什麼？ 
• 不同團隊協作流程順暢嗎？
• 軟硬體架構安全嗎？ 有考慮到業務成長量的對應擴充方式嗎？
• 開發團隊的價值有傳遞給客戶嗎？ 我知道客戶在抱怨還是幫我們說話嗎？

所以如果你期望看到底下有軟硬體架構的解決方案，很抱歉並沒有 XDD
這篇文章講得是我個人的思維。

目的

講到"目的"，通常我們想到的是：「如期如質上線，滿足老闆或客戶（或BU單位）的需求，讓公司營運正常並賺錢。」

這個大方向沒錯，但是我們再切成 "人"、"系統" 和 "業務" 來看的話，可能就沒有那麼單純。 以系統來看我們要達成的目的， 我們至少必須要知道

• 分辨必要（Must have）或是次要（Nice to have）的功能。
• Sizing，未來幾年的業務及系統成長量。
• SLA, SLO。
• 如果是專案，專案合約可能有明訂一些必要的規劃和使用的技術。

至於架構設計為何需要考慮到人（即利害關係人）？ 原因是每一項任務的成因和老闆的期望，可能不是我們想的那麼單純... 

政治因素、外包廠商、專案價格... etc（還有不好說的那部分），都會影響到我們評估要花多少資源在整個架構及任務上。  或許老闆的期望是讓團隊花更多時間在研發上，那我們就可以花更多資源在設計解決方案上。

業務角度也是重點，產品的業務是以套裝解決方案、或客製化收入為主？ 以 SaaS 還是導入客戶端來做為服務重點？ 上線後的維運單位和成本？ 這會影響到我們的架構設計和技術選型。  

當時的環境、時間和資源

試著回想起三年前或最近剛上線的專案，是不是覺得有更多改善的空間？ 肯定是的。
但是當時的情況允許我們用目前更好的架構或方式來建置嗎？ 不一定。

考慮環境，包含法規、公司及部門政策和團隊素質。  如果我們的解決方案和架構，和現行環境有衝突的話，就要回過頭去思考目的和思考必要的 tradeoff`。 

至於時間和資源，就不用多說了，鐵定是要考量的因素。 

我自己衡量的標準是

• 先理解相關利害關係人的期望，在可以完成任務及先滿足擁有權力和資源的關係人（通常是老闆和客戶）的情況下，去嘗試取得更多時間和資源完成團隊的期望。 
• 透過數據、經驗和知識來下決策，有的時候我們必須要堅持對的事情，去和老闆或客戶持續溝通。
• 團隊素質如果高的話，可以在過程中去做更多嘗試和想法，這有利於在架構設計上有更多的選擇和彈性。   

當然現實情況是殘忍的，經常不會有最佳的資源去達成我們想要的方式，仍是取捨問題。 

當時最適合

當時最適合的決策和設計，現在回顧可能是錯誤的；也表示我們現在已經成長了也學習到更多經驗和知識，來理解如何用更好的方式來處理它。 隨著資訊越來越進步、技術推陳出新，團隊掌握更多知識和經驗（不管從內部或外部），可以讓我們更快、更準確的於當下做更適合的決策。  我自己的想法是，勇於改變和挑戰，即使結果不如預期，勝於什麼都不想改變。