Author：Anders小明

軟件工程中的經(jīng)濟(jì)行為
1. 在傳統(tǒng)財(cái)務(wù)概念下，軟件公司或者商業(yè)公司IT部門(mén)的員工，是公司的成本中心。對(duì)于一個(gè)定額合同項(xiàng)目，員工工資成為項(xiàng)目中唯一的可變成本。
2. 因此，盡可能的縮短工期，減少人員投入就成為縮減成本的基本方式。

3. 軟件的分工模式，以及傳統(tǒng)的waterfall——流水線的工作方式，決定了問(wèn)題發(fā)現(xiàn)的越早，修正的成本越低。
4. 有兩種手段來(lái)減少工期，工程上采用迭代，并讓迭代周期盡可能短，以及從技術(shù)上對(duì)于問(wèn)題域進(jìn)行分解，建立有效的邊界。
5. 迭代周期減少的目的是減少分工環(huán)節(jié)中尤其是第一個(gè)環(huán)節(jié)的不確定性帶來(lái)的問(wèn)題，而對(duì)問(wèn)題域的技術(shù)分解是解決開(kāi)發(fā)環(huán)節(jié)的質(zhì)量問(wèn)題。因?yàn)橥ǔ＞S護(hù)成本是開(kāi)發(fā)成本的3倍，提高質(zhì)量可以減少項(xiàng)目后期對(duì)前期開(kāi)發(fā)代碼的維護(hù)成本。
6. 同時(shí)，分解的好壞將決定了是否可以在開(kāi)發(fā)環(huán)節(jié)中引入測(cè)試環(huán)節(jié)的工作，從而提供質(zhì)量；并減少修正缺陷以及測(cè)試的工作量。
7. 質(zhì)量是難以衡量的，通常以能否工作為準(zhǔn)。而通常意義上的高質(zhì)量代碼是可以較容易調(diào)整以及適應(yīng)變化，但是不容易識(shí)別。
為保障質(zhì)量，通常的手段是代碼審查，但在工程中完全代碼審查承保高昂，同時(shí)工作量大，并難以評(píng)估（評(píng)估結(jié)果有時(shí)因人而異）。而各種各樣的代碼規(guī)范檢查工具只能保障最低要求。

8. 在進(jìn)度落后于計(jì)劃時(shí)，管理人員通常會(huì)下達(dá)行政指令——要求項(xiàng)目成員全力以赴趕上計(jì)劃。在此情況下，工程人員通常犧牲質(zhì)量換取開(kāi)發(fā)進(jìn)度，同時(shí)把質(zhì)量問(wèn)題推后發(fā)生。
9. 軟件開(kāi)發(fā)是腦力勞動(dòng) 而非體力勞動(dòng)；因此工程人員有很大的權(quán)利，他們有選擇質(zhì)量和進(jìn)度的能力，工程人員的工作狀況嚴(yán)重影響產(chǎn)出和進(jìn)度。而上述情況的發(fā)生是人在利益環(huán)境下的自然選擇，對(duì)于工程人員的指責(zé)無(wú)濟(jì)于事。
10. 正確的工作方式是，為工程人員創(chuàng)造合適的條件以便工程人員做正確的事。

軟件架構(gòu)師的工作
軟件工程的三要素：工具，方法和過(guò)程。然這所有的一切是規(guī)范人的分工和行為，提高人的生產(chǎn)效率，降低成本。
架構(gòu)師的工作圍繞這個(gè)三個(gè)要素進(jìn)行。
1. 工具評(píng)估（包括開(kāi)發(fā)平臺(tái)，開(kāi)發(fā)語(yǔ)言，開(kāi)發(fā)工具以及輔助工具）。
A. 用好的工具提高生產(chǎn)效率，使人關(guān)注于有效工作內(nèi)容，從而減少不必要工作量，減少成本。
特別對(duì)于分工下的團(tuán)隊(duì)開(kāi)發(fā)尤為重要。典型的分工是流水線，一步接一步。減少上一個(gè)環(huán)節(jié)的工作量，如開(kāi)發(fā)環(huán)節(jié)，不僅提前下一個(gè)環(huán)節(jié)——測(cè)試的時(shí)間。
B. 用好的工具保證質(zhì)量——另一種生產(chǎn)效率。
保證質(zhì)量有利于減少工作上的反復(fù)，尤其影響到測(cè)試工作量，從而減少成本。
提高生產(chǎn)效率的同時(shí)有利于保證士氣。

2. 方法論選擇
解決問(wèn)題的辦法就是分治。要被分解問(wèn)題域是：數(shù)據(jù)（模型），計(jì)算和流程；而如何分解問(wèn)題便是架構(gòu)師的取舍啦，流行的有OOD和AOSD兩種。

在大比例結(jié)構(gòu)中必需考慮的是：抽象分層，技術(shù)分層以及模塊切分。抽象分層(包括模型，計(jì)算以及流程抽象)以及模塊切分是基于業(yè)務(wù)的縱向以及橫向分解。而技術(shù)分層則是對(duì)于業(yè)務(wù)邏輯的技術(shù)分類，分類本身還可能涉及到平臺(tái)技術(shù)限制。所有分解都涉及到上下文的邊界建立——不僅僅是業(yè)務(wù)邏輯同時(shí)也是技術(shù)邊界。

分解問(wèn)題必需考慮人的因素，降低分解后的知識(shí)學(xué)習(xí)阻力，保持知識(shí)的內(nèi)聚以及有效組織是保證分解成功的關(guān)鍵。這些工作將有效保證開(kāi)發(fā)人員不做出破壞系統(tǒng)分解邊界的行為。
考核分解的有效性：保證開(kāi)發(fā)的效率。分解的目的是降低解決問(wèn)題的難度，從而提高生產(chǎn)效率，如果分解方案增加了系統(tǒng)適應(yīng)變化的能力，那么分解方案可能是錯(cuò)誤的。

除了開(kāi)發(fā)方法還有開(kāi)發(fā)方式，已知的三種開(kāi)發(fā)方式：編程式，聲明式以及產(chǎn)生式。
開(kāi)發(fā)方式的選擇和技術(shù)分層有相當(dāng)?shù)穆?lián)系，一般認(rèn)為除了Service以及Model，其它的技術(shù)分層代碼盡量使用聲明式以及產(chǎn)生式開(kāi)發(fā)方式來(lái)完成，減少建立以及維護(hù)成本，提高效率。

對(duì)于Domain Model還要分析model的生命周期，明確設(shè)計(jì)主題。

3. 過(guò)程選擇
選擇的過(guò)程，最重要的是讓問(wèn)題及早暴露（降低成本），盡早讓用戶使用（創(chuàng)造價(jià)值）.
敏捷方法就是要讓問(wèn)題更快的暴露，讓功能更快的實(shí)現(xiàn)。

文檔，文檔是過(guò)程的一個(gè)重要產(chǎn)物。文檔也是保證知識(shí)傳遞的。
在問(wèn)題分解情況下的開(kāi)發(fā)角色分為三種：開(kāi)發(fā)者，使用者以及維護(hù)者。開(kāi)發(fā)者寫(xiě)的文檔給后兩者看，最最關(guān)鍵是寫(xiě)給使用者的文檔。

所有的決定都是基于利益和成本考慮的。