三年Android開發習慣

Android三年，現在寫代碼，真心沒什麼很大的興趣，每天都是最佳化代碼，最佳化架構，支援人員。非常枯燥乏味。

一個項目做了大半年，才做了1／4,光src就有3M了。對這種大型app，我表示很無奈。什麼時候才能到個頭。

不過感謝我的line manager，讓我專心做架構，還有我老大給予我支援人員。

寫代碼的時候三要素：Stable，Flexible，Readable

 

現在我搭個小型app的架構，大概3小時（複製，粘貼）

1.HTTP架構，用自己的，

2.ActionBarSherlock ，整合actionbar，我還是比較喜歡4.0風格，現在做的app都遵守標準的4.0

3.重寫ActionBar Style , 更換主題樣式。

4.圖片lib（Android-Universal-Image-Loader），最近找了個不錯的。

5.下拉重新整理，改的開源的，增加下拉和上拉的區分回調，連結不記得了。我部落格裡有。

6.瀑布流，最近也碰到的牛x的。PinterestLikeAdapterView 不過代碼我也改過了，在onscroll裡載入更多，回調。發現下拉重新整理的方式都是一樣的。。。

7.資料庫，自己寫的架構太大了，基本手寫。ormlite沒試過，db4o，perst太小眾，不怎麼靈活。

8.BaseActivty,BaseFragment,BaseFragmentActivity. 很多時候有基類是非常好的事，邏輯都在基類裡寫好，子類只要改下UI布局就好了。

9.工具類。

10.複製粘貼，一個項目搭好了。

 

我喜歡把UI和邏輯拆開，如果拆不開，要麼棄用，要麼重寫。不然以後維護沒人能看懂，可別提改bug了。

不管team有多少人，一開始寫代碼盡量寫虛擬碼(//TODO)，把整體邏輯寫完，TODO的地方慢慢加上，一個Activity就寫完了。而且如果不做了，或者讓別人來做，能很快順著你的思路繼續下去。如果你有很好的畫流程圖的習慣。把它們變成TODO試試。你會發現代碼寫起來很輕鬆。把寫代碼當成一種享受。當我看到別人在Activity有一堆演算法邏輯的時候，簡直是噩夢。如果team都能按照這個標準，效率至少提高50％。

對於新手來說，借鑒別人的sourcecode不是越多越好，整天有人問，這個項目的那個方法怎麼用。你連看懂的資質都沒有，到時候出bug了，誰來幫你fix。再者需求不是生搬硬套，別人的源碼拿來還要改的，那麼怎麼改？建議好好分析一個項目，自己再試著寫個簡單的libary。你就明白怎麼使用別人的架構，而且還會修改。架構本身就是為了更簡化開發，所以很靈活，考慮的情景也很多。看明白一個架構，你的邏輯能力會變強，自己試著寫個小架構哪怕是個小自訂view，動手能力也會變強。當然，如果簡單基礎知識都不理解的話，建議還是一步步來。

當你在寫代碼時，調用api，或者別人的架構，首先先想想你要什麼樣的功能，對方應該要提供給你什麼功能，這個方法會叫什麼樣的名字，多YY，這樣你會很驚喜的發現，它們確實有這樣的方法。如果沒有，自己加，或者換個思路。這樣YY多了，你也會在寫代碼的時候想提供什麼樣的方法給外部。這樣良性迴圈，寫代碼就真的是很容易的事情了。

當你成為team裡的核心人員，如何去把控整個項目，梳理邏輯和架構，就需要平時多YY，多畫流程圖，多站在非技術的角度看整個項目，很難說有需求是無法實現的，也不能因為需求頻繁改動而去抗拒。所以多想想在技術之外你還能為這個項目貢獻什麼。idea，溝通，協作。這樣你在team扮演的角色越來越重要。升職，轉行，隨你。

最近沒啥技術可以分享的，只能寫寫心得，僅供參考，可以交流，但真正問我什麼問題怎麼解決，我可能回答不了。術業有專攻，不是所有我都能解答，也不是所有都非得問他人才能有答案。