三月即将过去了，这意味着很多，比如，上市公司要开始准备第一季度的财报了；比如，2019年不知不觉已经过去1/4；比如，金三银四的跳槽季，你拿到满意的offer了吗？...

整个三月份，我大概做了一些事；

• 给阿里云服务器有续费了一年（整整去年涨了200RMB），完成了node、nginx、mongo配置
• 给个人域名续费了一年（做个个人站点）
• 苹果降价,购入了iMac（整体感觉写文档时比macbook爽）
• 基于个人的React组件库，做了个通用管理后台，并完善了React组件库
• 用React SSR方案做了我的个人网站
• ......其他的一些事，比如股票竟然没涨。kao

回到正题，写这篇文章是想跟记录和分享下搭建个人网站项目的过程。发了大概三个周末，外加15个的20:00 ~ 22:30 。

我想大概可以按下面几点来开始

王佳欣的小站​www.shuxia123.com

1. 个人网站的大概定位，为什么想做？
2. 技术选型，为什么用React SSR？
3. 服务端开发，接口怎么做才规范？
4. 接口测试，怎么完整的测试后台接口，为后续前端开发提高效率？
5. 后台系统开发，基于要我的组件库吗？
6. 前端页面开发，React服务端渲染联调，接口联调。
7. 为了用户体验，做了哪些事情？
8. 再讲讲其他的？

2019.03.31 13:41:30 先上线了....

一：个人网站定位，为什么想做呢？

网站以前端总结文章为主。写一些技术总结；一些读后感；尝试翻译英文文档；转载一些觉得不错的文章(会先取得作者同意)。

展示目前正在做的一些开源项目，代码还是托管在github上。

展示一些比较有趣的demo。

为什么想做呢？因为意识到时间很快，工作很忙，而离开学校后渐渐没有了写日记的习惯，每当年尾月末常常不得忆，需要有一个可以放"东西"的地方。

还有也是最重要的，就是最近我真的很闲....

第二：技术选型的问题，为什么用React SSR?

技术选型的话大概是这样的。

确定站点以响应式的形式展示。

服务器：nginx，用了阿里云windows server 2008，为什么不用linux？其实本来想用，无奈很久以前有一些数据用的SqlServer数据库。

服务端语言选型：Koa2.0 + Mongoddb

前端工程化，webpack4.0，实现：React + Redux + React-Router

发布：本地git push，服务器git pull 完成发布

采用SSR的原因是，考虑到要适配PC端和移动端，如果采用前后端分离的方案的话，会造成首次访问首屏的问题，这个问题在移动端，我们可通过添加Loading、占位符等方案处理，但是在PC端下屏幕比较大，问题会成倍放大，因为考虑做SSR服务端渲染。SEO？这个个人网站倒无所谓。

为什么用React呢？因为我的React组件库，自动16年用在公司几个项目上后，就很少再去优化了，18年年底升级到React16版本，我想借此机会看下它有什么问题，也看它还有什么欠缺，完善一下。

还有呢？我喜欢React，喜欢它组件分离；喜欢它的高阶组件式的装饰增强组件，实现依赖反转很好扩展；喜欢函数组件简洁的写法；喜欢它每个大版本都站在应用者的角度，给人很大的惊喜。

第三：服务端开发，接口怎么做才规范？

这次服务端的选型是，Koa2 + Mongodb。当然考虑过用关系型数据如MySql，毕竟更加熟悉，后面做了份表结构设计，发现其实挺简单的，基本上，可以不用到关联等操作。因此还是用Mongodb，我也想借此机会，看下以后扩展起来，文档型数据库，是否会难以下手。

如果说网站的前端页面是作品的长相，那么服务端开发和接口应该就是“柜子的背后了”。乔布斯他爸教导乔布斯，做为一名木匠，柜子的背面也是作品的一部分。所以，在这上面也发了比较多的精力。接口规范；数据返回规范；状态码规范等等。把以往和服务端人员配合时，疑惑的问题都考虑了进去。

接口规范方面采用了restful的规范，严格采用get、post、put、delete。这个在后续前端api层开发可以非常简洁；

