2009-6-16，7/21/2008

8:43 AM 7/21/2008
關於學習
    要學習某個優點，首先看看如果你具備這個優點你該怎麼做，然後在思想上模擬着做一
    遍，以後也經常保持生活和思想上都去這樣做，那麼你就很容易的學會了它。因爲不論
    在思想上模擬着做，還是在實際生活中去中，都是爲了養成習慣。一旦習慣養成，它自
    然而然就成了你的優點了。

    要學會幽默，不論在任何場合。因爲我認爲幽默是改善乏味的人際關係的良藥。
    鼓勵的詞彙：哥看好你，你肯定行，哦，對了，走，搞它，怕毛，搞之，去噻
   
    學習就是：分析（現象）-思考（本質）-應用（結論）

 
11:25 AM 8/18/2008
我目前很需要改進的一個缺點：找到一個大概的解決辦法就不去深入，不去徹底地解決。只
看冰山一角就認爲任務已經完成是嚴重不負責的表現。

11:18 AM 9/11/2008
《UML軟件開發》中關於80/20原則：
    80%的收益來自20%的系統。意思是最常用的功能優先實現。原書中說：“所以，在區分
    優先次序的時候，找到對早期階段最有益處的用力是十分重要的。這樣做有很多好處，
    可以快速開發出實用的系統，也可以適應需求的變化。”
   
1:00 PM 4/1/2009
在JIRA中看到某些任務的題目和描述都很模糊，這是否說明了任務沒有結果合理的計劃？

4:00 PM 6/1/2009
對待任務
    把一個5小時的任務交給甲乙兩個人：
   
    甲：
    承諾3小時可以完成，經理給了1天，甲輕率地做了2小時，發現有很多細節，然後又花
    了4小時，可以跑了，然後測試了1小時，於是提交。第二天，用戶說有很多問題，於是
    又花了幾個小時修復。第三天又報告了新問題。。。
   
    乙:
    覺得可能有很多細節，所以保守估計要1天，經理給了2天。做了3小時後發現果然有很
    多細節，於是開始重新設計。1天后，程序可以跑了，又花了2小時調試和修復。最後花
    了1天2小時完成並提交。之後運行基本沒問題。
   
    經理的評價：
    甲過於輕率和自大，對工作不夠重視，工作效率高但是質量不高。
    乙比較保守，工作很負責，工作效率雖然不是最高的，但是工作質量很好。   
   
    記住： 魔鬼隱藏在細節中。。。。
   
2009-6-15 11:02:34
爲什麼標準的windows文件打開窗口下面的過濾器不能填入自己的過濾格式？


2009-6-16 10:47:19
由warcraft3想到的
    針對一個遊戲類型開發一個遊戲製作工具，然後第三方用遊戲製作工具製作遊戲。
    好處是分工明確，遊戲開發商只開發工具，第三方用工具製作遊戲。
   
22:27 2009-10-18
非功能需求

    來自開發人員
        代碼要有高可讀性和可維護性，或者可移植性。
        代碼要穩定，簡單，方便，有對應文檔。

    來自策劃
        界面及時修改。
        聲音及時修改。
        人工智能及時修改。
        對象及時修改。
        邏輯及時修改。

    來自維護人員
        要能方便的觀察、修改和保存數據。
        要有調式開關。

    來自測試人員
        錯誤跟蹤能力。
        快速啓動或者關閉某些功能。
        調試輸出。

    來自用戶
        程序小，快，乾淨環保。
        方便的問題反饋通道
        用戶友好
        簡單的DIY通道
       
 
高靈活性將帶來額外的複雜度，因此：

    來自策劃的需求：
        如果不能及時修改，至少也要能快速修改。比如及時保存並退出，然後修改資源重
        新恢復現場，之類。