如何優雅的寫一篇安利文-以Sugar ORM爲例

前言

我最近喜歡把寫的十分優美的技術文章叫作安利文。首先，文章必須是原創而非軟廣；其次，閱讀以後不只能快速吸納技術要點併入門開發，還能感同身受的體會做者熱情洋溢的讚美和急於分享心得體驗的心情，讓人感受相見恨晚，醍醐灌頂。

安利文基於技術文章但又高於技術文章，同是經驗總結，但卻由於做者認真的揣摩每個標點、斷句而變得優雅。一篇盡是主觀感覺的文章卻不嚼之乏味，做者用心的指出每個須要注意的技術亮點在文字中如蛟龍戲水，讓閱讀者大呼過癮。所以，我以爲能原創分享一篇技術文章精神已經難能難得，但若能錦上添花讓技術文章變得優雅，那實乃萬全之事，功德之記。

贖我能力有限，沒法筆下生花，恰巧前天在作一個Android項目的時候從github無心覓得sugar這個棒極了的ORM庫。難忍手癢望安利之，所以擺弄一下筆墨，一方面說說我以爲程序員該如何寫一篇優雅的安利文，一方面讓你們知道這個真心棒呆了的庫。

何爲安利文
」安利文「是網絡詞彙，只要非標準化協議的定義，都是一件很主觀的東西，我認爲安利文應該具有的條件包括：

1.開源。只有開源產品纔會讓人硬起來，不表明竭澤而漁的獲取，而是隻有愛的人才會明白的一種精神（我水平低只有個star200多的開源項目，但我以爲很開心）。

2.原創。哪怕是譯文，也應加入本身的主觀體驗。由於只有「實踐是檢驗真理的惟一工具」，若未親身嘗試何談讚美一說。

3.文章乾淨利索。1..2..3簡單明瞭的說明怎麼用，4..5..6直接了當的說明技術亮點。不要從「今天坐地鐵趕上個黑絲大波妹」開始，"這個項目作完老闆加班費都不給"結尾，只談技術。

4.有領域經驗，有本身的見地，能一針見血的指出安利對象讓人愛不釋手的理由。閱讀者不乏入門開發者，若沒有起碼2個以上的項目經驗，拿着一個本身用過的東西就瘋狂的寫上我愛它，但有其餘更優秀的輪子能替代，若無人評論中指出，豈不貽人之時。

5.絕不掩飾本身的喜悅之情。若你對本身推薦的輪子沒有信心，那如何向其餘人證實這確實就是右轉就再永遠錯過的佳做？根本不用左的保守表達來訴說你運用過程當中體會到的興奮、快感，就是應該讓閱讀者感同身受。

如何優雅的寫
「優雅」一詞我見於技術類文章，最先是在學習laravel文檔的時候看到的。看過文檔的人態度很是兩極：愛的不要不要的和罵的不要不要的。我很是理解爲什麼會有人罵，讀laravel文檔的心態和受MSDN傳統教育刻板挑錯別字的閱讀心態徹底不一樣：讀起來感受很輕，措辭用起來像軟廣。說一個開源項目發軟廣，確定是門戶之爭、輪子忠誠的事，但這也算安利文的樂趣和精華之一，從評論中能夠了解更多的經驗教訓，而這些都是創建在大拿們無私分享經驗基礎上的。所以，「優雅」的寫，引起一場爭論，反而是一件值得慶幸的事。

「優雅」帶有很強烈的資產階級文藝小資派氣息，要習慣裝的像個文青，大膽「優雅」的去寫安利文。下面，我說說我認爲應該如何優雅的寫：

1.讀起來像機翻。「使人激動的新特性」、「多是XXX」、「值得去深刻探究」、「超乎想象的極致」...，是否是很眼熟？細思肉麻，讀來上口。用這些科技公司的廣告語，老是比打開搜索引擎賣弄唐詩更實在的選擇，由於雖然辭藻談不上華麗，但卻最容易讓開發人員感同身受，畢竟習慣了譯文的句式和用詞。固然若是你能寫出羅貫中的筆鋒來，中文科技博客就該辦個做協了。

