下面是對Hibernate開發工作的個人想法
正是這些工作使得Hibernate如此迅速的得到廣泛的歡迎
飛快的版本發布 保持活躍的開發速度
經常進行版本發布
甚至幾天 之內就從前一個版本開發到下一個版本
這樣是保證軟件遠離Bug的最好的辦法
也可以讓用戶感到很放心
確信Hibernate的開發十分活躍
另外這樣做也有一大好處
就是可以發現哪些功能是用戶真正需要的
回歸測試 我想現在整個Java社區一定都很重視自動回歸測試
如果軟件的功能和設計有比較大的修改
那麼一個綜合性的test suite對於軟件可維護性和穩定性來說實在是太重要了
我們應該有這樣的意識
如果對軟件的一個新功能沒有進行回歸測試
我們根本就不該去做它
把一個功能做到最好 要麼不做
要做
就一定做到最好
那些我們做不到最好的功能
我們根本不去做
扔給其他軟件去做吧
避免過度設計 浪費大量的時間和精力進行軟件功能的抽象和擴充軟件的靈活性
還不如多花點時間來解決你的用戶面臨的實際問題呢！簡單一點
軟件最重要是運行起來
不要嘗試去解決你的用戶根本不關心的問題
就算你的軟件設計的不夠優雅也沒有關系
反正還是initial階段
以後還可以再refactor
你應該關注的問題是及時的把有用的功能給做出來
集權 在你需要由民主投票來下決定之前
至少你已經把軟件輪廓做好了
軟件開發需要由一兩個開明的人來領導
這樣可以保證軟件開發的連貫性而不至於產生太大的分歧
可以保證開發團隊集中火力把要實現的功能做到最好
我覺得
OSS軟件最大的風險就是意見不統一
攤子鋪的太大
結果最後搞的什麼都沒有做好
（譯者按
非常贊同
凡是成功的OSS軟件
都是在某個人已經把軟件做好了之後
發布出來
然後由大家往裡面添加功能的
並且在這個人的領導下不斷進步
缺乏此人的OSS軟件都不算很成功
比如Mozilla）
文檔 沒有什麼比文檔更重要的了
如果你的用戶不知道你的軟件有這麼一個功能
就等於沒有這個功能
干脆把它去掉得了
省得給源代碼增加復雜度
避免標准化 好的標准可以帶來軟件的互用性和可移植性
壞的標准能夠窒息軟件創新
最好的軟件是在不斷的嘗試
不斷的出錯
不斷的經驗積累的過程中產生的
事實上的標准往往更加貼近用戶需求
分鐘之內把Hibernate跑起來 潛在的Hibernate的用戶在他們下載了Hibernate
第一次使用的時候根本就不可能花半個小時那麼多時間來安裝
配置和 troubleshooting
他們早就喪失了對Hibernate的興趣了
我們的口號就是新用戶（假設有足夠的JDBC知識）
分鐘之內把 Hibernate的Demo跑起來
而他們能夠在
個小時之內寫出
Hello World
式的最簡單的Hibernate程序並且正常運行
開發人員的責任感 用戶總是不可避免的碰到問題
開發團隊有責任有義務提供幫助
用戶讓我們知道了文檔的漏洞
用戶讓我們知道了測試用例的小bug
此外
沒有用戶來用我們的Hibernate
我們還開發它做什麼
不是浪費時間嗎！
有個關於bug的笑話
用戶根本不介意發現新功能的bug（譯者按
Windows的用戶好像都是如此）
只要你能迅速的改掉bug
責任感
意味著 bug修復應該在
周之內
從收到bug報告到bug修復代碼提交到CVS上要做到平均在
小時左右
這才是一個理想的目標
易用的可更新的wiki網頁
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28422.html
