以前一直想寫(xiě)一篇總結(jié) Android 開(kāi)發(fā)經(jīng)驗(yàn)的文章，估計(jì)當(dāng)時(shí)的我還達(dá)不到某種水平吊输，所以思路跟不上饶号，下筆又捉襟見(jiàn)肘。近日璧亚，思路較為明朗讨韭，于是重新操起鍵盤(pán)開(kāi)始碼字一番。先聲明一下哈癣蟋，本人不是大廠的程序猿透硝。去年畢業(yè)前，就一直在當(dāng)前創(chuàng)業(yè)小團(tuán)隊(duì)從事自己熱愛(ài)的打碼事業(yè)至今疯搅。下面總結(jié)是建立在我當(dāng)前的技術(shù)水平和認(rèn)知上寫(xiě)的濒生，如有不同看法歡迎留下評(píng)論互相交流。

1.理解抽象幔欧，封裝變化

目前 Android 平臺(tái)上絕大部分開(kāi)發(fā)都是用著 Java 罪治，而跟 Java 這樣一門(mén)面向?qū)ο蟮恼Z(yǔ)言打交道丽声，不免要觸碰到 抽象 和 封裝 的概念。我身邊接觸過(guò)的一些開(kāi)發(fā)者觉义，有一部分還對(duì)這些概念停留在寫(xiě)一個(gè)抽象類(lèi)雁社、接口、或者一個(gè)方法（或抽象方法）晒骇。至于為什么霉撵，我不大清楚是他們表達(dá)不出來(lái)，還是不理解洪囤。下面我也不高談闊論徒坡，直接舉例子來(lái)解釋我所理解的抽象。

//Activity 間使用 Intent 傳遞數(shù)據(jù)的兩種寫(xiě)法 下面均是偽代碼形式瘤缩，請(qǐng)忽略一些細(xì)節(jié)

//寫(xiě)法一

//SrcActivity 傳遞數(shù)據(jù)給 DestActivity
Intent intent = new Intent(this,DestActivity.class);
intent.putExtra("param", "clock");
SrcActivity.startActivity(intent);

//DestActivity 獲取 SrcActivity 傳遞過(guò)來(lái)的數(shù)據(jù)
String param = getIntent.getStringExtra("param");

//寫(xiě)法二

//SrcActivity 傳遞數(shù)據(jù)給 DestActivity
Intent intent = new Intent(this,DestActivity.class);
intent.putExtra(DestActivity.EXTRA_PARAM, "clock");
SrcActivity.startActivity(intent);

//DestActivity 獲取 SrcActivity 傳遞過(guò)來(lái)的數(shù)據(jù)
public final static String EXTRA_PARAM = "param";
String param = getIntent.getStringExtra(EXTRA_PARAM);

寫(xiě)法一喇完，存在的問(wèn)題是，如果 SrcActivity 和 DestActivity 哪個(gè)把 "param" 打錯(cuò)成 "para" 或者 "paran" 剥啤，傳遞的數(shù)據(jù)都無(wú)法成功接收到锦溪。而寫(xiě)法二則不會(huì)出現(xiàn)此類(lèi)問(wèn)題，因?yàn)閮蓚€(gè) Activity 之間傳遞數(shù)據(jù)只需要知道 EXTRA_PARAM 變量即可铐殃，至于 EXTRA_PARAM 變量到底是 "param" 海洼、 "para" 、"paran" 這一點(diǎn)并不需要關(guān)心富腊，這就是一種對(duì)可能發(fā)生變化的地方進(jìn)行抽象封裝的體現(xiàn)，它所帶來(lái)的好處就是降低手抖出錯(cuò)的概率域帐，同時(shí)方便我們進(jìn)行修改赘被。

基于抽象和封裝，Java 本身很多 API 在設(shè)計(jì)上就有這樣的體現(xiàn)肖揣，如 Collections 中的很多排序方法：

Collections中的排序API

