熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Java核心技術 >> 正文

Java中生成文件思路和優化

2013-11-23 18:45:24  來源: Java核心技術 
    記住 越少越好並非總是如此(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 isnt much controlling required)
   
    對Print行或字符串說不(Say no to Print lines and String Concatenations) – 我知道為了調試方便程序員喜歡到處用Systemoutprintln 然後對自己說過一會就刪掉但我們常常忘記刪掉這些行或不願刪掉我們用Systemoutprintln 做測試為什麼測完後還要去改代碼?這很可能導致誤刪一行我們需要的代碼不要低估Systemoutprintln 的危害


   
    單元測試單元測試單元測試 (Unittest Unittest Unittest) – 我不准備討論如何單元測試的細節我只是想說這必須要做這是編程中最基本的規則了尤其不能忽略如果你同事能為你的代碼創建一個測試計劃那就再好不過了如果不能那就要自己做做單元測試計劃時遵循下面原則
   
    編碼前就寫單元測試
   
    保留單元測試的注釋
   
    對任何有趣的公共方法都要做單元測試(有趣的是指除了像最常見的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
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.