今天的主题是，要做一个在线明信片的项目。这个项目已经开发完毕，并且还有宣传海报。

虽然用户量不是很大，但我今天还是想从决定要做一个项目开始，完整地描述这个东西的开发过程。

可能不是符合一般企业技术团队（朋友圈大神技术团队）的开发流程，所以如果读着读着发现我哪里做得不是很符合您的心意，请您对着房顶喊出您的不满。

这篇文章作于作者在家办公的第二周周末，已经很久没有活人交流，自然显得十分话痨。作为话痨的补偿，长篇大论中会夹杂一些段子。如果不喜欢作者的幽默风格，请您对房顶喊出您的不满。请勿抬杠，抬杠算您赢。

冒出来一个需求

过年回老家之前国内爆发了新冠，导致这个年就没是过得很好，对普通老百姓来说，最直接的影响就是没法在短短的一周假期里串完所有的亲戚，见到自己想见到的人了。如果屏幕前的读者非要说自己过年把所有的亲戚都串完了，那你就串完了，反正我没串完。

在我百无聊赖躺在奶奶的炕头上时，电视上说，这个不平凡的中国年，大家应该理性拒绝集会balabalabalabala…然后建议大家线上拜年，或者写邮件，体验一下传统的拜年方式。

虽然我并不会写电子邮件来拜年，这显得会用微信的我异常沙雕，但我想到了，我们可以用另一种方式——明信片。为了让会用微信的我不显得异常沙雕，我想到了可以用电子明信片。互联网思维就是好互联网思维就是妙，电子明信片的想法冒出来之后，我都想给我家猫改装成电子的。

需求有了，接下来细化一下需求，设计一个方案出来。

设计一个方案

沙雕设计

要是电子明信片给沙雕来设计，那可能就是每个人上线注册一个账号，然后微信告诉对方我的账号，然后两个人用这个账号来互发明信片。这就好像上世纪四十年代，原本相隔千里的两个人，因为不能上网而只能书信交流，但是不知道对方的具体地址，没法告诉邮差怎么走，就只能凭借记忆跑到对方老家，问了详细地址，再跑回自己家，写信告诉对方自己想说的话。

上述设计方案简称“脱裤子放屁”，是产品设计阶段的一种设计方法（我现编的）。

开始设计

如果知道对方的手机号，就可以线上填写想说的话，再告诉系统对方的手机号，系统给对方发短信告知要说的话就好了。我们能上网，为啥不用21世纪人类的方式来做这件事呢。

要是直接就把内容发送过去了，会有两个问题：

1. 短信服务那边不允许短信内容完全自定义；
2. 要是有人想给对方发一篇完整的千字文，我的短信服务余额可能直接被榨干；
3. 一点都不好玩。

我也不知道为啥说好了两个问题，随手就摁了个3出来。不过不重要，代码打多了难免数学（数[shû]数[shù]）不好。

如果不直接用短信发送内容，那我直接想到了快递柜的模式。

将收件人的手机号和要发送的内容记录下来，生成一个随机的取件码。短信告知对方有明信片要取，再告知取件码。

收件人点开短信里的地址，输入取件码，打开明信片，色卜ruai兹！

这个方案简直太鹅妹子嘤了，于是我赶紧结束设计阶段，开始下一步。

各种评估

技术评估

作为本身就是一个臭写代码的，首先进行技术评估，要是技术上不能实现（就是做不出来的高级说法），那就不往下看了。如果在公司里，可能会先评估符不符合公司业务之类的。

都做出来了，肯定是能做。所以技术评估就是一闪鹅过，走个流程。

花多少钱评估

因为要使用短信服务，所以不得不看一下需要花多少钱。

在众多臭卖短信的的服务商中，我选中了腾讯云。虽然腾讯云的价格看上去我买不起（也用不上）

，旁边还是有个自定义可以用的。于是我选了个最卑微的价格，充值了信仰。

总共就需要花50块钱，少吃两顿饭就省出来了，这步评估也通过。

评估到这，基本就可以开始做了。

决定技术方案

决定啥啊，我就会这么些个东西，又要做网页，又要接口，还得用数据库，那没啥选择了。我会的东西排列组合一下，符合要求的也就这么一种了。

前端：html三件套、jquery

后端：php

数据库：mysql

服务器：阿里云ecs-t5，centos

由于需要保存验证码和登录套什么的，正常来说应该加个redis，但我估计这玩意也不会有很多人来用，就暂时用mysql代替。等什么时候mysql扛不住这巨大的登录频率了，再换redis。估计到时候我直接花钱升级mysql硬顶都能顶住了。

