意大利輸球了，睡不著阿！現在就剩下德國和阿根廷是比較喜歡的球隊了。

?

還是聊聊代碼上的事情吧。什么地方該省代碼？在我參與、開發和接觸到的很多項目中，曾經都很喜歡在開始階段做一個設計。這本身沒有錯，問題在于，經常在還沒有用戶或者網站總用戶才幾十萬的場景下，去考慮高并發，去考慮高負載，去設計能夠跑在N臺服務器上的架構。現在想來這都沒有錯，不去嘗試，不去思考就不會進步。當然，所考慮絕不是僅僅這一個問題，而是言必談擴展性。積極地去考慮擴展性的問題，我一直認為是個好事情，假如我是老板，我一定會適當放松項目周期，以期讓開發人員有更多的思考。事實上在我以期考慮這些問題的時候，我經常會把下班時間也用上，對公司其實并不一定吃虧。

?

但現在想來是一個極端的表現。現在想來應該是當時對使用到的技術的各個方面：比如I/O吞吐能力、線程并發能力、網絡并發能力、事物處理等等，對他們都一知半解或者干脆就不了解。另外兩個最重要的方面在于對需求定位不清，以及總想一步到位。不要試圖說你對需求的定位很清晰，實際上需求方都不一定完全把握。就比如項目的生命周期，整個項目組真的清楚了么？對使用的技術缺乏整體上的理論理解，才會讓人不之所措，以至于過分關注性能等問題。出現性能問題也不能立刻把握瓶頸。

?

跑題了，繼續說說我對省代碼和多寫代碼的理解。我認為，開發任何一個項目，只要不是一錘子買賣，都需要從整體進行把握。不但能有效地進行業務的后期擴展，也可以在協同中少走很多彎路。我認為只要不是自己能夠把握的代碼，都可以能省則省。那什么是自己不能把握的代碼？舉個離子，我開發一個項目需要用到B部門開發的一個系統，那么調用B部門系統的方式就是我不能把握的代碼。更極端地說，如果B部門的系統還要依賴C部門開發的組件，那B不能都不能把握給我調用的方式，那自然我就更加不好把握。這種情況，就需要和需求方多溝通，讓需求方于B、C部門保持溝通才能讓我在開發時更加省力。這種情況一般把B給你的接口和你實際的調用方式分開更好。可以根據需求方的業務要求，制定自己需要的接口，然后再拿自己定義的接口和B部門提供的接口做適配。這樣做有兩個好處，沒有他們的系統你也可以很方便地模擬數據進行單元測試，或者說是即便沒有他們的系統，你的系統依然可以運行，只是不能用而已。另外一個好處是如果B部門的接口不影響你的接口調用的方式，就可以隔離掉對你的系統的影響。這樣就將對B部門系統的依賴降到最低。一定要把整個過程當成兩件事情，當整個團隊確定要做一件事情，那先要保證你的事情做好了，然后再去看別人的事情做好沒有。當然如果需求方在保持溝通過程中發現事情根本不能做，大家都放棄，那是最壞的打算。但不能因為這個理由而拖延項目的開發，以致項目延期。在這種場合就要多做設計，多寫點代碼，哪怕最后沒用上都沒關系。我做過的項目，沒有中途不變更的，所以還是先考慮設計要緊。

?

剛才說了不要過分關注對未來的擴展，因為你也不能保證你的設計就能符合未來的場景。但是有一些設計還是可以做的，比如，可以將你認為會影響性能的地方抽象化，先做簡單的實現。如果在項目上線后發現確實是這里拖了后腿，改動的化也只要改實現而不用重新架構項目。

?

那什么時候可以省代碼呢？對那樣根本不要重用或者很難重用的東西，可以考慮省代碼，省設計。比如一個頁面要以5種樣子顯示，老老實實地做5個頁面就行了，不用過分地去設計。A頁面顯示10條數據3個字段，B頁面顯示.....如果做抽象設計會繞進去，我嘗試過很多次，沒有做到一個可以讓我滿意的方案出來。當然你也可以去嘗試，我做不出不代表你做不出，呵呵。

?

一般來說不需要做多種解決方案的也不要過渡地去設計。比如做個日志，你不是要把日志存儲到N種設備上就不用考慮設備相關。誠然，做得象log4j那樣確實很牛，但common-logging中也提供的簡單的實現。一般來說，一個團隊形成的積累不用過渡考慮你們根本用不上的場景，那只是增加負擔。

轉載于:https://www.cnblogs.com/birdshover/archive/2010/06/25/1764828.html

總結

以上是生活随笔為你收集整理的该省代码的地方要省，反之亦然。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。