2.一個天然段不宜過長。想表達的東西不少，很好，但你能夠分爲多個天然段。過長的天然段可能會下降閱讀者的閱讀興趣，其實這很很差，與其說是用戶體驗優化，不如說是讓人變懶了，不該該適用於開發人員。

3.圖。一圖頂百字，用Visio、XMind、UML畫，太懶了QQ截屏也是不錯的選擇。

4.善用括號增強主觀態度（就像這樣，你看這裏就像是和我在交心，討厭-_-!!）。把你在描述技術點時的心得體會寫進括號，閱讀者可以體會到更強烈的主觀印象。

5.代碼處理好細節。必須格式化，markdown或者博客編輯器自帶的格式化工具，沒人會喜歡沒有縮進的代碼。儘可能豐富的添加備註，這會讓閱讀者感動。

6.標題、小標題、加粗。這是讓文章寫做更簡單的一件事，而不是加劇你的寫做負擔。由於你是理科生，這更符合你的思惟邏輯。若是不知道如何措辭，就像我這樣用小標題1..2..3分段吧，不須要css裝飾，其餘開發人員會看明白的。

7.善意的吹牛逼。這會提升閱讀者的心理「錨點」，就是「星巴克的拿鐵賣的就必須比肯德基貴」的道理，善意的吹吹牛逼是你在代表本身對輪子忠誠度的方式，好比我就從不用dagger或者butterKnife，我公司項目全都是剪切加複製，也沒見上線運行出問題（看明白了？）。

8.謙虛謹慎的自信，恍恍惚惚的放屁。天外有天，人外有人，誰一晚上看得完萬卷書，一碗吃得下千斤飯。千萬不可自驕自傲，應該虛心接受評論裏的指正，心態頗有必要。可是，爲了提升閱讀者的閱讀興趣，插科打諢、睜着眼放屁，出現「5成的把握它會是Github上最棒的項目，5成的把握它會是Github上最爛的項目」，這種徹底無心義的文字，是徹底鼓勵的一種行爲。

9.放入草稿箱，喝杯茶再打開修改一遍。最後一點請記住，你是想寫一篇引發共鳴的安利文，而不是通常的技術總結，因此重構是很是有必要的。

想到些什麼，就即興寫了，其實我也是在爲本身練筆，勤能補拙。原本還想安利一下我微博喜歡閱讀的幾個科技號，但有沾人家地氣的嫌疑，看我常常轉發的微博就知道是哪些了。若是讓你有了次日本身寫一篇安利文的衝動，也算這篇文章沒有白寫。下面是本身練習寫的安利文例子，但願你們喜歡。

---

Android數據庫竟然能夠如此輕巧
-Sugar ORM簡單指南

Android下的數據庫操做一直是一個比較使人頭疼的事，若是用原生編寫，那麼除了數據庫鏈接、版本升級、基礎查詢等幾個基本功能可打包複用外，業務邏輯從Schema到增刪改查都必須重寫一遍。而更多的時候，我項目的數據庫業務邏輯其實並無那麼高的性能要求和複雜度，所以，選擇一款ORM庫代替，是一件極爲明智的選擇。

恰似柳暗花明
目前Android ORM開源項目中，最知名、應用最普遍的是GreenDAO，它出自著名的greenrobot（就是寫EventBus的那羣大神），常年排在Github Android ORM榜單的第一位，其優缺點網上已有衆多文章深刻解讀，這裏再也不深刻。

結合我自身業務需求，GreenDAO仍然顯得過重了--它須要用JAVA桌面程序生成Model（實際上是由於JAVA我只會android啊..這不是要我命麼），所以我一直採用原生的方式處理數據庫業務邏輯，直到心裏崩潰。到Github又趴了一遍，結果立馬就深深愛上了排名第二的Sugar ORM並當即運用到項目中。

Sugar ORM特性
簡單，就是對Sugar最高的評價。KISS（Keep it simple and stupid）原則最完美的展示，須要經驗豐富的代碼重構才能作到。我一直是ORM的忠實擁躉者，我首先考慮快速開發，從不考慮性能。從Entity FrameWork到Eloquent ORM再到Sugar ORM，雖然Sugar沒有前二者強大，可是我以爲已經足夠，爲何？

