軟體架構

通常要開發具有一定規模或比較複雜的軟體時，都會先根據需求或規格設計架構。
以個人的角度而言，可以讓自己在開發時有更明確的方向，選擇框架時能考慮更全面，也會降低排除 BUG 的困難。
以團隊的角度而言，好的架構設計可把軟體拆分成數個可獨立運作的部分，在開發上提升效率。常見的例子是有前後端的軟體，在設計架構時可先決定資料交互的形式、API 接口等等…，接著同步開發，最後花費一些時間整合即可。

設計好架構後記錄的方式有很多，架構圖加上文字說明是最詳盡，只有架構圖也可以接受，若不記錄可能會產生一些問題。

個人經驗

我自己是不喜歡記錄的，一來麻煩，再者，思考單位如果是實體，思考速度會大幅下降，同時也限縮了很多可能性，
就像是黏土一樣，黏土硬掉後要重新塑型比較困難，雖然可以用新的土把原本的蓋掉，但體積也會變大。

話雖如此，我最近卻深刻體會到沒有記錄帶來的後果。
現在手上有一個開發週期挺長的專案，初期程式碼規模還比較小的時候沒有體會到這個問題，但到後面規模相對大的時候，突然意識到嚴重性，
這個專案的需求都非常細微，因此一開始接手時無法完整的釐清所有需求及規格，都是邊開發邊修改，而我開發的時間又很間斷，一週只會開發三天，就這樣累積到中期，規模越來越大，使我在新一週開始時都會忘記想好的架構，我又懶，所以就依據新得到的需求重新思考部分架構硬寫，而每次重新思考都會有小部分差異，所以有時程式碼會隱藏一些問題，而這些問題不會在當下就表現出來，但到了某個時間就會一起爆發出來，又要花時間去修正，實在是很頭大。

除此之外，因為每次思考都會有一些差異，到後期架構已經變得很不清晰，這個專案程式碼撰寫的工作大部分是我，就算我自己隔一段時間來看都要花很多時間，
目前這個專案已經在測試階段，有時會有一些比較緊急需要修改的部分，如果我不在的話學長需要幫忙修改，學長看這支程式應該會覺得很痛苦，想想就覺得不好意思😥

如果開發週期較短而且只有自己一個人開發的話不記錄還是可以的，畢竟很省事，但如果是開發週期較長的專案還是好好記錄比較好，對自己有好處也減少給別人造成的麻煩。

我也不知道為什麼會想寫這篇，可能是希望自己記取教訓，但我覺得最後惰性還是會戰勝