記住
越少越好
並非總是如此(Keep in Mind –
Less is more
is not always better)
– 高效率的代碼是件好事
但很多情況下
並非代碼行數越少效率就越高
不要把簡單事情復雜化(Do not complicate things)
– 我曾經這麼做過
我相信你也一樣
開發者都傾向於采用復雜方式解決簡單問題
我們在一個只有
個用戶的系統中引入EJB
為一個並不需要框架的應用實現一套框架
采用屬性文件
采用面向對象解決方案
使用線程
而這些根本用不著
為什麼會這麼做?一些人可能不知道有更好的解決方案
但另一些人可能故意這樣做來學習新知識
或僅僅是因為有趣
對那些不知道更好解決方案的人
要多聽有經驗程序員的建議
對於那些純粹出於個人目的而將設計復雜化的人
我建議你要更加專業一點
不要
硬編碼
(No hard coding please)
– 由於時間緊迫
開發者總是會忘記或故意忽略這一條
然而另一種可能是
遵循這條戒律
我們就不會陷入
時間緊迫
的困境
定義一個static final 變量
增加一行代碼
又能花多長時間呢?
為代碼添加注釋(Add comments to your code)
– 每個人都知道這一點
但不是每個人都會這麼做
你有多少次
忘記
添加注釋了?確實
注釋不會為你的程序增加任何函數功能
但是
有多少次
看到
周前寫的代碼
你都記不起它是干什麼的?你很幸運
那些未注釋的代碼是你自己寫的
你腦海中還會有殘存的印象
非常不幸
大多時候
代碼是別人寫的
並且那個人很可能已經離開公司了
有句諺語說的好
有來有往
互惠互利
因此程序員應該體諒彼此(還有你自己)
給你的代碼加上注釋
不要發明你自己的框架(Do not invent your own frameworks)
– 不誇張地講
已經有幾千個框架存在了
大多數還是開源的
很多框架都是極完美的解決方案
並已被用到成千的系統中
我們只要關注最新的流行的框架
至少表面上要熟悉一下
一個最成功的
也是被廣泛使用的例子是Struts框架
這個開源的web框架是建立web系統的極佳選擇
不要試圖構造你自己的Struts版本
會累死的
但你必須記住第
條(譯注
原文是
第
條
顯然不對)戒律
不要把簡單事情復雜化
如果你要開發的系統只有
個界面
就不要用Struts
對於這樣一個系統
沒有足夠的需要被
控制
的東西(譯注
Struts將界面做MVC劃分
C即controller
所以作者說there isn
t much
controlling
required)
對Print行或字符串說不(Say no to Print lines and String Concatenations)
– 我知道為了調試方便
程序員喜歡到處用System
out
println
然後對自己說過一會就刪掉
但我們常常忘記刪掉這些行或不願刪掉
我們用System
out
println 做測試
為什麼測完後還要去改代碼?這很可能導致誤刪一行我們需要的代碼
不要低估System
out
println 的危害
單元測試
單元測試
單元測試 (Unit
test
Unit
test
Unit
test)
– 我不准備討論如何單元測試的細節
我只是想說這必須要做
這是編程中最基本的規則了
尤其不能忽略
如果你同事能為你的代碼創建一個測試計劃
那就再好不過了
如果不能
那就要自己做
做單元測試計劃時
遵循下面原則
編碼前就寫單元測試
保留單元測試的注釋
對任何
有趣的
公共方法都要做單元測試(
有趣的
是指除了像最常見的getter/setter這類方法外的方法
但包含有自己內容的getter/setter 方法)
注意圖形用戶界面(Pay attention to the GUI)
– 無論聽上去多荒謬
但有一點我注意過多次了
圖形用戶界面(GUI)對於商業用戶而言與程序功能及執行效率一樣重要
GUI對於應用程序的成功至關重要
IT管理者(譯注
這裡應該是指程序開發方的IT management)常常忽略GUI的重要性
很多公司為了省錢而不雇傭web設計人員
而這些設計人員有足夠的經驗來設計
用戶友好
的應用軟件
Java程序員不得不依賴他們有限的HMTL知識
我見過非常多對
計算機友好
而非對
用戶友好
的應用程序
同時精通軟件開發和用戶界面開發的開發者非常少見
記住
質量
而非數量(Remember – quality
not quantity)
不要待的太晚(除非有必要)
我知道有時因為產品問題
截止期限或其他突發事件
不能按時下班
但經理不會因為你為一般問題待的太晚而感激或獎勵你
他們會為有質量的工作而感激你
如果你遵循上面的列的原則
你就會寫更健壯的
少bug的程序
這才是你最應該做的
提前准備需求文檔(Always Prepare Document Requirements)
– 每項業務需求都記入文檔
這在童話故事中可能實現
而現實中很難做到
無論時間多麼緊迫
無論截止日期如何迫近
你必須確保業務需求被記錄下來
From:http://tw.wingwit.com/Article/program/Java/hx/201311/25675.html