如何优雅的写一篇安利文-以Sugar ORM为例

前言

我最近喜欢把写的十分优美的技术文章叫做安利文。首先，文章必须是原创而非软广；其次，阅读之后不仅能快速吸纳技术要点并入门开发，还能感同身受的体会作者热情洋溢的赞美和急于分享心得体验的心情，让人感觉相见恨晚，醍醐灌顶。

安利文基于技术文章但又高于技术文章，同是经验总结，但却因为作者认真的揣摩每一个标点、断句而变得优雅。一篇满是主观感受的文章却不嚼之乏味，作者用心的指出每一个需要注意的技术亮点在文字中如蛟龙戏水，让阅读者大呼过瘾。因此，我觉得能原创分享一篇技术文章精神已经难能可贵，但若能锦上添花让技术文章变得优雅，那实乃万全之事，功德之记。

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的例子

不像GreenDAO，需要专门用桌面工具生成Bean。不需要你写表创建代码，不需要写增删改查的代码（当然业务代码还是要写，他懂你的心情，不懂你的心），就是简单到这个程度。如果属性中有Drawable等不想存入数据库的字段，那么加上@Ignore就好，随心所欲。

配置2步搞定

Sugar的配置只有2处.

1.修改你的AndroidManifest.xml

如图，依此为包括数据库名称、版本、是否打开日志、你的项目包名。别忘了在application标签加上2中重载的Application类参数

AndroidManifest.xml添加数据库信息

2.为你的Application类添加初始化和销毁。

一个启动，一个关闭。设置好后其他都不需要操心。

在Application中添加Sugar环境设置

想早点下班，用QueryBuilder

ORM最强大的地方体现在OOP原则的查询操作上，Sugar把增删改查都给你封好了。因为足够简单，所以就以查询为例，包含：

1.Id查询，findById

2.简单Sql语句查询，find

3.复杂Raw语句查询，findWithQuery

3.数量查询，count

不用写一长串代码，一句话搞定

复杂点的业务逻辑，写好Sql语句，用executeQuery或者findWithQuery执行，选哪个函数看你心情，开心就好。倒是有一个需要注意的坑，Sugar有一个命名规范约定，如果字段以驼峰命名法命名，需要改为下划线命名法，如“testUnderscore”需要改为“test_underscore”。不过你也不必过于担心，Sugar已经提供了函数StringUtil.toSQLName("testUnderscore")，自动帮你转换命名。

我不知道你，反正我就他了

其实在刚开始做Android开发时，用到国内大神写的xUtils框架时就已经较浅的了解ORM了，但是后来放弃坚持用原生写所有代码。由于疏于了解，只知道GreenDAO，但是用起来过于麻烦。发现Sugar之后，各种数据也不打算存Preference了，我仍然坚持不打算用Annotation库，但Sugar肯定会用在之后的每一个项目。因为简单，可以把更多的精力放在业务逻辑上，这不正是开源社区的思想么。我不知道你，反正我就他了。

保安保安

我的大海是全栈