《構建之法》第4.17章讀書筆記
《構建之法》第4.17章讀書筆記
第四章
原文語句：
異常不能跨過DLL或進程的邊界來傳遞信息，所以異常不是萬能的。
提出問題：
1.什麽是DLL？DLL是來解決什麽問題的？
網上說法：
DLL是Dynamic Link Library的縮寫，意為動態鏈接庫。在Windows中，許多應用程序並不是一個完整的可執行文件，它們被分割成一些相對獨立的動態鏈接庫，即DLL文件，放置於系統中。當我們執行某一個程序時，相應的DLL文件就會被調用。一個應用程序可有多個DLL文件，一個DLL文件也可能被幾個應用程序所共用，這樣的DLL文件被稱為共享DLL文件。
它允許進程共享執行特殊任務所必需的代碼和其他資源.比較大的應用程序都由很多模塊組成，這些模塊分別完成相對獨立的功能，它們彼此協作來完成整個軟件系統的工作。可能存在一些模塊的功能較為通用，在構造其它軟件系統時仍會被使用。在構造軟件系統時，如果將所有模塊的代碼源都靜態編譯到整個應用程序 EXE 文件中，會產生一些問題：一個缺點是增加了應用程序的大小，它會占用更多的磁盤空間，程序運行時也會消耗較大的內存空間，造成系統資源的浪費；另一個缺點是，在編寫大的 EXE 程序時，在每次修改重建時都必須調整編譯所有源代碼，增加了編譯過程的復雜性，也不利於階段性的單元測試。 Windows 系統平臺上提供了一種完全不同的較有效的編程和運行環境，你可以將獨立的程序模塊創建為較小的 DLL 文件，並可對它們單獨編譯和測試。在運行時，只有當 EXE 程序確實要調用這些 DLL 模塊的情況下，系統才會將它們裝載到內存空間中。這種方式不僅減少了 EXE 文件的大小和對內存空間的需求，而且使這些 DLL 模塊可以同時被多個應用程序使用。Windows 自己就將一些主要的系統功能以 DLL 模塊的形式實現。 一般來說，DLL 是一種磁盤文件，以.dll、.DRV、.FON、.SYS 和許多以 .EXE 為擴展名的系統文件都可以是 DLL。它由全局數據、服務函數和資源組成，在運行時被系統加載到調用進程的虛擬空間中，成為調用進程的一部分。如果與其它 DLL 之間沒有沖突，該文件通常映射到進程虛擬空間的同一地址上。DLL 模塊中包含各種導出函數，用於向外界提供服務。DLL 可以有自己的數據段，但沒有自己的堆棧，使用與調用它的應用程序相同的堆棧模式；一個 DLL 在內存中只有一個實例；DLL 實現了代碼封裝性；DLL 的編制與具體的編程語言及編譯器無關。 在 Win32 環境中，每個進程都復制了自己的讀/寫全局變量。如果想要與其它進程共享內存，必須使用內存映射文件或者聲明一個共享數據段。DLL 模塊需要的堆棧內存都是從運行進程的堆棧中分配出來的。Windows 在加載 DLL 模塊時將進程函數調用與 DLL 文件的導出函數相匹配。Windows 操作系統對 DLL 的操作僅僅是把 DLL 映射到需要它的進程的虛擬地址空間裏去。DLL 函數中的代碼所創建的任何對象（包括變量）都歸調用它的線程或進程所有。我的理解：
DLL是存放各種程序函數等內容的一種文件，是一種相對獨立地動態鏈接庫，當我們執行程序時，就要從系統中調用多個DLL文件如果想從·其他進程https://blog.csdn.net/shenzi/article/details/4739746共享內存，必須使用內存映射文件或者聲明一個共享數據段，一個DLL文件也可以被多個應用程序使用。當我們無法跨越進程地址空間的邊界時，我們就需要“DLL註入”技術，將DLL註入到進程地址空間中。這些都是DLL註入的方法和例子：https://blog.csdn.net/zm_21/article/details/52654482、https://www.cnblogs.com/5iedu/p/5180828.html
原文語句：
領航員：審閱駕駛員的文檔；監督駕駛員對編程等開發流程的執行；考慮單元測試的覆蓋率；思考是否需要和如何重構；幫助駕駛員解決具體技術問題。領航員也可以設計TDD中的測試用例。
提出問題：
什麽是重構？重構的目標是什麽？
網上說法：
1、 代碼重構（Code refactoring）重構就是在不改變軟件系統外部行為的前提下，改善它的內部結構。軟件重構需要借助工具完成，重構工具能夠修改代碼同時修改所有引用該代碼的地方。在極限編程的方法學中，重構需要單元測試來支持。
重構（），通過調整程序代碼改善軟件的質量、性能，使其程序的設計模式和架構更趨合理，提高軟件的擴展性和維護性。 也許有人會問，為什麽不在項目開始時多花些時間把設計做好，而要以後花時間來重構呢？要知道一個完美得可以預見未來任何變化的設計，或一個靈活得可以容納任何擴展的設計是不存在的。系統設計人員對即將著手的項目往往只能從大方向予以把控，而無法知道每個細枝末節，其次永遠不變的就是變化，提出需求的用戶往往要在軟件成型後，才開始"品頭論足"，系統設計人員畢竟不是先知先覺的神仙，功能的變化導致設計的調整再所難免。所以"測試為先，持續重構"作為良好開發習慣被越來越多的人所采納，測試和重構像黃河的護堤，成為保證軟件質量的法寶。
2、通過重構可以達到以下的目標：
·持續糾偏和改進軟件設計
重構和設計是相輔相成的，它和設計彼此互補。有了重構，你仍然必須做預先的設計，但是不必是最優的設計，只需要一個合理的解決方案就夠了，如果沒有重構、程序設計會逐漸腐敗變質，愈來愈像斷線的風箏，脫韁的野馬無法控制。重構其實就是整理代碼，讓所有帶著發散傾向的代碼回歸本位。
Martin Flower在《重構》中有一句經典的話："任何一個傻瓜都能寫出計算機可以理解的程序，只有寫出人類容易理解的程序才是優秀的程序員。"對此，筆者感觸很深，有些程序員總是能夠快速編寫出可運行的代碼，但代碼中晦澀的命名使人暈眩得需要緊握坐椅扶手，試想一個新兵到來接手這樣的代碼他會不會想當逃兵呢？
軟件的生命周期往往需要多批程序員來維護，我們往往忽略了這些後來人。為了使代碼容易被他人理解，需要在實現軟件功能時做許多額外的事件，如清晰的排版布局，簡明扼要的註釋，其中命名也是一個重要的方面。一個很好的辦法就是采用暗喻命名，即以對象實現的功能的依據，用形象化或擬人化的手法進行命名，一個很好的態度就是將每個代碼元素像新生兒一樣命名，也許筆者有點命名偏執狂的傾向，如能榮此雅號，將深以此為幸。
對於那些讓人充滿迷茫感甚至誤導性的命名，需要果決地、大刀闊斧地整容，永遠不要手下留情！
·幫助發現隱藏的代碼缺陷
孔子說過：溫故而知新。重構代碼時逼迫你加深理解原先所寫的代碼。筆者常有寫下程序後，卻發生對自己的程序邏輯不甚理解的情景，曾為此驚悚過，後來發現這種癥狀居然是許多程序員常患的"感冒"。當你也發生這樣的情形時，通過重構代碼可以加深對原設計的理解，發現其中的問題和隱患，構建出更好的代碼。
· 從長遠來看，有助於提高編程效率
當你發現解決一個問題變得異常復雜時，往往不是問題本身造成的，而是你用錯了方法，拙劣的設計往往導致臃腫的編碼。改善設計、提高可讀性、減少缺陷都是為了穩住陣腳。良好的設計是成功的一半，停下來通過重構改進設計，或許會在當前減緩速度，但它帶來的後發優勢卻是不可低估的。
我的理解：
1、代碼重構就是在你的代碼中出現過大的類或者過長的方法、牽一毛而需要動全身的修改、類之間需要過多的通訊、過度耦合的信息鏈等問題時，在不改變軟件系統外部行為的條件下，改變它的內部結構，從而達到改善軟件的質量、性能，使其程序的設計模式和架構更趨合理，提高軟件的擴展性和維護性作用。"測試為先，持續重構"，測試和重構成為保證軟件質量的法寶。
2、重構的目標有：持續糾偏和改進軟件設計、幫助發現隱藏的代碼缺陷、有利於提高編程的效率、改善軟件的質量，提高代碼的可讀性，使代碼更加的符合人們的需求，促進軟件的可持續發展，也為軟件的質量提供也保障。
第十七章
原文語句：
人員（People）:參照RASCI模型，說清楚誰負責什麽，誰不負責什麽（說清楚誰不負責有利於大家放手工作）。
提出問題：
什麽是RASCI模型？
網上說法：
無論一個科研項目計劃本身多麽完備細致，具體實施人員及負責分配方面的誤解與疏漏總會客觀存在，並引發一系列嚴重問題。
RACI模式旨在幫助大家落實項目定位、分配具體責任，並改善項目成果。據管理學家研究，大多數機構都未能有效處理或高度重視其中最為關鍵的一大決定性成功因素。所謂決定性成功因素，是指項目實施過程中參與者以及關鍵負責人的角色定位與責任細則。無論項目規劃本身多麽詳盡完善，參與者與關鍵負責人在角色定位與責任細則方面的模糊及混亂幾乎已經成為一種常態。在每一次著手對陷入困境的項目加以補救時，首先都應將這一因素當作需要優先處理的內容。
RACI模式是目前最簡便、最高效的項目角色定位及責任分配方案，將RACI模式與機構的項目運作周期相結合，能夠為整體工作帶來最大化的效果提升及產出改善。
一、RACI模式中的四大角色定位RACI模式通過嚴謹的結構與細致的表述，幫助關鍵性項目負責人找到自己在工作中的準確定位。這套模式的主旨在於明確每個崗位的責任分工，並確保項目中的一切細節都與相應的“執行者”關聯起來。在實施RACI模式時，我們首先要對項目中的每項任務、階段性成果及關鍵決策進行收集整理，並明確哪些人對特定內容負責、哪些 人需要為特定內容提供咨詢及指導意見。所謂RACI模式，四個縮寫字母代表的是項目中普遍存在的四種主要管理角色：
負責人（R = Responsible）他們是工作中的“執行者，一切具體執行內容都由他們來掌控。他們的任務是完成目標、處理對象或者做出決策，而且在大多數項目中負責人角色彼此獨立。
管理者（A = Accountable）: 扮演這類角色的工作人員可以說是任務的“擁有者”，一項任務、具體工作或者責任內容是否完成需要由他們來簽字確認。管理者的職能是確保各項任務按預期分配給對應負責人。要讓項目取得成功，必須確立惟一一位管理者，這樣才能保證出現問題時問責機制能夠立即發揮作用。
顧問（C = Consulted）: 這類角色需要在工作正式開展之前提出建議，並對討論結果進行簽字確認。他們始終處於討論、審議實施效果、討論的工作循環之中，並以參與者的角度全程監控。
指導員（I = Informed）: 這類角色需要時刻關註“發展藍圖”，他們的責任是在項目過程及決策環節提供指導意見，但並不會直接以顧問身份出現。而且他們的看法也不會直接影響任務或議程的結果，指導意見”或者說“參考意見”是他們對於管理者們的主要貢獻。
除了RACI以外，RASCI和RASIC也都是用來描述變革過程中的角色、任務的。其中支持者（S= Support）是對任務提供支持, 輔助任務的完成的角色。以下主要介紹RACI模式的應用。
二、RACI模式的實際應用RACI模式的實際應用並不復雜，只需以下六個簡單步驟，我們
1. 確定項目實施過程中涉及的所有具體任務，並在圖表左側按照優先級順序將內容一一列出。對於項目而言，這樣做能夠最大程度地保證項目周期與交付成果之間的平衡。
2. 列出項目中所有相關負責人，並將他們在圖表上方一一列出。
3. 將模式中的每個工作單元劃分出來，並確定哪些人在其中扮演負責人或者管理者的角色。接下來考量工作人員的職業技能與知識背景，並為每項具體任務分配合適的顧問及指導員。
4. 確保每項任務都擁有至少一位主要負責人。
5. 每項任務最多只能分配一位主要管理者。這樣做是為了避免同一項特定任務由於決策者過多而導致沖突或意見分歧。
6. 將RACI模式與團隊中的主要負責人分享，確保大家都能夠在討論之後認同這種執行方案。在項目啟動之初做好這些準備工作，能夠防止未來可能出現的意見分歧或者溝通障礙等負面影響。下圖所示的就是一套簡化版的RACI模式，我們可以從中看到項目如何按特定流程轉化為方案內容：
我的理解：
RASCI模型當中R是指負責人，A是指管理者，S是指支持者，C是指顧問，I是指指導者。RACI、RASCI和RASIC也都是用來描述變革過程中的角色、任務的，都是一種科學合理的具體實施人員及負責分配方面的模型，旨在幫助大家落實項目定位、分配具體責任，並改善項目成果。其中RACI模型是運用最簡單、最快捷的模型。RACI模型是在專案管理或組織改造時常用的工具。任何一項流程改造或專案的活動，都不會自動發生，除非“人”讓它發生，RACI就是協助你找到那個“人”及其他必要資源的有效分工計劃工具。
《構建之法》第4.17章讀書筆記