這些方法都是基于 List 這個(gè)抽象的列表接口進(jìn)行排序民假，至于這是一個(gè)用什么樣的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn) List（ArrayList 還是 LinkedList），排序方法本身并不關(guān)心龙优⊙蛞欤看，是不是體現(xiàn)了 JDK 的設(shè)計(jì)人員的一種抽象編程的思維彤断，因?yàn)?List 的具體實(shí)現(xiàn)可能有千萬(wàn)種野舶，如果每一類(lèi) List 都要寫(xiě)一套排序方法，估計(jì)要哭瞎了宰衙。

小結(jié)：把容易出現(xiàn)變化的部分進(jìn)行抽象平道，就是對(duì)變化的一種封裝。

2.選好"車(chē)輪"

一個(gè)項(xiàng)目的開(kāi)發(fā)供炼，我們不可能一切從0做起一屋，如果真是這樣窘疮，那同樣要哭瞎。因此冀墨，善于借用已經(jīng)做好的 "車(chē)輪" 非常重要闸衫，如：

網(wǎng)絡(luò)訪問(wèn)框架：okhttp、retrofit诽嘉、android-async-http楚堤、volley
圖片加載框架：Android-Universal-Image-Loader、Glide含懊、Fresco身冬、Picasso
緩存框架：DiskLruCache、 Robospice
Json解析框架：Gson岔乔、Fastjson酥筝、Jackson
事件總線：EventBus、Otto
ORM框架：GreenDAO雏门、Litepal
還有其他各種各樣開(kāi)源的自定義控件嘿歌、動(dòng)畫(huà)等。除了以上提到的開(kāi)源框架茁影，也包括一些不開(kāi)源的SDK
數(shù)據(jù)統(tǒng)計(jì)：友盟統(tǒng)計(jì)宙帝，百度統(tǒng)計(jì)...
奔潰搜集：騰訊bugly、bugtags...
云存儲(chǔ)：七牛...
即使通訊：環(huán)信募闲、融云步脓、阿里百川...
推送：小米推送、騰訊推送浩螺、百度推送...
安全加固：360加固寶靴患、愛(ài)加密...

一般情況下，我在選擇是否引入一些開(kāi)源框架主要基于以下幾個(gè)因素：

• 借助搜索引擎要出，如果網(wǎng)上有一大波資料鸳君，說(shuō)明使用的人多，出了問(wèn)題好找解決方案患蹂；當(dāng)然或颊，如果普遍出現(xiàn)差評(píng)，就可以直接Pass掉了
• 看框架的作者或團(tuán)隊(duì)传于，如 JakeWharton大神囱挑、Facebook團(tuán)隊(duì)等。大神和大公司出品的框架質(zhì)量相對(duì)較高格了，可保證后續(xù)的維護(hù)和bug修復(fù)看铆，不容易爛尾；
• 關(guān)注開(kāi)源項(xiàng)目的 commit密度盛末，issue的提交弹惦、回復(fù)否淤、關(guān)閉數(shù)量，watch數(shù)棠隐，start數(shù)石抡，fork數(shù)等。像那種個(gè)基本不怎么提交代碼助泽、提issue又不怎么回復(fù)和修復(fù)的項(xiàng)目啰扛，最好就pass掉；

針對(duì)不開(kāi)源SDK的選擇嗡贺，也主要基于以下幾點(diǎn)去考慮：

• 借助搜索引擎隐解，查明口碑；
• 很多第三方SDK的官網(wǎng)首頁(yè)都會(huì)告訴你诫睬，多少應(yīng)用已經(jīng)接入了此SDK煞茫，如果你看到有不少知名應(yīng)用在上面，那這個(gè)SDK可以考慮嘗試一下了摄凡。諸如续徽，友盟官網(wǎng)：

接入友盟的App

