——瑞·达利欧

在日常的开发和设计过程中， 大家对技术设计上的一些问题往往会面临很多的选择，不同的人会有不同的选择， 将心比心... 每每如此，我都会尝试着问自己：我做出选择和判断背后的原则是什么？

说实话，这个问题问得我头都大了。我是个写代码的，平时也就是在那敲敲键盘，写写接口，调调bug。我有时候真的在想，那些所谓的架构设计原则，真的有用吗？还是说就是那些写书的人为了显摆自己懂多而编出来的？但我想了想，如果不懂点原则，我这接口写出来的东西，是不是真的像一坨屎，太水了。？

我倾向于... 今天我就随便聊聊， 瞎扯淡一下关于我在数据接口开发中遇到的那些破事儿，还有那些所谓的原则。

一、 写接口真的很烦，就像天天吃方便面

做接口开发，说白了就是让A系统能和B系统说话。以前我觉得很简单，不就是传个JSON过来我再存到数据库里嘛。后来发现，根本不是那么回事。

有时候接口写多了我自己都分不清哪个是哪个。数据进来出去，中间经过多少层，我都搞不清楚。就像便利店的收银员，前面的人买了包烟， 薅羊毛。 后面的人买了瓶水，收银员得一个一个扫，扫错了还要退回去。那个收银员就是我，那个顾客就是数据。

站在你的角度想... 有时候数据一大，接口就慢。慢了用户就骂人，我就得加班改。改来改去，代码越来越乱。我就想，如果我有原则，是不是就不会这么乱？

1. 单一职责原则， 别把所有活都揽在自己身上

与君共勉。 这个原则我听过但我总是忘。它的意思好像是说一个函数，或者一个类，就只做一件事。

但我经常不遵守。比如我写一个接口，既要查数据库，又要发邮件通知，还要写日志，还要计算个什么积分。我觉得这很高效啊， 整一个... 一次调用全搞定了。但是后来出问题了。数据库挂了邮件没发出去，日志也丢了。我找问题找了三天三夜，头发都掉了好几根。

后来我想明白了那个接口它太累了。它想死。如果我把查数据的和发邮件的分开，查数据的只管查，发邮件的只管发，这样是不是就清楚多了？如果查数据库的挂了发邮件的还在跑。这就是单一职责吧，何苦呢？？

可是分开写代码也很麻烦啊，要写更多的函数，要调更多的接口。为了偷懒，我还是喜欢把东西揉在一起。唉，我真是个懒人。

2. 开闭原则， 别动老代码，改新代码

这个原则听起来很高级，但我怎么觉得是在让我写更多的代码呢，太离谱了。？

意思好像是说软件要尽量开放 ，关闭修改。就是说如果我以后要加个功能， 换个赛道。 别去改我以前写好的那个函数，你应该写个新的函数，或者继承一下。

但现实是老代码我都不想看，更别说改了。一看老代码，全是坑。上次我想加个功能，我看了一眼以前的代码，吓得我手都在抖。那个变量名叫`temp`，`temp1`，`temp2`，我根本不知道哪个是哪个。

差不多得了... 如果强行不改老代码，我就得写新代码。新代码调用老代码。这样确实挺好的，老代码不动，新代码乱飞。但是如果老代码有个bug，我是改新代码还是改老代码？改老代码吧，怕把系统搞崩；不改吧，这个bug一直都在。真的很纠结。

我觉得这个原则是给那些有钱有闲的人说的。我们这种搬砖的，能跑就行。不过话说回来如果大家都守这个原则， 本质上… 我的代码可能就不会变成现在这个样子了。

二、 接口设计那些事儿，怎么搞都不对

接口怎么设计？这是个大问题。RESTful？GraphQL？还是Soap？我都听说过但我真的不懂。我只知道我要把数据传过去，往往.….。

1. 依赖倒置原则，别让东西死死绑在一起

这个原则我听得最多的就是“依赖注入”。但我怎么理解呢？

大概就是说高层次的模块不应该依赖低层次的模块，它们都应该依赖抽象。抽象？什么是抽象？不就是写个接口定义一下嘛，弄一下...。

有啥说啥... 以前我写代码，直接new一个对象出来用。比如我写个Service，直接new一个Dao。如果Dao变了我的Service是不是也得跟着变？这听起来很麻烦。

后来我试着用了一下接口。我定义了一个`IUserDao`接口，然后让`UserDao`去实现它。我的Service只依赖`IUserDao`。这样，如果我要换数据库了从MySQL换成Oracle，我只需要改一下实现类，Service不用动，呵...。

没耳听。 哇，这样好像确实好一点。但是写接口也很累啊，要多写好几行代码。而且有时候，为了省事，我还是直接new了。我觉得那个所谓的“抽象”，有时候就是自欺欺人，大家还是面对面的具体对象。

2. 接口要稳定，别天天变

这是我最痛恨的一点。产品经理说这个需求改一下。我就得改接口。改了接口，前端就得改。前端改了测试就得测。测试测不完，我就得加班。