前端选择了最原始的人类科技jquery，不是因为我不会vue，而是用脚手架太麻烦。要是看热闹的您非要看我用vue脚手架搭个什么，下次更新用vue脚手架搭建一个fade流项目。

下次更新是指我什么时候想起来。2018年9月我打算写一个php入门手册，到现在还在拖着。但是我没忘，没忘就不算tj了。初中的时候想要拍一个短片，当时还没有vlog的概念，现在vlog热乎劲都过去了，我还没开始拍，但我还没忘，没忘就不算tj。

虽然说了很多废话来掩饰我拖延的尴尬，但是这个fade流的东西真的存在，并且可以扫描下面的二维码访问：

因为域名是night，所以下文提到这个fade流都称之为night。可能是脑抽了，让我觉得这个明信片在night中，所以跟night共用同一个后端项目和同一个前端文件夹。

服务器选用阿里云的ecs-t5，因为啥呢，因为我只有这个。服务器os选用centos，原因也一如既往地简单，我只有这个。我也想让服务器用macos，但是实力不允许。

技术方案决定了，中午请前端老哥吃个椒麻鸡，就开始做了。

编码开发

写代码之前要做的事也太多了，要不是写文章，我都不知道自己动手之前拖了这么久。

在服务器建文件夹

这一步是让项目有一个安稳的家。

设置nginx解析

先搞一个前端解析

server {
    listen       80;
    server_name  postcard.host.host;
    location / {
        root   /path/path/path;
    }
}

再搞一个接口解析

nginx下的接口需要通过php-fpm来实现（？解读/分析/认识/转发？），总之就是php-fpm能读php脚本而nginx不能，php-fpm的服务在127.0.0.1:9000，我们就需要用端口转发的方式让nginx去认识127.0.0.1:9000来的请求，并当成接口来给前端。

我也不知道上边这段我写了什么几把，可能就是对php-fpm的概念掌握不牢固而导致的心虚而导致的语无伦次吧。

server {
    listen       80;
    server_name  apihost.host.host;
    location / {
        root   /path/path/path/api;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
    }

    location ~ [^/]\.php(/|$) {
        root /path/path/path/api;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include fastcgi.conf;
    }
}

抄这两段配置之前需要明白一件事，我在域名后台把*直接解析到服务器ip了，这样就可以不用每次都去登录域名后台了。要是你没跟我一样设置，就算喊破喉咙也没有用的。

配置里还有一个fastcgi.conf，跟这次业务没啥关系，我就不发了，所以你完全没法照抄这段代码。

然后就完事了。上边配置里的域名和路径信息我都使用了国内最流行也是最安全的瞎几把混淆方式，具体路径以我服务器存放路径为准，具体域名以网站真实使用为准。

部署后端代码

后端代码在写night的时候就已经部署好了。

在我年少无知不会用composer的时候自己写了个框架，可以参考我之前的文章《搞一个框架出来》。这个破框架唯一的优点是有一个跟ci差不多的路由，这个破框架的缺点是

• 不支持composer
• 没有orm
• 不知道psr4是啥
• 不分业务层和数据层
• db底层是mysqli不是pdo
• 等等你能想得到的缺点

由于night就用的是它，所以这次很艰难地继续用了。

代码分享

为了展现程序员人性化的一面，这次项目所有的代码我都放在一个单独的github仓库里了，仓库地址我会变成二维码和地址本身放在文章最后。如果看编码实现这段不知所云，建议你先滑到最后看一下代码。

转念一想还是别放最后了，你再懒得滑回来咋整。大放假的都怪懒的，我先把地址放出来吧。

地址是

https://github.com/xtzero/xtPostcard_Share

部署前端代码

前端部署就很简单了，在服务器上建个文件夹再建个index.html，再写点骚话，试一下域名能访问就是成功了。

开发（写代码|扯皮|水群|撸猫|刷微博|抠脚）

开发就是一把梭，由于写文章没法体现我具体的开发过程，所以建议您去读代码。在后台回复“我想看过程”并留下你想看开发过程了三万字理由，下次我直播开发东西的时候叫你。

自动部署

我也没用ci也没用action，我用的是xtGithubWeebhookCi.php，是一个同样出自本人之手的沙雕自动部署工具。使用了github的webhook功能，在push的时候向服务器post一个消息，服务器就屁颠屁颠自动去项目目录下执行git pull了。