• 查看SDK使用文檔、它們的開(kāi)發(fā)者社區(qū)亲澡、聯(lián)系客服钦扭。好的SDK，使用文檔肯定會(huì)詳細(xì)指引你床绪。出了問(wèn)題客情，上開(kāi)發(fā)者社區(qū)提問(wèn)，他們的開(kāi)發(fā)工程師也會(huì)社區(qū)上回答会涎。實(shí)在不行只能聯(lián)系客服裹匙，如果客服的態(tài)度都讓你不爽，那就可以考慮換別家的SDK了末秃。

小結(jié)：選好 "車(chē)輪" ，事半功倍

3.抽象依賴(lài)第三方框架

為什么要抽象依賴(lài)于第三方框架呢籽御？這里和第1點(diǎn)是互相照應(yīng)的练慕，就是降低我們對(duì)具體某個(gè)框架的依賴(lài)性，從而方便我們快速切換到不同的框架去技掏。說(shuō)到這里铃将，你可能覺(jué)得很抽象，那我直接舉一個(gè)加載圖片的例子好了哑梳。

假設(shè)你當(dāng)前為項(xiàng)目引入一個(gè)加載圖片的框架 —— Android-Universal-Image-Loader劲阎，最簡(jiǎn)單的做法就是加入相應(yīng)的依賴(lài)包后，在任何需要加載圖片的地方寫(xiě)上下面這樣的代碼段鸠真。

ImageLoader imageLoader = ImageLoader.getInstance(); // Get singleton instance
// Load image, decode it to Bitmap and display Bitmap in ImageView (or any other view 
//  which implements ImageAware interface)
imageLoader.displayImage(imageUri, imageView);
// Load image, decode it to Bitmap and return Bitmap to callback
imageLoader.loadImage(imageUri, new SimpleImageLoadingListener() {
    @Override
    public void onLoadingComplete(String imageUri, View view, Bitmap loadedImage) {
        // Do whatever you want with Bitmap
    }
});

這種做法最簡(jiǎn)單粗暴悯仙，但是帶來(lái)的問(wèn)題也最嚴(yán)重的龄毡。如果我有幾十上百個(gè)地方都這么寫(xiě)，而在某一天锡垄，我聽(tīng)說(shuō)Facebook出了個(gè)神器 Fresco沦零，想要換掉 Android-Universal-Image-Loader ，你就會(huì)發(fā)現(xiàn)你需要喪心病狂的去改動(dòng)幾十上百個(gè)地方的代碼货岭，不僅工作量大路操，而且還容易出錯(cuò)。造成這樣的原因千贯，就在于項(xiàng)目和加載圖片的框架之間形成了強(qiáng)耦合屯仗，而實(shí)際上，項(xiàng)目本身不應(yīng)該知道我具體用了哪個(gè)加載圖片的框架搔谴。

正確的方式魁袜，應(yīng)該是對(duì)框架做一個(gè)抽象的封裝，以應(yīng)對(duì)未來(lái)發(fā)生的變化己沛，我直接舉自己的開(kāi)源項(xiàng)目 AndroidAlbum 中的一種封裝做法好了慌核。

AndroidAlbum

大致代碼如下：

//1、聲明 ImageLoaderWrapper 接口申尼，定義一些抽象的加載接口方法

public interface ImageLoaderWrapper {

    /**
     * 顯示 圖片
     *
     * @param imageView 顯示圖片的ImageView
     * @param imageFile 圖片文件
     * @param option    顯示參數(shù)設(shè)置
     */
    public void displayImage(ImageView imageView, File imageFile, DisplayOption option);

    /**
     * 顯示圖片
     *
     * @param imageView 顯示圖片的ImageView
     * @param imageUrl  圖片資源的URL
     * @param option    顯示參數(shù)設(shè)置
     */
    public void displayImage(ImageView imageView, String imageUrl, DisplayOption option);

    /**
     * 圖片加載參數(shù)
     */
    public static class DisplayOption {
        /**
         * 加載中的資源id
         */
        public int loadingResId;
        /**
         * 加載失敗的資源id
         */
        public int loadErrorResId;
    }
}

