顯示具有 software architecture / 軟體架構 標籤的文章。 顯示所有文章
顯示具有 software architecture / 軟體架構 標籤的文章。 顯示所有文章

2020年3月31日 星期二

編程範式:Functional / Imperative / OO / Procedure Programming

常見的編程範式有以下幾種:
functional programming(函數式編程)
imperative programming(命令式編程)
Objective-Oriented programming(物件導向式編程)
procedure programming(程序式編程)

Functional Programming

Functional programming 沒有只是構想,沒有絕對的規定。
視程式設計為數學函式,每個函式各自獨立,彼此互不影響,
只要每個各自獨立的函式是正確的,那麼整個程式就是正確的。

各程式語言實作不同,但是有共通點:

  • No Side Effect-在表示式(Expression)內不可以造成值的改變。
  • First-Class Function-函數被當作一般值,可當傳入參數、傳出結果。
  • 資料放在堆疊stack-或由堆疊指向heap。
  • 盡量避免[狀態]與[可變資料],一切與函式內部無關。

優點

  • Unit test 相對容易。以函式為單位,且只檢查輸入、輸出是否正確,不管其他狀態。
  • 好除錯,因為沒有外部變數影響,所以錯誤容易重現,好找。
  • 因為可以保留函式內狀態(closure)所以程式可以精簡。
  • 適合寫併發(Concurrency)程式,因為不共享記憶體、沒執行緒、不上鎖、不擔心Critical Section。

Functional Programming到底做了什麼?

  • Higher-Order Functions-可接受函式當參數,或以函式為回傳值的函式,稱為 higher-order function,容易進行資料處理(排序、過濾、對應)。
  • Currying-用currying方式,定義特殊化函式。例如,有個函數為power(x, y),會計算出x的y次方,那麼事先將參數y指定為2,就可以定義一個平方函數square(x)。
  • Lazy Evaluation-表示式可拖到真正需要執行才執行,因此編譯器有更大的優化空間。
  • Continuations-將一個函數的傳出值,傳進另一個函數當作傳入值,也可以產生循序執行的效果。
  • Pattern Matching-模式比對的方式,可以讓系統自動幫我們進行分支與變數的指定。降低switch/case依賴、多型依賴。
  • Closure-函式離開後,其context依然保留,保留在內部函式,可當傳出值。
  • List processing-有好用的list處理函式。
  • Meta-Programming-許多FP語言都提供方便的Meta-Programming工具,讓你可以設計自己的Domain specific language

Imperative Programming(命令式編程)

Imperativ programming 認為程式的執行,就是一連串狀態的改變。
資料大量放在heap中。利用大量的流程控制,或狀態判斷還選擇執行的程式。
例如switch/case就是最好的例子。

Objective-Oriented Programming

2016年1月11日 星期一

軟體架構做什麼用?

軟體架構在軟體工程上究竟能帶來什麼好處?
一般來說,只要提到『架構』兩個字,
地位好像就很崇高,給人一種無法親近的fu,
軟體架構也是如此,
所以我們常常會看到開發人員討論某個問題怎麼解?
但是很少聽到大家研究架構怎麼做。

舉凡要讓人接受一項新東西,
不外是威脅或利誘兩種方式。
專案開發一向講求「以和為貴」,
我們當然不能用威脅的,
而是要告訴大家服用後好處多多,
保證一日雙北,或是30分鐘登上101。

好的架構能讓開發更快速

架構定了,開發人員有完成目標,有規範可遵守,
有方式可合作,整體開發能夠更順利。
且好架構是適應變化的,
面對未來的改變,也能有一定的彈性。

架構明確出團隊的共同目標

有目標,方向才不會亂。
團隊有共同的目標,才不會互相掣肘,
從而發揮1+1>=2的效果。

架構具體化團隊使用的技術

團隊中的成員未必都熟悉系統所使用的技術,
確定出技術後,成員可以提前練習,
也方便互相研究。

架構勾勒出每個人的責任

多人共同開發要順暢有一個重點,
就是每個人清楚知道自己的責任範圍。
責任範圍一確認,就能避免重疊和遺漏的部分,
團隊協力完成預先規劃的全部內容。

2016年1月9日 星期六

2015年12月30日 星期三

軟體架構有用嗎?

寫程式需要先來個架構嗎?
之前的案子沒寫軟體架構,還不是照樣做?

初接觸軟體架構的開發者,
常常會有類似的疑問。
通常我們會聽到「浪費時間」、「沒必要」等答案。

可是仔細想想,不只是軟體,
人類處理複雜事物,
都習慣於拆分成小區塊來處理。
軟體架構做的也就是這件事,
做法上完全符合人類處理事情的基本概念。

從實作的觀點來看,
一個軟體系統開發者通常不只一位,
要區分每個人的責任區,
就需要先拆解系統嗎。
如果不先拆解系統,那要如何分配每個人的任務呢?
同時軟體架構圖也是系統的整體面貌,
架構出來的幾張圖應該能表現出整個軟體的功能與目標。
否則的話,這個架構圖表達的就不夠完整。
團隊的所有成員都應當要能從這張圖看出共同的目標。