将心比心... 架构原则说要稳定。可是需求是死的，人是活的，市场是变的。需求变来变去，接口怎么可能稳定？

有时候我想，能不能设计一个万能接口？什么数据都能查？但是那样太不平安了也太复杂了。我觉得吧，接口设计，看心情。心情好了就设计得好看点，心情不好就随便写写，PPT你。。

三、 数据来了怎么处理才不乱套？

数据接口，核心就是数据。数据怎么存，怎么传，怎么错，都是问题。

1. 接口要返回格式统一， 别搞那些花里胡哨的

以前我写接口，想怎么写就怎么写。有时候返回个字符串，有时候返回个对象，有时候直接返回个数字。 破防了... 前端拿到数据，还得自己判断一下类型，搞得我很不爽。

后来我看别人写，大家都返回一个标准的JSON格式。比如：，杀疯了！

{
  "code": 0,
  "message": "成功",
  "data": { ... }
}

大家都这么干，我也这么干。这样前端就方便了只要判断code是不是0就行了。不用管里面是啥。 总体来看... 我觉得这挺好的，虽然有点死板，但是大家都这么干，你也得这么干。

但是 有时候有些特殊情况，比如我删不掉一条数据，我是返回code=1还是code=-1？message写“删除成功”还是“删除失败”？这里面学问大着呢。我有时候写错了前端就报错，我也搞不清，躺平。。

2. 异常处理，别让用户看到红色的报错

我懵了。 接口出错了怎么办？这是个大问题。如果我写代码的时候忘了写try-catch，数据库一挂，整个页面就黑屏了。用户一看，完了这网站有病毒。

所以原则说要处理异常。把所有的异常都catch住然后返回一个友好的错误信息给用户。告诉用户，系统出错了请稍后再试。

不忍直视。 但是异常太多了。网络断了数据格式错了权限不够了数据库锁了……每一种异常都要写一个处理逻辑吗？那代码得写到什么时候去？

麻了... 有时候我就随便写个`try-catch { return "系统错误"; }`。反正只要不崩就行。但是这样的话，如果真的出问题了我连日志都找不到，主要原因是日志也被catch住了。这算不算掩耳盗铃？

四、 性能优化，能跑就别优化

说到性能，大家都想快。但是快是需要代价的。原则说要优化，但我真的没钱买服务器，也没时间优化代码。

1. 缓存，是不是必须的？

原则说数据接口要加缓存。比如Redis，Memcached。但是数据是实时的，加了缓存，数据就不准了，极度舒适。。

太坑了。 比如一个商品的价格， 我缓存了用户看到的价格是旧的，后来啊下单的时候价格变了这就麻烦了。所以有些数据不能缓存，有些数据可以缓存。

说白了... 我不知道该缓存什么。有时候我连Redis都没装，我就直接查数据库。数据库小，跑得快，我也懒得配缓存。我觉得，只要用户不骂，我就不优化。反正现在电脑都很快了。

2. SQL语句怎么写？

原则说要优化SQL。少写`select *`，多写`where`条件，建索引，他急了。。

别怕... 但是建索引会影响写入速度。如果我的业务是写入特别多，那我建索引是不是就亏了？而且，索引建多了数据库文件就变大，服务器硬盘不够用。

我有时候写SQL，就是瞎蒙。先写个`select * from table`，看看能不能跑通。能跑通就完事了。管它是不是全表扫描，管它是不是慢SQL。反正现在是晚上，没人用，我CPU干烧了。。

五、 一下其实我也没懂多少

说了这么多，其实我也不知道我到底懂了没有。那些架构设计原则，听起来头头是道，但是真要用到实际开发中，还是有难度的。

我觉得，写代码嘛，有时候就是靠直觉。看到需求，想怎么写就怎么写。等写完了再回头看，发现这代码写得真烂。然后我想着改一下后来啊越改越烂，再说说索性不看了。

但是如果真的想把这行干好，还是得懂点原则。至少，当你写代码的时候，你知道自己在干什么而不是像个傻瓜一样瞎敲键盘，毕竟.…。

瑞·达利欧说原则很重要。我觉得他说得对。但是原则这个东西， 换言之... 太抽象了。就像说明书一样，你看得懂字，但你不知道怎么用。

没法说。 数据接口开发，就是这样一个过程。我在这个坑里爬，在那个坑里摔。有时候我想，要是能有个人告诉我，直接抄作业就好了。但是没有，只有那些冷冰冰的原则。

所以学习这些原则，真的能让我少走弯路吗？我觉得可能吧。至少，我现在知道，不能把所有东西都写在一个函数里了。我也知道，接口的返回格式最好统一一下，让我们一起...。

但是要想真正写出好的代码，还需要很多年的磨练。还需要很多次加班，很多次被骂，很多次改需求。

希望我的这些废话，能帮到一点点人吧。或者，至少能证明我写出来了。毕竟我也不是专业的， 一句话概括... 我就是一个普通的程序员，一个在深夜里敲代码的普通人。

就这样吧，我要去吃饭了。今天的饭还没吃呢。希望能吃饱。

---

---