// 2垮卓、將 UniversalAndroidImageLoader 封裝成繼承 ImageLoaderWrapper 接口的 UniversalAndroidImageLoader ，
//這里代碼有點(diǎn)長(zhǎng)师幕，感興趣可以查看項(xiàng)目源碼中的實(shí)現(xiàn) https://github.com/D-clock/AndroidAlbum

// 3粟按、做一個(gè)ImageLoaderFactory

public class ImageLoaderFactory {

    private static ImageLoaderWrapper sInstance;

    private ImageLoaderFactory() {

    }

    /**
     * 獲取圖片加載器
     *
     * @return
     */
    public static ImageLoaderWrapper getLoader() {
        if (sInstance == null) {
            synchronized (ImageLoaderFactory.class) {
                if (sInstance == null) {
                    sInstance = new UniversalAndroidImageLoader();//<link>https://github.com/nostra13/Android-Universal-Image-Loader</link>
                }
            }
        }
        return sInstance;
    }
}

//4、在所有需要加載圖片的地方作如下的調(diào)用

ImageLoaderWrapper loaderWrapper = ImageLoaderFactory.getLoader();
ImageLoaderWrapper.DisplayOption displayOption = new ImageLoaderWrapper.DisplayOption();
displayOption.loadingResId = R.mipmap.img_default;
displayOption.loadErrorResId = R.mipmap.img_error;
loaderWrapper.displayImage(imagview, url, displayOption);

這樣一來(lái)霹粥，切換框架所帶來(lái)的代價(jià)就會(huì)變得很小灭将，這就是不直接依賴(lài)于框架所帶來(lái)的好處。當(dāng)然后控，以上只是我比較簡(jiǎn)單的封裝庙曙，你也可以進(jìn)行更加細(xì)致的處理。

小結(jié)：預(yù)留變更浩淘，不強(qiáng)耦合于第三方框架

4.從 MVC 到 MVP

說(shuō)實(shí)話捌朴，在沒(méi)接觸 MVP 的架構(gòu)之前，一直都是使用 MVC 的模式進(jìn)行開(kāi)發(fā)张抄。而隨著項(xiàng)目越來(lái)越大砂蔽，Activity或者 Fragment里面代碼越來(lái)越臃腫，看的時(shí)候想吐署惯，改的時(shí)候想屎...這里撇開(kāi)其他各種各樣的架構(gòu)不談左驾，只對(duì)比MVC 和 MVP 。

MVC

• View：布局的xml文件
• Controller：Activity、Fragment诡右、Dialog等
• Model:相關(guān)的業(yè)務(wù)操作處理數(shù)據(jù)（如對(duì)數(shù)據(jù)庫(kù)的操作安岂、對(duì)網(wǎng)絡(luò)等的操作都應(yīng)該在Model層里）

你會(huì)發(fā)現(xiàn)，如果 View 層只包含了xml文件稻爬，那我們 Android 項(xiàng)目中對(duì) View 層可做操作的程度并不大嗜闻，頂多就是用include復(fù)用一下布局。而 Activity 等簡(jiǎn)直就是一個(gè)奇葩桅锄，它雖然歸屬于 Controller 層琉雳，但實(shí)際上也干著 View 層的活（View 的初始化和相關(guān)操作都是在Activity中）。就是這種既是 View 又是 Controller 的結(jié)構(gòu)友瘤，違背了單一責(zé)任原則翠肘，也使得 Activity 等出現(xiàn)了上述的臃腫問(wèn)題。

MVP

• View：Activity辫秧、Fragment束倍、Dialog、Adapter等盟戏，該層不包含任何業(yè)務(wù)邏輯
• Presenter：中介绪妹，View 與 Model 不發(fā)生聯(lián)系，都通過(guò) Presenter 傳遞
• Model:相關(guān)的業(yè)務(wù)操作處理數(shù)據(jù)（如對(duì)數(shù)據(jù)庫(kù)的操作柿究、對(duì)網(wǎng)絡(luò)等的操作都應(yīng)該在Model層里）