有了自动部署，就可以专心修bug（关掉ssh终端而放心地出好多好多bug只管本地push不用费劲巴力ssh登录服务器像蠢狗一样这边push那边pull）了。

后事

后事不是gg了而是开发之后的事。大概就分为测试和发布了。

测试

我前前后后找了一些最近在聊天的人帮我测试，这种测试方式叫喊人测试。一般专业一些的互联网公司的技术团队都会有专门的测试人员，而测试人员们通常都会使用更专业一些的黑白盒和自动化测试之类的。我们喊人测试中最大的技术要点就是点点点测试。告诉他们可以体验我们的新功能，他们就会帮我们点点点，并告诉哪里有问题。

切记，这时候出现bug，不要引导用户向天花板大喊，这样我们会错过bug而导致发布的时候也有bug。

测试通过后就等待0点的到来，于是就到了我们激动人心的

发布

环节。

在发布环节我们将再次见到最开始的那张海报。

这样我们就告诉了一整个朋友圈我们发布了这个东西。一整个朋友圈是什么概念呢，就是一整个好友列表都知道了，神奇不神奇？如果要学习怎么发朋友圈，后面我可能会专门写一次文章来教学。

总结

数据

这玩意从发到朋友圈让一整个列表都知道了之后，到现在总共有

条数据。

快乐得一批。

所有参与的人（鸣谢|谢谢喃）

开发

前端：js兄弟

后端：啊你亲爱的彤彤姐

测试

本来一个下午就能做完的玩意，让我硬生生拖了半个月，像毕设一样。最离谱的是我还写了论文（本文）。真的是闲在家里，什么沙雕事都能干得出来。

要是当毕设做

• 下载你学校的封皮和模板

要是下载不到就问问学委能不能干了不能干就下班。

• 摘要

描述一下你为啥要做，还有大致要写的内容啥的。重要的是把字数凑够了。

再挑几个关键词出来。

随着xxx在市场上的推广，xx在中国乃至世界上的普及率日益增高，人们对xx的依赖性也日益增长。
在xxx时间，xx如何如何。
在xxx时间，xx如何如何。
在xxx时间，xx如何如何。
随着xxx时间的普及，xxx已经走进千家万户。
再夸一夸xxx的理念和优点。

本系统基于xxx技术。本论文基于此项目，从需求分析、产品设计、功能的编码与实现、系统测试等方面，按照在企业中一个项目的生命周期的顺序进行详细叙述。系统具有科学且严谨的架构，遵循软件工程基本原理，遵循一套详尽的代码格式要求。系统使用前后端分离开发的方式，在最大程度上降低了开发成本与系统复杂性，让一切问题都有迹可循，同时也提高了系统的性能，提高安全性，易于维护和操作。 

关键词：随便挑几个；差不多就行；三四个就够；四个不算多

• 翻译摘要

banana
apple
niubility
do you know google translate

• 目录

目录用word自带目录功能生成，不会就学。

• 引言

我到现在也没分清引言和摘要有啥区别，反正都是写一些套话，夸一夸这个东西哪好。

我的意思不是这里只能写套话，而是写套话也可以。

你要是会写论文就别看我在这胡诌八扯了，用你古灵精怪聪明伶俐的才能去自己写啊。

xxx已经成为了未来xxx的一种趋势，相比市场上现阶段流行的xxx，xxx具有什么什么优点。xxx的这种特点顺应时代的趋势，大大满足了用户的需求。 

随着xxx市场的不断完善，已经有大部分主流应用都入驻了xxx。而借助（夸时代好），xxx也得到了很好的引流。基于xxx进行开发，有如下优势： 

第一，可以提高程序的开发效率。夸它开发快。 

第二，很大程度上降低了用户的使用门槛。夸它。 

夸你项目的优点。
(当今市场上社交应用层出不穷，而大多应用都是微信、微博、贴吧等应用的子功能。但是这些巨头的应用也有其缺点，那就是不具有特异性。例如，贴吧上可以找到具有各种爱好的人，但是如果想要聚集更多喜欢某一个爱好的人，贴吧却受到其推广程度的限制以至于做不到。)

夸你需求设计得好
(随着人们生活质量的提升，旅行已经不是一种高成本的活动，同时旅行也已经被大众的价值观接受。这时旅行者们就需要一个平台可以来分享旅行见闻。市场上已经存在的每个平台上都有其他社交圈子上的朋友或者是亲友，将旅行见闻分享到这些通用的平台上，有的时候反而不会收获到期望中的成就感与满足感。 )

