<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    2005年10月30日

    制定計劃是一件困難的事情(在軟件開發中哪一件事情不難呢?),不只是新手,就是有好幾年工作經驗的人,對制定計劃也頗感為難,往往隨便給出個時間了事。我曾親歷過不少場面,大家對任務計劃的態度很隨意,對時間的估計都是隨口而出的。大多數時候,管理者都會對勇士們夸幾句,對謹慎者報以輕視。

     

    實踐證明這些計劃都是紙上談兵,有的嚴重超期,有的質量不過關,有的功能遺漏,很少按預期完成的。這也難怪,就是精心制定的計劃都有偏差,何況是隨便給出的呢。

     

    這里總結一些個人經驗,這是對簡單任務而言的。所謂簡單任務指的是能分到某個人頭上的任務,不包括需要一個小組協同完成的任務(當然部分也適用于小組任務的)。

     

    1.         對任務盡可能的細劃。任務分得越細,考慮得越周到,遺漏的可能越少。同時我們對細小任務的估計更準確,我想這也是大家鐘愛WBS的緣故吧。

     

    2.         建立任務的風險列表。外在環境、技術難點、甚至近一段時間工作狀態,都會影響任務的進度。風險很多,列出我們能處理的風險就差不多了,至于第三次世界大戰之類的風險完全可以拋開。根據風險列表,在理想的計劃上,加上一定的風險儲備。

     

    3.         征求做過類似任務的同事的意見。我們不是神仙,對從未有類似經驗的任務,很難估計準確,征求做過類似任務的同事的意見是明智的做法,至少我們能從中了解一些潛在的風險。

     

    4.         不斷調整計劃。計劃不是不變的,早期的估計或多或少的有些偏差。隨著任務的進展,一些風險的消除,以及這期間的經驗積累,我們可以更準確的估計時間了。一般來說在任務預定時間過去30%左右時,重新評估一下任務計劃是比較好的習慣。

     

    5.         及時反饋任務的執行情況。特別是研究性任務,出現計劃與實際較大差異的情況是很常見的。讓你的上司清楚任務的執行情況,很有必要,一旦出現較大偏差,他可以對你提供幫助,或者對整體計劃進行調整。切記不要在時間快完了,才報告出了大問題。

     

    6.         計劃要實事求是,不是估計時間越短越好。不要因為面子上的問題,把時間估計得過短。否則你的任務太重,不但會影響你的正常休息和工作情緒,最終無法完成時,面子丟了是小,影響整體計劃是大。

     

    7.         采用PSP中一些方法,評估自己的效率。記錄在執行任務過程,你的時間分配情況,估計你在做某類事情時的效率,為以后類似的任務提供經驗數據。

    posted @ 2006-03-12 21:34 成長記錄 閱讀(1562) | 評論 (1)編輯 收藏
     
         摘要: prototype.js開發筆記 覆蓋版本 1.3.1 1. Prototype是什么? 或許你還沒有用過它, prototype.js 是一個由Sam Stephenson寫的JavaScript包。這個構思奇妙編寫良好的一段兼容標準的一段代碼將承擔創造胖客戶端, 高交互性WEB應用程序的重擔。輕松加入Web 2.0特性。 如果你最近體驗了這個程序...  閱讀全文
    posted @ 2005-12-08 21:25 成長記錄 閱讀(291) | 評論 (0)編輯 收藏
     

    日志(Log)是什么?字典對其的解釋是"對某種機器工作情況或某項任務進展情況的記載"。對于應用系統來說,日志就應該記錄應用系統的運行狀況了。

    是否需要記錄日志?這個問題無需回答,這是毋庸置疑的--當然要記了。
    剩下的問題就是應該如何記錄日志才能確保日志具有高可用性和低耗性了。日志信息過于簡化,乃至于沒有日志,則用戶無法找到解決問題所需的信息,進而妨礙問題的解決;然而日志信息過于詳細不僅會降低系統的性能而且會使真正有用的信息淹沒在文字的海洋中。

    為此JDK給出了建議的日志分級標準。將不同的信息根據其重要性分級。與此同時可以根據實際需要在JRE中設置需要記錄的日志級別--級別高于此值的日志才被記錄。依照JDK提供的標準(java.util.logging.Level)將日志劃分為OFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST、ALL等從高到低九個級別。他們都分別對應著唯一的整數值,即OFF=Integer.MAX_VALUE、SEVERE=1000、WARNING=900、INFO=800、CONFIG=700、FINE=500、FINER=400、FINEST=300、ALL=Integer.MIN_VALUE。通過對java.util.logging.Level的泛化(擴展),開發人員可以在JDK提供的標準基礎之上定義自己的日志分級標準。

    在這九個級別中OFF、SEVERE、WARNING、INFO、CONFIG、ALL比較容易理解。

    OFF級別主要用于JRE日志輸出控制,表示不輸出任何信息。

    SEVERE(嚴重)級別描述組織程序正常運行的重大事件。這些事件的表述必須能夠讓最終用戶和系統管理員清晰地了解到底發生了什么事情。

    WARNING(警告)級別描述了最終用戶或系統管理員維護時比較感興趣的事件,或指示系統存在潛在問題的事件。這些事件都需要特別提醒最終用戶或系統管理員注意。

    INFO(信息)級別主要用于描述輸出到控制臺或其替代品的,具有相當程度重大意義的事件。譬如系統的心跳信息,以及其他系統希望告知最終用戶或系統管理員的信息等。

    CONFIG(配置)級別主要用于描述可以輔助調試解決問題的靜態配置信息。譬如CPU類型、操作系統類型、內存容量、系統語言等等。

    ALL級別也是主要用于JRE日志輸出控制,表示輸出所有日志信息。

    FINE、FINER、FINEST等三個級別被用于描述不同程度的跟蹤信息。這三個級別被sun分別翻譯為"良好","較好"和"最好",但是筆者認為翻譯為"略細","較細","最細"更合適。這三個級別比較容易使人難于區分。到底什么樣的信息應該以哪個級別輸出呢?

    一般說來,FINE級別用于輸出開發人員廣泛關注的信息。包括小的可恢復的故障,潛在的性能問題、數據源連接不足、服務超時等。

    FINER級別描述比FINE級別更詳細的信息。包括進入/返回方法調用,拋出了一個異常等信息。

    FINEST級別描述更詳細的調試信息。包括開發人員在方法內為了調試方便而輸出的調試信息,即某些日志分級系統中定義的DEBUG級別信息。

    將方法調用/返回信息作為一個單獨的級別處理是一個明智的選擇。在解決系統運行問題時,通常根據方法調用/返回過程就能大致確定問題所在。

    此日志分級標準被廣泛地應用于中小型系統中。更詳細的信息可以參考JDK
    API文檔的java.util.logging部分。

    posted @ 2005-10-30 22:40 成長記錄 閱讀(520) | 評論 (0)編輯 收藏
     

    只有懶惰的程序員才會去編寫那些可以最終代替自己工作的自動化工具,才不會成天為了實現相似的功能去編寫大段大段冗余重復的代碼 - 這種代碼往往是軟件后期維護和重構的天敵。通常來說,由于惰性的驅使所產生出來的工具和程序將最終極大的提高生產開發的速度。

    當然,對于一個程序員來說,光光具備懶惰這個要素還是不夠的。在享受懶惰之前,他必須以最大的熱情和最高的效率去研究解放自己的途徑,比如:找到最有助于開發的工具,最能體現“一次編寫,多次復用”精神的代碼架構的設計。只有在這些必要的工作之后,才可能真正享受輕松編程的樂趣。

    所以“懶”的精髓用一句老話來描述,那就是磨刀不誤砍柴功。如果你不想辦法磨亮手中的柴刀,就算一天二十四小時都在砍柴,效果也不如拿把鋒利的斧頭一天只砍一小時。

    從這個角度來說,Google給員工的20%自由時間是完全發揮了“懶”的能動力。為了更好的享受偷懶的樂趣,員工會更加具有創造力的去高效完成自己的任務。

    夸張一點來說,懶惰才是人類進步的原動力。

    這一點似乎比懶更讓人不能接受。在解釋這里所說的笨的具體含義之前,我們先看看一個聰明人(或者說認為自己足夠聰明)會做什么:

    1) 停止學習新的東西

    2) 不愿意用批判的眼光去審視自己的工作

    第1點將使我們很難去接受或者主動的去研究一項新的技術 - 即使新技術能帶給他更多工作上的便利。第2點會使我們無法清晰的分析自身工作的問題所在,要對其進行改進或者重構就更加困難。

    從這兩點來考慮,作為一個程序員太自以為是不見得是件好事情。由于對自身的過于自信,往往無法客觀的看待自己和自己的工作。相反的,笨一點(確切的說,謙遜一點)有時候倒有助于開發的順利進行。舉例來說,當程序出現bug的時候,最好盡早承認問題是出在自己編寫的代碼上面而不是在于編譯器(當然除非是字節高低位編碼方式之類的問題,這種問題編譯器會是錯誤的根源之一)。如果你太自負的認為自己的程序沒有問題而去猜測可能是編譯器或者其他的什么外部因素出問題的話,那么十有八九你會在調試過程中走上一長段的彎路。

    程序員應該笨一些的更為關鍵的原因在于,當需要思考問題的最佳解決方案的時候,往往要求我們首先要跳出思維定式。你對系統了解的越多,積累了越多的經驗,就越難走出已有的局限,可以嘗試的范圍就越小。相反的,對于一個什么也不懂的門外漢來說,因為沒有任何失敗的記憶和潛規則的約束,也就沒有什么是“不可能”的,這樣的大腦所能迸發出來的在專業人士看起來愚不可及的想法往往正是解決問題所需要的關鍵點所在。

    可能很多程序員都會有類似的經歷,在面對別人(尤其是其他部門)對于一個bug的描述的時候,必須把自己擺在一個普通用戶而不是程序開發者的角度來分析問題,否則的話可能你永遠都想象不到這種錯誤也會發生。越能讓自己變得“笨”起來,越能很快的定位到問題所在。我們先看看這么一段關于web開發問題的程序員和客服人員的對話:

    “從昨天開始我們的用戶就看不到我們站點上的Logo了。”

    “他試過重啟瀏覽器么?”

    “是的。”

    “他試過重啟電腦么?”

    “是的。”

    “他清空過瀏覽器Cache么?”

    “是的。”

    “他的瀏覽器版本是IE6么?”

    “是的。”

    “他確信是真的看不到Logo了么?”

    “是的。”

    “他是在電腦顯示器屏幕上看我們的站點么?”

    “什么?”

    “比如說,它可能是打印出來看不到?”

    “不。他是在顯示器上看的。”

    “除了站點Logo之外,他是不是其他的圖片都看不到?”

    “什么?哦。我再問問他。”

    從這段對話來說,估計用戶實際上是禁止了瀏覽器顯示圖片的功能(或者他兒子干的)。不管怎么樣,如果你不是用這種傻瓜式的思維方式去尋找答案的話,可能怎么也找不到問題的根源。

    很多時候,問題發現者對于問題的描述往往是非常片面的,并且加上了主觀推測的成分在里面。如果你不能透過這些主觀的描述去發現問題的實際表象,或者說根本就是你自己根據程序員的經驗邏輯來判斷問題所在的話,十有八九會在歧途上越走越遠。

    對于白癡級的問題,只有用白癡的行為方式才能得到答案。

    即便同樣是程序員,但對于你的程序并不熟悉,也會經常有這樣的疑問:“為什么我調用你的代碼出錯了?”這種問題的答案,很多時候是因為他們的調用方式不對,或者調用了錯誤的庫文件,或者庫文件的版本使用不當,或者根本就沒有聯接到庫文件上。當你想讓同事幫你檢查一下程序中的一個莫名其妙的bug的時候,一般來說希望他對你的系統了解的越少越好,只有這樣他才會問一些你自己認為絕對不可能出問題的“笨”問題。

    所以“笨”的精髓在于你如何去思考問題:不要假設些什么,把自己假設的太完美或者把別人假設的很聰明都會使你忽視一些很淺顯的事實。思考的前提必須是完整的事實表象,思考的過程必須是拋棄成見的問題跟蹤。在發現事實之前作太多的主觀思考和臆斷,倒不如把自己當作白癡一樣來行動更好。

    當然,不思考的一個極端是不分情況都直接去做,另一個極端是完全脫離事實,用思想辦事。一個優秀的程序員應該做好權衡。10次決定里面的1次錯誤決定不是致命的;只做5次正確的決定而另外5次沒有任何決定才更糟糕。

    最后是一個蜈蚣的故事。蜈蚣本來用自己的幾百只腳走路走的很快很好,但他從來沒有花時間去想過為什么。直到有一天,一只臭蟲問他:“你是怎么管理好你的幾百只腳的?你不覺得這是件很困難的事情嗎?”臭蟲問完之后就走了。只剩下蜈蚣坐在地上,不停的思考這個問題,卻一直想不出個究竟。從此以后,這只蜈蚣再也沒辦法好好的走路了

    posted @ 2005-10-30 22:33 成長記錄 閱讀(476) | 評論 (1)編輯 收藏
     
    什么是XML數據島? 
    數據島是指存在于HTML頁面中的XML代碼。數據島允許你在HTML頁面中集成XML,對XML編 
    寫腳本,而不需要通過腳本或<OBJECT>標簽讀取XML。幾乎所有能夠存在于一個結構完整 
    的XML文檔中的東西都能存在于一個數據島中。包括處理指示、DOCTYPE聲明和內部子集 
    。(注意,編碼串不能放在數據島中。) 
    <XML>元素標記數據島的開始,它的ID屬性提供了一個可以用來引用數據島的名稱。 
    數據島的XML可以是內嵌的: 
    <XML ID="XMLID"> 
       <customer> 
          <name>Herbert Hanley</name> 
          <custID>81422</custID> 
       </customer> 

    </XML> 
    或者在XML標簽中通過SRC屬性引用: 
    <XML ID="XMLID" SRC="customer.xml"></XML> 
    也可以使用<SCRIPT>標簽來創建一個數據島: 
    <SCRIPT LANGUAGE="xml" ID="XMLID"> 
      <customer> 
        <name>Mark Hanson</name> 
        <custID>81422</custID> 
      </customer> 
    </SCRIPT>

    posted @ 2005-10-30 22:26 成長記錄 閱讀(351) | 評論 (0)編輯 收藏
     
    主站蜘蛛池模板: 国产乱码免费卡1卡二卡3卡| 午夜影院免费观看| 尤物永久免费AV无码网站| 亚洲国产成人在线视频| 曰批全过程免费视频网址| 久久久久亚洲av无码尤物| a级毛片免费观看视频| 亚洲精品无码永久在线观看你懂的 | 成人看的午夜免费毛片| 亚洲国产综合AV在线观看| 免费鲁丝片一级在线观看| 色妞www精品视频免费看| 亚洲精品无码永久在线观看| 久久久久久毛片免费看| 亚洲成AV人片在线观看ww| 99久久免费精品视频| 狠狠色香婷婷久久亚洲精品| 免费观看的av毛片的网站| 免费人成大片在线观看播放| 日韩一卡2卡3卡4卡新区亚洲| 女人隐私秘视频黄www免费| 久久亚洲春色中文字幕久久久| 亚洲大片免费观看| 亚洲youwu永久无码精品| 亚洲男人在线无码视频| 少妇太爽了在线观看免费视频 | 国产又大又粗又长免费视频| 亚洲heyzo专区无码综合| 亚洲一区无码精品色| 精品无码无人网站免费视频| 亚洲欧美熟妇综合久久久久| 亚洲一区二区三区国产精品| 91福利免费视频| 国产成人 亚洲欧洲| 亚洲av日韩av无码| 日韩特黄特色大片免费视频| 免费无码黄网站在线看| 2020天堂在线亚洲精品专区| 国产日韩成人亚洲丁香婷婷| 亚色九九九全国免费视频| 日韩电影免费在线观看网址|