相比 MVC邮旷，MVP在層次劃分上更加清晰了，不會(huì)出現(xiàn)一人身兼二職的情況（有些單元測(cè)試的童鞋蝇摸，會(huì)發(fā)現(xiàn)單元測(cè)試用例更好寫(xiě)了）婶肩。在此處你可以看到 View 和 Model 之間是互不知道對(duì)方存在的，這樣應(yīng)對(duì)變更的好處更大貌夕，很多時(shí)候都是 View 層的變化律歼，而 Model 層發(fā)生的變化會(huì)相對(duì)較少，遵循 MVP 的結(jié)構(gòu)開(kāi)發(fā)后啡专，改起來(lái)代碼來(lái)也沒(méi)那么蛋疼险毁。
這里也有地方需要注意，因?yàn)榇罅康慕换ゲ僮骷性?Presenter 層中们童，所以需要把握好 Presenter 的粒度辱揭，一個(gè) Activity 可以持有多個(gè) View 和 Presenter，這樣也就可以避開(kāi)一個(gè)碩大的 View 和 Presenter 的問(wèn)題了病附。

推薦兩個(gè)不錯(cuò)的 MVP 架構(gòu)的項(xiàng)目給大家，還不明白的童鞋亥鬓，可以自行體會(huì)一下其設(shè)計(jì)思想：

https://github.com/pedrovgs/EffectiveAndroidUI
https://github.com/antoniolg/androidmvp

小結(jié)：去加以實(shí)踐的理解 MVP 吧

5.歸檔代碼

把一些常用的工具類(lèi)或業(yè)務(wù)流程代碼進(jìn)行歸類(lèi)整理完沪，加入自己的代碼庫(kù)（還沒(méi)有自己個(gè)人代碼倉(cāng)庫(kù)的童鞋可以考慮建一個(gè)了）。如加解密、拍照覆积、裁剪圖片听皿、獲取系統(tǒng)所有圖片的路徑、自定義的控件或動(dòng)畫(huà)以及其其他他一些常用的工具類(lèi)等宽档。歸檔有助于提高你的開(kāi)發(fā)效率尉姨，在遇到新項(xiàng)目的時(shí)候隨手即可引入使用。如果你想要更好的維護(hù)自己的代碼庫(kù)吗冤，不妨在不泄露公司機(jī)密的前提下又厉，把這個(gè)私人代碼庫(kù)加上詳細(xì)文檔給開(kāi)源出去。 這樣能夠吸引更多開(kāi)發(fā)者來(lái)使用這些代碼椎瘟，也可以獲得相應(yīng)的bug反饋覆致，以便于著手定位修復(fù)問(wèn)題，增強(qiáng)這個(gè)倉(cāng)庫(kù)代碼的穩(wěn)定性肺蔚。

小結(jié)：合理歸檔代碼煌妈，可以的話，加以開(kāi)源維護(hù)

6.性能優(yōu)化

關(guān)于性能優(yōu)化的問(wèn)題宣羊，大體都還是關(guān)注那幾個(gè)方面：內(nèi)存璧诵、CPU、耗電仇冯、卡頓之宿、渲染、進(jìn)程存活率等赞枕。對(duì)于這些地方的性能優(yōu)化思路和分析方法澈缺，網(wǎng)絡(luò)上已經(jīng)有很多答案了，此處不做贅述炕婶。我只想說(shuō)以下幾點(diǎn)：

• 不要過(guò)早的做性能優(yōu)化姐赡，app先求能用再求好用。在需求都還沒(méi)完成的時(shí)候把大量時(shí)間花在優(yōu)化上是本末倒置的柠掂；
• 優(yōu)化要用實(shí)際數(shù)據(jù)說(shuō)話项滑，借助測(cè)試工具進(jìn)行檢測(cè)（如：網(wǎng)易的Emmagee、騰訊的GT和APT涯贞，科大訊飛的iTest枪狂，Google的Battery Historian）。畢竟老板問(wèn)你比以前耗電降低多少宋渔，總不能回答降低了一些吧???
• 任何不以減低性能損耗來(lái)做敝菁玻活的手段，都是耍流氓皇拣。