項目本身都認爲--極致簡單的方式處理數據庫業務
先來看看Sugar的介紹裏面本身是怎麼說的：

A simple, concise, and clean integration process with minimal configuration.

（用最少的配置實現最簡單、明瞭、暢快的集成過程）

Automatic table and column naming through reflection.

（採用反射的方式無須干預自動生成表和字段）

Support for migrations between different schema versions.

（支持不一樣版本數據庫集合的遷移）

那麼Sugar的集成，到底簡單到什麼程度呢。看看Bean的編寫：

一個Bean的例子

public class Book extends SugarRecord {
  @Ignore
  String name;
  @Unique
  String ISBN;
}

不像GreenDAO，須要專門用桌面工具生成Bean。不須要你寫表建立代碼，不須要寫增刪改查的代碼（固然業務代碼仍是要寫，他懂你的心情，不懂你的心），就是簡單到這個程度。若是屬性中有Drawable等不想存入數據庫的字段，那麼加上@Ignore就好，爲所欲爲。

配置2步搞定
Sugar的配置只有2處.

1.修改你的AndroidManifest.xml

<application android:label="@string/app_name" android:icon="@drawable/icon"
android:name="com.orm.SugarApp">
<meta-data android:name="DATABASE" android:value="sugar_example.db" />
<meta-data android:name="VERSION" android:value="2" />
<meta-data android:name="QUERY_LOG" android:value="true" />
<meta-data android:name="DOMAIN_PACKAGE_NAME" android:value="com.example" />
</application>

依此爲包括數據庫名稱、版本、是否打開日誌、你的項目包名。別忘了在application標籤加上2中重載的Application類參數

2.爲你的Application類添加初始化和銷燬。

public class AppContext extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        SugarContext.init(this);
    }

    @Override
    public void onTerminate() {
        SugarContext.terminate();
        super.onTerminate();
    }
}

一個啓動，一個關閉。設置好後其餘都不須要操心。

在Application中添加Sugar環境設置
想早點下班，用QueryBuilder
ORM最強大的地方體如今OOP原則的查詢操做上，Sugar把增刪改查都給你封好了。由於足夠簡單，因此就以查詢爲例，包含：

1.Id查詢，findById

2.簡單Sql語句查詢，find

3.複雜sql語句查詢，findWithQuery

3.數量查詢，count

Note.find(Note.class, "name = ? and title = ?", "satya", "title1");//就像string format同樣簡單
//直接執行sql語句
Note.executeQuery("VACUUM");

//這也是直接執行sql語句
List<Note> notes = Note.findWithQuery(Note.class, "Select * from Note where name = ?", "satya");

複雜點的業務邏輯，寫好Sql語句，用executeQuery或者findWithQuery執行，選哪一個函數看你心情，開心就好。卻是有一個須要注意的坑，Sugar有一個命名規範約定，若是字段以駝峯命名法命名，須要改成下劃線命名法，如「testUnderscore」須要改成「test_underscore」。不過你也沒必要過於擔憂，Sugar已經提供了函數

StringUtil.toSQLName("testUnderscore");

自動幫你轉換命名。其餘增刪改查的函數請自行瀏覽官方文檔,抱着簡單的心態，5分鐘就看完。

我不知道你，反正我就他了
其實在剛開始作Android開發時，用到國內大神寫的xUtils框架時就已經較淺的瞭解ORM了，可是後來放棄堅持用原生寫全部代碼。因爲疏於瞭解，只知道GreenDAO，可是用起來過於麻煩。發現Sugar以後，各類數據也不打算存Preference了，我仍然堅持不打算用Annotation庫，但Sugar確定會用在以後的每個項目。由於簡單，能夠把更多的精力放在業務邏輯上，這不正是開源社區的思想麼。我不知道你，反正我就他了。

相關資料
項目地址：https://github.com/satyan/sugar
文檔：http://satyan.github.io/sugar/getting-st...

P.S. 本身在作獨立開發，但願廣結英豪，尤爲是像我同樣腦子短路不用react硬拼anroid、ios原生想幹點什麼的朋友。 App獨立開發羣533838427 微信公衆號『懶文』-->lanwenapp<--