說到功能和體驗，正好昨天就軟體的日誌功能說過一串話，現在趕緊整理總結一下
乙個軟體，沒有日誌功能，也能用
但是，如果有偶爾的異常現象，則不好跟蹤，因為人不可能老盯著，而盯著的時候它也不一定就會重現
所以，需要日誌功能，日誌是一直寫的，事後分析日誌，按發生時間定位日誌，還是可以接受的
寫日誌又有2種，1種是編譯出2個版本，乙個是不寫日誌的發布版，乙個是寫日誌的除錯版
這種，需要跟蹤時，需要更換程式版本，才能進行，不需要跟蹤了，又需要更換程式版本
1種做法是程式支援乙個選項，以此決定是否寫日誌
這個選項是重新執行才生效還是執行時都可以隨時切換，又是2種做法了
而且，日誌是關注物件是不是可以分級（錯誤、關鍵事件、普通事件、除錯資訊等），又是乙個方面的做法了
但是日誌檔案的輸出方式，又有很多做法：每次輸出乙個不同的日誌檔案，還是連續輸出到乙個相同的日誌檔案
前者會導致小日誌檔案非常多，後者比較整潔，但是寫的過程會複雜一些
如果是後者，就還有乙個附加問題：日誌檔案很大了怎麼辦？
應該規定到一定大小就換個檔案，這裡又有2種做法了：大小限制固定為乙個數（如100k）；大小限制也是通過配置決定
當然，後者這個配置似乎沒有必要執行時調整了
每100k換檔案了，單個日誌檔案的大小不會無限大了，但是檔案的個數又會無限的多了（如果日誌寫的頻繁的話）
所以，又需要乙個功能：每天把當天的日誌轉移到乙個壓縮檔案（以日期為檔名）
當然，如果每天乙個日誌壓縮檔案還嫌雜亂的話，可以每月乙個日誌壓縮檔案，或者每次執行結束生成乙個日誌壓縮檔案
所以，寫應用的，沒有寫核心、底層那麼高深，但是，它的軟體功能和使用者體驗，也還是無止境的，不應該那麼受輕視。。。。。。。。。
同時，也說明寫軟體是一件多麼靠程式設計師積極性的事情。
除非你能把這些「精深」的需求都寫清楚了，否則就完全靠程式設計師的積極性、良心了
國內的軟體專案，（數量上的）大多數應該都不可能把需求預先寫的這麼「精深」吧，除非是外包
如果領導不能完全信任、放手，那麼就準備好把需求預先寫的這麼「精深」吧
這些事情（功能的「精深」程度的確定），本來也許是專案經理、架構師的事情，
但是國內的實際情況往往是落到程式設計師的頭上，尤其是第一次需要這樣的功能的時候
用乙個決策樹來表達，就是：
軟體的日誌功能
├沒有日誌：如果有偶爾的異常現象，則不好跟蹤，因為人不可能老盯著，而盯著的時候它也不一定就會重現
└有日誌：日誌是一直寫的，事後分析日誌，按發生時間定位日誌，還是可以接受的
├|編譯出2個版本，乙個是不寫日誌的發布版，乙個是寫日誌的除錯版：需要跟蹤時，需要更換程式版本，才能進
│|行，不需要跟蹤了，又需要更換程式版本
├程式支援乙個選項，以此決定是否寫日誌
│├如何切換
││├重新執行才生效
││└執行時都可以隨時切換
│└日誌是否分級
│ ├日誌物件不分級：要寫都記，要不寫就都不記
│ └日誌分級（錯誤、關鍵事件、普通事件、除錯資訊等）：可以通過設定決定記哪些
└日誌檔案的實現
├每次輸出乙個不同的日誌檔案：會導致小日誌檔案非常多
└連續輸出到乙個相同的日誌檔案：比較整潔，但是寫的過程會複雜一些
├日誌檔案很大了怎麼辦？：規定到一定大小就換個檔案
│├大小限制固定為乙個數（如100k）
│└大小限制也是通過配置決定：這個配置似乎沒有必要執行時調整了
└是否每天/或月把當天/或月的日誌轉移到乙個壓縮檔案（以日期為檔名）
使用者體驗與功能
最近有不少朋友問我，乙個平台，更多的是需要使用者體驗還是功能上的優化？這個話題我相信在座的各位都有不同的看法，包括我本人也是這樣不知如何去選擇！我只能說，兩者缺一不可！首先我們回顧一下歷史的微軟 谷歌 蘋果這三大世界級有創意的公司吧！首先是當年的微軟，比爾蓋茨過去曾經搞得basic只有幾十k的容量，...
從高階功能到傻瓜軟體看使用者體驗
今天在客戶提出新的功能需求後，發現他們對我們公司的軟體很不適應，對他們以前使用過的老系統有很大的依賴性。我突然發現並不是開發的功能越複雜 越高階就ok了，而是需要讓他們普通業務人員能夠很容易的操作並上手。因為他們大部分人都是不懂 和軟體架構的，可能在你看來乙個很容易的操作，在他們眼中需要通過很多個步...
「瘋狂猜成語」軟體使用者體驗
郭志偉 意見 1 初級的難度大於中級，光有成語的解釋而無的結合太難以答出結果 雖然你們高階的還沒編寫但個人感覺初級的比高階的略難 2 進入初級 中級 高階form框後應該設乙個返回按鈕，一開始我還以為點選右上角的叉是結束程式 3 在首form框中應新增退出按鈕 孔祥安 好的方面 介面設計相對來說就比...