小結(jié)：合理優(yōu)化严蓖，數(shù)據(jù)量化

7.實(shí)踐新技術(shù)

Rxjava薄嫡、React Native、Kotlin...開(kāi)始興起后颗胡，身邊有很多開(kāi)發(fā)者會(huì)跟風(fēng)直上毫深。學(xué)習(xí)新技術(shù)的精神是非常值得鼓勵(lì)的，但沒(méi)有經(jīng)過(guò)一段時(shí)間實(shí)踐觀察毒姨，就擅自把新技術(shù)引入到商業(yè)項(xiàng)目中哑蔫，則有失妥當(dāng)。對(duì)于大公司的團(tuán)隊(duì)來(lái)說(shuō)弧呐，會(huì)有專(zhuān)門(mén)團(tuán)隊(duì)或項(xiàng)目去研究這些新興技術(shù)闸迷，以確定是否在自己的產(chǎn)品線開(kāi)發(fā)中引入。但作為小公司泉懦，是不是就意味著沒(méi)有實(shí)踐嘗試新技術(shù)的機(jī)會(huì)呢稿黍？并不是！個(gè)人有以下幾點(diǎn)建議：

• 借助搜索引擎崩哩⊙睬颍看此項(xiàng)技術(shù)坑多不多，口碑不錯(cuò)但是坑多的話邓嘹，則說(shuō)明當(dāng)前技術(shù)不成熟酣栈，可以耐心等待更新；
• 考慮學(xué)習(xí)成本汹押。學(xué)習(xí)成本太大且不容易招到懂這方面的開(kāi)發(fā)者的情況下矿筝，建議不要引入該技術(shù)；
• 高仿一個(gè)項(xiàng)目并開(kāi)源棚贾。如果你想引入 React Native 做商業(yè)開(kāi)發(fā)窖维，最好先高仿實(shí)現(xiàn)一個(gè)應(yīng)用然后將其開(kāi)源。這樣一些對(duì) RN 感興趣的開(kāi)發(fā)者會(huì)運(yùn)行你的代碼并反饋 bug 給你妙痹，有助于你知道一些新技術(shù)的坑铸史，并尋找相應(yīng)的解決方案，最終確定是否引入該技術(shù)怯伊；
• 降低入門(mén)門(mén)檻琳轿。實(shí)踐新技術(shù)的過(guò)程盡量加以詳細(xì)的文檔記錄，這會(huì)有助于降低項(xiàng)目組其他同事對(duì)新技術(shù)的入門(mén)門(mén)檻耿芹，可以的話崭篡，也將學(xué)習(xí)文檔開(kāi)源，獲得更多開(kāi)發(fā)者對(duì)此份文檔的反饋吧秕，也可糾正一些文檔中的錯(cuò)誤琉闪；
• 結(jié)合實(shí)際業(yè)務(wù)。所有新技術(shù)的引入都要考慮是否符合當(dāng)下的業(yè)務(wù)需求砸彬，我聽(tīng)過(guò)有些程序猿想引入新技術(shù)的原因是因?yàn)橛X(jué)得這種技術(shù)很酷塘偎，網(wǎng)上說(shuō)很好用疗涉，很啥啥啥...自己完全沒(méi)弄過(guò)就人云亦云。有時(shí)候好無(wú)語(yǔ)吟秩，感覺(jué)在會(huì)用一些技術(shù)就像在炫技一樣；