再说明你做这玩意为了啥，为了世界和平之类的。

• 需求分析

  • 用户需求分析

  先分析一下主流的同类竞品如何，再夸你这玩意有自己独特的点。

  • 需求列表

  把你要做的需求细分一下都列出来。

  （1）登录/注册 
  
  （2）设置用户基本资料（昵称、头像） 
  
  （3）按时间顺序查看帖子 
  
  （4）基于帖子进行互动（评论、回复评论） 
  
  （5）发送帖子 
  
  （6）查看我发送的帖子 
  
  （7）查看我参与过的帖子 
  
  （8）查看攻略 
  
  （9）进行系统设置 
  

• 开发工具及技术

  • 架构
  • 前端
  • 后端
  • 数据库
  • 缓存
  • 服务器
  • 代码版本管理
  • 开发工具

  有啥写啥，每项技术都介绍两句，不知道咋介绍的，把你这项技术打到百度上，随便抄两句，改改句子结构。

• 产品设计

  • 可行性分析

    • 经济可行性

    算算钱，计划一下钱够不够花。最后得出结论经济可行。

    不可行你还写啥论文，直接毕设题目都换了。

    本系统运行于xxx平台。服务器xx元/天。
    
    xxxxxxx
    
    综上，经济可行性得以论证，答案是可行的。 
    

    • 技术可行性

    再叨叨一遍你都用啥技术，再说技术可行，

  • 系统流程设计

  描述一遍用户打开你这玩意之后的操作流程，再画个流程图。流程图在课上应该学过，没学过就去翻翻书。

• 系统功能设计

建议在这个地方按照功能画原型图，显得很专业。不画原型图的话就按照功能一个一个描述它应该是什么样子。

原型图用墨刀或者axure画，实在不行就用windows画图也行。

• 用户用例图

要是没听过用例图，也去翻翻书。

• 开发准备

  挨个去描述你都怎么做的，一边打字一边截图，有理有据令人信服证据确凿百口莫辩。

  • 购买服务器
  • 购买域名
  • 设置解析
  • 安装git本地仓库
  • 设置自动部署
  • 上传初始代码到git仓库

• 数据库设计

  • 概念结构设计

  画ER图。

• 逻辑结构设计

将ER图转换为关系模式。

• 数据库物理实现

先跑去数据库建库建表，然后直接复制表结构的SQL。再加点废话，描述一下主键外键索引啥的。

在DBMS上，我们选择MySQL，配合PHP 5.3下的Thinkphp框架，可以发挥其最大的优势。 

创建数据表user，用于存储用户信息。其中id是主键，为用户表的索引行。openid是唯一字段，为微信提供的用户唯一id。执行语句： 

CREATE TABLE IF NOT EXISTS user ( 
  id int(11) NOT NULL AUTO_INCREMENT, 
  openid varchar(64) NOT NULL, 
  create_time varchar(25) NOT NULL, 
  change_time varchar(25) NOT NULL, 
  nickname varchar(25) NOT NULL, 
  usericon varchar(1024) NOT NULL, 
  sina varchar(255) NOT NULL, 
  PRIMARY KEY (id) 
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=6 ; 

上边说的两个图还有一系列数据库术语在数据库课应该都学过，要是没学过你就翻翻书。

• 编码开发

  反正就挨个写你都咋做的，别贴代码。

  • 发送验证码
  • 发送明信片
  • 读取明信片

• 软件测试

  夸一夸各种技术架构好用，然后把表格直接贴上就行了。

  都能写论文了说明项目早就过了测试，好使就完事了。

  • 功能测试

• 可用性测试

• 测试结果分析

在编写代码过程中，已经对致命性缺陷进行排除，但由于小程序方面的经验不足，写代码的过程中依然造成了许多缺陷。在反复地调试之后，将前后端成功地组装在了一起，完成了整个系统的编码开发。 

经过编码调试、功能测试、可用性测试，此程序可以满足用户的需求和要求，所有基本功能齐全，操作简单且友好，系统性能优良，可以完美运行于任何能运行微信的终端。 

• 结论

我也不知道咋编，反正就是编。夸你这玩意好使，还顺应时代需求，用户用得还爽。

• 参考文献

去搜几个跟你这一堆技术相关的书放上去，记得用参考文献标准格式。标准格式也能搜到。

• 附录

附录有没有都行，贴代码也行。

• 后记

写点煽情的话，感谢导师感谢学校啥的。