// api接口允许的options有：[get、post、put、delete]
// 地址：http://www.shuxia123.com/services/classifies// 前端api层非常简单如下
import Base from './base';
class Classifies extends Base {constructor () {// 构造函数声明实体super('classifies');}fetch (param) {return this.request({});}fetchOne (id) {return this.request({ id });}create (param) {return this.request({ data: param, method: 'post' });}edit (id, param) {return this.request({ id, data: param, method: 'put' });}remove (id) {return this.request({ id, method: 'delete' });}
}export default new Classifies();

数据返回规范；如下

{"meta": {"code": 0,"msg": ""},"response": [{"id": 0,"name": "所有","path": "","total": 2}]
}
// meta放状态信息，错误信息等
// response放数据信息

状态码规范，制定了一些统一的状态码，这样前端开发的时候，可以根据状态码做信息提示。

.......

第四：接口测试

这次个人网站的搭建，我决定采取的方式是，先搭建服务端，开发好对应接口；然后，再开发前端页面。然后进行最后的联调。

考虑到，为了最大程度的提高后续前端接口调用调试的效率。因此，对接口进行了完成测试。

首先，分好模块，比如，文章模块、demo模块、开源模块、用户模块；

然后，选好测试工具，我用的是postman进行测试，在里面建好集合，按模块进行各个模块的测试。

我建立的测试集合大概是这样的，覆盖了所有主要的接口。

第五：后台系统开发

基于：React + Redex，组件库用自己的组件库。

其实，能做这个开源代码非常多，antd、ele、等等，甚至有很多git提供了完整的方案。

我呢，出于想完善下我的组件库的原因，做了一个决定，用我的组件库进行开发。坏处是，可能要发更多的时间写代码；好处是，我给组件库做了一些完善，比如，表单验证，比如，文档编辑器，比如，照片编辑器等等。

后台也是需要好好设计，我见过很多工作很久好几年的开发者，写出来的后台异常难用，这个在我这里是不能存在的，所以，也发了比较大的精力进行开发。结果比较满意，非常简洁，好用。好吧，可能我比较挑哈。

可以展示下界面（考虑后期开源哈）

第六：前端页面开发

这次的前端页面都是自己做的（连logo都是用css写的，毕竟ps技术不善于），风格也比较符合我。有借鉴了一些网站。比如详情页，是看了airbnb(大爱airbnb的体验)的页面。

然后就是具体开发了，这个也比较擅长，因为也比较简单，所以就不深入了。

更多的时间是发在在服务端渲染后，和react首次挂载时，如何考虑性能，避免不必要的请求浪费。

第七：用户体验

做了比较多的考虑。

loading采用什么形式？

试过了很多loading效果后，决定采用骨架图，好处是再数据没有出来前可以用骨架图占住和数据一致的图案，这样比采用普通的loading造成的视觉冲突小。

因为本地的接口请求太快了，造成了闪屏，骨架图没出现的情况。为了能体现出骨架图的效果，在前端对接口层做了统一的处理，既接口请求小于600ms的，等待到了600ms后再resolve这样效果比较同意。为什么是600ms？试了很多次，觉得它很合适。等真实到线上后，可能需要再调优一次。

图片加载，怎么优化？

图片怎么加载呢？一般的做法是懒加载可视区域的图片。但这次我想做一些不一样的，因为这次服务端是自己开发，图片上传存储也是自己开发，所以可以完全按照我的想法进行。

比如：3241234_w_500_h_300.jpg，对应的存储的预览图未：3241234_w_500_h_300_preview.jpg。

这样在服务端渲染时，可以通过正则替换的形式，替换文档内的图片路径优先加载预览图。

以往做懒加载，大概可以保证用户的需求。这次我的做法是，在上传图片的时候同时保持两张图片，一张原尺寸，一张宽度20px的小图片，同时存储是命名采用“时间戳_w_[width]_h_[height].[ext]”，这样我从图片名称就可以利用正则匹配出图片的宽度高度，在加载时，采用先加载20px小图（按原图尺寸展示），这样可以做到模糊加载的效果。最终效果也比较符合我的想法。

路由间切换要不要做过渡动画？

原本有考虑，PC端因为屏幕比较大，实现后发现，动画动画很大，因此放弃，移动端做了渐入的效果。

怎么提高阅读体验？

文章原本用了统一的背景，后来发现很死板，因此直接用封面预览图(20px)做模糊背景，实现起来效果还是很不错的。

因为，文章大部分会涉及到代码展示，所以支持在服务端渲染的时候支持了下代码高亮显示。

预览图加载时，为了让用户看到预览图的时候，不会觉得没有在加载，因此，做了0.1 ->0.5透明度的animation动画。

滚动条滚动时，让背景和导航栏都变得更模糊(根据滚动范围做0.35->0.8的透明度递增)，让内容更突显，突出主要内容。

第八：讲讲其他的

接下来打算做PWA，做离线状态下的缓存，因此，会利用阿里云的https部署https服务。这是后话了。

另外，部署方面，目前主要通过git push的推代码，服务器 git pull拉取代码进行发布。接下来需要考虑如何优化这个流程。

服务器运维方面的知识也需要加强下，毕竟大概三四年没用过windows系统了。

目前小实验室和开源项目两个模块，只简单的实现了链接的存储，没有实现项目的结算，后续时间充足的话会逐步完善这两块。

体验完善，这个版本制作了很基本的体验考虑，接下来会根据用户的反馈，逐步做更好的用户体验优化。

说一些最近的感想，最近有在看机会，有没通过的，也有通过后我婉拒的。

说下没通过的吧，暴露了我一个很大的问题，因为本身是闽南人说以口音有点重；然后是，复述和表述能力不强，很多时候，没办法把我的想法很完整清晰的传递给对方，尤其是复述技术原理这种抽象画的话题。这方面我的确要加强。

我婉拒的，无非两点；第一，有的面试官会讲很多他们自己的技术团队、产品，很能讲，让你觉得好像很强，然后你回家打开他们的官网、产品，或者他们的git源码，体验非常rubbish，最后觉得如果你进入了，可能没办法适应他们的无规范，便罢了，在我看来产品体验很重要，我们应该对用户负责。第二，给的岗位不太合适的，我目前还比较有技术激情，所以，我比较偏向开发岗位比重较大的岗位，因为在厦门所以多小厂，小厂很多需要你去发很多精力去处理其他的事情。

总之，写好代码吧。

王佳欣的小站​www.shuxia123.com