該場景下，一定需要日誌輸出。原因很顯然，因為是個迭代過程，整體結構模型並不明確，一些邏輯都不是很可靠的，故需要提供乙個側面可供觀察程式執行動態。
二次開發一般也是採用一種原型來迭代完成的。即便不是基於原型迭代變化，那日誌觀察則更是需要，至少依賴平台的一些呼叫我們需要觀察。程式設計師一般對於不是自己定義的邏輯都是不能完全信任的。除非有可靠評測資料。
有單元測試，那就是說有可信可靠的評測資料。對於這部分依賴項，同二次開發說明的，那我們只管應用層邏輯的日誌輸出即可，而最好能夠遮蔽這些可靠依賴項的輸出。因為的單元測試保證，所以我們不希望依賴項內部輸出而膨脹我人瓣觀察範圍。
日誌作為程式執行的內側面，是寫給人員看的，不同形式輸出日誌給程式設計師的體驗就不一樣。因此我們需要一種規範日誌，流程清晰，以觀測某些關鍵資訊。以下總結了三條規則以定義我們的開發過程。
什麼時候需要流程日誌，這看函式塊的對其他塊的依賴性；
最簡法則就是，發生某呼叫前，對於呼叫函式名及入參有較關鍵的日誌記錄。
說到這裡了，流程日誌只關注對別的函式呼叫的發生記錄。那麼出口日誌就是關注本函式塊目標輸出；
最簡法則就是，函式返回前，對本函式的返回值及出參作比較關鍵的日誌記錄。
乙個古老的問題真算解答了，結構化設計有一則單入單出的模組設計原則。這就是為什麼盡量要求單出口，方便跟蹤記錄！
又到了這裡說明了，既然有出口日誌自然考慮入口也列印個記錄了。莫急莫慌！這一條是有講究的。
不對外提供的函式模組，不要產生入口日誌。為什麼，因為有流程日誌作前置宣告的，所有上下文流程會在日誌裡體現的一清二楚。
最簡法則就是，匯出與其他工程目標呼叫的函式塊作好入參的關鍵記錄。
那個模組設計原則，乙個入口乙個出口。在函式體上下文中，入口始終都是唯一乙個。我只能嘿嘿了！
有了流程日誌和出口日誌作保障，我們就能很方便觀察程式執行的上下文出入了。
對於以上三項法則有個前提註明，一條日誌記錄，最基本需要有時間戳，函式名這些資訊，有了函式名我們才能清晰的看出完整的流程運作！
遵循此規範來執行迭代開發，程式設計的好不好，就很明顯的能夠在日誌輸出中反映了。設計良好則可以從日誌體現出流程清晰、層次分明的特點。
這裡的工程只講說**工程。每乙個工程由若干編譯單元組成，同時包含一些依賴項。
應用程式及應用程式擴充套件。
完成目標鏈結所需的依賴項。
這裡要說就涉及到功能目標及人員分工相關。
一般會按不同功能劃分工程目標，然後再分組管理不同的開發人員，即組織不同的團隊完成不同的開發目標。
關於日誌輸出
嘿嘿，開博第一篇，寫點簡單的東西。在寫專案的過程中，如果用nslog 輔助輸出日誌來測試的話，每次執行程式都會輸出一大堆日誌。而且當軟體發布時，程式會把所有nslog 也編譯出來，所以建議自己寫巨集來控制日誌輸出。如下 ifdef debug define dhlog nslog va args e...
python日誌輸出
import logging logger logging.getlogger 生成乙個日誌物件，內為日誌物件的名字，可以不帶，名字不給定就是root，一般給定名字，否則會把其他的日誌輸出也會列印到你的檔案裡。handler logging.filehandler log test.txt 生成乙個...
日誌輸出筆記
set log levels log4j.rootlogger debug stdout 輸出到控制台 輸出到日誌檔案 儲存異常資訊到單獨檔案 conversionpattern 的輸出格式引數定義 m 輸出 中指定的訊息 p 輸出優先順序，即debug，info，warn，error，fatal ...