小結(jié)：空談?wù)`國(guó)绽淘，實(shí)干興邦

8.UML

UML涵防，馴服代碼和了解項(xiàng)目結(jié)構(gòu)的利器，本人也在學(xué)習(xí)和體驗(yàn)其好處的路途上沪铭。不管遇到大小項(xiàng)目壮池，有了它，可以更好的理清一些脈絡(luò)結(jié)構(gòu)杀怠。對(duì)付舊的龐大項(xiàng)目代碼椰憋，或者有志閱讀某些開(kāi)源項(xiàng)目代碼的開(kāi)發(fā)者，絕對(duì)是居家必備赔退。

小結(jié)：工欲善其事橙依，必先利其器

9.自造"車(chē)輪"

前面 2 提到，項(xiàng)目不可能從0開(kāi)始硕旗，是需要引入很多第三方框架的窗骑。這里并不與 2 互相違背，而是建議有想提高技術(shù)逼格的開(kāi)發(fā)者漆枚，可以在空暇時(shí)間去編碼實(shí)現(xiàn)一個(gè)框架创译。如果你對(duì)網(wǎng)絡(luò)訪問(wèn)、圖片加載方面很有研究見(jiàn)解墙基，不妨把這些腦海里的思想落實(shí)成具體的代碼软族。也許你會(huì)發(fā)現(xiàn)，你動(dòng)手去實(shí)踐的時(shí)候残制，考慮的東西會(huì)多得多立砸，自己最終得到的也會(huì)更多。（特別建議那些看過(guò)很多開(kāi)源代碼痘拆，又至今未自己動(dòng)手自擼一發(fā)的）

小結(jié)：不要停留在 api 調(diào)用的層面

10.擴(kuò)大技術(shù)圈

有空又經(jīng)濟(jì)能力承受得起的時(shí)候仰禽，不妨去參加一些自己感興趣的技術(shù)交流會(huì)。很多都有大牛上臺(tái)演講纺蛆，聽(tīng)聽(tīng)人家的解決方案吐葵，拓寬一下自己看問(wèn)題的思路，也可以多參加一些含金量高的線上活動(dòng)桥氏。我有挺多開(kāi)發(fā)者朋友温峭，就是參加活動(dòng)的時(shí)候認(rèn)識(shí)的，有時(shí)候遇到一些技術(shù)問(wèn)題字支，還會(huì)互相探討交換一下解決思路凤藏。挺贊的奸忽！

小結(jié)：拓寬技術(shù)視野

11.寫(xiě)博客總結(jié)

這個(gè)可能沒(méi)什么好說(shuō)的，大家看了標(biāo)題就懂了揖庄。它最大的好處在于：

• 系統(tǒng)化記錄自己的解決方案栗菜；
• 方便日后自己回顧；
• 有問(wèn)題也會(huì)有讀者評(píng)論反饋蹄梢，促進(jìn)技術(shù)交流疙筹；
• 增強(qiáng)自己書(shū)面表達(dá)能力；

小結(jié)：認(rèn)真總結(jié)禁炒，不斷完善

12.找個(gè)對(duì)象

程序猿不要老是對(duì)著電腦而咆，趕緊找個(gè)對(duì)象提升一下幸福感。據(jù)說(shuō)幸福感高的程序猿幕袱，編碼效率高暴备，出bug幾率小...

總結(jié)：做個(gè)面向?qū)ο蟮某绦騿T

大概就想到這些了，以后要是再有想寫(xiě)的们豌，另開(kāi)新篇涯捻。絮絮叨叨寫(xiě)了這么多，最關(guān)鍵的還是自己要落實(shí)玛痊，千萬(wàn)不要聽(tīng)說(shuō)過(guò)太多道理汰瘫，卻依然過(guò)不好這一生哈！＠奚贰；烀帧！

• 我的個(gè)人博客：http://blog.coderclock.com/
• 我的知乎專(zhuān)欄：https://zhuanlan.zhihu.com/coderclock
• 我的Diycode：https://www.diycode.cc/d_clock
• 我的新浪微博：D_clock愛(ài)吃蔥花
• 我的微信公眾號(hào)：技術(shù)視界