程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> JAVA編程入門知識 >> 軟件開發成功12法則

軟件開發成功12法則

編輯:JAVA編程入門知識


      本文篇幅較長,但是對於程序員來說仔細看完肯定會有收獲,作者對於開發和項目治理的功力頗深,文中的許多經驗辦法微軟沿用至今。也許讀完項目治理需要很長的時間和大量金錢,但是joel的這一套衡量系統,按joel的話說:“三分鐘你就可把握。你可以把省下的時間去讀醫學院了”(注:美國的醫學院可是要讀死人的!)。下面我們就開始吧!
  
   Joel 衡量法則
  
      你們用不用源文件治理系統?
      你們可以把整個系統從源碼到CD映像文件一步建成嗎?
      你們天天白天都把從系統源碼到CD映像做一遍嗎?
      你們有軟件蟲治理系統嗎?
      你們在寫新程序之前總是把現有程序裡已知的蟲解決嗎?
      你們的產品開發日程安排是否反映最新的開發進展情況?
      你們有沒有軟件開發的具體說明書?
      你們的程序員是否工作在安靜的環境裡?
      你們是否使用現有市場上能買到的最好的工具?
      你們有沒有專職的軟件測試人員?
      你們招人面試時是否讓寫一段程序?
      你們是否隨便抓一些人來試用你們的軟件?
  
      “Joel 衡量法則”好就好在你只需照著逐條回答以上問題,然後把所答為“是”的問題算成一分,再加起來就可以了,而不需要去算什麼天天寫的程序行數或程序蟲的平均數等等。但咱丑話說在前面,可別用“Joel 衡量法則”去推算你的核電站治理程序是否可靠。
  
      假如你們得了12分,那是最好,得了11分還過得去,但假如只得了10分或低於10分,你們可能就有很嚴重的問題了。嚴酷的現實是:大多數的軟件開發公司只能得到2到3分。這些公司假如得不到急救可就玄了,因為像微軟這樣的公司從來就沒有低過12分。
  
      當然,一個公司成功與否不僅僅只取決於以上標准。比如,讓一個治理絕佳的軟件公司去開發一個沒有人要的軟件,那開發出來的軟件也只能是沒有人要。或反過來,一幫軟件痞子以上標准一條也達不到,沒准照樣也能搞出一個改變世界的偉大軟件。但我告訴你,假如不考慮別的因素,你只要能達到以上12條准則,你的團隊就是一個可以准時交活的紀律嚴明的好團隊。
  
   1. 你們用不用源文件治理系統?
      我用過商業化的源文件治理系統,我也用過免費的系統,比如CVS,告訴你吧,CVS挺好用。但假如你根本就沒有用源文件治理系統,那你就是累死了也沒法讓你的程序員出活:他們沒法知道別人在改動什麼源文件,寫錯了的源文件也沒法恢復。
  
      使用源文件治理系統還有一大好處是,由於每一位程序員都把源文件從源文件治理系統裡提出來放到自己的硬盤裡,幾乎不會發生丟失源文件的事,最起碼我還沒聽說過。
  
   2. 你們可以把整個系統從源碼到CD映像文件一步建成嗎?
      這句話問的問題是:從你們最新的源碼開始到建立起能夠交出去的最後文件,你們有多少步驟要做? 一個好的團隊應該有一個批處理程序一步便可將所有的工作做完,像把源文件提取出來,跟據不同的語言版本要求(英文版,中文版),和各種編譯開關(#ifdef)進行編譯,聯接成可執行文件,標上版本號,打包成CD映像文件或直接送到網站上去,等等等等。
  
      假如這些步驟不是一步做完,就有可能出人為差錯。而且當你很接近產品開發尾聲的時侯,你可能很急於把最後幾個蟲解決,然後盡快地交活。假如這時候你需要做20步才能把最終文件制出來,你肯定會急得要命,然後犯一些很不該犯的錯誤。
  
      正因為這個原因,我工作的前一個公司從用WISE改用InstallShield:我們必需要讓我們的批處理程序完全自動化地,在夜裡,被NT scheduler起動把最終文件制成,WISE不能被NT scheduler啟動而InstallShield可以,我們只能把WISE扔掉。(WISE的那幫家伙向我保證他們的下一代產品一定支持在夜裡自動運行.)
  
   3. 你們天天白天都把從系統源碼到CD映像做一遍嗎?
      你們有沒有碰到過這樣的事情:一個程序員不小心把有毛病的源碼放進源文件治理系統,結果造成最終文件沒法制成。比如,他建立了一個新源文件但忘了把它放進源文件治理系統,然後他高興奮興鎖機回家了,因為在他的機器上整個編譯得很好。可是別人卻因為這沒法工作下去了,也只好悶悶地回家了。
  
      這種造成最終文件沒法制成的情況很糟糕,但卻很常見。假如天天在白天就把最終文件制一遍的話,就可以讓這種事不造成太大危害。在一個大的團隊裡,要想保證有毛病的源碼及時得到糾正,最好天天下午(比如午餐時)制一下最終文件。午餐前,每個人都盡可能地把改動的源文件放到源文件治理系統裡,午餐後,大家回來,假如最終文件已經制成了,好!這時大家再從源文件治理系統裡取出最新的源文件接著干活。假如最終文件制作出錯,出錯者馬上修正,而別人還可接著用原有的沒問題的源程序干活。
  
      在我以前曾干過的微軟Excel開發組裡,我們有一條規定:誰造成最終文件制作出錯,誰就得被罰去負責監視以後的最終文件制作過程,直到下一位造成最終文件制作出錯的人來接任他。這樣做不僅可以督促大家少造成最終文件制作出錯,而且可以讓每個人都有機會去了解最終文件制作過程。
  
      假如想更多了解這個話題,可以讀我的另一篇文章 Daily Builds are Your Friend.
   4. 你們有軟件蟲治理系統嗎?
      不論你有任何借口,只要你寫程序,哪怕只是一個人的小組,假如你沒有一個系統化的治理軟件蟲的工具,你寫的程序的質量一定高不了。許多程序員覺得自己可以記得自己的軟件蟲。沒門!我從來記不住超過2到3個軟件蟲。而且第二天早上起床後忙著去買這買那,好不輕易記住的軟件蟲早忘掉了。你絕對需要一個系統來管住你的那些蟲。
  
 

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved